STA and method executed by STA

Abstract

A station (STA) and a method performed by the STA are disclosed. The method includes receiving a frame including a broadcast service element from a transmitting STA, the broadcast service element including one or more fields associated with an enhanced broadcast service (eBCS) traffic flow that may be provided by the STA, the field comprises an identifier associated with one of the eBCS traffic flows, a field indicating whether a negotiation with the transmitting STA is required to receive data of one of the eBCS traffic flows, and scheduling information for receiving a broadcast transmission comprising the data of one of the eBCS traffic flows; and receiving, based on the scheduling information, the broadcast transmission of the data comprising the identifier associated with the one of the eBCS traffic flows and the one of the eBCS traffic flows.

Description

[0001] This application is a divisional application of Chinese invention patent application filed on February 28, 2020, with application number 202080028587.0 and invention title "Method for WUR Scanning and WTRU".

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 811,967, filed on February 28, 2019, the entire contents of which are incorporated herein by reference. Background Technology

[0004] Fixed or low-mobility wireless communications in local area networks (LANs) utilize technologies such as IEEE 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ax, 802.11be, or commonly 802.11x (often also known as WiFi). These technologies involve media 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 in the same transmissions used for multiple types of WLAN interfaces to achieve desired performance and spectral efficiency. Summary of the Invention

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

[0006] A wireless transmit / receive unit (WTRU) is disclosed. The WTRU includes: a processor configured to generate a request primitive that enables a WRU scanning process 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 process based on the plurality of first parameters; at a MAC layer, generate at least one acknowledgment primitive based on the result of the WUR scanning process and at least a portion of the plurality of first parameters; and transmit the at least one acknowledgment primitive from the MAC layer to a station management entity (SME). Attached Figure Description

[0007] The invention can be understood in more detail from the following description given by way of example in conjunction with the accompanying drawings, wherein like reference numerals denote like elements, and wherein:

[0008] Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments;

[0009] Figure 1B The embodiment illustrates that it can be used Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system.

[0010] Figure 1C The embodiment illustrates that it can be performed... Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown.

[0011] Figure 1D The embodiment illustrates that it can be performed... Figure 1A The system diagram shows another example RAN and another example CN used within the communication system shown;

[0012] Figure 2A This is a flowchart illustrating a method according to an embodiment of this application;

[0013] Figure 2B This is a flowchart illustrating a method according to another embodiment of this application;

[0014] Figure 3 An example design of a downlink (DL) broadcast element is shown;

[0015] Figure 4 An example design of an uplink (UL) broadcast element is shown;

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

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

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

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

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

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

[0022] Figure 11 An example power-saving process with xIFS interframe intervals between BCS repetitions is shown;

[0023] Figure 12 An example of a power-saving process with specific timing differences between repetitions is shown;

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

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

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

[0027] Figure 16 An example of multi-AP broadcasting with a space transmission diversity scheme is shown;

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

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

[0030] Figure 19 An example process is shown where the AP provides downlink (DL) feedback that identifies a portion of the lost data. Detailed Implementation

[0031] Figure 1AThis diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables 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 Extended OFDM (ZT-UW DTS-S OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0032] like Figure 1A As 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 should be understood that any number of WTRUs, base stations, networks, and / or network elements are contemplated in the disclosed embodiments. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 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 processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any WTRU 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE. It should be noted that, in this application, unless otherwise stated, the terms "WTRU" and "STA" are used interchangeably.

[0033] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, e-node Bs (eNBs), home node Bs, home e-node Bs, next-generation node Bs (such as g-node Bs (gNBs)), new radio (NR) node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0034] Base station 114a may be part of RAN 104, and may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of 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, i.e., one transceiver per sector of the cell. In embodiments, 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.

[0035] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

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

[0038] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0039] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE radio access and NR radio access. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to or from various types of base stations (e.g., eNBs and gNBs).

[0040] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0041] Figure 1A Base station 114b can be, for example, a wireless router, home node B, home e node B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114b does not need to access the Internet 110 via CN 106.

[0042] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 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. CN 106 can provide call control, billing services, location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs using the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0045] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 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 peripheral devices 138, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0046] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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. Processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0047] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0049] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0050] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from any type of suitable memory and store data in said memory, such as non-removable memory 130 and / or removable memory 132. 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. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory and store data in memory that is not physically located on WTRU 102, such as on a server or home computer (not shown).

[0051] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 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.

[0052] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116, and / or determine its location based on the timing of signals received from two or more neighboring base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0053] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0054] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes 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 (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) are concurrent and / or simultaneous.

[0055] Figure 1C This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0056] RAN 104 may include eNodeBs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. eNodeBs 160a, 160b, and 160c may each include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNodeB 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0057] Each of eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, nodes B160a, 160b, and 160C can communicate with each other via the X2 interface.

[0058] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of 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.

[0059] The MME 162 can connect to each of the eNodeBs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0060] The SGW 164 can connect to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available for WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

[0061] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as the Internet 110, to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0062] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0063] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is anticipated that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0065] In an Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic originating from a STA outside the BSS can reach and be delivered to the STA via the AP. Traffic originating from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP; for example, a source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be transmitted between a source STA and a destination STA (e.g., directly between the source and destination STAs) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to here as an "ad-hoc" communication mode.

[0066] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, 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 particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0068] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels; this is known as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0069] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (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 may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0070] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the 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 one of the STAs operating in the BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, for a STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC-type device), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available bands remain idle.

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

[0072] Figure 1DThis diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0073] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c includes one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0075] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without needing to access other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, and one or more eNodeBs 160a, 160b, and 160c. In a non-standalone configuration, eNodeBs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0076] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing user plane data toward User Plane Functions (UPF) 184a and 184b, routing control plane information toward Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0077] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of 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.

[0078] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c according to the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (e.g., LTE, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0079] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0080] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. This provides WTRU 102a, 102b, and 102c with access to packet-switched networks such as the Internet, facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and so on.

[0081] CN 106 can facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or may communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0082] Given Figure 1A-1D and Figure 1A-1D As described herein, one or more of the functions described herein with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any (one or more) other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0083] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or perform tests using over-the-air wireless communication.

[0084] One or more emulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test rigs. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0085] 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 (QoS) for all user experiences across wide-spectrum wireless users in numerous use cases, including high-density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. The HEW SG is considering new use cases supporting dense deployments of APs and STAs, as well as associated Radio Resource Management (RRM) technologies. Potential applications for HEW include emerging use cases such as data delivery for stadium events, high-user-density scenarios such as train stations or enterprise / retail environments, evidence of increasing reliance on video delivery, and wireless services for medical applications. Based on the results developed in the HEW SG, the IEEE Standards Committee approved the IEEE 802.11ax Task Group (TG).

[0086] At the TGax standards conference, several contributions demonstrated the high probability of short packet usage for measurement services in various applications, and the existence of network applications that can also generate short packets. These applications include: virtual offices; TPC ACK; video streaming ACK; devices / controllers (e.g., mouse, keyboard, game controls, 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. Mechanisms for designing and defining UL random access for different purposes can be used in 802.11ax and other protocols.

[0087] The TGax proposals regarding media access issues in the 6 GHz band include using triggered or scheduled media access only in the 6 GHz band, and / or restricting Active Scan and Scheduled Enhanced Distributed Channel Access (EDCA) media access in the 6 GHz band.

[0088] The IEEE 802.11ba TG was created to define physical (PHY) and media access control (MAC) modifications to provide enhanced low-power operation for 802.11 devices. These MAC and PHY modifications enable the operation of the Wake-Up Radio (WUR). The expected operating bands for the WUR include 2.4 GHz and 5 GHz, and can extend below 1 GHz. The WUR device can operate as a companion radio to the Primary Connected Radio (PCR) used for transmitting regular 802.11 packets. The PCR can also be referred to as the primary radio. The WUR can transmit packets carrying control information (only) and can have an effective receiver power consumption of less than one milliwatt (mW). Receiving wake-up packets via the WUR can wake the Primary Connected Radio (PCR) from sleep mode. In this example, the WUR can have a range at least the same as that of the Primary Connected Radio operating over a payload bandwidth of at least 20 MHz.

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

[0090] The IEEE 802.11bc TG was created to define MAC modifications for Enhanced Broadcast Service (eBCS) on 802.11 devices. These IEEE 802.11bc modifications may not affect the IEEE 802.11 PHY specification. eBCS service can be provided in the DL direction from the AP to a non-AP STA, or in the UL direction from a sensor non-AP STA. eBCS can be provided to STAs associated with or unassociated with a specific AP. It is expected that an AP can support up to 3000 non-AP STAs with eBCS service. Additionally, there may be a class of low-cost non-AP STAs that consume eBCS service 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 multilingual broadcasting; and / or event producer information and content broadcasting.

[0091] 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 decoding, the content of the transmitted frame can be derived from multiple sets of coded bits, which are typically transmitted in separate frames but are generated (e.g., using linear coding over additional increments) to form new subframes that can be transmitted to aid decoding. This allows broadcast signals to be transmitted to all receiving WTRUs (STAs) with rate matching in an incremental form for increased reliability, allowing for smooth changes in code rate. The encoders used are typically rate-compatible codes, where for any two code rates R > R', a rate R' frame is a concatenation of rate R frames and additional redundant bits.

[0092] WUR scanning is agreed upon by 802.11ba devices. During a WUR scan, an AP can send a WUR discovery frame, which provides information about itself and its BSS. A WUR-capable WTRU can scan the WUR discovery frame to discover suitable APs and BSSs for association. However, MAC Layer Management Entity (MLME) primitives may need to be defined to enable the WTRU to initiate a WUR scan and / or provide collection information about received WUR discovery frames to higher layers. Appropriate MLME primitives can be defined to allow the WTRU to control the WUR scan process and provide information about received WUR discovery frames collected during the WUR scan process to higher layers. It should be noted that, unless otherwise stated, the terms WUR scan and WUR scan process are used interchangeably.

[0093] To address the aforementioned problems, the method and WTRU described in this application are as follows.

[0094] The following will refer to Figure 2A Method 200 according to an embodiment of this application is described. Figure 2A A flowchart of method 200 is shown. (See attached diagram.) Figure 2A As shown, method 200 may include: at 201, generating a request primitive by a station management entity (SME) that enables a WUR scan process for wake-up radio (WUR) discovery frames transmitted by one or more access points (APs), the request primitive including a plurality of first parameters; at 202, performing the WUR scan process based on the plurality of first parameters; at 203, generating at least one acknowledgment primitive at the media access control (MAC) layer based on the result of the WUR scan process and at least a portion of the plurality of first parameters; and at 204, transmitting the at least one acknowledgment primitive from the MAC layer to the SME.

[0095] Therefore, the WTRU according to an embodiment of this application may include: a processor configured to generate a request primitive that enables a Wake-up Radio (WUR) scanning process 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 process based on the plurality of first parameters; generating at least one acknowledgment primitive at the MAC layer based on the result of the WUR scanning process and at least a portion of the plurality of first parameters; and transmitting at least one acknowledgment primitive from the MAC layer to the SME.

[0096] The following description will detail the process at point 201.

[0097] The request primitive can be an MLME primitive, which can be defined and used for WUR scans. In an embodiment, the request primitive can be an MLME-WURSCAN request primitive (MLME-WURSCAN.Request primitive). For example, a WUR scan can be initiated by an MLME primitive, such as the MLME-WURSCAN request primitive. This MLME primitive can request an investigation of a potential BSS via a WUR discovery frame, which the WTRU can 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" are used interchangeably. The parameters in the request primitive (e.g., the MLME-WURSCAN request primitive) will be described below with reference to detailed embodiments.

[0098] In another embodiment, the request primitive may be an MLME-SCAN request primitive (MLME-SCAN.Requestprimitive) or a part of an MLME-SCAN request primitive. The parameters in the MLME-SCAN request primitive may be similar to those in the MLME-WURSCAN request primitive, and the parameters in the MLME-SCAN request primitive will be further described below. In this application, unless otherwise stated, the terms "MLME-SCAN request primitive," "MLME-SCAN request," and "request primitive" are used interchangeably. The parameters in the request primitive (e.g., the MLME-WURSCAN request primitive) will be described below with reference to detailed embodiments.

[0099] In this embodiment, the request primitive can be generated by the Station Management Entity (SME). For example, the MLME-WURSCAN request primitive can be generated by the SME so that the WTRU uses its WUR or low-power WUR mode to determine the presence of other BSSs it can join. In this embodiment, the request primitive can be generated by the processor.

[0100] The Wake-up Radio (WUR) scanning process for WUR discovery frames transmitted by one or more APs is a scanning process in which the WTRU scans and thus discovers the appropriate APs and BSSs for association. The WTRU scans and discovers WUR discovery frames transmitted from APs. WUR discovery frames may include various fields such as SSID, compressed BSSID, channel information, etc.

[0101] Request primitives can include multiple first parameters. The plurality of first parameters may include at least one of the following: Basic Service Set Identifier (BSSID), BSSID List, Service Set Identifier (SSID), SSID List, Compressed BSSID, Compressed SSID, Compressed BSSID List, Compressed SSID List, Discovery Channel, Discovery Channel List, Minimum Discovery Channel Time, Maximum Discovery Channel Time, Received Power Threshold, Maximum Scanning Time, WUR Scanning Reporting Period (or WUR Scanning Reporting Time), WUR Scanning Mode, WUR Scanning Reporting Option, or Request WUR Result. The following sections will describe the above parameters one by one.

[0102] A BSSID can indicate the BSSID of a desired AP or a desired BSS. In an embodiment, a BSSID can identify a basic service set as a 48-bit tag conforming to the MAC-48 convention. A BSSID can be a wildcard BSSID (e.g., ff:ff:ff:ff:ff:ff:ff). In an embodiment, there can be only one BSSID in a request primitive. In another embodiment, there can be multiple BSSIDs in a request primitive. One or more BSSIDs can be included in a BSSID list. In other words, a BSSID list can contain information about one or more BSSIDs. For example, a BSSID list can be a list containing multiple BSSIDs, where each BSSID can 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 limiting of this application. Any variations of the above embodiments of BSSIDs and BSSID lists can also be applied to the method and WTRU according to this application, as long as they help to implement the principles of this application.

[0103] An SSID can be a service set identifier for a desired AP, BSS, or SS. That is, an SSID can indicate the service set that the WTRU may expect to connect to. An SSID can be a wildcard SSID. In one 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 can be included in an SSID list. In other words, an SSID list can contain information about one or more SSIDs of a desired AP or BSS. For example, an SSID list can be a list containing multiple SSIDs, where each SSID can indicate the desired service set of the AP or BSS. Although some examples of SSIDs and SSID lists have been described above, they are not intended to be exclusive or limiting of this application. Any variations of the above embodiments of SSIDs and SSID lists can also be applied to the method and WTRU according to this application, as long as they help to implement the principles of this application.

[0104] A CompressedBSSID can indicate a compressed BSSID of a desired AP or BSS, which the WTRU may expect to be associated with. In an embodiment, a CompressedBSSID can be a partial BSSID. A CompressedBSSID can be associated with a wildcard BSSID. An associated CompressedBSSID can be calculated based on the provided BSSID. In an embodiment, there may be only one CompressedBSSID in a request primitive. In another embodiment, there may be multiple CompressedBSSIDs in a request primitive. One or more CompressedBSSIDs can be included in a CompressedBSSIDList. In other words, a CompressedBSSIDList can contain one or more compressed BSSIDs of a desired AP or BSS. For example, a CompressedBSSIDList can be a list containing multiple compressed BSSIDs, where each compressed BSSID can indicate a desired BSS or AP. Although some examples of CompressedBSSIDs and CompressedBSSIDLists have been described above, they are not intended to be exclusive or limiting of this application. Any variations of the above embodiments of CompressedBSSID and CompressedBSSIDList can also be applied to the method and WTRU according to this application, as long as they help to achieve the principles of this application.

[0105] DiscoveryChannel can indicate a channel or WUR channel on which discovery frames (e.g., WUR discovery frames) can be scanned during a WRU scan. In one embodiment, there may be only one DiscoveryChannel in the request primitive. That is, discovery frames can be scanned on the specific channel indicated by that DiscoveryChannel. In another embodiment, there may be multiple DiscoveryChannels in the request primitive. That is, discovery frames can be scanned on multiple channels indicated by these DiscoveryChannels. One or more DiscoveryChannels can be included in a DiscoveryChannelList. In other words, DiscoveryChannelList may contain information about one or more DiscoveryChannels. For example, DiscoveryChannelList may be a list containing multiple DiscoveryChannels, each of which can indicate a channel or WUR channel on which discovery frames (e.g., WUR discovery frames) can be scanned to discover the desired AP(one or more) or BSS(one or more) discovery frames. If the MLME-WURSCAN request primitive includes one or more WURDiscoveryChannels or WURDiscoveryChannelLists, the WTRU may tune to only 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 limiting of this application. Any variations of the above embodiments of DiscoveryChannels and DiscoveryChannelLists can also be applied to the methods and WTRUs according to this application, as long as they help to implement the principles of this application. It should be noted that, unless otherwise indicated, channels, WUR channels, and discovery channels can be used interchangeably.

[0106] MinDiscoveryChannelTime can indicate a minimum time, expressed in units of time (TU) or other units, for the WTRU to perform a WUR scan on each of the channels indicated by one or more DiscoveryChannels in the DiscoveryChannelList. MinDiscoveryChannelTime can be determined based on the expected WUR discovery period of one or more APs, BSSs, or SSs. The WUR discovery period can be prior 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 limiting of this application. Any available value of MinDiscoveryChannelTime can also be applied to the method and WTRU according to this application, as long as they help to achieve the principles of this application.

[0107] MaxDiscoveryChannelTime can indicate the maximum time, expressed in TU or other units, for the WTRU to perform a WUR scan on each of the channels indicated by one or more DiscoveryChannels in the DiscoveryChannelList. MaxDiscoveryChannelTime can be determined based on the expected WUR discovery period of one or more APs, BSSs, or SSs. The WUR discovery period can be prior 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 limiting of this application. Any available value of MaxDiscoveryChannelTime can also be applied to the method and WTRU according to this application, as long as they help to achieve the principles of this application.

[0108] ReceivedPowerThreshold indicates a threshold for the received power, above which one or more discovery frames (e.g., WUR discovery frames) are processed. That is, during a WUR scan, only one or more discovery frames with a received power greater than ReceivedPowerThreshold can be processed. During a WUR scan, one or more discovery frames with a received power lower than ReceivedPowerThreshold can be ignored. In embodiments, ReceivedPowerThreshold can be defined based on the Received Channel Power Indicator (RCPI), Received Signal Strength Indicator (RSSI), Signal-to-Noise Ratio (SNR), and / or 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 limiting of this application. Any available value of ReceivedPowerThreshold can also be applied to the method and WTRU according to this application, as long as they help to achieve the principles of this application.

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

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

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

[0112] The WURScanningReportingOption can indicate how the results of the WUR scan process should be reported. In other words, the option for reporting the results of the WUR scan process can be indicated by the 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," then 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 scan process can be provided or reported. The above options for reporting the results of the WUR scan process will be further described below with reference to detailed embodiments. Although the WURScanningReportingOption and its exemplary values ​​have been described below, they are not intended to be exclusive or limiting of this application. Any available values ​​of the WURScanningReportingOption may also be applied to the method and WTRU according to this application, as long as they help to achieve the principles of this application.

[0113] RequestResults indicates the current result of the WUR scan process being requested and should be provided by issuing a confirmation primitive (e.g., the MLME-WURSCAN confirmation primitive (MLME-WURSCAN.confirm primitive)).

[0114] The various first parameters that can be included in a request primitive have now been described. It should be noted that the first parameters described above are given by way of example only and are not intended to be exclusive or limiting of this application. Any available parameters may be included in the request primitive, as long as they contribute to the implementation of the principles of this application.

[0115] The following sections will describe the process at 202 in detail. As described above, method 200 may include: at 202, performing a WUR scan process using WUR based on a plurality of first parameters.

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

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

[0118] If the value of the WURScanningMode parameter is "WUR scan only", the WUR scan process can be initiated solely as a WUR scan. In this case, for example, the WTRU can turn off its main radio and / or perform a WUR scan only in low-power WUR mode, while the WTRU may not perform any other type of operation.

[0119] If the WURScanningMode parameter is set to "Simultaneous with Regular Scan" or "Simultaneous with Passive / Active Scan," then the WUR scanning process can be performed as a simultaneous discovery process along with regular scanning, active scanning, or passive scanning, as indicated by the WURScanningMode parameter. For example, the WTRU can use its WUR to scan for WUR discovery frames in low-power WUR mode, while simultaneously performing passive or active scanning, for example, using a PCR or master radio.

[0120] As mentioned above, different WUR scan modes can be selected based on the WURScanningMode parameter. It should be noted that a WUR scan process may not be the only scan process executed by the WTRU within a given time period. That is, the WTRU can simultaneously execute non-WUR scan processes (such as active scan processes, passive scan processes, etc.) and WUR scan processes.

[0121] In another embodiment, the request primitive may be an MLME-SCAN request primitive or a part of an MLME-SCAN request primitive. In the example, the WUR scan process may be initiated by an MLME-SCAN request primitive, which may include one or more WUR scan parameters. For example, any of the following parameters may 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 may be as described herein, and the process for initiating a WUR scan may be similar to that described herein. Detailed descriptions of these parameters may be similar to those described with reference to the MLME-WURSCAN request primitive. Therefore, detailed descriptions of these parameters will be omitted. The terms MLME-WURSCAN and MLME-SCAN can be used interchangeably (e.g., by the names of primitives such as MLME-SCAN request, MLME-SCAN confirmation, MLME-WURSCANSTOP request and / or MLME-WURSCANSTOP confirmation).

[0122] The following description will describe the process at 203. As described above, method 200 may include: at 203, generating at least one confirmation primitive based on the results of the WUR scan process and at least a portion of a plurality of first parameters.

[0123] 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 determination 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. As 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 at least one confirmation primitive have been described above, they are not intended to be exclusive or limiting of this application. In some embodiments, the terms "MLME-SCAN confirmation primitive," "MLME-WURSCAN confirmation primitive," and "confirmation primitive" may be used interchangeably.

[0124] The at least one confirmation primitive can 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, at least one confirmation primitive can be generated based on the result of the process at 202, i.e., the result of the WUR scan process. On the other hand, at least one confirmation primitive can 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 following description will describe in detail the portion of the plurality of first parameters used to determine the confirmation primitive. In the following description, unless otherwise indicated, confirmation primitives and MLME-WURSCAN confirmation primitives may be used interchangeably.

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

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

[0127] If the value of WURScanningReportOption is "Channel_Specific", the MLME-WURSCAN acknowledgment primitive can be generated after a specific WUR discovery channel has scanned 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 can be one or more WUR discovery channels indicated in the MLME_WURSCAN request.

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

[0129] If the value of WURScanningReportingOption is “At_End”, then after a WUR scan is completed on one or more WUR discovery channels, an MLME-WURSCAN acknowledgment primitive can be published at the end of the current WUR scan process, which can be indicated in the MLME-WURSCAN request primitive.

[0130] If the value of WURScanningReportionOption is "Periodic" or "At_Time", the MLME-WURSCAN acknowledgment primitive can be generated in each cycle or at a certain time, as indicated in the MLME-WURSCAN request primitive.

[0131] In an embodiment, a 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 acknowledgment primitive can 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 acknowledgment primitive and the above(one or more) parameters, i.e., how the MLME-WURSCAN acknowledgment primitive is generated based on the value of at least one(one or more) of the above parameters.

[0132] For example, if a WUR discovery frame with a matching SSID, BSSID, compressed SSID, or compressed BSSID has been received, an MLME-WURSCAN acknowledgment primitive can 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), an MLME-WURSCAN acknowledgment primitive can be generated if a WUR discovery frame with a matching compressed SSID or a matching compressed BSSID is received. For example, if in a 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, a matching compressed BSSID may exist, and an MLME-WURSCAN acknowledgment primitive can then be generated. If the MLME-WURSCAN request includes one or more of CompressedBSSID, CompressedSSID, CompressedBSSIDList, and CompressedSSDList, then only the BSS with a matching CompressedBSSID or CompressedSSID (or a portion thereof) can be reported.

[0133] In an embodiment, a portion of the plurality of first parameters may include the ReceivedPowerThreshold parameter. That is, the MLME-WURSCAN acknowledgment primitive can be generated based on the value of ReceivedPowerThreshold. For example, if the MLME-WURSCAN request primitive includes ReceivedPowerThreshold, then the MLME-WURSCAN acknowledgment primitive can be generated only for BSSs whose WUR discovery frames have been received by the WTRU at a receive power greater than the given ReceivedPowerThreshold. That is, if the receive power of the WUR discovery frame is greater than the given ReceivedPowerThreshold, then one or more BSSs that transmitted the WUR discovery frame can be reported by the MLME-WURSCAN acknowledgment primitive.

[0134] The following description describes the content of the confirmation primitives according to this application. Confirmation primitives (e.g., MLME-WURSCAN confirmation primitives) can be used to return a description of the set of BSSs detected by a WUR scanning process (e.g., by receiving one or more WUR discovery frames). In an embodiment, multiple MLME-WURSCAN confirmation primitives can be generated when the value of WURReportingOption is “Channel_Specific”, “At_Request”, “Periodic”, or “At_Specified_Time”. In another embodiment, a single MLME-WURSCAN confirmation primitive can be generated.

[0135] In an embodiment, at least one confirmation primitive may be generated, and each of the at least one confirmation primitive may include a plurality of second parameters. The plurality of second parameters may include at least one of the following: a BSS description (BSSDescriptionFromWURDFSet) from the WUR set, a result code (ResultCode), a scanned WURDiscoveryChannelList (ScannedWURDiscoveryChannelList), or vendor-specific information (VendorSpecificInfo). The BSSDescriptionFromWURDFSet parameter may exist if dot11WUROptionImplemented (implemented dot11WUR option) or dot11WURActivated (activated dot11WUR) is true. The following description will describe the aforementioned second parameters in the confirmation primitive in detail.

[0136] In this embodiment, the validation primitive may contain one or more BSSDescriptionFromWURDFSets. Each BSSDescriptionFromWURDFSet may consist of one or more parameters, such as the example parameters shown in Table 1.

[0137]

[0138] Table 1 Parameters of BSSDescriptionFromWURDFSet

[0139] The ResultCode can have at least one of the following example values: SUCCESS, INTERMEDIATE_SCAN_RESULT, NOT_SUPPORTED, PARTIAL_WURSCAN, PERIODIC_SCAN_RESULT, and REQUESTED_SCAN_RESULTS. In all these example values, "SCAN" can be replaced with "WURSCAN" to clarify that the result is a WUR scan result. The value of ResultCode can depend on the reason the MLME-WURSCAN confirmation primitive was issued. The following description details the above example values ​​of ResultCode.

[0140] If the WUR scan process has been successfully executed, SUCCESS can be used. If the WURReportingOption parameter in the MLME-WURSCAN request primitive is Channel_Specific or Immediate, INTERMEDIATE_SCAN_RESULT can be used. If not all WUR discovery channels have been scanned, the ResultCode value can be set to PARTIAL_SCAN. If the WURReportingOption parameter in the MLME-WURSCAN request primitive is Periodic or At_Requested_Time, the ResultCode value can 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 can be set to REQUESTED_SCAN_RESULTS.

[0141] It should be noted that the example values ​​of ResultCode given above are given by way of example only, and they are not intended to be exclusive or limiting of this application. Any available values ​​of ResultCode may be applied to the methods and WTRU according to this application, as long as they help to implement the principles of this application.

[0142] ScannedWURDiscoveryChannelList can contain a list of WUR discovery channels that have been scanned.

[0143] In embodiments, WUR SCAN results may be reported by or as part of an MLME-SCAN confirmation primitive. That is, an MLME-SCAN confirmation primitive can be used to return a description of the BSS or AP set detected during the WUR scan process (e.g., by receiving one or more WUR discovery frames). Multiple MLME-SCAN confirmation primitives can be published when the value of WURReportingOption is “Channel_Specific”, “At_Request”, “Periodic”, or “At_Specified_Time”. Otherwise, a single MLME-SCAN confirmation primitive can be published. An MLME-SCAN confirmation primitive may include any of the following example parameters: BSDescriptionFromWURDFSet, ResultCode, ScannedWURDiscoveryChannelList, or VendorSpecificInfo. These example parameters may be the same as or similar to those described with reference to the MLME-WURSCAN confirmation primitive. Therefore, detailed descriptions 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. Therefore, unless otherwise stated, the terms MLME-SCAN request and MLME-WURSCAN request are used interchangeably; the terms MLME-SCAN confirmation and MLME-WURSCAN confirmation 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 confirmation," "MLME-WURSCAN-STOP confirmation primitive," "MLME-SCAN-STOP confirmation," "MLME-SCAN-STOP confirmation primitive," and "stop confirmation primitive" are used interchangeably.

[0144] Following process 203, method 200 will proceed to process 204, namely, transmitting at least one acknowledgment primitive from the MAC layer to the SME.

[0145] The following will be referenced Figure 2B This application describes the method and WTRU according to a second embodiment. (As...) Figure 2B As shown, the process from 201 to 204 is similar to the above reference. Figure 2B The processes described are similar or identical. The difference between the first and second embodiments lies in... Figure 2B The illustrated method 200 includes steps 205 through 207. More specifically, method 200 further includes: at 205, detecting whether a stop request primitive for stopping the WUR scan process has been generated, wherein if a stop request primitive has been generated, method 200 further includes: at 206, stopping the WUR scan process; and at 207, generating a stop confirmation primitive. The stop primitive may be generated before the first confirmation primitive has been generated.

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

[0147] In another embodiment, the stop request primitive can be a WUR-SCAN-STOP request primitive or part of a WUR-SCAN-STOP request primitive. The WUR-SCAN-STOP request primitive can be used to terminate any ongoing WUR scan process. The WUR-SCAN-STOP request primitive can include one or more parameters, such as ScanType. As described above, WTRU can perform multiple scan processes simultaneously (e.g., both WUR scan processes and non-WUR scan processes). The ScanType parameter can indicate the type(s) of scan(s) that the primitive can terminate. The ScanType parameter can have any of the following values: WUR_Scan, Non-WUR_Scan, and All_Scan. If ScanType is WUR_Scan, all ongoing WUR scan processes can be terminated. If ScanType is Non_WUR_Scan, non-WUR scan processes, including passive and active scan processes, can be terminated. If ScanType is All_Scan, all ongoing scanning processes can be terminated, including WUR scans and non-WUR scans (e.g., active and passive scans).

[0148] If a stop request primitive has been generated, then at 206, the corresponding scan(s) can be terminated based on that stop request primitive. That is, if the WTRU or its processor receives a stop request primitive, the corresponding scan(s) identified by that stop request primitive can be terminated.

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

[0150] In a first embodiment, the stop confirmation primitive can be the MLME-WURSCAN-STOP confirmation primitive, which can 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 can be the MLME-Scan-Stop confirmation primitive or a portion thereof. The MLME-Scan-Stop confirmation primitive can be used similarly to the MLME-WURSCAN-STOP confirmation. In a third embodiment, the stop confirmation primitive can be either the MLME-WURSCAN confirmation primitive or the MLME-SCAN confirmation primitive described above. That is, the MLME-WURSCAN confirmation primitive or the MLME-SCAN confirmation primitive can be used for the same purpose as the MLME-WURSCAN-STOP confirmation.

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

[0152] Broadcast service support for unassociated WTRUs is required. Furthermore, uplink broadcast service is required in the current WLAN standard. The system needs to be designed to support downlink broadcast services for unassociated WTRUs or for WTRUs that only receive and cannot transmit. Additionally, uplink broadcast from a WTRU to one or more APs needs to be designed. 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.

[0153] This document describes a mechanism for broadcast service support according to this application. A WTRU (e.g., an AP or non-AP STA) with dot11eBCS SIimplemented and / or dot11eBCSActivated may include an eBCS element in its beacon or in probe request / response and / or reassociation request / response frames transmitted by the WTRU. In one example, the eBCS element may be included in uplink (UL) and / or downlink (DL) broadcast messages. In another example, a UL eBCS element may be included in a UL broadcast message and / or a DL eBCS element may be included in a DL broadcast message. It should be noted that, in this application, unless otherwise indicated, the terms DL broadcast element, DL eBCS element, and DL broadcast capability element are used interchangeably.

[0154] Example designs of DL broadcast elements or DL ​​eBCS elements are in Figure 3 As shown in the diagram. A DL broadcast element can contain any one or more of the following example fields: element ID; length; element ID extension; and / or DL ​​broadcast capability including N eBCS fields. The combination of element ID and element ID extension can identify the current element as a DL broadcast element or a DL eBCS element. The length field can indicate the length of the DL broadcast element.

[0155] The DL broadcast capability can contain N fields (i.e., from eBCS1 to eBCS N), allowing each field to be used to specify a particular broadcast service provided by the transport WTRU (e.g., the transport AP). Each eBCS field can contain any one or more of the following example subfields: broadcast service ID, eBCS type, association requirements, UL transport requirements, broadcast rate, broadcast frequency, broadcast encoding, broadcast control, broadcast parameters, and / or broadcast status. These subfields are further described below.

[0156] The Broadcast Service ID subfield can indicate the ID of the broadcast service. The eBCS Type subfield can include the type of broadcast service (e.g., whether the eBCS is UL or DL, or whether the broadcast service is a category such as automotive, direction, emergency, support, information, and / or event support). In the example, a bitmap can be included in the DL broadcast element to indicate which types of broadcast services are provided by the transmitting WTRU(s). The type can also be a multi-AP broadcast. In another example, the broadcast type can be identified by an Organization Unique Identifier (OUI). The Association Requirement subfield can indicate whether an association is required to consume one or more broadcast services (e.g., a broadcast service identified by the Broadcast Service ID).

[0157] The UL Transport Request subfield can indicate whether a UL transport is requested to consume one or more broadcast services (e.g., a broadcast service identified by a broadcast service ID). The Broadcast Rate subfield can indicate the data rate associated with the broadcast service. The Broadcast Frequency subfield can indicate the frequency at which the broadcast data is being transmitted. The Broadcast Encoding subfield can indicate the encoding of the broadcast data packets (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)).

[0158] The broadcast control subfield can indicate how to control broadcast services. For example, the broadcast control subfield can indicate that if the WTRU expects a certain broadcast service, the WTRU needs to negotiate directly with the transmitting WTRU (e.g., the transmitting AP) using, for example, a broadcast request frame. In another example, the broadcast control subfield can indicate a server address (e.g., the server's IP address) or a controller AP address (e.g., the MAC address or BSSID of another AP). Such a controller AP can be the master AP of a multi-AP set. The WTRU can also communicate with the controller AP or server to provide feedback on broadcast services or negotiated rates or codes. Example methods for control can be via WLAN, Transmission Control Protocol / Internet Protocol (TCP / IP), broadcast request negotiation, ANQP, and / or General Advertising Service (GAS) frame exchange.

[0159] The broadcast parameter subfield can include one or more broadcast parameters, including offset, channel, etc. For example, offset can indicate the offset at which the next broadcast packet or broadcast burst begins, which can be from the end of the current transmission, or from the Target Beacon Transit Time (TBTT) or other reference point. Channel can indicate the channel, OFDMA subchannel, or resource element (RU) available on which the broadcast service packet is located.

[0160] The broadcast status subfield can indicate the current broadcast status, such as broadcasting, paused, or about to be started.

[0161] Example designs of UL broadcast elements or UL eBCS elements are in Figure 4 As shown in the figure. A 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 capability element may be used interchangeably.

[0162] A combination of element ID and element ID extension can identify the current element as a UL broadcast element or a UL eBCS element. The length field indicates the length of the UL broadcast element. UL broadcast information can include N fields (i.e., from eBCS1 to eBCSN), such that each field can be used to specify a particular UL broadcast service supported by the transport WTRU. Each eBCS field may contain 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 encoding; broadcast control; broadcast parameters; and / or broadcast status. These subfields are further described below.

[0163] The Allowed Broadcast Service ID subfield can indicate the ID of the UL broadcast service supported and allowed by the transmitting WTRU. The Allowed eBCS Type subfield can include the type of allowed broadcast service (e.g., whether the allowed eBCS is UL or DL, or the category of broadcast service: automotive, sensor, orientation, emergency, support, information, and / or event support). In the example, a bitmap can be included in the UL broadcast element to indicate which types of broadcast services are allowed and supported by one or more transmitting WTRUs. In another example, the broadcast type can be identified by the OUI or server address. The Allowed eBCS Type subfield can include a detailed description of the broadcast service provided.

[0164] Association requires subfields ( Figure 4 (Not shown in the text) can indicate whether association is required to utilize one or more permitted UL broadcast services (e.g., broadcast services identified by permitted broadcast service IDs). DL Reception Requirement Subfield ( Figure 4 (Not shown) can indicate whether DL reception is required in order to use one or more permitted UL broadcast services (e.g., broadcast services identified by permitted broadcast service IDs).

[0165] The Permitted Broadcast Rate subfield indicates the permitted data rate for transmission within the UL associated with the broadcast service for one or more WTRUs. The Permitted Broadcast Frequency subfield indicates the permitted frequency at which the WTRU is allowed to broadcast data within the UL associated with the permitted broadcast service. The Broadcast Encoding subfield indicates the encoding to be used for UL broadcast data packets, such as inter-frame BCC, inter-frame LDPC, HARQ CC, or HARQ IR.

[0166] The broadcast control subfield can indicate the method of controlling UL broadcasts. For example, the broadcast control subfield can indicate how to control broadcast services (e.g., indicating the destination of permitted UL broadcast services). For example, it can indicate that if a WTRU expects to use certain UL broadcast services, it needs to negotiate directly with the transmitting WTRU (e.g., the transmitting AP) using, for example, a broadcast request frame. In another example, the broadcast control subfield can indicate a server address (e.g., the server's IP address) or a controller AP address (e.g., the MAC address or BSSID of another AP). Such a controller AP can be the master AP of a set of multiple APs. The server or controller can be contacted by the WTRU that expects to utilize the uplink broadcast service to obtain feedback or negotiate the MCS to be used. For example, the method of control can be through WLAN, TCP / IP, broadcast request negotiation, ANQP, or GAS frame exchange.

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

[0168] In this embodiment, as described above, UL and DL broadcast elements can be combined into a single broadcast element or eBCS element. In another embodiment, information included in the UL and DL broadcast elements can be included as part of an ANQP element. Furthermore, any subset of the UL and DL broadcast elements can be transmitted in any other type of frame, or in any other type of element, MAC and PHY header, etc.

[0169] The DL broadcasting process according to this application will be described below.

[0170] First, a WTRU (i.e., a non-AP WTRU) expecting a DL broadcast service may include a DL broadcast element in the frames it transmits, such as probe request frames, ANQP frames, or GAS query frames. When transmitted by the WTRU, the DL broadcast element may indicate information or parameters of the expected DL broadcast service. In another example, a non-AP WTRU may include a DL broadcast request element, which may contain one or more subfields described for a DL broadcast element describing the expected DL broadcast service.

[0171] Secondly, the AP may include DL broadcast elements or eBCS elements, probe responses, association responses, ANQP response frames, GAS response frames, or any other type of frame in its beacon. In the example, if the AP has already received a frame requesting a DL broadcast element from the WTRU (e.g., when it has received a frame including a desired DL broadcast element or eBCS element indicating DL broadcast service, such as an ANQP frame, GAS query frame, or probe request frame), the AP may include only the DL broadcast element. When transmitted by the AP, the DL broadcast element may indicate the DL broadcast service provided by the AP.

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

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

[0174] Then, the WTRU can use broadcast control methods to further negotiate broadcast services, such as feedback, coding, modulation and decoding schemes (MCS), and / or repetition.

[0175] The UL broadcasting process according to this application will be described below.

[0176] First, a WTRU (i.e., a non-AP WTRU) that intends to utilize one or more UL broadcast services may include UL broadcast elements in the frames it transmits, such as probe request frames, ANQP frames, or GAS query frames. 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, which may include one or more subfields described for a UL broadcast element describing the desired UL broadcast service.

[0177] Secondly, the AP may include UL broadcast elements or eBCS elements, probe responses, association responses, ANQP response frames, GAS response frames, or any other type of frame in its beacon. The AP may include DL broadcast elements if it has already received a frame from the WTRU requesting a DL broadcast element (e.g., when it has received a frame including a desired UL broadcast element or eBCS element indicating UL broadcast service, such as an ANQP frame, GAS query frame, or probe request frame). When transmitted by the AP, the UL broadcast element may indicate the UL broadcast services supported and permitted by the AP. The AP may provide policies regarding supported and permitted UL broadcast services, such as permitted broadcast rates, permitted broadcast frequencies, or permitted UL broadcast methods, such as triggered broadcast, uplink OFDMA random access, or EDCA.

[0178] If the broadcast status is accepting broadcasts, a non-AP WTRU can begin broadcasting its UL data once it has received a frame (e.g., a beacon, probe response, or association response, or a FILS discovery frame) from the AP. This frame may include a UL broadcast element or an eBCS element, where the AP may indicate that it supports and allows that particular UL broadcast service. The WTRU can follow the instructions included in the UL broadcast element to perform the UL broadcast, such as using a permitted broadcast rate, broadcast frequency, and / or uplink broadcast method. If the broadcast status is paused or about to be started, the non-AP WTRU can use a broadcast control method instructed to negotiate directly with the AP, or use a broadcast control method (e.g., WLAN, TCP / IP) to contact the controller AP or server to resume or start the UL broadcast service provided by the AP.

[0179] Then, WTRU can use broadcast control methods to further negotiate broadcast services, such as encoding, MCS, or repetition.

[0180] The following description will illustrate how broadcast reliability can be improved according to this application.

[0181] Broadcast packets can be transmitted to multiple WTRUs, for example, in a downlink scenario. Channel conditions, as well as equipment capabilities and sensitivities, can vary from WTRU to WTRU. Therefore, the reliability of receiving broadcast packets may not be the same across all receiving WTRUs. Broadcast reliability is particularly important for irrelevant or undeliverable WTRUs. Therefore, broadcast protocols and broadcast packets can be designed to ensure that broadcast service is reliably provided to all WTRUs.

[0182] This document describes a mechanism for improving broadcast reliability according to this application. Example mechanisms for improving broadcast reliability are inter-frame coding, such as BCC and LDPC. A broadcast node (e.g., an AP) can transmit frames containing encoded and interleaved system bits or parity bits from previously transmitted frames. The data in the original frame can be encoded using BCC or LDPC. In a first example, the data in the new subframe may include encoded data from previously transmitted frames that are linearly encoded together; this is referred to as 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 may include encoded data from previously transmitted frames that are concatenated and interleaved. This can be described as partial frame HARQ. In this case, instead of transmitting the HARQ retransmission itself, it is transmitted from other frames along with the HARQ retransmission. This can help reduce the latency of broadcast transmissions. The following description will describe the two examples above in detail.

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

[0184] Nmax can be based on the length of the packets to be sent (N), the number of incremental subframes (D), and their corresponding lengths (Δ). i This is determined by [the variable name]. Each incremental subframe can be set to a different length, making [the variable name] ...]. If each incremental subframe has the same length, then Nmax = N + DΔ i The original transmission of each frame will be N bits (e.g., ... Figure 5 As shown), incremental subframes (e.g., Δ1-ΔD) can consist of additional (unpunctured) parity bits. Figure 6 In the example shown, the index of the increment can be random and can increase out of order.

[0185] Figure 7 An example of BCC inter-frame coding is shown. In the case of BCC inter-frame coding, for BCC transmission, the original transmission of each frame has N unpunctured bits (e.g., Figure 7 The N bits shown), and the incremental subframe (e.g., Figure 7 Δ1 and Δ2 shown can be composed of other punched bits. For example... 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).

[0186] Procedures for inter-frame BCC / LDPC transmission and partial packet HARQ of BCC / LDPC codes can be defined. Figure 8 An example of inter-frame coding with a fixed index and partial HARQ is shown. The AP can 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-coded frames consisting of N bits from each frame. For example... Figure 8 As shown, intra-frame coding includes NT frames from the 1st frame to the NTth frame. The last D transmissions consist of inter-frame coded subframes composed of a combination of D increments from each frame.

[0187] In one embodiment, the D subframes of each frame can be incrementally 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.

[0188] For each transmitted frame, one or more of the following information can be signaled (e.g., in the PLCP header): intra- or inter-frame coding, the index of the intra-coded frame, the index of the inter-coded frame (in the following example, this could be index 'a' in delta(a,b), and / or could be explicitly signaled or implicitly identified based on the frame index after the start of the entire transmission), or the index of the frame encoded in the incremental subframe (in the following example, this could be index 'b' in delta(a,b), and / or could be explicitly signaled or implicitly identified based on the number of frames in the transmission). Where the indices can have different sizes, the size of the increment from each frame in the incremental subframe can be signaled.

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

[0190] like Figure 10 As shown, the increments being transmitted can be dynamically selected. For example, this method can be used when the WTRU might have feedback on frames that have already been poorly received. The broadcast AP can dynamically select specific frames to transmit increment information. The broadcast AP can dynamically select the size of the increment to send based on the required quality of the broadcast signal (some frames may require more protection than others). In the example, feedback from (one or more) WTRUs indicates that the reception of a specific frame is very poor. For example, if most (selected) WTRUs indicate that a frame is poorly received, it may require more information. In another example, the WTRU can send more information on frames that could be sent earlier to ensure they are decoded faster, thereby reducing the overall latency.

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

[0192] If the packets are inter-frame coded, the WTRU can decode / deinterleave / de-aggregate incremental subframes within the frame. The WTRU can identify incremental subframes based on explicit or implicit signaling. The WTRU can discard incremental subframes of all frames that have been successfully decoded. The WTRU can process incremental subframes of all undecoded frames by adding the received incremental subframe information to an existing frame buffer and then decoding the result. If decoding is successful, the WTRU can send an ACK to the AP and / or terminate the decoding process for that frame as needed. If decoding fails, the WTRU can store the frame in its buffer. The WTRU can send a NAK to the AP or wait until the total number of incremental subframes received before sending a NAK. Because this channel is a broadcast channel, ACK / NAK transmissions can be based on a request from the AP to a specific WTRU, rather than all WTRUs being transmitted to. In the example, the WTRU can send an ACK / NAK on a specific (sub)channel, and the presence of a signal on the subchannel can notify the AP of success / failure.

[0193] If a packet is both intra-coded and inter-coded, WTRU can separate intra-packets from inter-packets and then process each packet separately using the method described above.

[0194] In HARQ broadcasting, broadcast frames can be transmitted multiple times or repeatedly. In the example process, repeated transmissions can be identical to the original transmission, allowing the receiver to easily combine and receive them. Signaling can be used to enable the receiving WTRU to combine the received frames. For example, the PLCP header, MAC body, and / or beacon frame may include one or more of the following information (fields): ID, broadcast, repeated transmission, repeated index, next repeated frame, or next repeated beacon. These fields will be further described below.

[0195] The ID field can indicate any of the following: 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, multicast frame, and / or unicast frame. The Repeat Transmission field can be used to indicate whether the frame is transmitted in a repeating manner. The Repeat Transmission field can also indicate the type of repeating used (e.g., simple repeat or inter-frame coding).

[0196] The repeat index field can indicate the number of repetitions in the current transmission. For example, the repeat index field can be transmitted in an incrementing manner. In another example, the repeat index field can be transmitted in a decrementing manner, allowing the receiving WTRU to know the subsequent number of repeat transmissions. The next repeat frame field can indicate the expected time for the next repeat of a frame. The next repeat frame field can also indicate the type of repeat frame to be sent at that time. The next repeat beacon field can indicate the expected time for the next repeat beacon. In the example, the expected time can be the duration.

[0197] In this embodiment, broadcast frames may be transmitted multiple times or sent using a repetition method with some diversity scheme. For example, the repeated transmissions may differ from the original transmissions. In this case, one or more of the following methods may be used.

[0198] In the first approach, different bit interleavers can be used for different repetitions. Bit interleavers 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 allowed number of repetitions. 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 indices and repetitions can be defined by a function. For example, a modular function can be used. The interleaver index used for the k-th repetition can be defined as `Interleaver_ID = mod(k, N)`, where N is the maximum number of interleavers defined. Bit interleavers can be used for LDPC codes or not. In the example method, bit interleavers can be defined for repeated transmissions.

[0199] In the second approach, 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 symbol-level interleavers can be to allocate modulation symbols among OFDM symbols. In the example, a fixed number of symbol interleavers can be defined. The mapping between interleaver indices and repetitions can be defined by functions. For example, modular functions can be used. The symbol interleaver index used for the k-th repetition can be defined as Interleaver_ID = mod(k, N), where N is the maximum number of symbol-level interleavers defined.

[0200] In the third method, 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 indices and repetitions can be defined by a function. For example, a modular function can be used. The RV index used for the k-th repetition can be defined as RV_ID = mod(k, N), where N is the maximum number of RVs defined.

[0201] Diversity broadcast transmissions can 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 Repeat Count, Repeat Index, Transmission Index, or Next Repeat Beacon / Timing. These example fields are further described below.

[0202] The ID field can indicate the destination ID, source ID, transmitter ID, and / or receiver ID. The broadcast field can be used to indicate whether this is a broadcast frame, multicast frame, and / or unicast frame. The repeat transmission field can be used to indicate whether the frame is being transmitted repeatedly. The maximum number of repeats field can indicate the expected maximum number of repeats. The repeat index field can indicate the number of repeat transmissions in the current transmission. In the example, the repeat index field can be transmitted in an incrementing count. In another example, the repeat index field can be transmitted in a decrementing count, so that the receiving WTRU knows the subsequent number of repeat transmissions.

[0203] The transmission index field can be used to signal the bit-level interleaver index, symbol-level interleaver index, and / or RV index used in subsequent transmissions. The next repeat beacon / timing field can indicate the expected time of the next repeat beacon / timing. In the example, the expected time can be a duration. This duration can be a function of the WTRU's ability to allow each WTRU to independently decode each transmission. In another example, the expected time can be immediate, indicating that the next repeat occurs after the inter-frame interval (xIFS) duration following the end of the current transmission.

[0204] This process can be used to leverage power savings from Broadcast Service (BCS) reception. The WTRU can receive a PLCP header with a repeat ID. In the example, the PLCP header may contain the total number of repeats and the repeat index. The WTRU can store all repeats and decode them after the last reception. The WTRU can decode after each repeat. One or more APs and one or more WTRUs can negotiate a minimum duration between repeats to allow packet decoding after each repeat.

[0205] If the WTRU has already decoded the packet, it can go into sleep mode for the duration of the transmission. Figure 11An example power-saving process with xIFS inter-frame intervals between repetitions is shown that can be used in BCS. For example, such as... Figure 11 As shown, WTRU1 decodes packets during Tx1, and then it can sleep until Tx4.

[0206] If the WTRU has already decoded the packet and the duration between repetitions is immediate, the WTRU can enter sleep mode for the duration of a specific repetition. Figure 12 An example of a power-saving process with specific timing differences between repetitions that can be used in BCS is shown. For example, such as Figure 12 As shown, WTRU1 decodes packets during Tx1, and then it can sleep during Tx2, Tx3 and Tx4.

[0207] In this embodiment, feedback-based retransmission can be used. The maximum number of retransmissions can be predefined or (re)determined. The maximum number of retransmissions can be carried and signaled in beacon frames, (re)association frames, probe request / response frames, 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. A WTRU can terminate retransmissions based on feedback. For example, if a WTRU receives a positive acknowledgment (ACK) from another WTRU that may be far away, that WTRU can stop retransmissions.

[0208] In embodiments, repeated transmissions may be separated at least by a predefined inter-frame interval (xIFS). In one approach, xIFS may be greater than a Short Inter-Frame Inter-Inter ...

[0209] In this embodiment, polling frames or MU-BAR frames may be transmitted before or after the repeated transmission. Alternatively, NDP trigger frames may be aggregated with broadcast frames. Polling frames, MU-BAR frames, or NDP trigger frames may trigger acknowledgment transmissions from one or more WTRUs. If a receiving WTRU successfully receives (one or more) a repeated broadcast transmission, that receiving WTRU may be polled or triggered and may respond with a positive acknowledgment. The broadcast WTRU may receive a positive acknowledgment and determine whether it can terminate the repeated transmission.

[0210] A broadcast WTRU can determine whether it can terminate the repetition. Alternatively, the broadcast WTRU or AP can be configured to terminate the repetition. 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 transmitted to unassociated WTRUs or partially transmitted to these unassociated WTRUs, the broadcast WTRU may not terminate the repetition transmission prematurely.

[0211] The maximum number of repetitions can be determined by the AP or otherwise specified. 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, if the BSS coverage area is likely large or the AP may know many cell edge WTRUs, the AP may determine to use a larger maximum number of repetitions. Otherwise, the AP may use a smaller maximum number of repetitions. Figure 13 An example of repeated transmission with feedback is shown. For example... Figure 13 As shown, during Tx1, WTRU1 receives a transmission from the AP, but WTRU2 and WTRU3 do not. Therefore, WTRU2 and WTRU3 can send a NAK to the AP. Then, during Tx2, a repeat transmission can be performed. WTRU2 then successfully receives the transmission. However, WTRU3 does not receive it. Then, during Tx3, a repeat transmission can be performed. Then, WTRU3 receives the transmission.

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

[0213] In embodiments, retransmission can be used for broadcast / multicast frames. For example, retransmission of broadcast / multicast frames can be used with different self-decoding RVs, different bit-level interleavers, different symbol-level interleavers (equivalent to changing the subcarrier mapping), and / or SIGs indicating broadcast, PAID (e.g., association ID), RV, HARQ, interleaver ID, and / or the next timing.

[0214] In embodiments, feedback-based repetitive transmissions can be used. For example, repetitive transmissions can be separated by at least a fixed duration (e.g., xIFS). xIFS can be greater than SIFS or DIFS. Feedback-based repetition can include the use of polling / multi-user block ACK requests (MU-BAR). If the transmission is successfully decoded, some WTRUs can be allowed to send back acknowledgments before the next repetition. In embodiments, pre-selected distant WTRUs can transmit acknowledgments (e.g., using a near-far procedure in 802.11ay). An AP that successfully receives an acknowledgment can terminate the transmission under certain circumstances. The AP can periodically complete a full repetition for unassociated WTRUs. BCS transmission parameters (for associating WTRUs) can be generalized, and / or TCP / IP can be configured for unassociated / non-transmitting WTRUs via (one or more) probe requests. ACKs can specify WTRUs, WTRU groups, null data packet (NDP) feedback reports, and / or random access MUs.

[0215] If an AP subnet is configured to send the same broadcast information from multiple APs, with or without Automatic Repeat (AR) configured for the transmitted frames, the WTRU receiving these transmitted frames must be able to identify frames containing the same broadcast data or incrementally redundant versions of broadcast data. In this case, the WTRU can improve its reception of broadcast data by combining frames as appropriate or ignoring redundant frames containing data that has already been received. For cases where AR is simple repeat (redundant versions of the same frame sent from multiple APs), the WTRU must have a means of knowing whether it has received data from ignored redundant frames or whether it has not received any data. The WTRU should know how to combine frames to increase the likelihood of data reception. For cases where AR has incrementally redundant (IR) frames, the WTRU must have a means of knowing how to combine incrementally redundant frames, combine frames with the same data, and ignore frames containing data that has already been received. Currently, there is no method to notify the WTRU that frames sent by different APs contain the same broadcast data or IR versions of data that the WTRU is attempting to receive.

[0216] The following description will describe subnet scheduling to address the above problems.

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

[0218] The Multiple AP Indicator field indicates that the frame and its associated ID(s) are being broadcast by multiple APs. The Subnet ID field provides a unique ID for the subnet, and all APs within the subnet can use the same identifier. Subnets can be coordinated to ensure that different subnets with overlapping service areas have unique subnet IDs. In this example, the subnet ID could 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 AP's location, a unique subnet ID assigned by the network / subnet administrator, or any other unique ID could be used.

[0219] 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 that this is a broadcast frame, multicast frame, and / or unicast frame. The repeat transmission field can be used to indicate whether the frame is transmitted in a repeating manner. The repeat transmission field can also indicate the type of repeat being used (e.g., simple repeat or inter-frame coding).

[0220] The repeat index field can indicate the number of repeat transmissions in the current transmission. In one embodiment, the repeat index field can be transmitted in an incrementing count. In another embodiment, the repeat index field can be transmitted in a decrementing count, so that (one or more) receiving WTRUs can know the subsequent number of repeat transmissions. The next repeat frame field can indicate the expected time of the next repeat of the frame. The next repeat frame field can also indicate the type of repeat frame to be sent at that time. The next repeat beacon field can indicate the expected time of the next repeat beacon. In the example, the expected time can be the duration.

[0221] An AP can coordinate and select the virtual SSID and / or MAC address that all APs in a subnet will use for broadcasting (e.g., a specific broadcast or a specific set of broadcasts). All APs in the subnet can 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 on any WTRU receiving broadcast frames sent by APs in the subnet. APs using virtual SSIDs and / or MAC addresses can provide broadcast ID information using one or more of the following information fields (e.g., in the PLCP header, MAC header, MAC body, and / or beacon frame): Virtual SSID Indicator, Virtual MAC Address, ID, Broadcast, Repeat Transmission, Repeat Index, Next Repeat Frame, and / or Next Repeat Beacon. These fields are further described below.

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

[0223] 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 that this is a broadcast frame, multicast frame, and / or unicast frame. The repeat transmission field can be used to indicate whether the frame is transmitted in a repeating manner. The repeat transmission field can also indicate the type of repeat being used (e.g., simple repeat or inter-frame coding).

[0224] The repeat index field can indicate the number of repeat transmissions in the current transmission. In one embodiment, the repeat index field can be transmitted in an incrementing count. In another embodiment, the repeat index field can be transmitted in a decrementing count, so that (one or more) receiving WTRUs can know the subsequent number of repeat transmissions. The next repeat frame field can indicate the expected time of the next repeat of the frame. The next repeat frame field can also indicate the type of repeat frame to be transmitted at that time. The next repeat beacon field can indicate the expected time of the next repeat beacon. In one embodiment, the expected time can be a duration.

[0225] This process can be used for UL broadcast reliability. In DL broadcasts, there may be multiple transmitters and receivers, and each receiver may represent a broadcast service endpoint located outside the AP WTRU. This can 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. Furthermore, the AP may need to coordinate among them to know which MAC PDU (MPDU) / block was lost for at least one WTRU before retransmission attempts.

[0226] The reliability of UL broadcasts may also be an issue. For example... Figure 17 As shown, the UL WTRU 1701 is unaware of the receiver status (or statistics of Physical Layer Convergence Process (PLCP) Protocol Data Units (PPDUs) received over a duration), which is indicated by "The WTRU has information on whether the PPDU was successful without upper-layer input?". An example requirement for the transmitted data could be that lost data is unacceptable and retransmission is necessary. In this case, without knowing the 802.11 protocol layer, the UL WTRU 1701 might need to associate with the BSS (or with another access connection) to have a unicast data connection to trigger a retransmission. Another example requirement for the transmitted data could be that lost data is tolerable but undesirable. In this case, feedback from the receiver can improve the quality of future PPDU transmissions.

[0227] In UL broadcasts, different receivers in a UL broadcast packet represent a single broadcast endpoint, and only a single transmitter exists (i.e., a single (joint) receiver state exists for a single transmitter to operate). This makes the MAC layer CSMA / ARQ protocol more likely in ULs. This helps eliminate air errors or improve the robustness of later transmitted data (retransmissions or new ones), and non-AP WTRUs do not need to rely solely on unicast connections via upper layers to the broadcast aggregation node to provide robustness.

[0228] Example procedures for UL broadcast transmissions can be applied on a per-PPDU basis (e.g., for feedback over a duration following a UL broadcast transmission, and for a duration during which UL transmitters in 802.11 MAC retain information that may need to be repeated). UL WTRUs can base UL broadcast transmissions on feedback to adjust the robustness of PPDUs sent after feedback without performing retransmissions of lost data. Example procedures for UL broadcast transmissions can be applied to non-broadcast PPDUs sent in the UL direction during multi-AP setups, where one AP is the anchor AP or master AP, and the other APs are auxiliary receivers or slave APs for the anchor AP.

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

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

[0231] Figure 19 Another example process is shown where the AP provides DL feedback, allowing the transmitter to acquire joint feedback (e.g., for each MPDU / data block in one or more aggregated MPDUs (AMPDUs) transmitted in the UL). A mechanism can be used that allows AMPDU transmission without prior exchange to establish a feedback agreement. This unsolicited feedback agreement can be used for UL broadcasting. Protocol parameters (e.g., buffer size, timeout value) can be set to predetermined values ​​for all WTRUs supporting UL broadcasting.

[0232] To receive a single joint feedback bitmap corresponding to a data block / MPDU, an NDP feedback method can be used, for example, using a positive feedback-based on-off keying. The tone set indicating state 0 may not be transmitted, while the tone set indicating state 1 may be transmitted by the AP. The NDP Long Training Field (LTF) can include a longer GI to cover differences in propagation delays from different APs to the initiator / transmitter (i.e., non-AP WTRU 1901).

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

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

[0235] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) 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-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A receiving station (STA), comprising: The processor and transceiver are configured to receive frames from a transmitting STA that include broadcast service elements, the broadcast service elements including one or more fields associated with an enhanced broadcast service (eBCS) traffic flow that can be provided by the STA. At least one of the said one or more fields includes: an identifier associated with one eBCS service flow in the eBCS service flow; a field indicating whether negotiation with the transmitting STA is required to receive data from the one eBCS service flow in the eBCS service flow; and scheduling information for receiving broadcast transmissions including the data from the one eBCS service flow in the eBCS service flow; and The processor and the transceiver are configured to receive, based on the scheduling information, the broadcast transmission including the identifier associated with the eBCS service flow in the eBCS service flow and the data of the eBCS service flow in the eBCS service flow.

2. The receiving STA according to claim 1, wherein the broadcast service element is an eBCS Access Network Query Protocol (ANQP) element.

3. The receiving STA according to claim 2, wherein the processor and the transceiver are configured to transmit a General Advertising Service (GAS) request frame, wherein the received frame is a GAS response frame in response to the transmitted GAS request frame.

4. The receiving STA according to claim 1, wherein the processor and the transceiver are configured to transmit a request frame to negotiate registration for one of the eBCS service flows in the eBCS service flows.

5. The receiving STA of claim 1, wherein the broadcast service element includes a field indicating whether it is necessary to associate with the transmitting STA to receive data of the one eBCS service stream in the eBCS service stream.

6. The receiving STA according to claim 1, wherein the processor and the transceiver are configured to receive periodic transmissions of the broadcast service element from the transmitting STA.

7. A method performed by a receiving station (STA), the method comprising: Receive a frame from the transmitting STA that includes a broadcast service element, the broadcast service element including one or more fields associated with an enhanced broadcast service (eBCS) traffic flow that can be provided by the STA. At least one of the said one or more fields includes: an identifier associated with one eBCS service flow in the eBCS service flow; a field indicating whether negotiation with the transmitting STA is required to receive data from the one eBCS service flow in the eBCS service flow; and scheduling information for receiving broadcast transmissions including the data from the one eBCS service flow in the eBCS service flow; and Based on the scheduling information, a broadcast transmission is received, including the identifier associated with the one eBCS service flow in the eBCS service flow and the data of the one eBCS service flow in the eBCS service flow.

8. The method of claim 7, wherein the broadcast service unit is an eBCS Access Network Query Protocol (ANQP) element.

9. The method of claim 8, further comprising transmitting a General Advertising Service (GAS) request frame, wherein the received frame is a GAS response frame in response to the transmitted GAS request frame.

10. The method of claim 7, further comprising transmitting a request frame to negotiate registration for one of the eBCS service flows.

11. The method of claim 7, wherein the broadcast service element includes a field indicating whether it is necessary to associate with the transmitting STA to receive data of the one eBCS service stream in the eBCS service stream.

12. The method of claim 7, further comprising receiving periodic transmissions of the broadcast service element from the transmitting STA.

13. A transmitting station (STA), comprising: The processor and transceiver are configured to transmit frames that include broadcast service elements, said broadcast service elements including one or more fields associated with an enhanced broadcast service (eBCS) traffic flow that can be provided by the transmitting STA. At least one of the said one or more fields includes: an identifier associated with one eBCS service flow in the eBCS service flow; a field indicating whether negotiation with the transmitting STA is required to receive data from the one eBCS service flow in the eBCS service flow; and scheduling information for receiving broadcast transmissions including the data from the one eBCS service flow in the eBCS service flow; and The processor and the transceiver are configured to transmit, according to the scheduling information, the broadcast transmission including the identifier associated with the one eBCS service flow in the eBCS service flow and the data of the one eBCS service flow in the eBCS service flow.

14. The transmitting STA according to claim 13, wherein the broadcast service element is an eBCS Access Network Query Protocol (ANQP) element.

15. The transmitting STA of claim 14, wherein the processor and the transceiver are configured to receive a General Advertising Service (GAS) request frame, wherein the transmitted frame is a GAS response frame in response to the received GAS request frame.

16. The transmit STA of claim 13, wherein the processor and the transceiver are configured to receive request frames to negotiate registration for one of the eBCS service flows in the eBCS service flows.

17. The transmitting STA of claim 13, wherein the broadcast service element includes a field indicating whether it is necessary to associate with the transmitting STA to receive data of the one eBCS service stream in the eBCS service stream.

18. The transmitting STA of claim 13, wherein the processor and the transceiver are configured to transmit periodic transmissions of the broadcast service element.

Images