EP3360272A1 - Procedures for high efficiency acknowledgement transmission - Google Patents

Procedures for high efficiency acknowledgement transmission

Info

Publication number
EP3360272A1
EP3360272A1 EP16785308.4A EP16785308A EP3360272A1 EP 3360272 A1 EP3360272 A1 EP 3360272A1 EP 16785308 A EP16785308 A EP 16785308A EP 3360272 A1 EP3360272 A1 EP 3360272A1
Authority
EP
European Patent Office
Prior art keywords
wtru
frame
ack
twt
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP16785308.4A
Other languages
German (de)
English (en)
French (fr)
Inventor
Xiaofei Wang
Guodong Zhang
Joseph S. Levy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of EP3360272A1 publication Critical patent/EP3360272A1/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1635—Cumulative acknowledgement, i.e. the acknowledgement message applying to all previous messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1664—Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1864—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0219—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave where the power saving management affects multiple terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0093—Point-to-multipoint
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • a wireless transmit/receive unit (WTRU) communicating in a WLAN system may use efficient acknowledgement (ACK) setup and transmission procedures in conjunction with other transmission and power saving techniques, such as target wake time / restricted access window (TWT/RAW), power save multi-poll (PSMP) and/or transmission opportunity (TXOP) mechanisms.
  • ACK acknowledgement
  • TWT/RAW target wake time / restricted access window
  • PSMP power save multi-poll
  • TXOP transmission opportunity
  • a WTRU may transmit a first frame including the following information: an indication that a TWT/RAW period is scheduled; an indication that multi-WTRU block ACK and/or Block ACK (BA) (M-BA) (e.g., multi-station (STA) ACK/BA) will be used by the WTRU for acknowledgement of received frames during the TWT/RAW period; and/or at least one targeted transmission time corresponding to a transmission of at least one multi-WTRU ACK/BA frame.
  • the WTRU may transmit a second frame triggering a start of the TWT/RAW period.
  • the WTRU may receive at least one data frame from at least one WTRU in the WLAN system, wherein the at least one WTRU is allowed to access the wireless medium during the TWT/RAW period.
  • the WTRU may transmit at least one multi-WTRU ACK/BA frame during the at least one targeted transmission time to acknowledge the at least one data frame received from the at least one WTRU.
  • FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;
  • FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;
  • WTRU wireless transmit/receive unit
  • FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;
  • FIG. 2 shows a frame format of an example multi-wireless transmit/receive unit (WTRU) block acknowledgement (BA) (M-BA) control frame;
  • WTRU multi-wireless transmit/receive unit
  • BA block acknowledgement
  • FIG. 3 shows a frame format of another example multi-WTRU
  • FIG. 4A shows a frame format of an example acknowledgment
  • FIG. 4B shows a flow diagram of an example ACK request setup procedure
  • FIG. 5 shows a frame format of an example UL request frame with delay tolerance indication and ACK type
  • FIG. 6 shows a flow diagram of an example High efficiency ACK transmission procedure
  • FIG. 7 shows a messaging diagram of an example multi-WTRU
  • FIG. 8 shows a messaging diagram of an example multi-WTRU
  • FIG. 9 shows a messaging diagram of an example multi-WTRU
  • TWT/RAW target wake time / restricted access window
  • FIG. 10 shows a messaging diagram of an example multi-WTRU
  • TXOP transmission opportunity
  • FIG. 11 shows a flow diagram of an example multi-WTRU
  • FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single-carrier FDMA
  • the communications 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, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • the communications systems 100 may also include a base station
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the other networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple -input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple -input multiple-output
  • 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).
  • RAT radio access technology
  • 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 establish the air interface 116 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • the base station 114a and the WTRUs are identical to the base station 114a and the WTRUs.
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • the base station 114a and the WTRUs are identical to the base station 114a and the WTRUs.
  • 102a, 102b, 102c may implement radio technologies such as Institute of Electrical and Electronic Engineers (IEEE) 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 1A may be a wireless router, Home
  • Node B, Home eNode B, or access point may utilize any suitable RAT for facilitating wireless connectivity in a locahzed area, such as a place of business, a home, a vehicle, a campus, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the core network 106.
  • the RAN 104 may be in communication with the core network
  • the core network 106 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.
  • the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication.
  • the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT.
  • the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106 may also serve as a gateway for the
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite.
  • TCP transmission control protocol
  • UDP user datagram protocol
  • IP internet protocol
  • the networks 112 may include wired or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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.
  • the WTRU 102c shown in FIG. 1A 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.
  • FIG. IB is a system diagram of an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display /touchp ad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
  • GPS global positioning system
  • 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, 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. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • a base station e.g., the base station 114a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic hght-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non- removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals
  • the peripherals 138 may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • an accelerometer an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • FM frequency modulated
  • FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the core network 106.
  • the RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 140a, 140b, 140c may implement MIMO technology.
  • the eNode-B 140a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.
  • the core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MME mobility management entity gateway
  • PDN packet data network
  • the MME 142 may be connected to each of the eNode-Bs 140a,
  • the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
  • the serving gateway 144 may be connected to each of the eNode
  • 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 user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the serving gateway 144 may also be connected to the 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.
  • the PDN gateway 146 may provide the WTRUs 102a, 102b, 102c with access to packet -switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the core network 106 may facilitate communications with other networks.
  • 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.
  • the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • 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.
  • WLAN 160 may include an access router 165.
  • the access router may contain gateway functionality.
  • the access router 165 may be in communication with a plurality of access points (APs) 170a, 170b.
  • the communication between access router 165 and APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol.
  • AP 170a is in wireless communication over an air interface with WTRU 102 d.
  • WTRU and station (STA) in a WLAN may be used interchangeably.
  • a WTRU may be, for example, an AP or a non-AP STA, such that all the examples and figures described herein may equivalently apply to an AP or a non-AP STA.
  • a WLAN system may be considered a network operating based on an IEEE 802.11 standard.
  • a WLAN may be a high efficiency (HE) WLAN (HEW) system, or any other type of WLAN system.
  • HEW high efficiency
  • a WLAN in Infrastructure Basic Service Set (BSS) mode may include, for example, an AP for the BSS and one or more WTRUs (e.g., STAs) associated with the AP within the BSS.
  • the AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in and out of the BSS.
  • Traffic to WTRUs that originates from outside the BSS may arrive through the AP and may be delivered to the WTRUs. Traffic originating from WTRUs to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations.
  • DS Distribution System
  • Traffic between WTRUs within the BSS may also be sent through the AP, where the source WTRU may send traffic to the AP and the AP may deliver the traffic to the destination WTRU.
  • Such traffic between WTRUs within a BSS may be considered peer-to-peer traffic.
  • Such peer-to- peer traffic may be sent directly between the source and destination WTRUs, for example using a direct link setup (DLS) using an 802. l ie DLS or an 802. l lz tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and may have WTRUs communicating directly with each other. This mode of communication may be referred to as an ad-hoc mode of communication.
  • a WTRU may include IEEE 802.11 STAs and/or an AP.
  • the IEEE 802.11 family of specifications for WLANs continues to evolve to include new and enhanced versions that add features such as higher throughput, extended transmission range, and improved efficiency for example. Some aspects of various 802.11 protocols are described below.
  • an AP may transmit a beacon on a fixed channel, such as the primary channel.
  • This channel may be 20 MHz wide, and may be the operating channel of the BSS.
  • This channel may be used by the WTRUs to establish a connection with the AP.
  • a fundamental channel access mechanism in an 802.11 system is Carrier Sense Multiple Access with Colhsion Avoidance (CSMA/CA).
  • CSMA/CA Carrier Sense Multiple Access with Colhsion Avoidance
  • every WTRU including the AP may sense the primary channel. If the channel is detected to be busy, the WTRU (including the AP) may back off from accessing the channel.
  • CSMA/CA multiple may allow only one WTRU to transmit at any given time in a given BSS, thus avoiding collision on the channel.
  • HT WTRUs may use a 40 MHz wide channel for communication in addition to other channels, such as a 20 MHz channel (e.g., primary channel). This may be achieved by combining the primary 20 MHz channel, with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.
  • a 20 MHz channel e.g., primary channel
  • VHT WTRUs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels.
  • the 40 MHz and 80 MHz channels may be formed by combining contiguous 20 MHz channels, as in the example of 802.11 ⁇ .
  • a 160 MHz channel may be formed by combining eight contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
  • the data after channel encoding, may pass through a segment parser that divides data into two streams. Inverse Fast Fourier transformation (IFFT) and time domain processing may be done on each stream separately.
  • IFFT Inverse Fast Fourier transformation
  • time domain processing may be done on each stream separately.
  • the data streams may be mapped on to and transmitted over the two channels.
  • this 80+80 configuration processing may be reversed to combine the two streams of data, and the combined data may be sent to the media access control (MAC) layer.
  • MAC media access control
  • Sub 1 GHz modes of operation may be supported by 802.11af, and/or 802.11ah.
  • the channel operating bandwidths and carriers may be reduced relative to those used in 802.11 ⁇ and 802.11ac, for example.
  • the 802. l laf specification may support 5 MHz, 10 MHz and/or 20 MHz bandwidths in the TV White Space (TVWS) spectrum.
  • the 802.11ah specification may support 1 MHz, 2 MHz, 4 MHz, 8 MHz, and/or 16 MHz bandwidths using non-TVWS spectrum.
  • An example use case for the 802.11ah standard is the support of meter and sensor devices in a macro coverage area. Meter and sensor devices may have limited capabilities such as support for limited bandwidths, and may have requirements such as a need for very long battery life.
  • WLAN systems which support multiple channels, and channel widths, such as 802.11 ⁇ , 802.1 lac, 802. l laf, and 802.11ah, may include a channel that is designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all WTRUs in the BSS. Thus, the bandwidth of the primary channel may be limited by the WTRU, among all WTRUs operating in the BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide if there are WTRUs, for example MTC type devices, that only support a 1 MHz mode even if the AP, and other WTRUs in the BSS, may support a 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes.
  • Carrier sensing and/or NAV settings may depend on the status of the primary channel. For example, if the primary channel is busy, due to a WTRU supporting only a 1 MHz operating mode transmitting to the AP, then the entire available frequency bands may be considered busy even though to majority of the frequency bands remain idle and available.
  • the available frequency bands that may be used by 802.1 lah are in the following ranges for various 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.
  • the IEEE 802.1 lac specification has introduced the concept for downhnk multi-user MIMO (MU-MIMO) transmission to multiple WTRU's in the same symbol's time frame, for example, during a downlink OFDM symbol.
  • MU-MIMO multi-user MIMO
  • the potential for the use of downlink MU-MIMO is also currently considered for 802.11ah.
  • Transmission to multiple WTRUs using downhnk MU-MIMO, as it is used in 802.1 lac, may be made possible by transmitting packets to multiple WTRUs in a spatially orthogonal manner simultaneously (e.g., using the same symbol timing).
  • all WTRUs involved in MU-MIMO transmission with an AP may use the same channel or band, which in turn may limit the operating bandwidth for the BSS to the smallest channel bandwidth that is supported by any one of the WTRUs included in the MU-MIMO transmission with the AP.
  • WLAN systems using 802.11 may employ acknowledgement
  • ACK acknowledgement
  • Wireless transmissions may be unreliable even though protection mechanisms, such as channel coding and interleaving, may be utilized to protect the transmissions. Therefore, ACK mechanisms for the acknowledgment of correct packet reception may be used in WLAN systems.
  • a WTRU/AP that successfully receives a data frame addressed to itself may immediately send a positive acknowledgement (ACK). If a WTRU/AP transmitting a frame does not receive an ACK corresponding to the frame within a prescribed amount of time, the WTRU/AP may assume that the data frame was not received correctly at the destination and may retransmit the data frame. Not all data frames in a WLAN system may be acknowledged in this way.
  • BA mechanisms may improve system efficiency by allowing the recipient of multiple frames to transmit a single block ACK (BA) to acknowledge a block of data frames. BA mechanisms may also reduce overhead because the preambles and headers may be sent once for multiple ACKs. BA mechanisms include immediate BA, providing a more immediate acknowledgement, and delayed BA, which may be used for example when some delay is tolerated.
  • BA block ACK
  • the 802.11ah specification proposes a short ACK packet format.
  • the short ACK packet format may only include short training fields (STFs), long training fields (LTFs) and signal (SIG) fields.
  • Frame aggregation mechanisms are used in WLAN systems to reduce overhead by sending (i.e., aggregating) two or more data frames in a single transmission.
  • WLAN systems may employ short packet aggregation mechanisms to aggregate short data packets in a single transmission.
  • multiple "short" ACKs using the short ACK packet format may be transmitted using short packet aggregation mechanisms.
  • WLAN systems may employ single user (SU) aggregation mechanisms, such as aggregated medium access control (MAC) protocol data unit (A-MPDU) and aggregated MAC service data unit (A-MSDU).
  • MAC medium access control
  • A-MPDU aggregated medium access control protocol data unit
  • A-MSDU aggregated MAC service data unit
  • 802.11 specifications in terms of multi-user (MU) aggregation mechanisms.
  • the 802.1 lac specification proposes downlink (DL) MU-MIMO, which is a MU aggregation method that may be hmited to sending polled ACKs individually in the UL direction.
  • DL MU-MIMO adds overhead, especially for shorter packets such as short ACKs.
  • the 802.11 specifications may not provide for MU ACK/BA aggregation in the DL direction.
  • SG was created to develop future WLAN systems, and the 802.1 lax specification is being developed for such WLAN systems.
  • a goal of the HEW SG and the 802.1 lax specification is to improve the average throughput per user and to implement mechanisms to serve more users in a consistent and reliable manner in the present of multiple users in future WLAN systems.
  • the HEW SG is exploring the scope and purpose of 802.11 specifications to enhance the quality of service that all users may experience for a broad spectrum of wireless users in many usage scenarios, including high-density scenarios in the 2.4 GHz and 5 GHz band.
  • Use cases that may support dense deployments of APs and WTRUs, and associated Radio Resource Management (RRM) technologies, are being considered by the HEW SG.
  • RRM Radio Resource Management
  • Potential applications being considered for WLAN systems may include, but are not limited to include, the following emerging usage scenarios: data delivery for stadium events; high user density scenarios such as train stations and/or enterprise/retail environments; evidence for an increased dependence on video delivery; and/or wireless services for medical applications.
  • Examples of applications that generate short packets include, but are not limited to, the following: virtual office; transmission control protocol (TPC) ACK; video streaming ACK; device/controller (e.g., mice, keyboards, and/or game controls) functions; access commands such as probe request and/or response; network selection such as probe requests and/or access network query protocol (ANQP); and/or network management such as control frames, for example.
  • TPC transmission control protocol
  • ANQP access network query protocol
  • network management such as control frames, for example.
  • the 802.1 lax specification may support MU features including
  • MU communications may support mechanisms for multiplexing DL ACKs sent in response to UL MU transmissions.
  • WLAN systems based on certain 802.11 specifications may have large overhead and/or delay for short packet and/or short payloads.
  • approaches and mechanisms are described herein that may enhance MAC efficiency, reduce medium access overhead, and/or reduce delay in WLAN systems (based on the 802.1 lax specification, for example) for transmission of short packets/bursts.
  • the approaches described herein include effective aggregation schemes for ACK and/or other feedback information in the context of MU communications including, but not limited to, DL and UL OFDMA and DL and UL MU-MIMO.
  • the approaches described herein are designed to effectively allow for simultaneous MU short packet transmissions.
  • the 802.1 lax specification defines a framework for using a multi-
  • FIGs. 2 and 3 shown example formats for multi-WTRU Block ACK (M-BA) control frames.
  • the examples in FIGs. 2 and 3 may include ACK and or BA information (e.g., multi-WTRU ACK/BA).
  • a multi-WTRU Block ACK may include only ACK packet(s), or BA packet(s), or both ACK and BA packets.
  • FIG. 2 shows a frame format of an example multi-WTRU BA frame 200.
  • the multi-WTRU BA frame 200 may be defined by modifying a multi-traffic identifier (multi-TID) BA frame format, for example.
  • the multi- WTRU BA frame 300 may include a MAC header 202.
  • the multi-WTRU BA frame 200 may include, but is not limited to include, 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).
  • a frame control field 204 e.g., 2 octets
  • ID e.g., 2 octets
  • RA receiving WTRU address
  • TA transmitting
  • the BA control field 212 may include an indication that the frame 200 is a multi- WTRU BA frame. In another example, an indication that the frame 200 is a multi-WTRU BA frame may be included anywhere in the frame 200. In an example, the BA control field 212 may include 16 bits, B0 to B15.
  • the BA control field 212 may include, but is not limited to include, any of the following subfields: a block acknowledgment request (BAR) ACK policy field 218 (e.g., bit B0); a multi-TID field 220 (e.g., bit Bl); a compressed bitmap field 222 (e.g., bit B2); a group code recording (GCR) field 224 (e.g., bit B3); reserved field(s) 226 (e.g., bits B4 to B ll); and/or a TIDJNFO field 228 (e.g., bits B 12- B15).
  • BAR block acknowledgment request
  • GCR group code recording
  • reserved field(s) 226 e.g., bits B4 to B ll
  • TIDJNFO field 228 e.g., bits B 12- B15.
  • the BA information field 214 may include information that is repeated for each TID.
  • the repeated information in the BA information field 214 may include, but is not limited to include, 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).
  • a per-TID information field 230 e.g., 2 octets
  • a BA starting sequence control field 232 e.g., 2 octets
  • a BA bitmap field 234 e.g., 8 octets
  • bits B0-B10 of the per-TID information field 230 may be part of a reserved field 236 (e.g., bits B0- B 11), may carry an association identifier (AID) field identifying 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 to B16).
  • FIG. 3 shows a frame format of another example multi-WTRU
  • the multi-WTRU BA frame 300 may be defined by modifying a multi-TID BA frame format, for example.
  • 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 include, any of the following fields: a frame control field 304 (e.g., 2 octets); a duration and/or ID field 306 (e.g., 2 octets); an 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 an FCS 316 (e.g., 4 octets).
  • a frame control field 304 e.g., 2 octets
  • the BA control field 312 may indicate that the frame 300 is a multi-WTRU BA frame.
  • the BA control field 312 may include 16 bits, B0 to B15.
  • the BA control field 312 may include, but is not limited to include, any of the following subfields: a BAR ACK policy field 318 (e.g., bit BO); a multi-TID field 320 (e.g., bit Bl); a compressed bitmap field 322 (e.g., bit B2); a GCR field 324 (e.g bit B3); reserved field(s) 326 (e.g., bits B4 to Bl l); and/or a TIDJNFO field 328 (e.g., bits B12-B15).
  • a BAR ACK policy field 318 e.g., bit BO
  • a multi-TID field 320 e.g., bit Bl
  • a compressed bitmap field 322 e.g., bit B2
  • GCR field 324
  • the BA information field 314 may include information that is repeated for each TID.
  • the repeated information in the BA information field 314 may include, but is not limited to include, 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).
  • the multi-WTRU BA frame 300 may allow an ACK indication per WTRU, in addition to or instead of a BA.
  • the BA information field 314 may indicate an ACK for the WTRU in Bl l of the per-TID info field 330 with AID indicated in bits B0 to B10 in the per-TID info field 330.
  • Bits B0-B10 of the per-TID information field 330 may carry an AID field identifying the intended receiver of the BA information field 314.
  • the per-TID information field 330 may include a TID value field 338 (e.g bits B12 to B16).
  • an originator WTRU transmitting to a recipient WTRU may receive 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, for example.
  • delayed acknowledgement 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, for example.
  • the transmitted packets may have different delay tolerance periods in which to receive an ACK.
  • a packet may have been buffered for some period of time before it is able to access the medium, which means that packet has already experienced some delay.
  • a packet that normally may be acknowledged by, for example, a delayed BA, such that the delayed BA would be within its delay tolerance may need to be acknowledged immediately by an immediate ACK or BA frame to stay within its delay tolerance.
  • a WTRU may be an AP or a non-AP.
  • a first WTRU (.e.g., an AP or a non-AP WTRU) may setup a new acknowledgement arrangement with a second WTRU (.e.g., an AP or a non-AP WTRU).
  • the second WTRU may be the AP that the first WTRU is associated with.
  • the second WTRU may be another non-AP WTRU.
  • the first WTRU may send an ACK setup request frame to the second WTRU to initiate a new acknowledgement setup procedure with the second WTRU.
  • FIG. 4A shows a frame format of an example ACK setup request frame 400A, which may be used for setting up ACKs for multi-WTRU ACK/BA mechanisms.
  • the example ACK setup request frame 400A may include, but is not limited to include, any of the following fields and/or subfields, which may be nested within other fields, repeated within the frame 400A (e.g., based on WTRUs or traffic), and or may appear in any order within ACK setup request frame 400A: a preamble 402; a MAC header 403; a frame body 404; a frame check sequence (FCS) field 406; traffic fields 408I...408N; traffic identification field 410; priorities 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 fields 432i
  • the preamble field 402 may include training signals and/or information for the recipient (i.e., receiving) WTRUs on how to decode the ACK setup request frame 400A and/or information on acknowledgement setup.
  • the frame body field 404 may carry information for the recipient WTRUs on ACK setup.
  • the preamble field 402 and/or the frame body 404, or any part of the frame 400 A, may contain one or more of a traffic fields 408I...408N.
  • Each of the traffic fields 408I...408N may include, but is not limited to include, any of the following information: information about one or more corresponding traffic streams that may be identified by traffic identifiers (TIDs); information about one or more packets; and/or information on one or more access categories (ACs) for the originating WTRU that is setting up or making the arrangement for ACK mechanisms.
  • TIDs traffic identifiers
  • ACs access categories
  • each traffic field 408I...408N may contain, but is not limited to contain, one or more of the following fields: a traffic identification field 410; a priorities field 412; an expected generation period/frequency field 414; an expected generation time field 416; expected an expected size field 418; a detailed delay indication field 420; and an ACK type field 430.
  • the traffic identification (ID) field 410 may include traffic identification information including, but not limited to, the following information: TIDs for traffic streams; access categories for traffic; priorities; packet/aggregated packet sequence numbers; packet batch numbers (i.e., the number of a batch or a set of packets); and/or some identity defined by the originating (transmitting) WTRU.
  • the priorities field 412 may indicate the priorities of the traffic and/or the originating WTRU, such as the User Priority (UP), for example.
  • the expected generation period/frequency field 414 may indicate the generation period and/or frequency of the traffic and/or WTRU indicated.
  • the expected generation time field 416 may indicate the generation time of the traffic and/or WTRU, for example by indicating an offset from a time reference (e.g., using a timing synchronization function (TSF) timer), or by indicating an absolute time or any other time reference.
  • TSF timing synchronization function
  • the expected size field 418 may indicate the expected size of data generated for the indicated traffic or originating WTRU.
  • the detailed delay indication field 420 may indicate the detailed delay tolerance, and may include, but is not limited to include, 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 the packets of the indicated traffic may sustain.
  • the delay tolerance field 422 may be specified in nanoseconds (ns), microseconds (us), milliseconds (ms), time units (TUs), or any other time units.
  • the delay tolerance field 422 may be specified from: the time of the generation of the packet; the transmission of an UL request frame; a certain point of time; and/or certain values of the TSF timer.
  • the retransmission time field 424 may indicate the time at which the transmitting (originating) WTRU considers that a transmitted packet (e.g., a single packet or an aggregated packet) is not correctly received and will start to retransmission procedure for that packet (or aggregated packet).
  • the retransmission time field 424 may be indicated as an absolute time, or a period starting from a certain point of time, such as the time of generation of the packet, the transmission time of the packet, or the end of the transmission of the packet, for example.
  • the receiving (recipient) WTRU may decide not to transmit an ACK frame, such as an ACK/BA or multi-WTRU ACK/BA, even if such an ACK frame has not been transmitted before for the indicated packet.
  • an ACK frame such as an ACK/BA or multi-WTRU ACK/BA
  • the discard time field 426 may indicate the time at which point the transmitting WTRU 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 as a period of time starting from a certain point of time, such as the time of generation of the packet, transmission time of the packet, or the end of the transmission of the packet, for example.
  • a WTRU for example an AP, may decide not to schedule or allocate resources for the transmission of the indicated packet.
  • the delay tolerance classification field 428 may be abstracted to delay tolerance levels.
  • delay tolerance levels may include: level 0, which may be associated with a delay tolerance of 0ns - 50 ns, and level 1, which may be associated with a delay tolerance of 51 ns - 100ns, among other levels similarly defined.
  • a tolerance interval may be calculated using the delay tolerance classification level (or delay tolerance classification number or value).
  • the delay tolerance classification levels and the associated delay tolerance intervals may be indicated, for example, in the delay tolerance classification field 428.
  • each of the delay tolerance classification levels may be associated with pre-defined or preset values of corresponding delay tolerance intervals, retransmission times, discard times, and/or desired ACK types.
  • An ACK type field 430 may be used to indicate the acknowledgement type that is applicable to the indicated traffic or originating WTRU.
  • ACK types may include, but are not limited to include: 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).
  • DTC delay tolerance classification
  • delay tolerance classification level 0 may be associated with an immediate SU ACK/BA
  • delay tolerance classification level 1 may be associated with SU delayed BA
  • delay tolerance classification level 2 may be associated with delayed multi-WTRU ACK/BA.
  • the UL request message for this packet may indicate the DTC level as DTC2 (i.e., tolerance for a longer delay).
  • DTC2 delay tolerance classification level 2
  • DTC2 delay tolerance classification level 2
  • the packet may need to be acknowledged directly using an immediate SU ACK/BA.
  • More than one type of ACK e.g., ACK type fields 4321. . .432K
  • each ACK type may be associated with a delay tolerance classification.
  • a recipient WTRU receiving an ACK setup request frame may respond with an ACK setup response frame immediately or with delay.
  • An example design of the ACK setup response frame may include a preamble and/or frame body.
  • the preamble may include training signals and information for the receiving WTRUs on how to decode the frame and/or on acknowledgement setup.
  • the frame body may carry information for the receiving WTRUs on acknowledgement setup.
  • the preamble and/or the frame body or any part of the frame may include, but is not limited to included, any one or more of the following fields: a status field; alternative values for detailed delay indication field, which may include retransmission time, discard time, and/or delay tolerance classification fields; and/or an alternative values for ACK type field.
  • a status field may include retransmission time, discard time, and/or delay tolerance classification fields
  • ACK type field may include retransmission time, discard time, and/or delay tolerance classification fields.
  • the fields in an example ACK setup response frame are described below.
  • a status field of an ACK setup response frame may indicate the status of the ACK setup procedure including, but not limited to, the following statuses: success; failed; failed without reason; and/or failed with alternative values.
  • ACK setup response frame may indicate the detailed delay tolerance and may include a retransmission time field and/or a delay tolerance classification field.
  • a retransmission time field may indicate the time at which the transmitting WTRU may consider a transmitted packet (e.g., a single packet or an aggregated packet) as not being correctly received and may start the retransmission procedure for that packet.
  • the retransmission time may be indicated as an absolute time, or a period starting from a certain point of time, such as the time of generation of the packet, the transmission time of the packet, or the end of the transmission of the packet, for example.
  • the receiving WTRU may decide not to transmit an acknowledgement frame, such as an ACK/BA, multi-WTRU ACK/BA even such an acknowledgement for the packet has not been transmitted before.
  • a discard time field may be used to indicate the time at which point the receiving WTRU may decide not to schedule or allocate resources for the transmission/retransmission of the packet. For example, this discard time may be specified from the expected generation time, or from the first transmission of the packet, or from the transmission of the first UL request frame for that frame containing the packet.
  • the delay tolerance classification may be abstracted to a few levels, such as level 0, which may be associated with a delay tolerance of 0ns - 50 ns, and level 1, which may be associated with a delay tolerance of 51 ns - 100ns, among other levels.
  • the tolerance interval may be calculated using the delay tolerance classification number.
  • the delay tolerance classification levels and the associated delay tolerance interval may be indicated. Each of the delay tolerance classification level may be associated with a set values corresponding to a delay tolerance interval, retransmission time and/or discard time, as well as desired ACK types.
  • ACK Type field may be used to indicate the acknowledgement type that is applicable to the indicated traffic or WTRU.
  • the ACK types may include, but are not limited to include, any of the foUowing types: 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).
  • DTC delay tolerance classification level 0
  • DTCl delay tolerance classification level 1
  • DTC2 delay tolerance classification level 2
  • DTC2 delay tolerance classification level 2
  • FIG. 4B shows a flow diagram of an example ACK request setup procedure 400B in a WLAN system.
  • the example WLAN system may include an AP 440, a WTRU 442 and other devices not shown.
  • AP 440 could equivalently be a non-AP WTRU (i.e., a non-AP STA), and similarly WTRU 442 may be an AP or a non-AP WTRU.
  • the AP 440 and WTRU 442 may be part of the same BSS, and/or the WTRU 442 and may be associated with the AP 440.
  • the AP 440 may specify each of the delay tolerance classification levels, their associated values for delay tolerance intervals, and/or their associated acknowledgement types.
  • the AP 440 may provide this information to WTRU 442 (and other devices not shown) using beacons 445, or similarly short beacons, probe responses, other type of control frame, management frame, data, frame extension, and/or other type of frame.
  • the WTRU 442 may send an ACK setup request frame 448 to the
  • AP 440 after receiving the ACK setup request frame 448, may respond to the WTRU 442 immediately or with delay, with an ACK setup response frame 450.
  • the AP 440 via the ACK setup response frame 450, may accept or reject the proposed detailed delay tolerance indications and/or associated ACK types (which may be associated with the delay tolerance classification levels), or reject the values by responding with alternative values.
  • the WTRU 442 may further acknowledge the alternative values, for example by sending another ACK setup request frame (not shown) with the proposed values, to which the AP 440 may send another ACK Setup Response frame (not shown) with status field set to "Success". If the requesting WTRU 442 finds the alternative values unacceptable, the WTRU 442 may resend an ACK Request frame (not shown) with new values for detailed delay tolerance indications and/or the ACK types (which may be associated with different delay tolerance classification levels).
  • the detailed delay tolerance indication and/or ACK types may be included in the setup process for BA, delayed BA, HT-delayed BA Extension, and/or multi-WTRU ACK/BA, for example.
  • any part of the ACK setup request and response frame or any combinations thereof may be implemented as any of the following frames: a control frame or a management frame such as action frames; action no ACK frames; other types of management frames; control frames; extension frames; null data packet (NDP) frames; and/or NDP carrying MAC information frames.
  • the detailed delay tolerance indication and/or ACK types may additionally or alternatively be implemented as an information element, sub-element, set or subset of fields, or subfields, of a management frame, control frame, extension frame, NDP frame or data frame or as a part of a MAC/PLCP header.
  • a WTRU may indicate delay tolerance and preferred acknowledgement options to an AP in an UL request.
  • FIG. 5 shows a frame format of an example UL request frame 500 with a delay tolerance indication and ACK type.
  • the UL request frame 500 may include a preamble 502, a MAC header 503, a frame body 504, and an FCS field 506.
  • a preamble 502 may include training signals and/or information for the receiving (recipient) WTRUs on how to decode the UL request frame 500 and/or on acknowledgement setup.
  • a frame body 504 may carry information for the receiving WTRUs on acknowledgement setup.
  • UL request frame 500 may contain one or more of a traffic field 1-N. may contain one or more of a traffic fields 508I...508N. Each of the traffic fields 508I...508N may include, but is not limited to include, any of the following information: information about one or more corresponding traffic streams; information about one or more packets; and/or information on one or more access categories (ACs) for which the originating WTRU is requesting resource to transmit.
  • ACs access categories
  • each traffic field 508I...508N may contain, but is not limited to contain, one or more of the following fields: a traffic identification field 510; a priorities field 512; an expected size field 514; a detailed delay indication field 520; and an ACK type field 530.
  • the traffic identification (ID) field 510 may include traffic identification information including, but not limited to, the following information: TIDs for traffic streams; access categories for traffic; priorities; packet/aggregated packet sequence numbers; packet batch numbers (i.e., the number of a batch or a set of packets); and/or some identity defined by the originating (transmitting) WTRU.
  • the priorities field 512 may indicate the priorities of the traffic and/or the originating WTRU, such as the User Priority (UP), for example.
  • the size field 514 may indicate the size of data buffered for the indicated traffic or WTRU.
  • the detailed delay indication field 520 may indicate the detailed delay tolerance for the indicated traffic, and may include, but is not limited to include, 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 traffic may sustain.
  • the delay tolerance field 522 may be specified in nanoseconds (ns), microseconds (us), milliseconds (ms), time units (TUs), or any other time units.
  • the delay tolerance field 522 may be specified from: the time of the generation of the packet; the transmission of the UL request frame 500; a certain point of time; and/or certain values of the TSF timer.
  • the retransmission time field 524 may indicate the time at which the transmitting (originating) WTRU considers that a transmitted packet (e.g., a single packet or an aggregated packet) is not correctly received and will start to retransmission procedure for that packet (or aggregated packet).
  • the retransmission time field 524 may be indicated as an absolute time, or a period starting from a certain point of time, such as the time of generation of the packet, the transmission time of the packet, or the end of the transmission of the packet, for example.
  • the receiving (recipient) WTRU may decide not to transmit an ACK frame, such as an ACK/BA, multi-WTRU ACK/BA, even if such an ACK frame has not been transmitted before for the indicated packet.
  • an ACK frame such as an ACK/BA, multi-WTRU ACK/BA
  • the discard time field 526 may indicate the time at which point the transmitting WTRU 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 as a period of time starting from a certain point of time, such as the time of generation of the packet, transmission time of the packet, or the end of the transmission of the packet, for example.
  • a WTRU for example an AP, may decide not to schedule or allocate resources for the transmission of the indicated packet.
  • the delay tolerance classification field 528 may be abstracted to delay tolerance levels.
  • delay tolerance levels may include: level 0, which may be associated with a delay tolerance of 0ns - 50 ns, and level 1, which may be associated with a delay tolerance of 51 ns - 100ns, among other levels similarly defined.
  • a tolerance interval may be calculated using the delay tolerance classification level (or number or value).
  • the delay tolerance classification levels and the associated delay tolerance interval may be indicated, for example in the delay tolerance classification field 528. If such a delay tolerance classifications has already been setup or are pre-determined, then the delay tolerance classification field 528 may simply include the DTC level values.
  • each of the delay tolerance classification levels may be associated with set values of delay tolerance interval, retransmission time and/or discard time, as well as desired ACK types.
  • An ACK type field 530 may be used to indicate the acknowledgement type that is being requested for the indicated traffic.
  • ACK types may include, but are not limited to include: 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.
  • An ACK type in an ACK type field 530 may be associated with a DTC.
  • delay tolerance classification level 0 may be associated with an immediate SU ACK/BA
  • delay tolerance classification level 1 may be associated with SU delayed BA
  • delay tolerance classification level 2 may be associated with delayed multi-WTRU ACK/BA.
  • DTC2 i.e., tolerance for a longer delay
  • the packet may have DTC2 (i.e., tolerance for a longer delay), such that the packet may be acknowledged by a delayed multi-WTRU ACK/BA.
  • the packet may need to be acknowledged directly using an immediate SU ACK/BA.
  • any part of the UL request frame 500 or any combinations thereof may be implemented as any of the following frames: a control frame or a management frame such as action frames; action no ACK frames; other types of management frames; control frames; extension frames; null data packet (NDP) frames; and/or NDP carrying MAC information frames.
  • the detailed delay tolerance indication and/or ACK types may additionally or alternatively be implemented as an information element, sub-element, set or subset of fields, or subfields, of a management frame, control frame, extension frame, NDP frame or data frame or as a part of a MAC/PLCP header.
  • the detailed delay tolerance indication and/or ACK types may also be implemented as an information element, sub-element, or set or subset of fields or subfields of a management, control, extension, NDP or data frames or as a part of a MAC/PLCP header.
  • a WTRU for example an AP, may use a frame, such as a beacon frame or a trigger frame, to announce ACK schemes and the planned acknowledge time for the acknowledgment schemes so that the WTRUs that are expected to transmit know when to expect an acknowledgement.
  • the announcement of ACK schemes may use transmission opportunity (TXOP) type and/or expected ACK time indication procedures in beacon and/or trigger frames, as described herein.
  • TXOP transmission opportunity
  • a beacon/short beacon frame may announce a schedule for one or more of the subsequent beacon (sub)-intervals, which may be based on any of the following example information: a trigger frame at the beginning of the beacon (sub)interval; one or more intervals for one or more of WTRUs to transmit and receive; and/or one or more expected ACK time to transmit the ACK to the WTRUs.
  • the expected ACK time may function similarly to the target beacon transmission time (TBTT) of the beacons, which may be delayed due to the occupied wireless medium/channel.
  • each expected ACK such as multi-WTRU ACK, multi-WTRU ACK/BA, or delayed BA, may be transmitted at the targeted time without taking into account any previous delays in transmitting acknowledgement frames.
  • a trigger frame may be transmitted at the beginning of a beacon (sub)interval, a TXOP, a target wake time (TWT), or a restricted access window (RAW).
  • the trigger frame may include, but is not limited to include, any one or more of the following information: a TXOP type field; a group of WTRUs field; ACK types field; and/or expected ACK times fields.
  • the information fields that may be included in the trigger frame are described in more detail below.
  • the TXOP type field may indicate the type of TXOP that follows the trigger frame. Examples of TXOP include, but are not limited to, the foUowing types: SU; MU; SU MIMO; SU OFDMA; SU OFDMA/MIMO; MU OFDMA; MU MIMO; and/or MU OFDMA/MIMO.
  • the group of WTRUs field may indicate one or more WTRUs, or a group of WTRUs, that are, have some common function, for example: allowed to transmit in the UL; expected to receive DL traffic; and/or expected to participate in MU transmissions.
  • the relative order of the group of WTRUs or the order of the WTRUs indicated in the trigger frame may imply the slot in which the WTRUs may access the medium for DL and/or UL in the TXOP/Beacon (sub)interval following the trigger frame.
  • a fixed number of WTRUs such as N WTRUs, may be expected to be grouped together for MU transmissions or receptions.
  • the first N WTRUs may be expected to be in the first MU group
  • the second N WTRUs may be expected to be in the second MU group.
  • the number N may be specified in the preamble or frame body or any part of the frame, for example.
  • the slot for which the n th MU group (for 1 ⁇ n ⁇ N) is expected to access the medium may be implied by the order of the WTRUs included in the TXOP type field.
  • An ACK types field may indicate one or more ACK types that may be used by the AP in 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)intervals following the trigger frame (or similarly beacon frame).
  • an acknowledgement 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 point of time, such as the end of the current transmitted frame, or the start of the beacon (sub)interval.
  • x ms may be 1.5 ms, 3 ms, or 4.5 ms
  • a reference point of time such as the end of the current transmitted frame, or the start of the beacon (sub)interval.
  • any part of the trigger frame or beacon frame described herein, or any combinations thereof may be implemented as a control frame, or a management frame including, but not limited to: action frames; action no ACK frames; any other types of management frames; any other types of control frames; extension frames; NDP frames; and NDP carrying MAC information frames.
  • the ACK types may additionally or alternatively be implemented as an information element, sub-element, set or subset of fields, or subfields, of a management frame, control frame, extension frame, NDP frame or data frame or as a part of a MAC/PLCP header.
  • a trigger frame may be, but is not limited to, any of the following types of frames: an ACK, BA, multi-WTRU ACK/BA, any other type of acknowledgement frame, control frame, extension frame, management frame, data frame, and/or NDP frame.
  • a trigger frame may include an indication or field that indicates that the current frame is serving as a trigger frame.
  • delay tolerance indication procedures in data or aggregated frames may be used.
  • a packet e.g., a single (data) packet, a HE packet, and/or aggregated packets
  • A-MPDU or A-MSDU may carry in its preamble and/or frame body or anywhere else any of the following information, described in further detail below: a detailed delay indication field; a delay tolerance field; a retransmission time field; a discard time field; and/or a delay tolerance classification field.
  • a detailed delay indication field may indicate the detailed delay tolerance for the indicated traffic, and may further include, but is not limited to include, any of the following subfields: a delay tolerance field; a retransmission time field; a discard time field; and/or delay tolerance classification.
  • a delay tolerance field may indicate the delay tolerance that the packets of the indicated traffic may sustain.
  • the delay tolerance may be specified in ns, ps, ms, TU, or any other time units.
  • the delay tolerance may be specified starting from the time of the generation of the packet, from the transmission of the frame, from a certain point of time, or using certain values of the TSF timer.
  • a retransmission time field may indicate the time at which the transmitting WTRU considers a transmitted packet (e.g., a single packet or an aggregated packet) is not correctly received and will start the retransmission procedure for that packet.
  • the retransmission time field may be indicated as an absolute time, or a period starting from a certain point of time, such as the time of generation of the packet, the transmission time of the packet, or the end of the transmission of the packet.
  • the receiving WTRU may decide not to transmit an ACK frame (such as an ACK/BA or multi-WTRU ACK/BA) even if such an ACK for the packet has not been transmitted before.
  • a discard time field may indicate the time at which the transmitting WTRU considers the packet as obsolete and will not attempt to transmit or retransmit the packet.
  • the discard time may be indicated as an absolute time, or a period from a given point of time, such as the time of generation of the packet, the transmission time of the packet, or the end of the transmission of the packet, for example.
  • a WTRU e.g., an AP
  • the delay tolerance classification field may be abstracted to delay tolerance levels.
  • delay tolerance levels may include: level 0, which may be associated with a delay tolerance of 0ns - 50 ns, and level 1, which may be associated with a delay tolerance of 51 ns - 100ns, among other levels similarly defined.
  • the tolerance interval may be calculated using the delay tolerance classification number.
  • the delay tolerance classification levels and the associated delay tolerance interval may be indicated. If such a delay tolerance classifications has been setup or pre-determined, then this field may include simply the DTC level values.
  • each of the delay tolerance classification levels may be associated with a set values of delay tolerance interval, retransmission time and/or discard time, as well as desired ACK types.
  • An ACK type field may be used to indicate the acknowledgement type that is being requested for the indicated traffic.
  • ACK Types may include, but are not limited to include: 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. .
  • delay tolerance classification level 0 may be associated with an immediate SU ACK/BA
  • delay tolerance classification level 1 may be associated with SU delayed BA
  • delay tolerance classification level 2 may be associated with delayed multi-WTRU ACK/BA.
  • the UL request for this packet may indicate DTC2 (i.e., tolerance for a longer delay). If resources are allocated quickly for the packet, then the packet may have DTC2 (i.e., tolerance for a longer delay), such that the packet may be acknowledged by a delayed multi- WTRU ACK/BA.
  • the packet may need to be acknowledged directly using an immediate SU ACK/BA.
  • FIG. 6 shows a flow diagram of an example High efficiency ACK transmission procedure 600 in a WLAN system.
  • the example WLAN system may include an AP 602 and a WTRU 604, and other devices not shown.
  • AP 602 could equivalently be a non-AP WTRU (i.e., a non-AP STA), and similarly WTRU 604 may be an AP or a non-AP WTRU.
  • the AP 602 and WTRU 604 may be part of the same BSS, and/or the WTRU 604 and may be associated with the AP 602.
  • the AP 602 may specify each of the delay tolerance classification levels, their associated values for delay tolerance intervals, and/or their associated ACK types.
  • the AP 602 may provide this information to WTRU 604 (and other devices not shown) using beacons 610, or similarly short beacons, probe responses, other type of control frame, management frame, data frame, frame extension, and/or any other type of frame.
  • beacons 610 or similarly short beacons, probe responses, other type of control frame, management frame, data frame, frame extension, and/or any other type of frame.
  • the WTRU 604 may conduct an ACK setup procedure 615 with
  • ACK Setup procedure 615 may be accomplished by exchanging one or more rounds of ACK setup request frame(s) 612 and ACK setup response frame(s) 614.
  • a WTRU class indication such as sensors or meters (that may be plugged in, not shown), may imply certain delay profile, delay tolerance classifications/descriptions, and/or ACK types, to the WTRU 604.
  • AP 602 may announce detailed delay tolerance descriptions, delay tolerance classification levels, and/or ACK types for one or more of beacon (sub)intervals by transmitting beacons 616 (or similarly short beacons, other control, management, data, extension frames, NDP, or other types of frames). The AP 602 may also announce, via beacons 616, one or more expected ACK times for one or more beacon (sub)intervals.
  • beacons 616 or similarly short beacons, other control, management, data, extension frames, NDP, or other types of frames.
  • the AP 602 may also announce, via beacons 616, one or more expected ACK times for one or more beacon (sub)intervals.
  • the WTRU 604 may request a resource allocation for transmitting packets by sending an UL request frame 618 to AP 602.
  • the WTRU 604 may evaluate the delay tolerance for its locally buffered traffic and provide delay tolerance indication for the indicated traffic in the UL request frame 618, for example, by providing detailed delay tolerance description, and/or delay tolerance classification levels, which may have been previously announced by the AP 602 (for example via beacons 610) or previously negotiated.
  • the WTRU 604 may include the requested ACK types in the UL request frame 618.
  • the WTRU 604 may transmit its packets, intended for AP 602, either by obtaining the channel or when the WTRU 604 is allocated resources by the AP 602 via a resource allocation 620.
  • the WTRU 604 sends its packet(s) (e.g., a single packet, an aggregated packet, or a packet as a part of a MU transmissions) to AP 602 via packet transmission 622
  • the WTRU 604 may evaluate the delay tolerance for the packet(s) that it is transmitting, and indicate the delay tolerance with the packet in the packet transmission 622, for example by including the detailed delay tolerance description, and/or using the delay tolerance classification levels.
  • the WTRU 604 may include the requested ACK types in the packet transmission 622, which may be associated with the indicated delay tolerance classification levels.
  • the delay tolerance description, delay tolerance classification levels, and/or requested ACK types may be included in the preamble, and/or frame body, and/or anywhere in the packet transmission frame 622.
  • the AP 602 may send an ACK frame 624 to WTRU 604 to acknowledge the received packet(s) from WTRU 604 in accordance with the indicated delay tolerance description, delay tolerance classification levels, and/or requested ACK types (i.e., that were indicated in the packet transmission 622).
  • the transmission timing of the appropriate ACK type may depend on the delay tolerance description, and/or delay tolerance classification levels provided.
  • the transmitting WTRU 604 may wait until the indicated expected ACK time for the acknowledgement for the packets that it has transmitted. If the transmitted packet was not acknowledged by an acknowledgement, such as delayed BA or delayed multi-WTRU ACK/BA (e.g., M-BA), by the expected ACK time from the AP 602, then the transmitting WTRU 604 may initiate a retransmission procedure (not shown). For example, if the transmitting WTRU 604 has indicated, for example, in the transmitted packet in transmission 622 that it needs acknowledgement prior to the indicated expected acknowledgement time, the WTRU 604 may consider that the packet was not correctly received by the receiving AP 602 if the retransmission time for the packet has expired.
  • an acknowledgement such as delayed BA or delayed multi-WTRU ACK/BA (e.g., M-BA)
  • M-BA delayed multi-WTRU ACK/BA
  • the transmitting WTRU 604 may start the retransmission procedure. If the discard time has expired for a particular packet, then the transmitting WTRU 604 may not attempt to transmit or retransmit the packet, and the AP 602 may choose not to allocate any resources for the transmission and/or retransmission of the packet.
  • Multi-WTRU ACK/BA mechanisms may provide higher efficiency in acknowledging transmissions from multiple WTRUs than sending individual ACK frames.
  • efficient and appropriate ACK transmission procedures may be needed to address some of issues as minimizing delay for all WTRUs, and providing correct fault recovering procedure when the transmitted data or ACK/BA was not correctly received.
  • procedures may be defined for high efficiency acknowledgment transmission with feedback, buffer and operation mode change indication, as described below.
  • acknowledgement frames such as ACK BA, multi-WTRU ACK/BA (e.g., M-BA), or MU block ACK request (BAR) may carry additional information, such as a buffer indication field, feedback field, and/or operation mode change field, as described below.
  • additional information such as a buffer indication field, feedback field, and/or operation mode change field, as described below.
  • the inclusion of these fields and information within ACK frames may enable the WTRU to provide efficient and fast communication to one or more WTRUs, such as the destination WTRU of an ACK frame, to achieve high efficiency.
  • a valid data packet or any other type of packet transmitted by a WTRU may be considered as a valid ACK frame to the previously transmitted packets to the same WTRU.
  • the data packet(s) or any other type of frames that may include an acknowledgement field may be considered a valid acknowledgement frame to the previously transmitted packets to the same WTRU.
  • an aggregated frame, such as an A-MPDU or A-MSDU, transmitted by a WTRU, that includes an ACK, BA and/or multi-WTRU ACK/BA (e.g., M-BA), may be considered as a valid acknowledgement frame to the previously transmitted packets to the same WTRU.
  • a buffer indication field may include buffer status for each access category, each traffic stream which may be identified by TID, and/or the total buffered traffic at the WTRU.
  • the buffer status may include, but is not limited to include, any of the following information: a number of packets; a total time estimated to transmit the packets; and/or total bytes for each packet or packets, which may be for each access class (AC), or TID, or for the entire WTRU.
  • the delay requirements may be specified in an ACK frame for each packet, or each AC, or each TID, so that the destination WTRU of the ACK frame may be able to allocate resources for the buffered traffic.
  • the feedback field in an ACK frame may include, but is not limited to include, any of the following feedback information: feedback for resource blocks (RBs), channel(s), and/or subcarriers; detailed or compressed channel state information (CSI) feedback; detailed or compressed channel quality indication (CQI); detailed or compressed beamforming feedback; modulation and coding scheme (MCS) feedback; and/or preference indication such as preferred channel indication, preferred RB indication, preferred MCS indication.
  • the feedback field in an ACK frame may provide information to one or more WTRUs, such as the destination WTRU of the ACK frame.
  • the feedback field may contain relative (delta) quantity or MCS performance values.
  • the feedback field may include the current RB(s), a preferred or alternative RB(s), and a value indicating the difference in CQI between the current and alternative RBs.
  • the quality or CQI could be better or worse for the alternative RB(s) relative to the current RB(s).
  • the destination WTRU of the acknowledgement frame may then adapt resource allocation, MCS setting, beamforming setting, SU or MU-MIMO settings in subsequent transmissions based on any of the information in the feedback field.
  • an operation mode change field in an ACK frame may include the transmission mode and reception mode scheduled for the transmitting WTRU(s) of the acknowledgement frame.
  • 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; SU number of spatial streams (Nss); MU Nss; Nss; operation bandwidth; operation channel; operation resource block width; reception 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.
  • the buffer indication field, the feedback field, and/or the operation mode change field, and any subset thereof may be implemented as any other field, subfield, information element, MAC and/or PHY headers, and may be included in any kind of frames such as control frames, management frames, data frames, extension frames, NDP frames, and/or aggregated packets, such as A-MPDUs or A-MSDUs.
  • the buffer indication field, the feedback field, and/or the operation mode change field, and any subset thereof may be implemented in a field such as the QoS field, the HT/VHT control field, or an HE control field in the MAC header or PHY headers.
  • a transmitting (originating) WTRU may transmit DL (SU or MU) packets to one or more WTRUs, for example as part of control frames, a management frames, a data frames, extension frames, aggregated packets, and/or NDP frames.
  • the transmitting WTRU may provide resource allocation for the receiving (recipient) WTRUs to transmit UL packets, such as acknowledgement packets, or data packets.
  • the transmitting WTRU may also provide information on broadcast/multicast channel/RBs on which the receiving WTRU should monitor subsequently for broadcast/multicast information.
  • the receiving WTRU may transmit in a SU or a MU PPDU to the transmitting WTRU an acknowledgement frame, such as ACK, BA, multi-WTRU ACK/BA (e.g., M-BA), in order to acknowledgement the packets received.
  • an acknowledgement frame such as ACK, BA, multi-WTRU ACK/BA (e.g., M-BA)
  • a valid data packet or any other type of packet transmitted by a receiving (recipient) WTRU may be considered as a valid ACK frame to the previously transmitted packets to the receiving WTRU.
  • the data packet(s) or any other type of frames with an acknowledgement field used for acknowledging previously received frames may be considered as a valid acknowledgement frame to the previously transmitted packets to the receiving WTRU.
  • an aggregated frame such as an A-MPDU or A-MSDU, which may include an ACK, BA, and/or multi-WTRU ACK/BA (e.g., M-BA), transmitted by a receiving WTRU may be considered as a valid ACK frame to the previously transmitted packets to the receiving WTRU.
  • the receiving WTRU i.e., the WTRU that received packets from the transmitting WTRU
  • the destination WTRU of the ACK frame (i.e., the transmitting or originating WTRU of the data packets), after receiving the acknowledgement frame that may include feedback, buffer status, and/or operation mode change, may then adjust resource allocation, scheduling of transmission or receptions, transmission and reception settings, and/or grouping of WTRUs, for example, based on the received feedback, operation mode change, and buffer status.
  • the destination WTRU of the ACK frame (e.g., an
  • the AP may allocate resources according to the feedback in 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 he originating WTRU, and the receiving (recipient) WTRU that sent the ACK frame.
  • the destination WTRU of the ACK frame e.g., an AP
  • the destination WTRU may use another MCS that is more suitable for the channel condition based on the feedback information.
  • the destination WTRU may allocate resources according to the Operation Mode Change information in the received ACK frame. For example, the destination WTRU may allocate more or less RBs and channels, and/or more or less Nss, based on the operation mode change. In another example, the destination WTRU may transmit broadcast/multicast packets to the receiving WTRU on the indicated Broadcast/Multicast/Monitor RBs and channels. In another example, the destination WTRU may not allocate any resources or transmit any packets to the receiving WTRU if the receiving WTRU has indicated that it will power off for a certain period of time.
  • the destination WTRU may allocate resources according to the Buffer Status in the received ACK frame.
  • the destination WTRU may allocate more or less RBs/channels to the receiving WTRU according to its buffer status and the delay requirements of the buffered packets.
  • the destination WTRU may adjust transmission/reception setting when communicating with the receiving WTRU according to the feedback, operation mode change, buffer status received in the ACK frame.
  • the destination WTRU may switch between SU or MU transmission/reception mode based on any of the following example events: the receiving WTRU indicates in the ACK frame that the receiving WTRU switched to SU operation mode; the receiving WTRU added or decrease Nss used; and/or packets are transmitted to the receiving WTRU on the RBs/channels that the receiving WTRU is monitoring, which may be indicated by the destination WTRU or receiving WTRU.
  • the destination WTRU of the ACK frame may also adjust a beamforming matrix.
  • the destination WTRU may only adjust the transmission/reception settings after a time or delay if an operation mode change is indicated to take effect after a time or delay by the ACK frame (or a data/NDP frame acting as an ACK frame).
  • PSMP procedures include PSMP sequences which begin with the transmission of a PSMP frame by a WTRU (e.g., an AP), and include one or more PSMP downlink transmission times (PSMP-DTTs) as a period for DL transmissions, and one or more PSMP uplink transmission times (PSMP-UTTs) as a period for UP transmissions.
  • PSMP-DTTs PSMP downlink transmission times
  • PSMP-UTTs PSMP uplink transmission times
  • an AP may transmit a multi-WTRU ACK/BA to the WTRUs during a PSMP-DTT.
  • the transmitted multi-WTRU ACK/BA may serve as an acknowledgement for the frames that were transmitted to the AP, for example in PSMP-UTTs immediately previous to the current PSMP-DTT, or previous PSMP-UTTs, or in any beacon (sub)intervals that preceded the current PSMP-DTT during which the multi- WTRU ACK/BA frame is transmitted.
  • An AP may indicate to the WTRUs in a frame transmission (e.g., any control, management, data, extension or other type of frames, such as beacon, trigger frame, or PSMP frames) that the AP is expected to transmit a multi-WTRU ACK/BA in an indicated PSMP-DTT time.
  • WTRUs that are expecting acknowledgement from the AP may sleep or doze (i.e., enter a power saving state), until the indicated PSMP-DTT time, for example, for the purpose of power saving.
  • FIG. 7 shows a messaging diagram of an example multi-WTRU
  • the AP 705 may be any WTRU, including a non-AP WTRU
  • the AP 705 may send a beacon 706 to WTRUs 701-704 that may include an indication (shown by arrow) that the AP 705 will transmit a multi-WTRU ACK/BA frame 726 in one or more PSMP-DTTs 724, which will occur one the PSMP-DTTs 724 are scheduled and have resources allocated to it.
  • the beacon 706 may be a beacon or any control, management, public action, data, extension or other type of frames, including for example, a short beacon, a trigger frame, and/or a PSMP frame.
  • the scheduled time of the multi-WTRU ACK/BA frame 726 may be indicated in terms of a TSF timer, which may be offset from the transmitted frame (e.g., beacon 706) or an offset from a reference time, such as an offset from a targeted PSMP frame transmission time or end of the PSMP frame (e.g., PSMP frame 722).
  • the multi-WTRU ACK/BA frame 726 may be acknowledgement of one or more frames that are received by the AP 705.
  • the multi-WTRU ACK/BA frame 726 may be acknowledgement of one or more frames that are received by the AP 705 during regular transmissions 708, previous PSMP UTTs 710, scheduled or unscheduled automatic power save delivery (APSD) (not shown), and/or scheduled medium access such as target wake time/restricted access window (TWT/RAW) (not shown).
  • regular transmission 708 include frame 712 (e.g., data and/or control frame) transmitted from the WTRU 701 to AP 705, and frame 714 transmitted from WTRU 704 to AP 705.
  • PSMP-UTTs transmissions include frame 716 transmitted from WTRU 702 to AP 705, and frame 720 transmitted from WTRU 7043 to AP 705.
  • FIG. 8 shows a messaging diagram of an example multi-WTRU ACK/BA procedure 800 using the PSMP bursts.
  • an AP 805 (the AP 805 may be any WTRU, including a non-AP WTRU) is communicating with WTRUs 801-804 in a WLAN system.
  • AP 805 may notify the WTRUs 801-804 of a PSMP burst by indicating in a first PSMP frame 806 transmission that another PSMP frame 822 will follow after the current PSMP sequence.
  • a PSMP sequence may include a PSMP-DTTs period, such as PSMP-DTTS 808, in which AP 805 may send downlink frames such as PSMP 806 (which may initiate the PSMP sequence), multi-WTRU ACK/BA frame 814, and frame 816 transmitted from the AP 805 to WTRU 801. [0140] For each PSMP sequence, a multi-WTRU ACK/BA frame 814 and
  • the multi- WTRU ACK/BA frame 824 may be used to acknowledge any one or more of the transmissions received previously by the AP 805.
  • the multi- WTRU ACK/BA frame 824 may be used to acknowledge the UL frame 818 (transmitted from WTRU 801 to AP 805, and including a BA to AP 805) and UL frame 820 (transmitted from WTRU 803 to AP 805) that were transmitted during PSMP-UTTs 810 in the PSMP sequence prior to PSMP frame 822.
  • the use of multi-WTRU ACK/BA in PSMP procedures may be indicated in any frame, such as beacon, short beacon, PSMP frames, NDP frames, and in MAC and/or PLCP headers.
  • the use of multi-WTRU ACK/BA in PSMP may be indicated by HT/VHT/HE capability field.
  • the use of multi-WTRU ACK/BA in PSMP may be indicated by setting the WTRU info type field to a value that may be reserved, or by using one or more reserved bits in the PSMP WTRU info fixed field.
  • multi-WTRU ACK/BA may be transmitted as part of an aggregated packet, or a part of a MU PPDU.
  • multi-WTRU ACK/BA transmission procedures may use TWT/RAW power saving mechanisms.
  • TWT is a function that may permit an AP to define a time or set of times for WTRUs to access the medium.
  • the WTRU and the AP may exchange information, such as an expected activity duration, to allow the AP to control the amount of contention and overlap among competing WTRUs.
  • the AP may use protection mechanisms to protect the channel or wireless medium during the expected duration of activity.
  • TWT may be used to reduce network energy consumption by allowing WTRUs to enter in a doze state until their TWT arrives.
  • RAW may allow partitioning of the WTRUs within a BSS into groups and restricting channel access to WTRUs within a designated group for a given time period. RAW may help to reduce contention and to avoid simultaneous transmissions from a large number of WTRUs hidden from each other.
  • FIG. 9 shows a messaging diagram of an example multi-WTRU
  • the AP 905 may be any WTRU, including a non-AP WTRU
  • the AP 905 may use multi-WTRU ACK/BA for efficient acknowledgement in a TWT or RAW period 920.
  • the AP 905 may indicate in a frame 906 (e.g., a beacon or short beacon frame), that a TWT/RAW period 920 is scheduled.
  • the frame 906 may indicate that the TWT/RAW period 920 is of the type of SU or MU.
  • 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 further indicate that the TWT/RAW period 920 will use multi-WTRU ACK/BA for acknowledgement.
  • 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).
  • multi-WTRU ACK/BA frames e.g., multi-WTRU ACK/BA frames 914, 916, and 91
  • the targeted time of transmission ti, t2, and t3, of the multi-WTRU ACK/BA frames 914, 916, and 918 may be indicated, for example in terms of absolute time, or an offset from a reference time, such as an offset of the transmission of the current frame 906 or the start of the TWT/RAW period 920.
  • the targeted time of transmission ti, t2, and t3 of the multi-WTRU ACK/BA frames 914, 916, and 918 may be assigned to one or more slots.
  • a TWT/RAW period 920 may commence with the transmission of a frame 908 by a WTRU, such as the AP 905.
  • the frame 908 may be a (short) beacon or trigger frame, resource allocation frame, an NDP frame, or part of a MU frame, for example.
  • the frame 908 may indicate the TWT/RAW period 920 may be of the type of SU or MU.
  • 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 to be used during the TWT/RAW period 920.
  • the frame 908 may indicate that the TWT/RAW wiU use multi-WTRU ACK/BA for acknowledgement.
  • the frame 908 may indicate that the AP 905 is scheduled to transmit one or more multi-WTRU ACK/BA during the TWT/RAW period 920.
  • the targeted time of transmission ti, t2, and t 3 of the multi-WTRU ACK/BA frames 914, 916, and 918 may be indicated in terms of absolute time, an offset from a reference time, such as an offset from the end of the transmission of the current frame or start of the TWT/RAW period 920.
  • the targeted time of transmission ti, t2, and t3 of the multi-WTRU ACK/BA frames 914, 916, and 918 may be assigned to one or more slots.
  • WTRUs 901-905 that are allowed to access the medium (e.g., channel(s)) may transmit frames to their destinations. Such transmissions may take place in assigned slots over allocated resources.
  • WTRU 901 may send frame 910 to AP 905, and WTRU 903 may send frame 912 to AP 905.
  • Frames 910 and 912 may include BAs to AP 905.
  • the WTRUs 901 and 903 may indicate that the ACK type is multi-WTRU ACK/BA when transmitting frames 910 and 912.
  • the WTRUs 901 and 903 may sleep or doze until the targeted time of transmission ti, t2, and t3 of the multi-WTRU ACK/BA frames 914, 916, and 918.
  • the recipient WTRU of the frames 910 and 912 which is the AP 905 in this example, may respond with multi-WTRU ACK/BA frames 914, 916, and 918 at the targeted transmission times ti, t2, and t3 to acknowledge the packets that the AP 905 has received.
  • the AP 905 may delay transmitting any of the multi-WTRU ACK/BA frames 914, 916, and/or 918, until the AP 905 has access to the medium.
  • the AP 905 may attempt the transmission of a multi-WTRU ACK/BA frame 914, 916, and/or 918 at each of the respective targeted transmission times ti, t2, and t3, without taking into account any delays in transmitting the previous multi-WTRU ACK/BA frames.
  • the WTRU 903 determines that one or more of its frames have not been acknowledged by the receiving WTRU, such as the AP 905, in a received multi-WTRU ACK/BA frame 914, 916, or 918, the WTRU may retransmit the unacknowledged frames the next time that the WTRU is allowed to access the medium. If a WTRU, for example WTRU 901 or WTRU 903, after transmitting a frame does not receive a multi-WTRU ACK/BA frame from the recipient WTRU (e.g., AP 905), the WTRU 901 or 903 may retransmit the unacknowledged frames the next time that the WTRU is allowed to access the medium.
  • the receiving WTRU such as the AP 905
  • the WTRU 901 or 903 may retransmit the unacknowledged frames the next time that the WTRU is allowed to access the medium.
  • the WTRU may transmit a block acknowledgement request (BAR) or multi-WTRU BAR (not shown), to the receiving WTRU (e.g., AP 905), as a part of the transmissions to the receiving WTRU to request acknowledgment.
  • BAR block acknowledgement request
  • AP 905 multi-WTRU BAR
  • multi-WTRU ACK/BA procedures may be used in conjunction with triggered TXOP.
  • FIG. 10 shows a messaging diagram of an example multi-WTRU ACK/BA procedure 1000 in a triggered TXOP period 1014.
  • WTRUs 1001-1005 where WTRU 1005 may be an AP, may use multi-WTRU ACK/BA mechanisms in triggered TXOP period 1014.
  • a triggered TXOP period 1014 may be started by a frame 1006 transmitted by a WTRU, for example, the AP 1005.
  • the frame 1006 may be a (short) beacon or trigger frame, a resource allocation frame, an NDP frame, part of a MU frame, or any other type of frames, for example.
  • the frame 1006 may include an indication that the triggered TXOP period 1014 is of the type of SU or MU.
  • 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 multi-WTRU ACK/BA for acknowledgement of received frames.
  • the frame 1006 may indicate that the AP 1005 is scheduled to transmit one or more multi-WTRU ACK/BA during the triggered TXOP period 1014.
  • the targeted time of transmission ti, t2, and t 3 of the multi-WTRU ACK/BA frames 1008, 1010, and 1012 may be indicated in terms of absolute time, TSF timer, an offset from a reference time, such as an offset from the end of the transmission of the current frame 1006 or the start of the triggered TXOP 1014.
  • the targeted time of transmission ti, t2, and t 3 of the multi-WTRU ACK/BA frames 1008, 1010, and 1012 may also be assigned to one or more slot.
  • WTRUs that are allowed to access the medium may transmit frames to their destinations.
  • WTRU 1001 may transmit frame 1016 to AP 1005
  • WTRU 1003 may transmit frame 1018 to AP 1005.
  • Frames 1016 and 1018 may include BAs to the AP 1005.
  • Frame transmissions 1016 and 1018 may take place in assigned slots over allocated resources.
  • the WTRUs 1001 and 1003 may indicate that the ACK type is multi-WTRU ACK/BA (e.g., M- BA) in frames 1016 and 1018.
  • the WTRUs 1001 and 1003 may sleep or doze until the targeted transmission times ti, t2, and t3 of the multi-WTRU ACK/BA frames 1008, 1010, and 1012.
  • the responding WTRUs that are receive frames 1016 and 1018 for example the AP 1005 in this example, may respond by transmitting multi-WTRU ACK/BA frames 1008, 1010, and 1012 for the packets that it has received at the targeted transmission times ti, t2, and t3.
  • the AP 1005 may delay transmitting any of the multi-WTRU ACK/BA frames 1008, 1010, and 1012 until the AP 1005 has access to the medium.
  • the AP 1005 may attempt the transmission of multi-WTRU ACK/BA frames 1008, 1010, and 1012 at any or each of the targeted transmission times ti, t2, and t3, without taking into account any delays in transmitting the previous multi-WTRU ACK/BA frames.
  • a WTRU for example WTRU 1001 and/or
  • the WTRU may retransmit the unacknowledged frames the next time that the WTRU is allowed to access the medium. If a WTRU, for example WTRU 1001 and/or 1003, after transmitting did not receive any multi-WTRU ACK/BA frames, then the WTRU may retransmit the unacknowledged frames the next time that the WTRU is allowed to access the medium.
  • the WTRU (WTRU 1001 and/or 1003) may transmit a BAR or multi-WTRU BAR (not shown) to the receiving WTRU (AP 1005) as a part of the other transmissions to the receiving WTRU.
  • FIG. 11 shows a flow diagram of an example multi-WTRU
  • the example multi-WTRU ACK/BA procedure 1100 in a TWT/RAW period performed by a WTRU.
  • the example multi-WTRU ACK/BA procedure 1100 may be performed, for example, by an AP in a WLAN system using TWT/RAW procedures.
  • the example multi-WTRU ACK/BA procedure 1100 may correspond to the example multi-WTRU ACK/BA procedure 900 in FIG. 9, and as such may include any subset of the features or elements described with respect to FIG. 9.
  • an AP may send a first frame indication that the TWT/RAW period is scheduled.
  • This first frame may be, for example, frame 906 in FIG. 9.
  • the first frame may include an indication that multi-WTRU ACK/BA will be used for acknowledgement during the TWT/RAW period.
  • the first frame may include targeted time of transmission for one or more multi-WTRU ACK/BA frames.
  • the indication of target times of transmission may enable other WTRUs to sleep or doze when acknowledgement is not expected and when not transmitting otherwise.
  • the AP may send a second frame triggering the start of the TWT/RAW period.
  • This second frame may be, for example, frame 908 in FIG. 9.
  • the second frame may include an indication that multi-WTRU ACK/BA will be used for acknowledgement during the TWT/RAW period, and/or the targeted time of transmission for one or more multi-WTRU ACK/BA frames.
  • 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. (This at least one frame may be, for example, frames 910 and 912 in FIG.
  • the AP may transmit one or more multi-WTRU ACK/BA frames during the TWT/RAW period at the targeted times of transmission 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, frames 914, 916 and 918 in FIG. 9.
  • the example multi-WTRU ACK/BA procedure 1100 may be repeated in each TWT/RAW period.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, STA, AP, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
EP16785308.4A 2015-10-09 2016-10-10 Procedures for high efficiency acknowledgement transmission Pending EP3360272A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562239691P 2015-10-09 2015-10-09
PCT/US2016/056266 WO2017062947A1 (en) 2015-10-09 2016-10-10 Procedures for high efficiency acknowledgement transmission

Publications (1)

Publication Number Publication Date
EP3360272A1 true EP3360272A1 (en) 2018-08-15

Family

ID=57190241

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16785308.4A Pending EP3360272A1 (en) 2015-10-09 2016-10-10 Procedures for high efficiency acknowledgement transmission

Country Status (8)

Country Link
US (3) US10979183B2 (he)
EP (1) EP3360272A1 (he)
JP (3) JP6853243B2 (he)
KR (1) KR20180081498A (he)
CN (4) CN108370292B (he)
IL (1) IL258531B (he)
MY (1) MY192669A (he)
WO (1) WO2017062947A1 (he)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108370292B (zh) * 2015-10-09 2021-09-03 交互数字专利控股公司 针对高效应答传输的方法及装置
US10805056B2 (en) * 2015-10-28 2020-10-13 Apple Inc. Wireless station control of WLAN receive operating mode change
US10455556B2 (en) * 2016-02-04 2019-10-22 Lg Electronics Inc. Method and apparatus for changing operating mode in wireless local area network system
US10594450B2 (en) * 2016-02-15 2020-03-17 Apple Inc. Asymmetric OFDMA tone mapping and dynamic channel access using non-primary channels
US11178568B2 (en) * 2016-02-17 2021-11-16 Lg Electronics Inc. Method for uplink transmission in wireless LAN system and wireless terminal using same
US11019507B2 (en) * 2016-04-18 2021-05-25 Lg Electronics Inc. Method and apparatus for changing operating mode in wireless LAN system
US11245633B2 (en) * 2016-08-18 2022-02-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and wireless device for handling transmission of data
US20180124866A1 (en) * 2016-11-03 2018-05-03 Qualcomm Incorporated Techniques for high efficiency basic service set operation
CN108093478B (zh) * 2016-11-22 2020-11-06 华为技术有限公司 通信方法、装置和系统
US20180160459A1 (en) * 2016-12-02 2018-06-07 Motorola Mobility Llc Method and apparatus for cooperative microsleep operation
WO2018195085A1 (en) * 2017-04-17 2018-10-25 Marvell Semiconductor, Inc. Operating mode notification for wireless communication networks
JP6920872B2 (ja) * 2017-04-24 2021-08-18 キヤノン株式会社 通信装置、制御方法、及びプログラム
JP7238799B2 (ja) * 2018-01-31 2023-03-14 ソニーグループ株式会社 送信装置、および送信方法、受信装置、および受信方法、並びに通信システム
WO2019156710A1 (en) * 2018-02-09 2019-08-15 Marvell World Trade Ltd. Block ack frame with flow control
US20190253968A1 (en) * 2018-02-14 2019-08-15 Qualcomm Incorporated Managing target wake time scheduling using congestion metrics
US11917540B2 (en) * 2018-08-03 2024-02-27 Apple Inc. Target wake time scheme for multicast communication
WO2020111822A1 (ko) * 2018-11-28 2020-06-04 엘지전자 주식회사 무선랜 시스템에서 map 전송을 기반으로 데이터를 전송하는 방법 및 장치
CN114070475A (zh) * 2020-07-31 2022-02-18 华为技术有限公司 比特块的发送方法及装置
CN116349404A (zh) * 2020-10-30 2023-06-27 英特尔公司 受限服务时段
US20220216937A1 (en) * 2021-01-04 2022-07-07 Samsung Electronics Co., Ltd. System and method for downlink feedback

Family Cites Families (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4032257B2 (ja) 2004-06-28 2008-01-16 日本電気株式会社 無線ｌａｎにおける省電力化方法、基地局、端末局、無線ｌａｎシステム
US7882412B2 (en) 2004-10-05 2011-02-01 Sanjiv Nanda Enhanced block acknowledgement
EP1816666B1 (en) * 2004-10-29 2016-02-03 Fujitsu Ltd. Communication device by multicarrier transmission method and communication system
US8619658B2 (en) 2005-09-21 2013-12-31 Interdigital Technology Corporation Method and apparatus for transmission management in a wireless communication system
TWI465085B (zh) * 2006-02-14 2014-12-11 Interdigital Tech Corp Ｗｌａｎ服務中提供可靠多播服務方法及系統
JP2009532954A (ja) * 2006-03-31 2009-09-10 クゥアルコム・インコーポレイテッド 高速メディアアクセス制御に関するメモリ管理
JP5329244B2 (ja) 2009-01-16 2013-10-30 株式会社東芝 無線端末および無線通信方法
US10236950B2 (en) * 2009-02-27 2019-03-19 Qualcomm Incorporated Video transmission over SDMA
KR101711657B1 (ko) * 2009-10-20 2017-03-02 한국전자통신연구원 고용량 무선 통신 시스템에서의 자원 관리 방법
KR101758909B1 (ko) * 2010-02-18 2017-07-18 엘지전자 주식회사 무선 랜에서 수신 확인 전송 방법 및 장치
KR101915271B1 (ko) * 2010-03-26 2018-11-06 삼성전자 주식회사 무선 통신 시스템에서 자원 할당을 위한 하향링크 제어 지시 방법 및 장치
EP2600536B1 (en) * 2010-07-01 2017-05-03 LG Electronics Inc. Method and apparatus for transceiving a mimo packet in a wireless lan system
WO2012033379A2 (en) * 2010-09-10 2012-03-15 Lg Electronics Inc. Method and apparatus of cipher communication for management frame using quality of service mechanism in wireless local area network system
US20120140842A1 (en) * 2010-12-06 2012-06-07 Qualcomm Incorporated Signaling to protect advanced receiver performance in wireless local area networks (lans)
CN102752867A (zh) * 2011-03-31 2012-10-24 北京新岸线无线技术有限公司 一种用于实现链路自适应的方法、终端设备及网络设备
CN103354478A (zh) * 2011-03-31 2013-10-16 北京新岸线移动多媒体技术有限公司 一种用于实现链路自适应的方法、网络设备和终端设备
EP2742618B1 (en) * 2011-08-11 2016-07-06 LG Electronics Inc. Method and apparatus for dynamic frequency selection in wireless local area network system
US9215747B2 (en) * 2011-10-13 2015-12-15 Electronics And Telecommunications Research Institute Method and apparatus of peer link setting, and method and apparatus of channel switching, in wireless mesh network
CN103096440B (zh) * 2011-11-07 2019-01-25 中兴通讯股份有限公司 一种无线信道接入方法及系统
US9451542B2 (en) * 2011-12-11 2016-09-20 Lg Electronics Inc. Method and device for transmitting and receiving frame using short guard interval
US9137781B2 (en) 2012-01-06 2015-09-15 Industrial Technology Research Institute Method of handling hybrid automatic repeat request resources in wireless communication system
US9351176B2 (en) * 2012-01-09 2016-05-24 Qualcomm Incorporated Phase and amplitude tracking in the presence of a walking pilot signal
WO2013122424A1 (ko) * 2012-02-15 2013-08-22 엘지전자 주식회사 무선 통신 시스템에서 채널 액세스 방법 및 이를 위한 장치
JP6122039B2 (ja) * 2012-03-01 2017-04-26 インターデイジタル パテント ホールディングス インコーポレイテッド Ｗｌａｎシステムにおけるマルチユーザ並列チャネルアクセス
KR102018016B1 (ko) * 2012-03-06 2019-09-03 인터디지탈 패튼 홀딩스, 인크 무선 근거리 통신망에서의 절전을 위한 방법 및 장치
US9609665B2 (en) * 2012-03-23 2017-03-28 Lg Electronics Inc. Method and apparatus for channel access in wireless LAN system
US9049616B2 (en) * 2012-03-29 2015-06-02 Broadcom Corporation Session recovery after network coordinator or AP restart for single user, multiple user, multiple access, and/or MIMO wireless communications
CN104335663B (zh) * 2012-04-02 2019-01-22 Lg 电子株式会社 在wlan系统中接入信道的方法和设备
AU2013250182B2 (en) * 2012-04-15 2016-10-20 Lg Electronics Inc. Method and apparatus for transmitting and receiving feedback trigger frames in wireless LAN systems
US9608789B2 (en) * 2012-05-11 2017-03-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting acknowledgements in response to received frames
WO2013187710A1 (ko) * 2012-06-13 2013-12-19 한국전자통신연구원 무선랜 시스템의 오퍼레이팅 모드 변경 방법 및 무선랜 시스템
CN108668347B (zh) * 2012-06-13 2021-06-29 韩国电子通信研究院 无线局域网动态连接识别码分配操作方法、基站和接入点
CN103516461B (zh) * 2012-06-18 2019-02-12 中兴通讯股份有限公司 无线帧处理方法及系统
KR102072597B1 (ko) * 2012-06-19 2020-02-03 한국전자통신연구원 무선랜 시스템의 슬롯 기반 채널 액세스 제어 장치 및 방법, 무선랜 시스템의 슬롯 기반 채널 액세스 단말
WO2014003463A1 (ko) * 2012-06-27 2014-01-03 엘지전자 주식회사 무선 통신 시스템에서 채널 액세스 타입 지시 방법 및 이를 위한 장치
SG11201501903SA (en) 2012-09-12 2015-05-28 Agency Science Tech & Res Communication methods and communication devices
US9504032B2 (en) 2012-09-13 2016-11-22 Interdigital Patent Holdings, Inc. Method, wireless transmit/receive unit (WTRU) and base station for transferring small packets
KR101672289B1 (ko) * 2012-09-18 2016-11-03 엘지전자 주식회사 무선랜 시스템에서 청취 간격 업데이트 방법 및 장치
US8934390B2 (en) * 2012-09-28 2015-01-13 Stmicroelectronics, Inc. Enhancement of low power medium access STAs
US9544848B2 (en) * 2012-10-24 2017-01-10 Qualcomm Incorporated Methods and apparatus for communicating short paging messages in a wireless communication network
US20140161010A1 (en) * 2012-12-12 2014-06-12 Qualcomm Incorporated Enabling hierarchical wakeup schedules in a wireless system utilizing relays
EP2944140B1 (en) * 2013-01-11 2017-11-22 Interdigital Patent Holdings, Inc. Method and apparatus for communication in a network of wlan overlapping basic service set
US9351250B2 (en) * 2013-01-31 2016-05-24 Qualcomm Incorporated Methods and apparatus for low power wake up signal and operations for WLAN
US20140254408A1 (en) * 2013-03-08 2014-09-11 Qualcomm Incorporated Rate control associated with frame aggregation
CN104066198B (zh) * 2013-03-22 2019-08-30 中兴通讯股份有限公司 无线局域网络中选择信道的方法及系统
US9577811B2 (en) 2013-05-03 2017-02-21 Qualcomm Incorporated Methods and systems for frequency multiplexed communication in dense wireless environments
US20150063190A1 (en) 2013-08-28 2015-03-05 Qualcomm Incorporated Methods and apparatus for multiple user uplink
US9467379B2 (en) * 2013-08-28 2016-10-11 Qualcomm Incorporated Methods and apparatus for multiple user uplink
WO2015035210A1 (en) 2013-09-05 2015-03-12 Huawei Technologies Co., Ltd. System and method for using sic to solve wifi collisions
US20160255656A1 (en) 2013-10-01 2016-09-01 Interdigital Patent Holdings, Inc. Enhancements for coordinated orthogonal block-based resource allocation (cobra) in wlan systems
US9825678B2 (en) * 2013-11-26 2017-11-21 Marvell World Trade Ltd. Uplink multi-user multiple input multiple output for wireless local area network
US9363752B2 (en) 2013-12-27 2016-06-07 Qualcomm Incorporated Target wake time flow identification in TWT acknowledgement
WO2015127616A1 (zh) * 2014-02-27 2015-09-03 华为技术有限公司 无线局域网数据的传输方法及装置
WO2015134553A1 (en) * 2014-03-04 2015-09-11 Mediatek Inc. Subchannel feedback for ofdma systems
KR102438318B1 (ko) * 2014-10-10 2022-08-30 뉴라컴 인코포레이티드 고효율 무선랜에서 동적 자원 할당
WO2016100631A1 (en) 2014-12-17 2016-06-23 Convida Wireless, Llc Methods for enabling delay-awareness in the constrained application protocol (coap)
WO2016104886A1 (ko) * 2014-12-25 2016-06-30 엘지전자 주식회사 트리거 프레임을 기반으로 한 데이터 단위의 전송 방법 및 장치
WO2016140546A1 (ko) * 2015-03-04 2016-09-09 주식회사 윌러스표준기술연구소 다중 사용자 동시 전송을 위한 무선 통신 단말 및 무선 통신 방법
US10231182B2 (en) * 2015-03-12 2019-03-12 Intel IP Corporation Techniques for implicit indication of trigger frame start times
CN108370292B (zh) * 2015-10-09 2021-09-03 交互数字专利控股公司 针对高效应答传输的方法及装置

Also Published As

Publication number Publication date
CN108370292A (zh) 2018-08-03
IL258531B (he) 2021-03-25
JP7428778B2 (ja) 2024-02-06
CN108370292B (zh) 2021-09-03
US10979183B2 (en) 2021-04-13
CN113890688A (zh) 2022-01-04
CN113890690A (zh) 2022-01-04
US20210234642A1 (en) 2021-07-29
JP2020129833A (ja) 2020-08-27
MY192669A (en) 2022-08-30
JP6853243B2 (ja) 2021-03-31
CN113890689A (zh) 2022-01-04
JP2018535591A (ja) 2018-11-29
IL258531A (he) 2018-05-31
JP2023015285A (ja) 2023-01-31
US20180302194A1 (en) 2018-10-18
WO2017062947A1 (en) 2017-04-13
KR20180081498A (ko) 2018-07-16
US20230344564A1 (en) 2023-10-26

Similar Documents

Publication Publication Date Title
US20210234642A1 (en) Procedures for high efficiency acknowledgement transmission
US20210367716A1 (en) Triggered transmission opportunity and multiple user ack procedures in wlan systems
US11770819B2 (en) Multi-user parallel channel access in WLAN systems
US10764014B2 (en) Acknowledgements in response to received frames
US20240064634A1 (en) Procedures and mechanisms for narrowband multi-channel transmission for wake up radios
US20230308938A1 (en) Multi-link steering and control in wlan
EP2944156A1 (en) Range extension in wireless local area networks

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180503

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200303

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INTERDIGITAL PATENT HOLDINGS, INC.