Method and device for efficient response transmission

Abstract

A wireless transmit / receive unit (WTRU) communicating within a wireless local area network (WLAN) system may use an effective acknowledgment (ACK) establishment and transmission procedure and may be combined with other transmission and power saving techniques such as target wake time / restricted access window (TWT / RAW), power save multi-polling (PSMP), and / or transmission opportunity (TXOP) mechanisms. In one example, a WTRU may transmit a frame including the following indications: an indication that a TWT / RAW (or TXOP) period is scheduled; an indication that a multi-WTRU acknowledgment ACK / block ACK (BA) is to be used for acknowledgment; and / or a target transmission time for transmission of a multi-WTRU ACK / BA frame(s). The WTRU may trigger the start of the TWT / RAW period and may receive at least one data frame from another WTRU(s). The WTRU may transmit the multi-WTRU ACK / BA frame(s) during the target transmission time(s) to acknowledge the at least one data frame received from the other WTRU(s).

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201680071874.3, entitled “Method and Apparatus for Efficient Response Transmission”, filed on October 10, 2016.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 239,691, filed October 9, 2015, the contents of which are incorporated herein by reference. Summary of the invention

[0004] A setup and transmission technique may be used for high efficiency (HE) acknowledgment transmission within a wireless local area network (WLAN) system. A wireless transmit / receive unit (WTRU) communicating within a WLAN system may use an efficient acknowledgment (ACK) setup and transmission procedure in conjunction with other transmission and power saving techniques such as target wake time / restricted access window (TWT / RAW), power save multi-polling (PSMP), and / or transmission opportunity (TXOP) mechanisms. In one example, a WTRU (e.g., an access point (AP)) may transmit a first frame including the following information: an indication that a TWT / RAW cycle is scheduled; an indication that a multi-WTRU block ACK and / or a block ACK (BA) (M-BA) (e.g., a multi-station (STA) ACK / BA) is to be used by the WTRU for acknowledgments of frames received during the TWT / RAW cycle; and / or at least one target transmission time corresponding to the transmission of at least one multi-WTRU ACK / BA frame. The WTRU may transmit a second frame that triggers the start of the TWT / RAW cycle. The WTRU may receive at least one data frame from at least one WTRU within the WLAN system, wherein the at least one WTRU is allowed to access the radio medium during the TWT / RAW period. The WTRU may transmit at least one multi-WTRU ACK / BA frame during the at least one target transmission time to acknowledge the at least one data frame received from the at least one WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be obtained through the following description given by way of example in conjunction with the accompanying drawings, in which:

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

[0007] Figure 1B It shows that it can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0008] Figure 1C It shows that it can be Figure 1A System diagram of an example radio access network and an example core network for use within a communication system is shown.

[0009] Figure 2 The frame format of an exemplary multi-radio transmit / receive unit (WTRU) block acknowledgement (BA) (M-BA) control frame is shown;

[0010] Figure 3 shows the frame format of another exemplary multi-WTRU BA (M-BA) control frame;

[0011] Figure 4A shows a frame format of an exemplary acknowledgment (ACK) setup request frame;

[0012] Figure 4B A flowchart of an exemplary ACK request establishment process is shown;

[0013] Figure 5 shows a frame format of an exemplary UL request frame with a delay tolerance indication and an ACK type;

[0014] Figure 6 A flow chart showing an exemplary efficient ACK transmission process;

[0015] Figure 7 A message passing diagram illustrating an exemplary multi-WTRU ACK / BA procedure using a Power Save Multi-Poll (PSMP) procedure;

[0016] Figure 8 A message passing diagram illustrating an exemplary multi-WTRU ACK / BA procedure using PSMP bursts;

[0017] Fig. 9 A schematic diagram showing message delivery of an exemplary multi-WTRU ACK / BA process performed within a target wake-up time / restricted access window (TWT / RAW) period is shown;

[0018] Fig.10 A message passing diagram illustrating an exemplary multi-WTRU ACK / BA process performed within a target transmission opportunity (TXOP) period; and

[0019] Fig.11 A flow chart of an exemplary multi-WTRU ACK / BA procedure performed within a TWT / RAW period is shown. DETAILED DESCRIPTION

[0020] Figure 1Ais a diagram showing an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may use 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), etc.

[0021] 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 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a consumer electronic device, and the like.

[0022] The communication system 100 may also include a base station 114a and a base station 114b. Each base station 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., the core network 106, the Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be base transceiver stations (BTS), node Bs, e-node Bs, home node Bs, home e-node Bs, site controllers, access points (APs), wireless routers, and the like. Although each base station 114a, 114b is depicted as a single component, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0023] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In one embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell.

[0024] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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

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

[0027] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN), among others.

[0028] Figure 1A The base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use, for example, any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, and the like). Figure 1A As shown, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the core network 106.

[0029] The RAN 104 may be in communication with a core network 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or may perform high-level security functions such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 104 and / or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104. For example, in addition to being connected to the RAN 104, which utilizes an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) that utilizes a GSM radio technology.

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

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

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

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

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

[0035] In addition, although Figure 1B 102 as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

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

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

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

[0039] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while remaining consistent with an embodiment.

[0040] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, and more.

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

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

[0043] Each eNodeB 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 1C As shown, the eNode-Bs 140a, 140b, and 140c may communicate with each other via an X2 interface.

[0044] Figure 1C The illustrated CN 106 may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. Although each of the foregoing components are described as being part of the core network 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the core network operator.

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

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

[0047] The serving gateway 144 may also be connected to a PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

[0049] The other network 112 may be further connected to a wireless local area network (WLAN) 160 based on IEEE 802.11. The WLAN 160 may include an access router 165. The access router may include a gateway function. The access router 165 may communicate with multiple access points (APs) 170a, 170b. The communication between the access router 165 and the APs 170a, 170b may be performed via wired Ethernet (IEEE 802.3 standard) or other types of wireless communication protocols. AP 170a wirelessly communicates with WTRU 102d via an air interface. Here, WTRU and station (STA) within the WLAN may be used interchangeably. The WTRU may be, for example, an AP or a non-AP STA, so that all examples and drawings described herein may be equally applicable to APs or non-AP STAs. Here, the WLAN system may be considered to be a network operating based on the IEEE 802.11 standard. In any of the examples described herein, the WLAN may be a high-efficiency (HE) WLAN (HEW) system, or other types of WLAN systems.

[0050] A WLAN using an architecture-based basic service set (BSS) mode may have an access point (AP) for the BSS and one or more WTRUs (e.g., STAs) associated with the AP within the BSS. The AP may access or be connected to a distributed system (DS) or other type of wired / wireless network that sends traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for the WTRU may arrive through the AP and be delivered to the WTRU. Traffic originating from the WTRU and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between WTRUs within the BSS may be sent through the AP, for example, a source WTRU may send traffic to the AP and the AP may deliver the traffic to the destination WTRU. Traffic between WTRUs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent between the source and destination WTRUs using, for example, a direct link setup (DLS), which may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP and may have WTRUs that can communicate directly with each other. This communication mode may be referred to as an "ad-hoc" communication mode. Here, the WTRU may include an IEEE 802.11 STA and / or an AP.

[0051] The IEEE 802.11 family of specifications for WLANs may continue to evolve to include new enhancements that add features such as higher throughput, extended transmission range, and improved efficiency.Some aspects of the various 802.11 protocols are described herein.

[0052] By using the 802.11ac infrastructure working mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a bandwidth of 20 MHz and can be the working channel of the BSS. The WTRU can use this channel to establish a connection with the AP. The basic channel access mechanism in the 802.11 system is carrier sensing multiple access with collision avoidance (CSMA / CA). By using CSMA / CA channel access, the WTRU including the AP can sense the primary channel. If the primary channel is sensed to be busy, the WTRU (including the AP) can back off from accessing the channel. Therefore, CSMA / CA allows only one WTRU to transmit at any given time within a given BSS, thereby avoiding conflicts on the channel.

[0053] According to the IEEE 802.11n specification, a high throughput (HT) WTRU may use a 40 MHz wide channel for communication in addition to other channels, such as a 20 MHz channel (e.g., a primary channel). This may be achieved by combining the primary 20 MHz channel with an adjacent 20 MHz channel to form a contiguous channel of 40 MHz width.

[0054] According to the IEEE 802.11ac specification, a very high throughput (VHT) WTRU may support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. For example, 40 MHz and 80 MHz channels may be formed by combining consecutive 20 MHz channels, as in the example of 802.11n. A 160 MHz channel may be formed by combining 8 consecutive 20 MHz channels or by combining two discontinuous 80 MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may be passed and passed through a segment parser, which may separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The data stream may be mapped onto two channels and may be transmitted on the two channels. At the receiver, this 80+80 configuration processing may be reversed to combine the two data streams, and the combined data may be sent to the Medium Access Control (MAC) layer.

[0055] 802.11af and / or 802.11ah may support sub-1GHz operating modes. Compared to, for example, 802.11n and 802.11ac, the channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced. The 802.11af specification may support 5MHz, 10MHz, and / or 20MHz bandwidths in the TV White Space (TVWS) spectrum. The 802.11ah specification may support 1MHz, 2MHz, 4MHz, 8MHz, and / or 16MHz bandwidths using non-TVWS spectrum. Exemplary use cases for the 802.11ah standard may support meters and sensor devices in macro coverage areas. Meters and sensor devices may have limited capabilities, such as supporting limited bandwidth, and may have requirements such as very long battery life.

[0056] For a WLAN system that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system may include a channel designated as a primary channel. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all WTRUs in the BSS. Therefore, the bandwidth of the primary channel may be limited by the WTRU that supports the smallest bandwidth operating mode among all WTRUs operating in the BSS. In the example of 802.11ah, even if the AP and other WTRUs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, if there are WTRUs that only support 1MHz mode (e.g., MTC-type devices), the width of the primary channel may be 1MHz. Carrier sensing and / or NAV settings may depend on the status of the primary channel. For example, if the primary channel is busy (e.g., because a WTRU (which only supports 1MHz operating mode) transmits to the AP), then the entire available frequency band may be considered busy even if most of the frequency band remains idle and available for use.

[0057] The available frequency bands for 802.11ah are in the following ranges for different countries: 902 MHz to 928 MHz in the United States, 917.5 MHz to 923.5 MHz in Korea, and 916.5 MHz to 927.5 MHz in Japan. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0058] To improve spectral efficiency, the IEEE 802.11ac specification has introduced the concept of multi-user MIMO (MU-MIMO) transmissions to multiple WTRUs during the time frame of the same symbol, for example during a downlink OFDM symbol. Potential applications of downlink MU-MIMO are also currently being considered for 802.11ah. Transmissions to multiple WTRUs using downlink MU-MIMO (as used in 802.11ac) may be made possible by transmitting packets to multiple WTRUs simultaneously in a spatially orthogonal manner (e.g., by using the same symbol timing). However, in this case, all WTRUs involved in a MU-MIMO transmission with the AP may use the same channel or frequency band, which in turn limits the operating bandwidth of the BSS to the minimum channel bandwidth supported by any of the WTRUs involved in the MU-MIMO transmission with the AP.

[0059] WLAN systems using 802.11 may employ an acknowledgement (ACK) mechanism to support successful delivery of data. Even though protection mechanisms such as channel coding and interleaving may be utilized to protect transmissions, wireless transmissions may be unreliable. Therefore, an ACK mechanism for acknowledging correct packet reception may be used within a WLAN system. A positive acknowledgement (ACK) may be sent immediately upon successful reception of a packet addressed to the WTRU / AP itself. If a WTRU / AP transmitting a frame does not receive an ACK corresponding to the frame within a predetermined amount of time, the WTRU / AP may assume that the data frame was not correctly received at the destination and may retransmit the data frame. Not all data frames within a WLAN system are acknowledged in this manner.

[0060] A block acknowledgment (BA) mechanism has been introduced within the 802.11e specification that can make ACKs for multiple frames more efficient. The BA mechanism can improve system efficiency by allowing the receiver of multiple frames to transmit a single block ACK (BA) to acknowledge a block of data frames. The BA mechanism can also reduce overhead because the preamble and header are only sent once for multiple ACKs. The BA mechanism includes immediate BA, which provides a more immediate acknowledgement, and delayed BA, which can be used, for example, where some delays can be tolerated.

[0061] The 802.11ah specification proposes a short ACK packet format. The short ACK packet format may include only a short training field (STF), a long training field (LTF), and a signal (SIG) field. Using a frame aggregation mechanism within a WLAN system can reduce overhead by sending (i.e., aggregating) two or more data frames within a single transmission. For example, a WLAN system may employ a short packet aggregation mechanism to aggregate segment data packets within a single transmission. Therefore, multiple "short" ACKs using the short ACK packet format may be transmitted using the short packet aggregation mechanism.

[0062] WLAN systems may employ single-user (SU) aggregation mechanisms, such as aggregated medium access control (MAC) protocol data units (A-MPDUs) and aggregated MAC service data units (A-MSDUs). The 802.11 specification defines fewer multi-user (MU) aggregation mechanisms. For example, the 802.11ac specification proposes downlink (DL) MU-MIMO, which is a MU aggregation method that can be limited to sending polling ACKs alone in the UL direction. Therefore, DL MU-MIMO increases overhead, especially for shorter packets, such as short ACKs. In addition, the 802.11 specification cannot provide MU ACK / BA aggregation in the DL direction.

[0063] The IEEE 802.11 High Efficiency WLAN (HEW) Study Group (SG) has been created to develop future WLAN systems, and is developing the 802.11ax specification for use in such WLAN systems. The goal of the HEW SG and the 802.11ax specification is to improve the average throughput per user and implement mechanisms to serve more users in a consistent and reliable manner in the presence of multiple users in future WLAN systems. For example, the HEW SG is developing the scope and purpose of the 802.11 specification to enhance the quality of service, where all users can enjoy a wide spectrum of wireless users in many use case scenarios, including high-density scenarios in 2.4 GHz and 5 GHz. The HEW SG is currently considering use cases that can support dense deployment of APs and WTRUs and associated radio resource management (RRM) technologies.

[0064] Potential applications that may be considered for WLAN systems may include, but are not limited to, the following emerging usage scenarios: data delivery for sporting events; high user density scenarios such as train stations and / or corporate / retail environments; evidence of increased reliance on video delivery; and / or wireless services for medical applications.

[0065] Based on the Project Authorization Request (PAR) and Criteria for Standard Development (CSD) developed within the HEW SG, the IEEE Standards Board has approved the IEEE 802.11ax Task Group (TGax) to study HE WLAN systems and develop the 802.11ax specification. For example, the results of the studies conducted by TGax have shown that the measured services for various applications have a high probability of being for short packets, and there are network applications that can generate short packets. Examples of applications that generate short packets include, but are not limited to, the following examples: virtual office, transmission control protocol (TPC) ACK; video stream ACK; device / controller (e.g., mouse, keyboard and / or game controller) functions; access commands, such as probe requests and / or responses; network selection, such as probe requests and / or access network query protocol (ANQP); and / or network management, such as control frames.

[0066] The 802.11ax specification may support MU features including UL and / or DL ​​OFDMA, and / or UL and / or DL ​​MU-MIMO. For example, such MU transmissions may support a mechanism for multiplexing DL ACKs sent in response to UL MU transmissions. WLANs based on certain 802.11 specifications may have significant overhead and / or latency for short packets and / or short payloads. Therefore, methods and mechanisms are described herein that may enhance MAC efficiency, reduce medium access overhead, and / or reduce latency in transmitting short packets / bursts within a WLAN system (e.g., based on, for example, the 802.11ax specification). The methods described herein include effective aggregation schemes for ACK and / or other feedback information within a MU communication (including, but not limited to, DL and UL OFDMA and DL and UL MU-MIMO) environment. The methods described herein are designed to effectively allow simultaneous MU short packet transmissions.

[0067] The 802.11ax specification defines a framework for using a multi-WTRU (e.g., multi-STA) block ACK (M-BA) control frame to acknowledge multiple WTRUs after a ULMU transmission. Figure 2 and 3 An example frame for a Multi-WTRU Block ACK (M-BA) control frame is shown. Figure 2 and 3Examples within a WTRU ACK / BA may include ACK and / or BA information (e.g., multi-WTRU ACK / BA). Examples described herein may apply and refer interchangeably to any of the following types of acknowledgments (but are not limited to any of the following types of acknowledgments): multi-WTRU block ACK; multi-STA block ACK (M-BA); multi-WTRU BA; multi-STA BA; multi-WTRU ACK / BA; and / or multi-STA ACK / BA. For example, a multi-WTRU ACK / BA frame may include only ACK packet(s), BA packet(s), or both ACK and BA packets.

[0068] Figure 2 The frame format of an exemplary multi-WTRU BA frame 200 is shown. The multi-WTRU BA frame 200 may be defined by modifying, for example, a multi-traffic identifier (multi-TID) BA frame format. The multi-WTRU BA frame 200 may include a MAC header 202. The multi-WTRU BA frame 200 may include, but is not limited to, any of the following fields: a frame control field 204 (e.g., 2 octets), a duration and / or identification (ID) field 206 (e.g., 2 octets), a receiving WTRU address (RA) field 208 (e.g., 6 octets); a transmitting WTRU address (TA) field 210 (e.g., 6 octets); a BA control field 212 (e.g., 2 octets); a BA information field 214 (e.g., variable length); and / or a frame check sequence (FCS) 216 (e.g., 4 octets). The BA control field 212 may include an indication that the frame 200 is a multi-WTRU BA frame. In another example, the indication that the frame 200 is a multi-WTRU BA frame may be included anywhere within the frame 200. In one example, the BA control field 212 may include 16 bits, B0-B15. The BA control field 212 may include, but is not limited to, any of the following subfields: a block acknowledgement request (BAR) ACK policy field 218 (e.g., bit B0); a multiple TID field 220 (e.g., bit B1); a compressed bitmap field 222 (e.g., bit B2); a group code record (GCR) field 224 (e.g., bit B3); a reserved field(s) 226 (e.g., bits B4 to B11); and / or a TID_INFO field 228 (e.g., bits B12-B15).

[0069] The BA information field 214 may include information that may be repeated for each TID. The repeated information within the BA information field 214 may include, but is not limited to, any of the following: a per-TID information field 230 (e.g., 2 octets); a BA starting sequence control field 232 (e.g., 2 octets); and / or a BA bitmap field 234 (e.g., 8 octets). Each repeated information for each TID within the BA information field 214 may be addressed to a different WTRU(s). For example, bits B0-B10 of the per-TID information field 230 (which may be part of a reserved field 236 (e.g., bits B0-B11)) may carry an association identifier (AID) field that identifies the intended receiver of the BA information field 214. The per-TID information field 230 may include a TID value field 238 (e.g., bits B12-B16).

[0070] Figure 3 The frame format of another exemplary multi-WTRU BA frame 300 is shown. The multi-WTRU BA frame 300 may be defined by modifying, for example, a multi-TID BA frame format. The multi-WTRU BA frame 300 may include a MAC header 302. The multi-WTRU BA frame 300 may include, but is not limited to, any of the following fields: a frame control field 304 (e.g., 2 octets), a duration and / or identification (ID) field 306 (e.g., 2 octets), a RA field 308 (e.g., 6 octets); a TA field 310 (e.g., 6 octets); a BA control field 312 (e.g., 2 octets); a BA information field 314 (e.g., variable length); and / or a FCS 316 (e.g., 4 octets). The BA control field 312 may indicate that the frame 300 is a multi-WTRU BA frame. In an example, the BA control field 312 may include 16 bits, B0-B15. The BA control field 312 may include, but is not limited to, any of the following subfields: a BARACK policy field 318 (e.g., bit B0); a multiple TID field 320 (e.g., bit B1); a compressed bitmap field 322 (e.g., bit B2); a GCR field 324 (e.g., bit B3); a reserved field(s) 326 (e.g., bits B4 to B11); and / or a TID_INFO field 328 (e.g., bits B12-B15).

[0071] The BA information field 314 may include information that may be repeated for each TID. The repeated information in the BA information field 314 may include, but is not limited to, any of the following: a per-TID information field 330 (e.g., 2 octets); a BA starting sequence control field 332 (e.g., 2 octets); and / or a BA bitmap field 334 (e.g., 8 octets). In addition to or as an alternative to the BA, the multi-WTRU BA frame 300 may allow for an ACK indication for each WTRU. For example, in the BA information field 314, if bit B11 in the per-TID information field 330 is set, the BA bitmap subfield 334 and / or the BA starting sequence control (SC) subfield 332 may not be present in the BA information field 314. In this scenario, the BA information field 314 may indicate an ACK for the WTRU in B11 of the per-TID information field 330 and an AID in bits B0 to B10 of the per-TID information field 330. Bits B0-B10 of the TID-by-TID information field 330 may carry an AID field that identifies the intended receiver of the BA information field 314. The TID-by-TID information field 330 may include a TID value field 338 (eg, bits B12 to B16).

[0072] In an exemplary scenario, an initiator WTRU transmitting to a recipient WTRU may receive a delayed acknowledgement from the recipient WTRU, such as a delayed ACK, a delayed BA, a HT delayed BA extension, a multi-WTRU ACK frame, and / or a multi-WTRU ACK / BA frame. Since each WTRU may have different requirements and each transmission may contain traffic with different QoS requirements, the transmitted packets may have different delay tolerance periods within which an ACK may be received. In another exemplary scenario, before a packet can access the medium, it may have been buffered for a period of time, which means that the packet has experienced some delay.

[0073] Therefore, in some such scenarios, a packet that would normally be acknowledged by, for example, a delayed BA (which would be within its delay tolerance) may need to be acknowledged immediately by an immediate ACK or BA frame to remain within its delay tolerance. Therefore, a mechanism or established procedure needs to be provided so that the WTRU performing the initiating operation indicates and exchanges the precise delay requirements (such as ACK delay and / or delay tolerance) so that the receiving WTRU may select the most appropriate ACK option and the receiving WTRU may transmit an ACK within the corresponding delayed ACK tolerance period.

[0074] According to an example, an efficient ACK establishment and efficient ACK transmission process may be defined to enable the use of an efficient ACK mechanism within a WLAN system. In any of the examples, the WTRU may be an AP or a non-AP. For example, a first WTRU (e.g., an AP or a non-AP WTRU) may establish a new ACK arrangement with a second WTRU (e.g., an AP or a non-AP WTRU). For example, the second WTRU may be an AP associated with the first WTRU. In another example, the second WTRU may be another non-AP WTRU. The first WTRU may send an ACK establishment request frame to the second WTRU to initiate a new ACK establishment process with the second WTRU.

[0075] Figure 4A The frame format of an exemplary ACK setup request frame 400A that can be used to establish an ACK for a multi-WTRU ACK / BA mechanism is shown. The exemplary ACK setup request frame 400A may include, but is not limited to, any of the following fields and / or subfields (which may be embedded in other fields, repeated within the frame 400A (e.g., based on WTRU or service), and / or may appear in other orders within the ACK setup request frame 400A): preamble 402; MAC header 403; frame body 404; frame check sequence (FCS) field 406; service field 4081 ... 408 N ; Service identification field 410; Priority information field 412; Expected generation period / frequency field 414; Expected generation time field 416; Expected size field 418; Detailed delay tolerance indication field 420; Delay tolerance field 422; Retransmission time field 424; Discard time field 426; Delay tolerance classification (DTC) field 428; and / or ACK type field 4321 ... 432 K The ACK setup request frame 400A may include other fields not shown. The fields within the ACK setup request frame 400A will be described in detail below.

[0076] The preamble field 402 may include training signals and / or information about how the receiving (i.e., receiving) WTRU decodes the ACK setup request frame 400A and / or information about the acknowledgement setup. The frame body field 404 may carry information about the ACK setup for the receiving WTRU. The preamble field 402 and / or the frame body 404 or any portion of the frame 400A may include the traffic fields 4081 ... 408 N The business fields 4081…408 NEach of which may include, but is not limited to, any of the following information: information about one or more corresponding service flows that may be identified by a service identifier (TID); information about one or more packets; and / or information about one or more access categories (ACs) for an initiating WTRU for which an ACK mechanism is being established and / or arranged.

[0077] For example, each business field 4081...408 N It may include, but is not limited to, one or more of the following fields: a service identification field 410; a priority field 412; an expected generation period / frequency field 414; an expected generation time field 416; an expected size field 418; a detailed delay indication field 420; and an ACK type field 430. The service identification (ID) field 410 may include service identification information including, but not limited to, the following information: a TID for a service flow; an access category for a service; a priority; a packet / aggregate packet sequence number; a packet batch number (i.e., a batch or collection number of packets); and / or some identification defined by the WTRU that initiates (performs the transmission operation).

[0078] The priority field 412 may indicate a priority of the traffic and / or the initiating WTRU, such as a user priority (UP). The expected generation period / frequency field 414 may indicate, for example, a generation period and / or frequency of the traffic and / or the indicated WTRU. The expected generation time field 416 may indicate a generation time of the traffic and / or WTRU, for example, by indicating an offset from a time reference (e.g., by using a timing synchronization function (TSF) timer) or by indicating an absolute time or other time reference.

[0079] The expected size field 418 may indicate the expected size of data generated for the indicated service or the initiating WTRU. The detailed delay indication field 420 may indicate detailed delay tolerance and may include, but is not limited to, the following subfields: a delay tolerance field 422; a retransmission time field 424; a discard time field 426; and / or a delay tolerance classification field 428. The delay tolerance field 422 may indicate the delay tolerance that packets of the indicated service can tolerate. For example, the delay tolerance field 422 may be specified in nanoseconds (ns), microseconds (μs), milliseconds (ms), time units (TUs), or other time units. In an example, the delay tolerance field 422 may be specified based on: the generation time of the packet; the transmission of the UL request frame; a certain point in time; and / or certain values ​​of the TSF timer.

[0080] The retransmission time field 424 may indicate the time at which the (initiating) WTRU performing a transmission operation believes that the transmitted packet (e.g., a single packet or an aggregate packet) has not been correctly received and will start a retransmission process for the packet (or aggregate packet). The retransmission time field 424 may be indicated as an absolute time or a time period starting from a certain point in time (such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet). In one example, after the retransmission time indicated by the retransmission time field 424 has elapsed, the (receiving) WTRU performing a reception operation may decide not to transmit an ACK frame, such as an ACK / BA or a multi-WTRU ACK / BA, even if such an ACK frame has not been previously transmitted for the indicated packet.

[0081] The discard time field 426 may indicate a point in time at which a WTRU performing a transmission operation may consider the packet (e.g., a single packet or an aggregated packet) as obsolete and may not attempt to transmit or retransmit the packet. The discard time field 426 may be indicated as an absolute time or a period of time starting from a certain point in time, such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet. After the discard time indicated by the discard time field 426, the WTRU (e.g., AP) may decide not to schedule or allocate resources for the transmission of the indicated packet.

[0082] The delay tolerance classification field 428 may be extracted as a delay tolerance level. For example, the delay tolerance level may include: level 0 which may be associated with a delay tolerance of 0ns-50ns and level 1 which may be associated with a delay tolerance of 51ns-100ns, and other similar levels may also be defined. The tolerance interval may be calculated using the delay tolerance classification level (or delay tolerance classification number or value). The delay tolerance classification level and the associated delay tolerance interval may be indicated, for example, in the delay tolerance classification field 428. In one example, each of the delay tolerance classification levels may be associated with a predefined or preset value of a corresponding delay tolerance interval, a retransmission time, a discard time, and / or an expected ACK type.

[0083] The ACK type field 430 may be used to indicate the type of acknowledgment applicable to the indicated service or initiating WTRU. For example, the ACK types may include, but are not limited to: SU ACK; immediate SU BA; SU delayed BA; SU HT delayed BA; immediate multi-WTRU ACK / BA; delayed multi-WTRU ACK / BA; immediate MU ACK; immediate MU BA; delayed MU BA; and / or delayed MU HT delayed BA. Each ACK type may be associated with a delay tolerance classification (DTC). For example, delay tolerance classification level 0 (DTC0) may be associated with immediate SU ACK / BA, delay tolerance classification level 1 (DTC1) may be associated with SU delayed BA, and delay tolerance classification level 2 (DTC2) may be associated with delayed multi-WTRU ACK / BA. In one example, when a packet is generated, the UL request message for the packet may indicate the DTC level as DTC2 (i.e., tolerance for longer delays). Therefore, when resources are quickly allocated for a packet with delay tolerance classification DTC2, it may be assumed that the packet may be acknowledged by a delayed multi-WTRU ACK / BA. If resources are allocated for the packet at a later time, such that the delay tolerance classification of the packet becomes DTC0 (i.e., requires shorter delays / less tolerance for long delays), the packet may need to be directly acknowledged using an immediate SU ACK / BA. Multiple types of ACKs may be used for the indicated traffic (e.g., ACK type fields 4321 ... 432 K ), and each ACK type can be associated with a delay tolerance category.

[0084] A receiving WTRU that receives an ACK setup request frame, such as ACK setup request frame 400A, may respond immediately or after a delay with an ACK setup response frame. An exemplary design of the ACK setup response frame may include a preamble and / or a frame body. The preamble may include a training signal and information about how to decode the frame and / or about the establishment of an acknowledgement for a WTRU performing a receive operation. The frame body may carry information about the establishment of an acknowledgement for the WTRU performing the receive operation. The preamble and / or the frame body or any portion of the frame may include, but is not limited to, one or more of the following fields: a status field; an alternative value field for a detailed delay indication, which may include a retransmission time, a drop time, and / or a delay tolerance classification field; and / or an alternative value field for an ACK type. The fields within an exemplary ACK setup response frame are described below.

[0085] The status field of the ACK setup response frame may indicate the status of the ACK setup process, including but not limited to the following statuses: success; failure; failure without reason; and / or failure in the presence of an alternative value.

[0086] The alternative value field for detailed delay indication of the ACK setup response frame may indicate the detailed delay tolerance and may include a retransmission time field and / or a delay tolerance classification field. The retransmission time field may indicate a time at which the WTRU performing a transmission operation may consider that the transmitted packet (e.g., a single packet or an aggregated packet) has not been correctly received and will start a retransmission process for the packet. The retransmission time may be indicated as an absolute time or a time period starting from a certain point in time (such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet). In one example, after the retransmission time has elapsed, the WTRU performing a reception operation may decide not to transmit an acknowledgment frame, such as an ACK / BA, a multi-WTRU ACK / BA, even if such an acknowledgment has not been previously transmitted for the indicated packet.

[0087] The discard time field may be used to indicate a point in time at which a WTRU performing a receive operation may decide not to schedule or allocate resources for the transmission / retransmission of the packet. For example, the discard time may be specified based on an expected generation time, based on the first transmission of the packet, or based on the transmission of a first UL request frame for a frame containing the packet. As described above, the delay tolerance classification may be extracted into several levels, such as level 0 which may be associated with a delay tolerance of 0ns–50ns and level 1 which may be associated with a delay tolerance of 51ns–100ns, although other levels may exist. The delay tolerance classification number may be used to calculate a tolerance interval. The delay tolerance classification level and the associated delay tolerance interval may be indicated. Each of the delay tolerance classification levels may be associated with a set of values ​​corresponding to a delay tolerance interval, a retransmission time, a discard time, and / or a discard time, as well as an expected ACK type.

[0088] The alternative value field for ACK type may be used to indicate the type of acknowledgment applicable to the indicated service or WTRU. The ACK type may include, but is not limited to, any of the following: SU ACK; immediate SU BA; SU delayed BA; SU HT delayed BA; immediate multi-WTRU ACK / BA; delayed multi-WTRU ACK / BA; immediate MU ACK; immediate MU BA; delayed MU BA; and / or delayed MU HT delayed BA.

[0089] Each ACK type may be associated with a delay tolerance classification (DTC). For example, delay tolerance classification level 0 (DTC0) may be associated with an immediate SU ACK / BA, delay tolerance classification level 1 (DTC1) may be associated with a SU delayed BA, and delay tolerance classification level 2 (DTC2) may be associated with a delayed multi-WTRU ACK / BA. In one example, when a packet is just generated, the UL request for the packet may indicate DTC2. When resources are quickly allocated for a packet with DTC2, the packet may be acknowledged by a delayed multi-WTRU ACK / BA. If resources are allocated for the packet at a later time, when the packet becomes DTC0, then the packet may be directly acknowledged with an immediate SU ACK / BA.

[0090] Figure 4B A flow chart of an exemplary ACK request establishment process 400B within a WLAN system is shown. The exemplary WLAN system may include an AP 440, a WTRU 442, and other devices not shown. The AP 440 may be equivalent to a non-AP WTRU (i.e., a non-APSTA), and similarly, the WTRU 442 may be an AP or a non-AP WTRU. In an example, the AP 440 and the WTRU 442 may be part of the same BSS, and / or the WTRU 442 may be associated with the AP 440. At 446, the AP 440 may specify each of the following: the delay tolerance classification level, the value of their associated delay tolerance interval, and / or the type of reply they are associated with. For example, the AP 440 may provide this information to the WTRU 442 (and other devices not shown) using a beacon 445 or similar short beacon, a probe response, other types of control frames, management frames, data, frame extensions, and / or other types of frames.

[0091] The WTRU 442 may send an ACK setup request frame 448 to the AP 440. After receiving the ACK setup request frame 448, the AP 440 may respond to the WTRU 442 immediately or after a delay with an ACK setup response frame 450. In an example, via the ACK setup response frame 450, the AP 440 may accept or reject the proposed detailed delay tolerance indication and / or associated ACK type (which may be associated with a delay tolerance classification level), or reject the value by replying with an alternative value.

[0092] If the requesting WTRU 442 finds that the alternative values ​​proposed by the AP 440 for the delay tolerance indication and / or the associated ACK type are acceptable, the WTRU 442 may further respond to the alternative values ​​by sending another ACK setup request frame (not shown) with the proposed values, for which the AP 440 may send another ACK setup response frame (not shown) with the status field set to "success." If the requesting WTRU 442 finds that the alternative values ​​are not acceptable, the WTRU 442 may resend an ACK request frame (not shown) with new values ​​for the detailed delay tolerance indication and / or ACK type (which may be associated with different delay tolerance classification levels).

[0093] In another example, the detailed delay tolerance indication and / or ACK type (which may be associated with different delay tolerance classification levels) may be included in the establishment process for, for example, BA, delayed BA, HT delayed BA extension, and / or multi-WTRU ACK / BA. In another example, any part of the ACK establishment request and response frame or any combination thereof may be implemented as any of the following frames: a control frame or management frame, such as an action frame; an action but no ACK frame; other types of management frames; control frames; extended frames; null data packet (NDP) frames; and / or NDP frames carrying MAC information. In addition, the detailed delay tolerance indication and / or ACK type may be additionally or alternatively implemented as an information element, sub-element, set or subset of fields, or sub-field of a management frame, control frame, extended frame, NDP frame, or data frame, or as part of a MAC / PLCP header.

[0094] In another example, the WTRU may indicate delay tolerance and preferred acknowledgment options to the AP within the UL request. Figure 5 The frame format of an exemplary UL request frame 500 with a delay tolerance indication and an ACK type is shown. The UL request frame 500 may include a preamble 502, a MAC header 503, a frame body 504, and an FCS field 506. The preamble 502 may include a training signal and / or information for a (receiving) WTRU performing a receiving operation on how to decode the UL request frame 500 and / or on acknowledgment establishment. The frame body 504 may carry information on acknowledgment establishment for the WTRU performing a receiving operation.

[0095] The preamble 502 and / or the frame body 504 or any part of the UL request frame 500 may include one or more of the service fields 1-N, and may include service fields 5081...508 N One or more of the following. Business fields 5081…508 NEach of which may include, but is not limited to, any of the following information: information about one or more corresponding service flows; information about one or more packets; and / or information about one or more access categories (ACs) for which the initiating WTRU is requesting resources for transmission.

[0096] For example, each business field 5081...508 N It may include, but is not limited to, one or more of the following fields: a service identification field 510; a priority field 512; an expected size field 514; a detailed delay indication field 520; and an ACK type field 530. The service identification (ID) field 510 may include service identification information, including but not limited to the following information: a TID for a service flow; an access category for a service; a priority; a packet / aggregate packet sequence number; a packet batch number (i.e., a batch or set number of packets); and / or some identification defined by the WTRU that initiates (performs the transmission operation).

[0097] The priority field 512 may indicate the priority of the service and / or the initiating WTRU, such as a user priority (UP). The size field 514 may indicate the size of the data buffered for the indicated service or WTRU. The detailed delay indication field 520 may indicate the detailed delay tolerance for the indicated service and may include, but is not limited to, the following subfields: a delay tolerance field 522; a retransmission time field 524; a discard time field 526; and / or a delay tolerance classification field 528. The delay tolerance field 522 may indicate the delay tolerance that the packets of the indicated service can tolerate. For example, the delay tolerance field 522 may be specified in nanoseconds (ns), microseconds (μs), milliseconds (ms), time units (TUs), or other time units. In an example, the delay tolerance field 522 may be specified based on: the generation time of the packet; the transmission of the UL request frame 500; a certain point in time; and / or certain values ​​of the TSF timer.

[0098] The retransmission time field 524 may indicate the time at which the (initiating) WTRU performing a transmission operation believes that the transmitted packet (e.g., a single packet or an aggregate packet) has not been correctly received and will start a retransmission process for the packet (or aggregate packet). The retransmission time field 524 may be indicated as an absolute time or a time period starting from a certain point in time, such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet. In one example, after the retransmission time indicated by the retransmission time field 424 has elapsed, the (receiving) WTRU performing a reception operation may decide not to transmit an ACK frame, such as an ACK / BA or a multi-WTRU ACK / BA, even if such an ACK frame has not been previously transmitted for the indicated packet.

[0099] The discard time field 526 may indicate a point in time at which a WTRU performing a transmission operation may consider the packet (e.g., a single packet or an aggregated packet) as obsolete and may not attempt to transmit or retransmit the packet. The discard time field 526 may be indicated as an absolute time or a period of time starting from a certain point in time, such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet. After the discard time indicated by the discard time field 526, the WTRU (e.g., AP) may decide not to schedule or allocate resources for the transmission of the indicated packet.

[0100] The delay tolerance classification field 528 may be extracted as a delay tolerance level. For example, the delay tolerance level may include: level 0 which may be associated with a delay tolerance of 0ns-50ns and level 1 which may be associated with a delay tolerance of 51ns-100ns, and other similar levels may also be defined. The tolerance interval may be calculated using the delay tolerance classification level (or delay tolerance classification number or value). The delay tolerance classification level and the associated delay tolerance interval may be indicated, for example, in the delay tolerance classification field 528. If such a delay tolerance classification has been established or predetermined, the delay tolerance classification field 528 may simply include a DTC level value. In one example, each of the delay tolerance classification levels may be associated with a delay tolerance interval, a setting value for a retransmission time and / or a discard time, and an expected ACK type.

[0101] The ACK type field 530 may be used to indicate the type of acknowledgment being requested for the indicated service. For example, the ACK type may include, but is not limited to: SU ACK; immediate SU BA; SU delayed BA; SU HT delayed BA; immediate multi-WTRU ACK / BA; delayed multi-WTRU ACK / BA; immediate MU ACK; immediate MU BA; delayed MU BA; and / or delayed MU HT delayed BA. The ACK type within the ACK type field 530 may be associated with a DTC. For example, delay tolerance classification level 0 (DTC0) may be associated with immediate SU ACK / BA, delay tolerance classification level 1 (DTC1) may be associated with SU delayed BA, and delay tolerance classification level 2 (DTC2) may be associated with delayed multi-WTRU ACK / BA. When a packet is first generated, the UL request frame 500 for the packet may indicate DTC2 (i.e., tolerance for longer delays). When resources are quickly allocated for having the packet, the packet may have DTC2 (i.e., tolerance for longer delays) so that the packet may be acknowledged by a delayed multi-WTRU ACK / BA. If resources are allocated for a packet at a later time, when the packet classification has become DTC0 (ie, requiring shorter delays / less tolerance for long delays), then the packet may be directly acknowledged using an immediate SU ACK / BA.

[0102] In one example, any portion of the UL request frame 500 or any combination thereof may be implemented as any of the following frames: a control frame or management frame, such as an action frame; an action but no ACK frame; other types of management frames; a control frame; an extended frame; a null data packet (NDP) frame; and / or an NDP frame carrying MAC information. In addition, the detailed delay tolerance indication and / or ACK type may be additionally or alternatively implemented as an information element, sub-element, set or subset of fields, or subfields of a management frame, a control frame, an extended frame, an NDP frame, or a data frame, or as part of a MAC / PLCP header. The detailed delay tolerance indication and / or ACK type may also be implemented as an information element, sub-element, set or subset of fields or subfields of a management frame, a control frame, an extended frame, an NDP frame, or a data frame, or as part of a MAC / PLCP header.

[0103] In another example, multiple mechanisms may be used to announce an ACK scheme. A WTRU (e.g., an AP) may use a frame (e.g., a beacon frame or a trigger frame) to announce an ACK scheme and a scheduled ACK time for the ACK scheme so that the WTRU, which is expected to transmit, knows when to expect an ACK. According to an example, as described herein, announcement of the ACK scheme may use a transmission opportunity (TXOP) type and / or expected ACK time indication procedure in a beacon and / or trigger frame.

[0104] In one example, a beacon / short beacon frame may announce a schedule for one or more subsequent beacon (sub)intervals, which may be based on any of the following exemplary information: a trigger frame at the start of a beacon (sub)interval; one or more intervals for one or more WTRUs to transmit and receive; and / or one or more expected ACK times for transmitting an ACK to a WTRU. The expected ACK times may function similarly to a target beacon transmission time (TBTT) for a beacon, which may be delayed due to an occupied wireless medium / channel. However, each expected ACK (e.g., multi-WTRU ACK, multi-WTRU ACK / BA, or delayed BA) may be transmitted at the target time without taking into account any prior delays in transmitting an acknowledgment frame.

[0105] In one example, a trigger frame may be transmitted at the start of a beacon (sub) interval, a TXOP, a target wake-up time (TWT), or a restricted access window (RAW). The trigger frame may include, but is not limited to, any one or more of the following information: a TXOP type field; a WTRU group field; an ACK type field; and / or an expected ACK time field. The information fields that may be included in the trigger frame are described in more detail below.

[0106] The TXOP type field may indicate the TXOP type following the trigger frame. Examples of TXOPs include, but are not limited to, the following types: SU; MU; SU MIMO; SU OFDMA; SU OFDMA / MIMO; MU OFDMA; MU MIMO; and / or MU OFDMA / MIMO. The WTRU Group field may indicate one or more WTRUs or groups of WTRUs that have some common functionality, such as: allowed to transmit in the UL; expected to receive DL traffic; and / or expected to participate in MU transmissions. The relative order of the WTRU groups or the order of the WTRUs indicated in the trigger frame may imply the time slots in which the WTRUs access the DL and / or UL medium within the TXOP / beacon (sub)interval following the trigger frame. In the case of MU transmission, a fixed number of WTRUs (such as N WTRUs) may be expected to be grouped together for MU transmission or reception, and another N WTRUs may be expected to be grouped together in a second MU group. The number N may be specified, for example, in the preamble or the frame body or any portion of the frame. The time slot in which the n-th MU group (1≤n≤N) is expected to access the medium (eg, transmit and / or receive, UL and / or DL) may be implied by the order of the WTRUs contained in the TXOP Type field.

[0107] The ACK Type field may indicate one or more ACK types that may be used by the AP within the TXOP / beacon (sub)interval following the trigger frame. Examples of ACK types include, but are not limited to: multi-WTRU ACK / BA; immediate SU ACK / BA; delayed SU BA; immediate multi-WTRU ACK / BA (e.g., M-BA); and / or delayed multi-WTRU ACK / BA (e.g., M-BA). The Expected ACK Time(s) field may indicate one or more expected ACK times during the TXOP / beacon (sub)interval following the trigger frame (or similar beacon frame). For example, an acknowledgment frame (such as delayed multi-WTRU ACK / BA or delayed SU BA) may be expected to arrive x ms (e.g., x ms may be 1.5 ms, 3 ms, or 4.5 ms) after a reference time point (such as the end of the currently transmitted frame, or the start of the beacon (sub)interval).

[0108] In one example, any portion or any combination of the trigger frame or beacon frame described herein may be implemented as a control frame or management frame, including but not limited to: an action frame; an action but no ACK frame; any other type of management frame; any other type of control frame; an extended frame; an NDP frame; and an NDP frame carrying MAC information. In addition, the ACK type may be additionally or alternatively implemented as an information element, sub-element, field set or subset, or subfield of a management frame, a control frame, an extended frame, an NDP frame, or a data frame, or as part of a MAC / PLCP header.

[0109] In another example, the trigger frame may be, but is not limited to, any of the following types of frames: ACK, BA, multi-WTRU ACK / BA, any other type of acknowledgement frame, control frame, extended frame, management frame, data frame, and / or NDP frame. Such a trigger frame may include an indication or field indicating that the current frame is being used as a trigger frame.

[0110] To further enable efficient ACK establishment and ACK mechanism, a delay tolerance indication procedure may be used within a data or aggregate frame. As part of the delay tolerance indication procedure, a packet (e.g., a single (data) packet, a HE packet, and / or an aggregate packet), such as an A-MPDU or A-MSDU, may carry any of the following information (described in detail below) in its preamble and / or frame body or any other part: a detailed delay indication field; a delay tolerance field; a retransmission time field; a discard time field; and / or a delay tolerance classification field.

[0111] The detailed delay indication field may indicate the detailed delay tolerance for the indicated service, and may further include, but is not limited to, any of the following subfields: a delay tolerance field; a retransmission time field; a discard time field; and / or a delay tolerance classification. For example, the delay tolerance field may indicate the delay tolerance that the packets of the indicated service can tolerate. The delay tolerance may be specified in ns, μs, ms, TU, or other time units. The delay tolerance may be specified based on: starting from the generation time of the packet; starting from the transmission of the frame; starting from a certain point in time; or by using certain values ​​of the TSF timer.

[0112] The retransmission time field may indicate a time at which a transmitting WTRU may consider that a transmitted packet (e.g., a single packet or an aggregate packet) was not received correctly and will start a retransmission process for the packet. The retransmission time may be indicated as an absolute time or a period of time starting from a certain point in time, such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet. After the retransmission time has elapsed, the receiving WTRU may decide not to transmit an acknowledgment frame (such as an ACK / BA or a multi-WTRU ACK / BA), even if such an acknowledgment has not been previously transmitted for the packet.

[0113] The discard time field may indicate a time at which a WTRU performing a transmission operation may consider the packet discarded and will not attempt to transmit or retransmit the packet. The discard time field may be indicated as an absolute time or a period of time starting from a certain point in time, such as the generation time of the packet, the transmission time of the packet, or the end time of the transmission of the packet. After the discard time, the WTRU (e.g., AP) may decide not to schedule or allocate resources for the retransmission of the indicated packet.

[0114] The delay tolerance classification field may be extracted as a delay tolerance level. For example, the delay tolerance level may include: level 0 which may be associated with a delay tolerance of 0ns–50ns and level 1 which may be associated with a delay tolerance of 51ns–100ns, and other similar levels may also be defined. The tolerance interval may be calculated using the delay tolerance classification number. The delay tolerance classification level and the associated delay tolerance interval may be indicated. If such a delay tolerance classification has been established or predetermined, the field may simply include a DTC level value. In one example, each of the delay tolerance classification levels may be associated with a delay tolerance interval, a setting value for a retransmission time and / or a discard time, and an expected ACK type.

[0115] The ACK type field may be used to indicate the type of acknowledgment being requested for the indicated service. For example, the ACK type may include, but is not limited to: SU ACK; immediate SU BA; SU delayed BA; SU HT delayed BA; immediate multi-WTRU ACK / BA; delayed multi-WTRU ACK / BA; immediate MU ACK; immediate MU BA; delayed MU BA; and / or delayed MU HT delayed BA. The ACK type may be associated with a DTC. For example, delay tolerance classification level 0 (DTC0) may be associated with immediate SU ACK / BA, delay tolerance classification level 1 (DTC1) may be associated with SU delayed BA, and delay tolerance classification level 2 (DTC2) may be associated with delayed multi-WTRU ACK / BA. In one example, when a packet is just generated, the UL request for the packet may indicate DTC2 (i.e., tolerance for longer delays). If resources are quickly allocated for the packet, the packet may have DTC2 (i.e., tolerance for longer delays) so that the packet may be acknowledged by a delayed multi-WTRU ACK / BA. If resources are allocated for a packet at a later time, when the packet classification has become DTC0 (ie, requiring shorter delays / less tolerance for long delays), then the packet may be directly acknowledged using an immediate SUACK / BA.

[0116] Figure 6A flow chart of an exemplary high-efficiency ACK transmission process 600 within a WLAN system is shown. The exemplary WLAN system may include an AP 602 and a WTRU 604, as well as other devices not shown. The AP 602 may be equivalent to a non-AP WTRU (i.e., a non-AP STA), and similarly, the WTRU 604 may be an AP or a non-AP WTRU. In an example, the AP 602 and the WTRU 604 may be part of the same BSS, and / or the WTRU 604 may be associated with the AP 602. At 608, the AP 602 may specify each of the following: a delay tolerance classification level, a value of their associated delay tolerance interval, and / or a type of acknowledgement they are associated with. For example, the AP 602 may provide this information to the WTRU 604 (and other devices not shown) using a beacon 610 or similar short beacon, a probe response, other types of control frames, management frames, data, frame extensions, and / or other types of frames.

[0117] The WTRU 604 may perform an ACK setup procedure 615 with the AP 602 to create a list of detailed delay tolerance descriptions, associated delay tolerance classification levels, and / or associated acknowledgement types. The ACK setup procedure 615 may be accomplished by exchanging one or more rounds of ACK setup request frames (one or more) 612 and ACK setup response frames (one or more) 614. In an example, a WTRU category indication, such as a sensor or meter (which may be inserted but not shown), may hint to the WTRU 604 certain delay profiles, delay tolerance classifications / descriptions, and / or ACK types.

[0118] The AP 602 may announce a detailed delay tolerance description, delay tolerance classification level, and / or ACK type for one or more beacon (sub) intervals by sending a beacon 616 (or similar short beacon, other control frame, management frame, data frame, extended frame, NDP, or other type of frame). The AP 602 may also announce one or more expected ACK times for one or more beacon (sub) intervals via the beacon 616.

[0119] The WTRU 604 may request resource allocation for sending packets by sending a UL request frame 618 to the AP 602. When sending the UL request frame 618, the WTRU 604 may evaluate the delay tolerance of its locally cached traffic and provide a delay tolerance indication for the indicated traffic within the UL request frame 618, for example, by providing a detailed delay tolerance description and / or delay tolerance classification level that may have been previously announced by the AP 602 (e.g., via the beacon 610) or previously negotiated. The WTRU 604 may include the requested ACK type within the UL request frame 618.

[0120] The WTRU 604 may send its packets for the AP 602 by acquiring a channel or when the AP 602 allocates resources to the WTRU 604 via resource allocation 620. When the WTRU 604 sends its packet(s) (e.g., a single packet, an aggregated packet, or a packet as part of a MU transmission) to the AP 602 via a packet transmission 622, the WTRU 604 may evaluate the delay tolerance of the packet(s) it sends and indicate the delay tolerance with the packet within the packet transmission 622, for example, by including a detailed delay tolerance description and / or by using a delay tolerance classification level. The WTRU 604 may include a requested ACK type within the packet transmission 622, which may be associated with the indicated delay tolerance classification level. The delay tolerance description, delay tolerance classification level, and / or requested ACK type may be included anywhere within the preamble, and / or frame body, and / or packet transmission frame 622.

[0121] The AP 602 (i.e., the receiving / receiving WTRU of the packet transmission frame 622) may send an ACK frame 624 to the WTRU 604 to acknowledge the received packet(s) from the WTRU 604 in accordance with the indicated delay tolerance profile, delay tolerance classification level, and / or requested ACK type (i.e., indicated within the packet transmission 622). The timing of transmission of the appropriate ACK type may depend on the provided delay tolerance profile and / or delay tolerance classification level.

[0122] The transmitting WTRU 604 may wait until the indicated expected ACK time for an acknowledgement of the packet it has transmitted. If the transmitted packet is not acknowledged by an acknowledgement (such as a delayed BA or delayed multi-WTRU ACK / BA (e.g., M-BA)) from the AP 602 before the expected ACK time, the transmitting WTRU 604 may initiate a retransmission procedure (not shown). For example, if the transmitting WTRU 604 has indicated in the transmitted packet, such as in transmission 622, that it needs to acknowledge before the indicated expected acknowledgement time, then if the retransmission time for the packet has expired, then the WTRU 604 may assume that the packet was not correctly received by the receiving AP 602. In this case, the transmitting WTRU 604 may initiate a retransmission procedure. If the discard time for a particular packet has expired, then the transmitting WTRU 604 may no longer attempt to transmit or retransmit the packet, and the AP 602 may choose not to allocate any resources for transmission and / or retransmission of the packet.

[0123] For example, by using Figure 2 and 3, a multi-WTRU ACK / BA mechanism may provide greater efficiency in acknowledging transmissions from multiple WTRUs than sending separate ACK frames. However, an efficient and appropriate ACK transmission process may be required to address issues such as minimizing latency for all WTRUs and providing a proper failure recovery process when the transmitted data or ACK / BA is not correctly received. In one example, a process for efficient acknowledgment transmission with feedback, buffering, and indication of an operating mode change may be defined as follows.

[0124] In one example, an acknowledgment frame, such as an ACK BA, a multi-WTRU ACK / BA (e.g., M-BA), or a MU block ACK request (BAR), may carry additional information, such as a buffer indication field, a feedback field, and / or an operation mode change field as described below. The inclusion of these fields and information within the ACK frame may enable the WTRU to provide efficient and fast communication to one or more WTRUs, such as the destination WTRU of the ACK frame, to achieve high efficiency.

[0125] In one example, a valid data packet or other type of packet transmitted by a WTRU may be considered a valid ACK for a transmission packet previously transmitted to the same WTRU. A data packet(s) or any other type of frame that may contain an acknowledgment field may be considered a valid acknowledgment frame for a transmission packet previously transmitted to the same WTRU. In another example, an aggregate frame (such as an A-MPDU or A-MSDU) containing an ACK, BA, and / or a multi-WTRU ACK / BA (e.g., M-BA) transmitted by a WTRU may be considered a valid acknowledgment frame for a transmission packet previously transmitted to the same WTRU.

[0126] In another example, the Buffer Indication field may include a buffer status for each access category, each traffic flow identified by a TID, and / or total buffered traffic at the WTRU. The buffer status may include, but is not limited to, any of the following information: number of packets; estimated total time to transmit the packets; and / or total bytes per packet or packets, which may be per access category (AC), or TID, or for the entire WTRU. A delay requirement may be specified per packet, or per AC, or per TID in the ACK frame so that the destination WTRU of the ACK frame can allocate resources for the buffered traffic.

[0127] In another example, the feedback field within the ACK frame may include, but is not limited to, any of the following feedback information: feedback for resource blocks (RBs), channels (one or more), and / or subcarriers; detailed or compressed channel state information (CSI) feedback; detailed or compressed channel quality indication (CQI); detailed or compressed beamforming feedback; adjustment and coding scheme (MCS) feedback; and / or preference indications, such as preferred channel indications, preferred RB indications, and preferred MCS indications. The feedback field within the ACK frame may provide information to one or more WTRUs, such as the destination WTRU of the ACK frame. In an example, the feedback field may include a relative amount (difference) or MCS performance value. For example, the feedback field may include the current RB(s), the preferred or alternative RB(s), and a value indicating the difference in CQI between the current RB and the alternative RB. In this case, the quality or CQI of the alternative RB(s) may be better or worse than that of the current RB(s). The destination WTRU of the acknowledgment frame may adapt resource allocation, MCS settings, beamforming settings, SU or MU-MIMO settings in subsequent transmissions based on the information in the feedback field.

[0128] In one example, the Operation Mode Change field within the ACK frame may include the scheduled transmission mode and reception mode of the WTRU(s) performing the transmission operation for the ACK frame. For the transmission and reception modes, the operation mode change may include a change in one or more of the following parameters: MU capability; SU / MU OFDMA capability; SU / MU MIMO capability; number of SUs of spatial streams (Nss); MU Nss; Nss; operating bandwidth; operating channel; operating resource block width; receive monitoring RB / channel; and / or power-off period. The Operation Mode Change field may include a time or delay after which the indicated operation mode change takes effect.

[0129] The buffer indication field, feedback field, and / or operation mode change field, and any subset thereof, may be implemented as any other field, subfield, information element, MAC and / or PHY header, and may be included in any type of frame, such as a control frame, a management frame, a data frame, an extended frame, an NDP frame, and / or an aggregated packet, such as an A-MPDU or an A-MSDU. The buffer indication field, feedback field, and / or operation mode change field, and any subset thereof, may be implemented in a field, such as a QoS field, an HT / VHT control field, or a HE control field in a MAC or PHY header.

[0130] According to an exemplary efficient acknowledgment procedure, a transmitting (initiating) WTRU (e.g., an AP) may transmit a DL (SU or MU) packet to one or more WTRUs as part of, for example, a control frame, a management frame, a data frame, an extended frame, an aggregated packet, and / or an NDP frame. Within the DL packet, the transmitting WTRU may provide a receiving (receiving) WTRU with resource allocations to transmit UL packets, such as acknowledgment packets or data packets. The transmitting WTRU may also provide information about the broadcast / multicast channels / RBs that the receiving WTRU should subsequently monitor to obtain broadcast / multicast information. The receiving WTRU may transmit an acknowledgment frame, such as an ACK, BA, multi-WTRU ACK / BA (e.g., M-BA), in a SU or MU PPDU to the transmitting WTRU to acknowledge the received packet.

[0131] In one example, a valid data packet or any other type of packet transmitted by the receiving (receiving) WTRU may be considered a valid ACK frame for a packet previously transmitted to the receiving WTRU. A data packet(s) or any other type of frame having an acknowledgment field for acknowledging a previously received frame may be considered a valid acknowledgment frame for a packet previously transmitted to the receiving WTRU. In one example, an aggregate frame (such as an A-MPDU or A-MSDU) that may contain an ACK, a BA, and / or a multi-WTRU ACK / BA (e.g., M-BA) transmitted by the receiving WTRU may be considered a valid ACK frame for a packet previously transmitted to the receiving WTRU.

[0132] In one example, along with feedback, cache status, and / or scheduled operating mode changes provided using the feedback field, cache status field, and / or operating mode change field, the receiving WTRU (i.e., the WTRU that receives a packet from the transmitting WTRU) may provide additional information, data packets, or other types of packets serving as a valid acknowledgment frame to the transmitting WTRU within the ACK frame.

[0133] After receiving an ACK frame that may include feedback, cache status and / or scheduling operation mode changes, the destination WTRU of the ACK frame (i.e., the transmitting or initiating WTRU of the data packet) may then adjust resource allocation, transmission or reception scheduling, transmission and reception settings, and / or WTRU group allocation, for example based on the received feedback, operation mode changes and cache status.

[0134] In one example, the destination WTRU (i.e., AP) of the ACK frame may allocate resources based on feedback within the ACK frame, such as CSI or CQI feedback, preferred RBs, and / or one or more channel indications. The destination WTRU may allocate RBs and channels based on the feedback to improve performance between the destination WTRU (which is also the initiating WTRU) and the receiving (receiving) WTRU that sent the ACK frame. In one example, the destination WTRU (e.g., AP) of the ACK frame may allocate resources based on the feedback, such as MCS feedback or preferred MCS indications. The destination WTRU may use another MCS based on the feedback information that is more suitable for the channel conditions.

[0135] In another example, the destination WTRU (i.e., AP) may allocate resources based on the operating mode change information in the received ACK frame. For example, the destination WTRU may allocate more or fewer RBs and channels, and / or more or less Nss based on the operating mode change. In another example, the destination WTRU may transmit broadcast / multicast packets to the receiving WTRU on the indicated broadcast / multicast / monitoring RBs and channels. In another example, if the receiving WTRU has indicated that it will turn off power for a certain period of time, the destination WTRU may not allocate any resources or transmit any packets to the receiving WTRU. In another example, the destination WTRU (e.g., AP) may allocate resources based on the buffer status in the received ACK frame. The destination WTRU may allocate more or fewer RBs / channels to the receiving WTRU based on its buffer status and the delay requirements of the buffered packets.

[0136] In one example, the destination WTRU (e.g., AP) may adjust transmit / receive settings based on feedback received in the ACK frame, operating mode changes, buffer status, when communicating with the receiving WTRU. The destination WTRU may switch between SU ​​or MU transmit / receive modes based on any of the following example events: the receiving WTRU instructs the receiving WTRU to switch to SU operating mode in an ACK frame; the receiving WTRU adds or decreases the Nss used; and / or transmits a packet to the receiving WTRU on an RB / channel that the receiving WTRU is monitoring (which may be indicated by the destination WTRU or the receiving WTRU). The destination WTRU of the ACK frame may also adjust the beamforming matrix. If the ACK frame (or the data / NDP frame used as the ACK frame) indicates that the operating mode change takes effect after a time or delay, the destination WTRU may adjust the transmit / receive settings only after a time or delay.

[0137] A further method for achieving efficient ACK transmission within a WLAN system includes a process for multi-WTRU ACK / BA transmission, which allows a WTRU to acknowledge packets received from multiple WTRUs within a common frame or transmission. In an exemplary method, multi-WTRU ACK / BA transmission may use a power save multi-polling (PSMP) process as described below. The PSMP process includes a PSMP sequence that begins with a WTRU (e.g., AP) transmitting a PSMP frame and includes one or more PSMP downlink transmission times (PSMP-DTT) as DL transmission periods and one or more PSMP uplink transmission times (PSMP-UTT) as UP transmission periods.

[0138] In an example of multi-WTRU ACK / BA transmission using the PSMP procedure, the AP (e.g., or any WTRU) may transmit a multi-WTRU ACK / BA to the WTRU during the PSMP-DTT. The transmitted multi-WTRU ACK / BA may be used as a response to a frame transmitted to the AP (e.g., transmitted in the PSMP-UTT immediately preceding the current PSMP-DTT, or transmitted in the previous PSMP-UTT, or transmitted in any beacon (sub) interval before the current PSMP-DTT during which the multi-WTRU ACK / BA frame is transmitted).

[0139] The AP may indicate to the WTRU within a frame transmission (e.g., any control frame, management frame, data frame, extended frame, or other type of frame, such as a beacon, trigger frame, or PSMP frame) that the AP is expected to transmit multiple WTRU ACK / BAs at an indicated PSMP-DTT time. In this case, for power conservation purposes, the WTRU that expects an acknowledgement from the AP may sleep or doze (i.e., enter a power conservation state) until, for example, the indicated PSMP-DTT time.

[0140] Figure 7A message passing diagram of an exemplary multi-WTRU ACK / BA procedure 700 using a PSMP procedure is shown. In the exemplary multi-WTRU ACK / BA procedure 700, it may be assumed that an AP 705 (which may be any WTRU, including a non-AP WTRU) is communicating with WTRUs 701-704 within a WLAN system. The AP 705 may send a beacon 706 to the WTRUs 701-704, which includes an indication (as indicated by the arrow) that the AP 705 will transmit a multi-WTRU ACK / BA frame 726 within one or more PSMP-DTTs 724 (which will occur when the PSMP-DTT 724 is scheduled and has resources allocated to it). The beacon 706 may be a beacon or any control frame, management frame, public action frame, data frame, extension frame, or other type of frame including, for example, a short beacon, a trigger frame, and / or a PSMP frame.

[0141] The scheduled time of the multi-WTRU ACK / BA frame 726 may be indicated according to a TSF timer, which may be an offset from a transmitted frame (e.g., beacon 706) or an offset from a reference time, such as an offset from a target PSMP frame transmission time or the end of a PSMP frame (e.g., PSMP frame 722). The multi-WTRU ACK / BA frame 726 may be an acknowledgement to one or more frames received by the AP 705. For example, the multi-WTRU ACK / BA frame 726 may be an acknowledgement to one or more frames received by the AP 705 during a regular transmission 708, a previous PSMP UTT 710, a scheduled or unscheduled automatic power save delivery (APSD) (not shown), and / or a scheduled medium access such as a target wake time / restricted access window (TWT / RAW) (not shown). Examples of the regular transmission 708 include frames 712 (e.g., data and / or control frames) transmitted from WTRU 701 to AP 705 and frames 714 transmitted from WTRU 704 to AP 705. Examples of PSMP-UTT transmissions include frames 716 transmitted from WTRU 702 to AP 705 and frames 720 transmitted from WTRU 703 to AP 705.

[0142] In another example, transmission of multiple WTRU ACK / BA may be performed using PSMP bursts. Figure 8An exemplary multi-WTRU ACK / BA process 800 messaging diagram using PSMP bursts is shown. In the exemplary multi-WTRU ACK / BA process 800, it may be assumed that an AP 805 (which may be any WTRU, including a non-AP WTRU) is communicating with WTRUs 801-804 within a WLAN system. The AP 805 may notify the WTRUs 801-804 of a PSMP burst by indicating within a first PSMP frame 806 transmission that another PSMP frame 822 will follow the current PSMP sequence. The PSMP sequence may include a PSMP-DTT period (such as PSMP DTT 808), wherein the AP 805 may send downlink frames, such as PSMP 806 (which may initiate the PSMP sequence), a multi-WTRU ACK / BA frame 814, and a frame 816 transmitted from the AP 805 to the WTRU 801.

[0143] For each PSMP sequence, the multi-WTRU ACK / BA frames 814 and 824 may each be used to acknowledge one or more of the transmissions previously received by the AP 805. For example, the multi-WTRU ACK / BA frame 824 may be used to acknowledge the UL frame 818 (transmitted from the WTRU 801 to the AP 805 and including a BA to the AP 805) and the UL frame 820 (transmitted from the WTRU 803 to the AP 805) transmitted during the PSMP-UTT 810 prior to the PSMP 822 within the PSMP sequence.

[0144] In another example, the use of multi-WTRU ACK / BA in the PSMP process may be indicated in any frame, such as a beacon, short beacon, PSMP frame, NDP frame, and in the MAC and / or PLCP header. For example, the use of multi-WTRU ACK / BA in PSMP may be indicated by the HT / VHT / HE Capability field. In another example, the use of multi-WTRU ACK / BA in PSMP may be indicated by setting the WTRU Information Type field to a value that may be reserved, or by using one or more reserved bits in the PSMP WTRU Information Fixed field. In another example, the multi-WTRU ACK / BA may be transmitted as part of an aggregated packet or as part of a MU PPDU.

[0145] In another example, the multi-WTRU ACK / BA transmission process may use the TWT / RAW power saving mechanism. TWT is a function that allows the AP to define a time or a set of times for the WTRU to access the medium. The WTRU and the AP may exchange information (such as the expected activity duration) to allow the AP to control the amount of contention and overlap between competing WTRUs. The AP may use a protection mechanism to protect the channel or wireless medium during the expected activity duration. TWT may be used to reduce network energy consumption by allowing WTRUs to enter a doze state until their TWT is reached. RAW may allow the WTRUs within a BSS to be divided into multiple groups and restrict the WTRUs within a specified group from accessing the channel during a given time period. RAW may help reduce contention and may avoid simultaneous transmissions from a large number of WTRUs that are hidden from each other.

[0146] Fig. 9 A message passing diagram of an exemplary multi-WTRU ACK / BA process 900 performed during a TWT / RAW period is shown. In the exemplary multi-WTRU ACK / BA process 900, it can be assumed that an AP 905 (which can be any WTRU, including a non-AP WTRU) is communicating with WTRUs 901-904 in a WLAN system. During a TWT or RAW period 920, the AP 905 can use a multi-WTRU ACK / BA to effectively acknowledge. For example, the AP 905 can indicate in a frame 906 (e.g., a beacon or short beacon frame) that a TWT / RAW period 920 is scheduled. The frame 906 can indicate that the TWT / RAW period 920 is of SU or MU type.

[0147] The frame 906 may indicate the WTRUs that are allowed to access the medium during the TWT / RAW period 920. The frame 906 may indicate the allocated resources to be used during the TWT / RAW period 920. The frame 906 may also indicate that the TWT / RAW period 920 will be acknowledged using a multi-WTRU ACK / BA. The frame 906 may also indicate that the AP 905 is scheduled to transmit one or more multi-WTRU ACK / BA frames (e.g., multi-WTRU ACK / BA frames 914, 916, and 918) during the TWT / RAW period 920 (e.g., an indication of the number of multi-WTRU ACK / BA frames that the AP 905 may transmit during the TWT / RAW period 920). The target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 914, 916, and 918 may be indicated, for example, in absolute time, or as an offset relative to a reference time, such as an offset relative to the transmission of the current frame 906 or the start of the TWT / RAW period 920. The target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 914, 916, and 918 may be assigned to one or more time slots.

[0148] The TWT / RAW period 920 may start the transmission of a frame 908 from a WTRU, such as an AP 905. The frame 908 may be, for example, part of a (short) beacon or trigger frame, a resource allocation frame, an NDP frame, or a MU frame. The frame 908 may indicate that the TWT / RAW period 920 may be of SU type or MU type. The frame 908 may indicate the WTRUs that are allowed to access the medium during the TWT / RAW period. The frame 908 may indicate the allocated resources that will be used during the TWT / RAW period. The frame 908 may indicate that the TWT / RAW will use a multi-WTRU ACK / BA for acknowledgment. The frame 908 may indicate that the AP 905 is scheduled to transmit one or more multi-WTRU ACK / BAs during the TWT / RAW period 920. The target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 914, 916, and 918 may be indicated, for example, in absolute time, or as an offset relative to a reference time, such as an offset relative to the end of transmission of the current frame or the start of the TWT / RAW period 920. The target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 914, 916, and 918 may be assigned to one or more time slots.

[0149] During the TWT / RAW period 920, the WTRUs 901-905 that are allowed access to the medium (e.g., one or more channels) may transmit frames to their destinations. The transmission may occur in the assigned time slots on the allocated resources. For example, WTRU 910 may send frame 910 to AP 905, and WTRU 903 may send frame 912 to AP 905. Frames 910 and 912 may include a BA to AP 905. In one example, WTRUs 901 and 903 may indicate the ACK type as multi-WTRUACK / BA when transmitting frames 910 and 912. After completing the transmission of frames 910 and 912, WTRUs 901 and 903 (or any of WTRUs 901-905) may sleep or nap until the target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 914, 916, and 918. The receiving WTRU of frames 910 and 912 (AP 905 in this example) may respond with multi-WTRU ACK / BA frames 914, 916, and 918 at target transmission times t1, t2, and t3 to acknowledge the packets received by AP 905. If the medium is busy, AP 905 may delay transmitting any of the multi-WTRU ACK / BA frames 914, 916, and / or 918 until AP 905 has access to the medium. In an example, AP 905 may attempt to transmit the multi-WTRU ACK / BA frames 914, 916, and / or 918 at each of the respective target transmission times t1, t2, and t3 without regard to the delay in transmitting the previous multi-WTRU ACK / BA frame.

[0150] If a transmitting WTRU (e.g., WTRU 901 or WTRU 903) determines that one or more of its frames are not acknowledged by a receiving WTRU (e.g., AP 905) in a received multi-WTRU ACK / BA frame 914, 916, or 918, the WTRU may retransmit the unacknowledged frames the next time the WTRU is allowed access to the medium. If a WTRU (e.g., WTRU 901 or WTRU 903) does not receive a multi-WTRU ACK / BA frame from a receiving WTRU (e.g., AP 905) after transmitting a frame, the WTRU 901 or WTRU 903 may retransmit the unacknowledged frames the next time the WTRU is allowed access to the medium. In one example, a WTRU (e.g., WTRU 901 or WTRU 903) may transmit a block acknowledgment request (BAR) or a multi-WTRU BAR (not shown) as part of a transmission to the WTRU performing the receiving operation (e.g., AP 905) to request an acknowledgment.

[0151] According to an example, a multi-WTRU ACK / BA procedure may be used in conjunction with a triggered TXOP. Fig.10 A multi-WTRU ACK / BA process 1000 is shown within a triggered TXOP period 1014. The WTRUs 1001-1005 (where WTRU 1005 may be an AP) may use a multi-WTRU ACK / BA mechanism within a triggered TXOP period 1014.

[0152] The triggered TXOP period 1014 may be initiated by a frame 1006 transmitted by a WTRU (e.g., AP 1005). The frame 1006 may be, for example, a (short) beacon or trigger frame, a resource allocation frame, an NDP frame, a portion of a MU frame, or any other type of frame. The frame 1006 may include an indication that the triggered TXOP period is of SU or MU type. The frame 1006 may indicate the WTRUs (e.g., WTRUs 1001-1005) that are allowed to access the medium during the triggered TXOP period 1014. The frame 1006 may indicate the allocated resources to be used during the triggered TXOP period 1014. The frame 1006 may indicate that the triggered TXOP period 1014 will use a multi-WTRU ACK / BA to acknowledge received frames. The frame 1006 may indicate that the AP 1005 is scheduled to transmit one or more multi-WTRU ACK / BAs during the triggered TXOP period 1014. The target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 1008, 1010, and 1012 may be indicated, for example, in terms of absolute time, a TSF timer, an offset relative to a reference time, such as an offset relative to the end of transmission of the current frame 1006 or the start of a triggered TXOP period 1014. The target transmission times t1, t2, and t3 of the multi-WTRU ACK / BA frames 1008, 1010, and 1012 may also be assigned to one or more time slots.

[0153] During the triggered TXOP period 1014, the WTRUs (e.g., WTRUs 901-905) that are allowed access to the medium (e.g., one or more channels) may transmit frames to their destinations. For example, WTRU 1001 may transmit frame 1016 to AP 1005, and WTRU 1003 may transmit frame 1018 to AP 1005. Frames 1016 and 1018 may contain a BA to AP 1005. Frame transmissions 1016 and 1018 may occur in the assigned time slots on the allocated resources. WTRUs 1001 and 1003 may indicate in frames 1016 and 1018 that the ACK type is multi-WTRU ACK / BA (e.g., M-BA). After completing the frame transmissions 1016 and 1018, the WTRUs 1001 and 1002 (or any other active WTRUs) may sleep or snooze until the target transmission times t1, t2, and t3 of the multiple WTRU ACK / BA frames 1008, 1010, and 1012. The responding WTRU (e.g., the AP 1005 in this example) that receives the frames 1016 and 1018 may respond by transmitting multiple WTRU ACK / BA frames 1008, 1010, and 1012 for the packets it has received at the target transmission times t1, t2, and t3. If the medium is busy, the AP 1005 may delay transmitting any of the multiple WTRU ACK / BA frames 1008, 1010, and 1012 until the AP 1005 has access to the medium. In another example, the AP 1005 may attempt to transmit the multi-WTRU ACK / BA frames 1008, 1010, and 1012 at each or any of the target transmission times t1, t2, and t3 without considering the delay in transmitting the previous multi-WTRU ACK / BA frame.

[0154] If a WTRU (e.g., WTRU 1001 and / or 1003) determines after transmission that one or more of the frames 1016 and / or 1018 it transmitted were not acknowledged by a receiving WTRU (e.g., AP 1005) in a received multi-WTRU ACK / BA frame 1008, 1010, and / or 1012, the WTRU may retransmit the unacknowledged frames the next time the WTRU is allowed access to the medium. If a WTRU (e.g., WTRU 1001 and / or 1003) does not receive any multi-WTRU ACK / BA frames after transmission, the WTRU may retransmit the unacknowledged frames the next time the WTRU is allowed access to the medium. In an example, a WTRU (e.g., WTRU 1001 and / or 1003) may transmit a BAR or a multi-WTRU BAR (not shown) to the receiving WTRU (e.g., AP 1005) as part of other transmissions to the receiving WTRU.

[0155] Fig.11 FIG. 1 is a flow chart of an exemplary multi-WTRU ACK / BA procedure 1100 performed by a WTRU during a TWT / RAW period. The exemplary multi-WTRU ACK / BA procedure 1100 may be performed, for example, by an AP in a WLAN system using a TWT / RAW procedure. The exemplary multi-WTRU ACK / BA procedure 1100 may correspond to Fig. 9 The exemplary multi-WTRU ACK / BA process 900 in FIG. 1 and thus may include reference to Fig. 9 Any subset of the features or elements described.

[0156] refer to Fig.11 At 1102, the AP may send a first frame indication indicating that a TWT / RAW cycle is scheduled. (The first frame may be, for example, Fig. 9 ) The first frame may include an indication that a multi-WTRU ACK / BA will be used to acknowledge during a TWT / RAW period. The first frame may include a target transmission time for one or more multi-WTRU ACK / BA frames. The target transmission time may enable other WTRUs to sleep or nap when an acknowledgement is not expected and when no transmission is being made.

[0157] At 1104, the AP may send a second frame that triggers the start of the TWT / RAW cycle. (The second frame may be, for example, Fig. 9 In addition to or in lieu of the information contained in the first frame, the second frame may include an indication that a multi-WTRU ACK / BA will be used for acknowledgment during the TWT / RAW period, and / or a target transmission time for one or more multi-WTRU ACK / BA frames. At 1106, the AP may receive at least one frame from at least one WTRU that is allowed to access the medium during the TWT / RAW period. (The at least one frame may be, for example, Fig. 9 ) At 1108, the AP may transmit one or more multi-WTRU ACK / BA frames at the target transmission time during the TWT / RAW period to acknowledge the at least one frame received during the TWT / RAW period. (The one or more multi-WTRU ACK / BA frames may be, for example, Fig. 9 ) The exemplary multi-WTRU ACK / BA process 1100 may be repeated in each TWT / RAW cycle.

[0158] Although the features and elements of the present invention are described in a preferred embodiment in a specific combination, each feature or element can be used alone without the other features and elements in the preferred embodiment, or can be combined or not combined with other features and elements of the present invention in various different combinations. Although the scheme described herein considers the 802.11 specific protocol, it is understood that the scheme described herein is not limited to this situation and can also be applied to other wireless systems. Although SIFS is used to indicate various inter-frame intervals in the examples of the design and process, all other inter-frame intervals (such as RIFS or other agreed time intervals) can also be applied to the same scheme.

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

Claims

1. A station STA operating in a wireless local area network WLAN, the STA comprising: a transceiver coupled to the processor, the transceiver configured to receive a beacon frame, the beacon frame comprising scheduling information for a subsequent time interval and type, wherein based on the indicated type, a single-user SU uplink UL transmission or a multi-user MU UL transmission is to be used during the subsequent time interval, wherein the scheduling information indicates a start time of the subsequent time interval coinciding with transmission of a trigger frame; The transceiver is configured to receive the trigger frame coinciding with the start time of the subsequent time interval; and The transceiver and the processor are configured to transmit at least one of a SU UL frame or a MU UL frame according to the indicated type during the subsequent time interval. 2 . The STA according to claim 1 , wherein the beacon frame includes information indicating at least one STA including the STA that is allowed to transmit a frame during the subsequent time interval.

3. The STA according to claim 1, wherein: The transceiver and the processor are configured to exit a power saving state and enter an active state during the subsequent time interval, and wherein the transceiver is configured to transmit the SU UL frame or the MU UL frame after entering the active state during the subsequent time interval.

4. The STA according to claim 1, wherein the beacon frame or the trigger frame includes at least one of the following: allocated resources to be used during the subsequent time interval, or an indication that a multi-STA acknowledgment / block acknowledgment ACK / BA frame is to be transmitted during the subsequent time interval.

5. The STA of claim 4, the transceiver being configured to receive a multi-STA acknowledgment / block acknowledgment ACK / BA frame acknowledging the transmitted SU UL frame or MU UL frame during the subsequent time interval. 6 . The STA of claim 1 , the transceiver being configured to receive a downlink (DL) MU frame during the subsequent time interval. 7 . The STA according to claim 1 , which is configured as a non-access point (AP) STA, wherein the transceiver is configured to receive the beacon frame and the trigger frame from an AP STA.

8. A method performed by a station STA operating in a wireless local area network WLAN, the method comprising: receiving a beacon frame, the beacon frame comprising scheduling information for a subsequent time interval and type, wherein a single-user SU uplink UL transmission or a multi-user MU UL transmission is to be used during the subsequent time interval based on the indicated type, wherein the scheduling information indicates a start time of the subsequent time interval coinciding with transmission of a trigger frame; receiving the trigger frame, the trigger frame coinciding with the start time of the subsequent time interval; and At least one of a SU UL frame or a MU UL frame is transmitted according to the indicated type during the subsequent time interval. 9 . The method of claim 8 , wherein the beacon frame includes information indicating at least one STA including the STA that is allowed to transmit a frame during the subsequent time interval.

10. The method according to claim 8, comprising: A power saving state is exited and an active state is entered during the subsequent time interval, and the SU UL frame or the MU UL frame is transmitted after entering the active state during the subsequent time interval.

11. The method according to claim 8, wherein: The beacon frame or the trigger frame includes at least one of the allocated resources to be used during the subsequent time interval or an indication that a multi-STA acknowledgment / block acknowledgment ACK / BA frame is to be transmitted during the subsequent time interval.

12. The method according to claim 11, comprising: A multi-STA acknowledgment / block acknowledgment ACK / BA frame acknowledging the transmitted SUUL frame or MU UL frame is received during the subsequent time interval.

13. The method according to claim 8, comprising: A downlink DL MU frame is received during the subsequent time interval.

14. The method according to claim 8, wherein: The STA is a non-access point AP STA, wherein the beacon frame and the trigger frame are received from the AP STA.

15. A station STA operating in a wireless local area network WLAN, the STA comprising: a transceiver coupled to a processor, the transceiver and the processor configured to transmit a beacon frame, the beacon frame comprising scheduling information for a subsequent time interval and type, wherein based on the indicated type, a single-user SU uplink UL transmission or a multi-user MU UL transmission is to be used during the subsequent time interval, wherein the scheduling information indicates a start time of the subsequent time interval coinciding with transmission of a trigger frame; The transceiver is configured to transmit the trigger frame coinciding with the start time of the subsequent time interval; and The transceiver is configured to receive at least one of a SU UL frame or a MU UL frame according to the indicated type during the subsequent time interval. 16 . The STA of claim 15 , wherein the beacon frame includes information indicating at least one other STA that is allowed to transmit a frame during the subsequent time interval.

17. The STA of claim 15, wherein the transceiver is configured to receive the SU UL frame or the MU UL frame during the subsequent time interval.

18. The STA of claim 15, wherein the beacon frame or the trigger frame comprises at least one of: allocated resources to be used during the subsequent time interval, or an indication that a multi-STA acknowledgment / block acknowledgment ACK / BA frame is to be transmitted during the subsequent time interval.

19. The STA of claim 18, the transceiver being configured to receive a multi-STA acknowledgment / block acknowledgment ACK / BA frame acknowledging the transmitted SU UL frame or MU UL frame during the subsequent time interval.

20. The STA of claim 15, wherein the STA is an access point (AP) STA, and wherein the transceiver is configured to receive the trigger frame from a non-AP STA.

Images