WO2024168155A1

WO2024168155A1 - Enhanced reverse direction in wlan

Info

Publication number: WO2024168155A1
Application number: PCT/US2024/015008
Authority: WO
Inventors: Zinan Lin; Hanqing Lou; Rui Yang
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-02-09
Filing date: 2024-02-08
Publication date: 2024-08-15
Anticipated expiration: 2025-08-09
Also published as: EP4662813A1; MX2025009347A; CN120752871A

Abstract

A method performed by a first station (STA) may compromise: receiving, from a second STA, a physical layer protocol data unit (PPDU); transmitting, to the second STA, a first frame, including an enhanced CAS subfield, wherein the enhanced CAS subfield is set to request a reverse direction transmission; receiving, from the second STA, a second frame that indicates an acceptance of the reverse direction transmission; and transmitting, to the second STA, a third frame, the third frame including a reverse direction data transmission.

Description

ENHANCED REVERSE DIRECTION IN WLAN

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/444,430, filed February 9, 2023, U.S. Provisional Application No. 63/537,026, filed September 7, 2023, and U.S. Provisional Application No. 63/593,366, filed October 26, 2023, the contents of which are incorporated herein by reference.

SUMMARY

[0002] A method performed by a first station (STA) may comprise: receiving, from a second STA, a physical layer protocol data unit (PPDU); transmitting, to the second STA, a first frame, including an enhanced command and status (CAS) subfield, wherein the enhanced CAS subfield is set to request a reverse direction transmission; receiving, from the second STA, a second frame that indicates an acceptance of the reverse direction transmission; and transmitting, to the second STA, a third frame, the third frame including a reverse direction data transmission.

[0003] The second frame may include a legacy CAS field, including an RDG/More PPDU subfield, wherein the RDG/More PPDU subfield is set to accept the reverse direction transmission. The RDG/More PPDU subfield may be set to 1. The first frame may be a +HTC BlockAck frame. The second frame may be a +HTC frame. The third frame may be a +HTC PPDU frame. The enhanced CAS subfield may be set to 1. The first frame may further include a RDG/More PPDU subfield. The first STA may be a non-access point (AP) STA.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0005] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0006] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0007] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0008] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0009] FIG. 2 is an example of a MAC frame format; [0010] FIG. 3 is an example of a high throughput (HT) control field format;

[0011] FIG. 4 is an example of a control subfield of a high efficiency (HE) variant HT control field format;

[0012] FIG. 5 is an example of a control subfield format;

[0013] FIG. 6 is an example of a control information subfield format in a command and status (CAS) control subfield;

[0014] FIG. 7 is an example of a HE MAC Capabilities Information field format;

[0015] FIG. 8 is an example of a HE 6 GHz Band Capabilities element format;

[0016] FIG. 9 is an example of a Capabilities Information field format;

[0017] FIG. 10 is an example of a trigger frame format in 802.11 ax;

[0018] FIG. 11 is an example of a Common Info field in a Trigger frame;

[0019] FIG. 12 is an example of a User Info field in a Trigger frame;

[0020] FIG. 13 is an example of a Control Information subfield format in an Enhanced CAS Control subfield;

[0021] FIG. 14 is an example procedure to indicate that a transmit opportunity (TXOP) responder transmits a reverse direction (RD) request and TXOP holder accepts the RD request;

[0022] FIG. 15 is an example of a RD frame exchange using an enhanced CAS;

[0023] FIG. 16 is an example of a Control Information subfield in a multi-link device (MLD) Enhanced CAS

Control subfield;

[0024] FIG. 17 is an example of a P2P traffic scenario;

[0025] FIG. 18 is an example of a control information subfield format in an Enhanced CAS Control subfield that indicates a P2P transmission request;

[0026] FIG. 19 is an example procedure of a RD request for peer-to-peer (P2P) transmission accepted by the TXOP holder;

[0027] FIG. 20 is an example procedure of a RD frame exchange using an enhanced CAS with a P2P traffic indication where the TXOP accepts the P2P RD request and the time used for P2P transmission is same as the allocated time by the RD initiator;

[0028] FIG. 21 is an example procedure of a RD frame exchange using an enhanced CAS with P2P traffic indication where the TXOP accepts the P2P RD request and the time used for P2P transmission is shorter than the allocated time by the RD initiator;

[0029] FIG. 22 is an example procedure of a RD frame exchange using an enhanced CAS with P2P traffic indication, where the TXOP holder accepts the P2P RD request and the time used for P2P transmission is shorter than the allocated time by the RD initiator and RD requester transmits QoS Null frame including the legacy CAS with the RDG/More PPDU set to 0; [0030] FIG. 23 is an example procedure of a RD frame exchange using an enhanced CAS with P2P traffic indication, where the TXOP declines the P2P RD request;

[0031] FIG. 24 is an example of a RD frame exchange using an enhanced CAS with P2P traffic indication, where the TXOP holder accepts the P2P RD request and RD requester sends data to multiple peering STAs; [0032] FIG. 25 is an example of a RD frame exchange using an enhanced CAS with P2P traffic indication, where the TXOP holder accepts the P2P RD request and initiates triggered TXOP sharing procedure;

[0033] FIG. 26 is an example of a Control Information subfield format in an Enhanced CAS Control subfield which indicates P2P transmission request; and

[0034] FIG. 27 is a flow chart providing an exemplary procedure for enhanced reverse direction.

DETAILED DESCRIPTION

[0035] FIG. 1A is a diagram illustrating 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. For example, 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), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0036] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 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. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0037] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, 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.

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

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

[0040] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may 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 (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA). [0041] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

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

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

[0044] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like. [0045] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0046] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 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. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0048] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0049] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, 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/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0050] 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 Arrays (FPGAs), 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. 1B 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.

[0051] 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. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0052] Although the transmit/receive element 122 is depicted in FIG. 1B as a single element, 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. [0053] 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. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0054] 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/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, 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. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0055] 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. For example, 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.

[0056] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, 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.

[0057] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/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, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

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

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

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

[0061] Each of the eNode-Bs 160a, 160b, 160c 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 UL and/or DL, and the like. As shown in FIG. 10, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface. [0062] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

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

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

[0066] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. [0067] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0068] In representative embodiments, the other network 112 may be a WLAN.

[0069] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0070] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0071] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0072] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0073] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control/Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0074] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all ST As in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0075] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

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

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

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

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

[0080] Each of the gNBs 180a, 180b, 180c 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 UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0081] The CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

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

[0084] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, 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 UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

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

[0086] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0087] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications.

[0088] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0089] A wireless local-area network (WLAN) in Infrastructure Basic Service Set (BSS) mode has an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in and out of the BSS. T raffic to STAs that originates from outside the BSS arrives through the AP and is delivered to the STAs. Traffic originating from STAs to destinations outside the BSS is sent to the AP to be delivered to the respective destinations. Traffic between STAs within the BSS may also be sent through the AP where the source STA sends traffic to the AP and the AP delivers the traffic to the destination STA.

[0090] Using the 802.11ac infrastructure mode of operation, the AP may transmit a beacon on a fixed channel, usually the primary channel. This channel may be 20 MHz wide, and is the operating channel of the BSS. This channel is also used by the STAs to establish a connection with the AP. The fundamental channel access mechanism in an 802.11 system is Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). In this mode of operation, every STA, including the AP, may sense the primary channel. If the channel is detected to be busy, the STA backs off. Hence only one STA may transmit at any given time in a given BSS.

[0091] In 802.11n, High Throughput (HT) STAs may also use a 40 MHz wide channel for communication. This is achieved by combining the primary 20 MHz channel, with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0092] In 802.11ac, Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. The 40 MHz, and 80 MHz, channels are formed by combining contiguous 20 MHz channels similar to 802.11n described above. A160 MHz channel may be formed either by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may also be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, is passed through a segment parser that divides it into two streams. The Inverse Discrete Fourier Transformation (IDFT) operation and time domain processing are done on each stream separately. The streams are then mapped on to the two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is sent to the MAC. [0093] To improve spectral efficiency 802.11ac has introduced the concept for downlink Multi-User MIMO (MU-MIMO) transmission to multiple STA’s in the same symbol’s time frame, e.g., during a downlink OFDM symbol. The potential for the use of downlink MU-MIMO is also currently considered for 802.11ah. It is important to note that since downlink MU-MIMO, as it is used in 802.11ac, uses the same symbol timing to multiple STA’s interference of the waveform transmissions to multiple STA’s is not an issue. However, all STA’s involved in MU-MIMO transmission with the AP must use the same channel or band, this limits the operating bandwidth to the smallest channel bandwidth that is supported by the STA’s which are included in the MU- MIMO transmission with the AP.

[0094] A STA may be able to construct a subset of the frames for transmission and to decode a (potentially different) subset of the frames upon validation following reception. The particular subset of these frames that a STA constructs and decodes may be determined by the functions supported by that particular STA. A STA may be able to validate every received frame using the frame check sequence (FCS) and to interpret certain fields from the MAC headers of all frames.

[0095] A STA may transmit frames using only the frame formats developed in IEEE 802.11 standards. The MAC frame format comprises a set of fields that occur in a fixed order in all frames.

[0096] FIG. 2 depicts the general MAC frame format 200 for protocol version 0 (PV0) MPDU. As shown in FIG. 2, the MAC frame may include a Frame Control field 202, Duration/ID field 204, Address 1 field 206, Address 2 field 208, Address 3 field 210, Sequence Control field 212, Address 4 field 214, QoS Control field 216, HT control field 218, Frame Body field 220, and FCS field 222.

[0097] The HT Control field 218 may always be present in a Control Wrapper frame and is present in QoS Data, (802.11 ax) QoS Null, and Management frames as determined by the +HTC subfield of the Frame Control field as defined in the IEEE 802.11.

[0098] The HT Control field 218 may be transmitted by a non-China Millimeter-Wave Multi-Gigabit (non- CMMG) STA. may have three variants: the HT variant, the VHT variant, and the HE variant. The variant formats may be differentiated by the values of B0 and B1. FIG. 3. Illustrates the three variants of the HT control field 218.

[0099] FIG. 4 illustrates an example format 400 of an A-Control (Aggregated Control) subfield of a HE variant HT Control field. As shown in FIG, 4, the A-Control subfield may include a Control List subfield 402 and Padding subfield 404. Further, the A-Control subfield may be 30 bits in length. The Control List subfield contains one or more Control subfields.

[0100] FIG. 5 illustrates an example format of a Control subfield. As shown in FIG. 5, the Control subfield may include a Control ID subfield 502 and Control Information subfield 504. The Control ID subfield 502 may indicate the type of information carried in the Control Information subfield 504. The length of the Control Information subfield 504 may be fixed for each value of the Control ID subfield 502 that is not reserved. The values of the Control ID subfield 502 and the associated length of the Control Information subfield 504 are defined in Table 1 below.

Table 1 - Control ID Subfield Values

[0101] The Control Information subfield in a CAS Control subfield contains the command and status (CAS) control. FIG. 6 illustrates an example format 600 of a Control Information subfield in a CAS Control subfield.

[0102] As shown in FIG. 6, the Control Information subfield in a CAS control subfield may include an AC Constraint subfield 602, RDG/More PPDU subfield 604, PSRT PPDU subfield 606, and Reserved subfield 608.

[0103] The AC Constraint subfield 602 is defined in Table 2 below, except that a value of 1 indicates to an HE STA that the response may contain RD Data frames from the same AC or higher priority ACs as defined in 10.29.4 (Rules for RD responder) in IEEE Std 802.11-REVme/D1.0: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Dec. 2021.

[0104] The RDG/More PPDU subfield 604 is defined in Table 3 below. The PSRT PPDU subfield may indicate whether the PPDU carrying the frame with the CAS Control subfield is an PSRT PPDU. The PSRT PPDU subfield is set to 1 if the PPDU is an PSRT PPDU; otherwise, it is set to 0.

Table 2 - AC Constraint Subfield Values

Table 3 - RDG/More PPDU Subfield Values

[0105] A HE STA declares that it is an HE STA by transmitting the HE Capabilities element. The HE capabilities element contains Element ID, length, Element ID Extension, HE MAC Capabilities Information, HE PHY Capabilities Information, Supported HE-MCS And NSS Set and PPE Thresholds (optional) subfields. FIG. 7 illustrates an example format 700 of a HE MAC Capabilities Information field.

[0106] A HE STA operating in the 6 GHz band may declare its extended capabilities by transmitting the HE 6 GHz Band Capabilities element. FIG. 8 illustrates an example format 800 of a HE 6 GHz Band Capabilities element. As shown in FIG. 8, the HE 6 GHz Band Capabilities element may include an Element ID field 802, Length field 804, Element ID Extension field 806, and Capabilities Information field 808. The Element ID 802, Length, and Element ID Extension fields 806 are defined in 802.11 IEEE standards.

[0107] FIG. 9 illustrates an example format 900 of the Capabilities Information field 808 As shown in FIG. 9, the Capabilities Information field 808 may include a Minimum MPDU Start Spacing subfield 902, Maximum A-MPDU Length Exponent subfield 904, Maximum MPDU Length subfield 906, Reserved subfield 908, SM Power Save subfield 910, RD Responder subfield 912, Rx Antenna Pattern Consistency subfield 914, Tx Antenna Pattern Consistency subfield 916, and Reserved subfield 918.

[0108] The RD Responder subfield 912 is defined in Table 4 below.

Table 4 - RD Responder Subfield of the HT Extended Capabilities Field

[0109] An HT STA may indicate support of the RD feature as an RD responder using the RD Responder subfield of the HT Extended Capabilities field of the HT Capabilities element or the RD Responder subfield of the HE 6 GHz Band Capabilities element. A STA may set the RD Responder subfield to 1 in frames that it transmits that include the HT Capabilities element in the 2.4 GHz or 5 GHz band and set the RD Responder subfield to 1 in frames that it transmits that include the HE 6 GHz Band Capabilities element in the 6 GHz band if dot 11 RDResponderOptionlmplemented is true. Otherwise, the STA may set the RD Responder subfield to 0. In a non-HE HT STA, the RDG/More PPDU subfield and the AC Constraint subfield may be present in the HTC field. In an HE STA, the RDG/More PPDU subfield and the AC Constraint subfield may be present in the CAS Control subfield.

[0110] An RD exchange sequence may include the transmission of a PPDU by a TXOP holder or SP source containing an RD grant (the RDG PPDU), which is indicated by the PPDU containing one or more +HTC or DMG MPDUs in which the RDG/More PPDU subfield is equal to 1. The STA that transmits this PPDU may be known as the RD initiator. The rules for an RD initiator apply only during a single RD exchange sequence (i.e., after the transmission of an RDG PPDU and up to the end of the last PPDU in the RD exchange sequence).

[0111] An RD exchange sequence may comprise the transmission of one or more PPDUs (the RD response burst) by the STA addressed in the MPDUs of the RDG PPDU. The first (or only) PPDU of the RD response burst contains at most one immediate BlockAck or Ack frame. The last (or only) PPDU of the RD response burst contains any MPDUs requiring a response that is an immediate BlockAck or Ack frame. The STA that transmits the RD response burst is known as the RD responder. The rules for an RD responder apply only during a single RD exchange sequence, i.e., following the reception of an RDG PPDU and up to the transmission of a PPDU by the RD responder in which the RDG/More PPDU subfield is equal to 0.

[0112] An RD exchange sequence may comprise the transmission of a PPDU by the RD initiator including an immediate BlockAck frame or Ack frame (the RD initiator final PPDU) The transmission of the PPDU may be required by the last PPDU of the RD response burst.

[0113] Transmission of a MPDU by an HE RD initiator that includes a CAS Control subfield with the RDG/More PPDU subfield equal to 1 may indicate that the duration indicated by the Duration/ID subfield is available for the RD response burst and RD initiator final PPDU (if present). A HE STA RD initiator that sets the RDG/More PPDU subfield to 1 in a CAS Control subfield in a frame transmitted during a TXOP may set the AC Constraint subfield in the CAS Control subfield to 1.

[0114] The recipient of an RDG may decline the RDG by: (1) not transmitting any frames following the RDG PPDU if no response is otherwise required and/or (2) transmitting a control response frame aggregated with other MPDUs with the RDG/More PPDU subfield set to 0.

[0115] The RD responder may ensure that its PPDU transmission(s) and any expected responses fit entirely within the remaining TXOP or SP duration, as indicated in the Duration/ID field of MPDUs within the RDG PPDU. An RD responder may not transmit an MPDU (either individually or aggregated within an A-MPDU) that is not one of the following frames: (1) Ack; (2) Compressed BlockAck; (3) Compressed BlockAckReq; (4) Extended Compressed BlockAck; (5) Extended Compressed BlockAckReq; (6) Multi-STA BlockAck; (7) QoS Data; (8) Management; and/or (9) Basic Trigger. [0116] During an RD response burst, any PPDU transmitted by an RD responder may contain at least one MPDU with an Address 1 field that matches the MAC address of the RD initiator or at least one Trigger frame that addresses the RD initiator, and the inclusion of traffic to STAs other than the RD initiator in a VHT MU PPDU, S1G MU PPDU, or HE MU PPDU may not increase the duration of the PPDU beyond that required to transport the traffic to the RD initiator. The RD responder may not transmit a frame that is not a Basic Trigger frame and that causes a response after SIFS with an Address 1 field that does not match the MAC address of the RD initiator. The RD responder may not transmit any PPDUs with a CH_BANDWIDTH that is wider than the CH_BANDWIDTH of the PPDU containing the frame(s) that delivered the RD grant. An RD responder that transmits a Basic Trigger frame may set the CS Required subfield to 1 and may allocate a number of streams for the RD initiator that is not smaller than the number of streams of the RD initiator’s last PPDU. If an RD initiator sets the RDG/More PPDU field to 1 in a +HTC frame transmitted during a TXOP and sets the AC Constraint subfield to 1 in that frame, the RD responder may set the Preferred AC subfield of the Trigger Dependent User Info field in the Trigger frame to the same AC as the last frame received from the RD initiator. If an RDG PPDU also requires an immediate block ack response, the BlockAck frame may be included in the first PPDU of the response.

[0117] Trigger frames were first introduced in IEEE 802.11ax. Trigger frames may be used to allocate resources and trigger single or multi-user access. FIG. 10 illustrates an exemplary Trigger frame format 1000. As shown in FIG. 10, a Trigger frame may include a Frame Control field 1002, Duration field 1004, TA field 1008, Common Info field 1010, User Info field 1012, blank field 1014, User Info field 1016, Padding field 1018, and FCS field 1020.

[0118] FIG. 11 illustrates an exemplary Common Info field format 1100. As shown in FIG. 11, the Common Info field may include a Trigger Type subfield 1102, UL Length subfield 1104, More TF subfield 1106, CS Required subfield 1108, UL BW subfield 1110, Gl and HE-LTF Mode subfield 1112, MU-MIMO HE-LTF Mode subfield 1114, Number HE-LTF Symbols and Midamble Periodicity subfield 1116, UL STBC 1118, LDPC Extra Symbol Segment subfield 1120, AP Tx Power subfield 1122, Pre-FEC Padding Factor subfield 1124, PE Disambiguaty subfield 1126, UL Spatial Reuse subfield 1128, Doppler subfield 1130, UL HE-SIG-A2 Reserved subfield 1132, Reserved subfield 1134, and Trigger Dependent Common Info subfield 1136.

[0119] FIG. 12 illustrates an exemplary User Info field for all trigger types except Null Feedback Report Poll (NFRP) trigger. As shown in FIG. 12, the User Info field may include a AID12 field 1202, RU Allocation field 1204, UL FEC Coding Type field 1206, UL HE-MCS field 1208, UL DCM field 1210, SS Allocation/RA RU Information field 1212, UL Target Receive Power field 1214, Reserved field 1216, and Trigger Dependent User Info field 1218.

[0120] Table 5 below provides possible values for the Trigger Type subfield in Common Info field.

Table 5 - Trigger Type

[0121] A “reverse direction transmission” is a transmission where data is sent from a TXOP responder to a TXOP holder. In 802.11 , a STA may acquire the wireless medium (WM) and become a TXOP holder. The TXOP holder may allow reverse direction transmission by transmitting a PPDU containing one or more +HTC fields in which the RDG/More PPDU subfield is set to 1. The STA that transmits this PPDU may be referred to as the RD initiator (also the TXOP holder). The addressed STA of the PPDU may be referred to a TXOP responder or a RD responder. On reception of the PPDU, the RD responder may respond with acknowledgement and reverse direction data transmissions. With the existing scheme, the RD initiator is the STA which may initiate the procedure. The RD responder may not be able to request a RD transmission.

[0122] In an embodiment, an enhanced RD procedure may include reusing the signaling defined in +HTC field. The enhanced RD procedure may be generalized using any other mechanisms or signaling. In general, a TXOP responder and/or any STA may request an enhanced reverse direction transmission by transmitting a frame with a RD Request. The TXOP holder may grant the RD by transmitting a frame with a RD grant. The TXOP responder may then start RD data burst transmissions or request additional resource for a RD burst. With P2P transmission, the procedure may be generalized using any other mechanisms or signaling. In general, a TXOP responder and/or any STA may request enhanced reverse direction/P2P transmissions by transmitting a frame with a RD request and/or a P2P request. The TXOP holder may grant the RD and/or P2P by transmitting a frame with a RD/P2P grant. Next, the TXOP responder may start RD transmissions and/or P2P data burst transmissions or request additional resources for a RD/P2P burst. The RD request, RD grant, P2P request, and/or P2P grant may be a field/subfield included in a frame, or element/subelement included in a frame, or a control/action frame, or a management frame, etc.

[0123] The primary use cases and applications for EHT include high throughput and low latency applications such as: (1) Video-over-WLAN; (2) Augmented Reality (AR); and (3) Virtual Reality (VR). A list of features that has been discussed in the EHT SG and 802.11 be to achieve the target of increased peak throughput and improved efficiency include: multi-AP, multi-band/multi-link, 320 MHz bandwidth, and new designs for 6 GHz channel access.

[0124] The RD protocol in 802.11ax is initiated by the TXOP holder. However, in many scenarios (e.g., the latency sensitive traffic comes in the recipient STA of the TXOP holder), the recipient STA may need to deliver the traffic as soon as possible due to the low latency requirements. Given the stringent latency requirements of this type of traffic, it may be desirable to design a protocol which enables the recipient STA of the TXOP holder to indicate the latency sensitive traffic to the TXOP holder (e.g. through enhanced CAS, and request for a data transmission from the recipient STA to the TXOP holder.

[0125] The RD protocol in 802.11 ax specification enables the RD frame exchange, which grants the data transmission from the recipient STA of the TXOP holder to the TXOP holder. As traffic volume and the number of devices increase, there is more traffic, particularly latency sensitive traffic, in the peering STAs. Therefore, there is a need for a simple but effective protocol to enable peer to-peer (P2P) communication through enhanced CAS.

[0126] Some data transmission (e.g., low latency traffic) may come to the TXOP responder or the TXOP holder during the middle of an ongoing TXOP. The recipient of this data may be an STA which is neither the TXOP responder or the TXOP holder. To ensure the recipient STA is not in power save mode and is available to receive the data, there may be a need to have mechanisms to make the potential recipient STAs available during this situation, especially in a case of low latency traffic delivery.

[0127] In one embodiment, an enhanced CAS subfield may be included in the Control Information subfield in a CAS Control subfield that contains the enhanced CAS control. FIG. 13 illustrates an exemplary Control Information field in an Enhanced CAS Control subfield. As shown in FIG. 13, the Control Information field may include an AC Constraint subfield 1302, RDG/More PPDU subfield 1304, PSRT PPDU subfield 1306, Enhanced CAS subfield 1308, and Reserved subfield 1310. The enhanced CAS control may enable the recipient STA of the TXOP holder to request the TXOP holder to grant the reverse direction transmission due to the incoming of the unexpected traffic (e.g., latency sensitive traffic).

[0128] Table 6 below depicts example value interpretations of Enhanced CAS and RDG/More PPDU fields. In Table 6, a RD requester may be the recipient STA of a TXOP holder. When the RDG/More PPDU subfield is set to 0 and the Enhanced CAS subfield is set to 1 in the Control Information subfield which is sent by the RD requester, it may indicate that the recipient TXOP holder, or RD requester, requests the TXOP holder to grant a reverse direction transmission in the next round. One factor that causes this request may be due to the incoming latency sensitive traffic, which may have a stringent latency requirement.

Table 6 - Example value Interpretations of Enhanced CAS and RDG/More PPDU subfields

[0129] The request for reverse direction may be included in any other part of MAC header, fields, subfields, elements, or sent in an individual MAC frame.

[0130] In an embodiment, the recipient STA of the TXOP holder may send the RD request to the TXOP holder and this request may be included in the +HTC field which is sent with a Block Ack (BA) frame upon the reception of the data frame from the TXOP holder.

[0131] FIG. 14 provides an exemplary flowchart which depicts that the TXOP responder transmits an RD request using an enhanced CAS and TXOP holder accepts the RD request. The RD requester may carry the reverse direction request in any other part of MAC header, fields, subfields, elements or sent in an individual MAC frame.

[0132] As shown in FIG. 14, at 1402, STA1 (the TXOP holder), may transmit a PPDU containing MPDUs addressed to STA2. This PPDU may require an immediate Block Ack (BA) response from STA2

[0133] At 1404, upon reception of the PPDU sent from STA1 , STA2 with low latency traffic in its buffer, may act as an RD requester and responds the PPDU with the transmission of a +HTC BlockAck frame in which the Enhanced CAS subfield is set to 1 and the RDG/More PPDU subfield is set to 0. This setting may indicate that STA2 requests STA1 to grant the reverse direction transmission, which may be the urgent traffic transmission. [0134] At 1406, upon reception of the +HTC BlockAck frame from STA2, STA1 may regain control of the TXOP, agree to grant the reverse direction transmission to STA2, and uses +HTC data frame with the legacy CAS to indicate RDG by setting the RDG/More PPDU subfield in the CAS control subfield to 1.

[0135] At 1408, upon reception of RDG, STA2, acting as the RD requester and the RD responder, may respond with the transmission of a +HTC BlockAck frame in which the Enhanced CAS subfield is set to 0 (i.e., legacy CAS) and the RDG/More PPDU subfield is set to 1 , indicating that another PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame. STA2, transmits a +HTC PPDU (the 2nd PPDU of an RD response burst) in which the enhanced CAS subfield is set to 1 and RG/More PPDU = 0. This setting may indicate to STA1 that there is no more PPDU in this Response Burst and there is a request for RDG from STA2.

[0136] At 1410, upon reception of the enhanced CAS which indicates RD request from STA2, STA1 (acting as a RD initiator) may regain control of the TXOP and transmit a +HTC BlockAck frame addressed to STA2 to acknowledge the MPDUs transmitted by STA2 in the RD response and RD request burst. This +HTC blockAck includes a legacy CAS control subfield in which the RDG/More PPDU subfield is set to 1. This indicates that STA1 agrees to grant the RD to STA2 per its request. At 1412, STA2 (the RD requester and the RD responder) may transmit a PPDU to STA1 , containing QoS data +HTC MPDUs with Implicit BAR ack policy and the RDG/More PPDU subfield set to 0. This represents that it is the only PPDU in the RD response burst. At 1414, STA1 may transmit a BlockAck (BA) frame to STA2 that acknowledges the MPDUs transmitted by STA2 in the RD response burst.

[0137] FIG. 15 provides examples of enhanced frame exchanges which shows the RD request sent from the recipient of TXOP holder, TXOP responder. As shown in FIG. 15, at 1510, STA1 1502 (the TXOP holder), may transmit a PPDU containing MPDUs addressed to STA2 1504. This PPDU may require an immediate Block Ack (BA) response from STA2 1504.

[0138] At 1512, upon reception of the PPDU sent from STA1 1502, STA2 1504 with low latency traffic in its buffer, may act as an RD requester and responds the PPDU with the transmission of a +HTC BlockAck frame in which the Enhanced CAS subfield is set to 1 and the RDG/More PPDU subfield is set to 0. This setting may indicate that STA2 1504 requests STA1 1502 to grant the reverse direction transmission, which may be the urgent traffic transmission.

[0139] At 1514, upon reception of the +HTC BlockAck frame from STA2 1504, STA1 1502 may regain control of the TXOP, agree to grant the reverse direction transmission to STA2 1504, and use the +HTC data frame with the legacy CAS to indicate RDG by setting the RDG/More PPDU subfield in the CAS control subfield to 1.

[0140] At 1516, upon reception of RDG, STA2 1504, acting as the RD requester and the RD responder, may respond with the transmission of a +HTC BlockAck frame in which the Enhanced CAS subfield is set to 0 (i.e., legacy CAS) and the RDG/More PPDU subfield is set to 1 , indicating that another PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame. STA2 1504, transmits a +HTC PPDU (the 2nd PPDU of an RD response burst) in which the enhanced CAS subfield is set to 1 and RG/More PPDU = 0. This setting may indicate to STA1 1502 that there is no more PPDU in this Response Burst and there is a request for RDG from STA2 1504.

[0141] At 1518, upon reception of the enhanced CAS subfield, which indicates RD request from STA2 1504, STA1 1502(acting as a RD initiator) may regain control of the TXOP and transmit a +HTC BlockAck frame addressed to STA2 to acknowledge the MPDUs transmitted by STA2 1504 in the RD response and RD request burst. This +HTC blockAck includes a legacy CAS control subfield in which the RDG/More PPDU subfield is set to 1. This indicates that STA1 agrees to grant the RD to STA2 1504 per its request. At 1520, STA2 1504 (the RD requester and the RD responder) may transmit a PPDU to STA1 1502, containing QoS data +HTC MPDUs with Implicit BAR ack policy and the RDG/More PPDU subfield set to 0. This represents that it is the only PPDU in the RD response burst. At 1522, STA1 1502 may transmit a BlockAck (BA) frame to STA2 1504 that acknowledges the MPDUs transmitted by STA2 1504 in the RD response burst.

[0142] The RD requester may also indicate the traffic related parameters (e.g., the type of traffic, the traffic size, etc.), using the reserved bits shown in FIG. 13.

[0143] Alternatively, STA1, the TXOP holder may reject the RD request from STA2 by setting the RDG subfield to 0 in the CAS control subfield.

[0144] In one embodiment, the RD Requester field may be included in either the Capabilities Information field of HE 6 GHz Band Capabilities element or the EHT MAC Capabilities Information field or any other Capabilities Information fields. Table 7 below provides an exemplary RD Requester field, which may be present in the HE 6 GHz Band Capabilities element, or the EHT MAC Capabilities Information field or any other Capabilities Information fields.

Table 7 - Exemplary RD Requester subfield of HE 6 GHz Band Capabilities element or EHT MAC Capabilities Information field

[0145] In one embodiment, the enhanced CAS control subfield may include the link information for MultiLink Device (MLD) STA.

[0146] FIG. 16 illustrates an exemplary of Control Information field in a MLD Enhanced CAS Control subfield format 1600. As shown in FIG. 16, the Control Information field in a MLD Enhanced CAS Control subfield may include a AC Constraint subfield 1602, RDG/More PPDU subfield 1604, PSRT PPDU subfield 1606, Enhanced CAS subfield 1608, and Link ID subfield 1610. The Link ID field may be included in the Enhanced CAS Control subfield. Table 7 below gives the example value interpretation of RDG/More PPDU, Enhanced CAS and link ID subfields.

Table 7 - Example value Interpretations of RDG/More PPDU, Enhanced CAS and Link ID subfields [0147] FIG. 16 and Table 7, illustrate, that in a situation where the transmitting STA is the RD requester, if the Enhanced CAS subfield is set to 1 , the RDG/More PPDU field is set to 0, and Link ID field is set to a value between 0 and 15, then the transmitting STA may request RDG for the next transmission on the link indicated in the Link ID field. In the case where the transmitting STA is the RD initiator which grants the reverse direction transmission to the recipient STA of the TXOP holder (i.e., RD initiator), if the Enhanced CAS subfield is set to 1 and RDG/More PPDU value is set to 1 , the granted reverse transmission may be present in the link whose Link ID is indicated in the Link ID subfield. In this case, if the RDG/PPDU field is set to 0 in the PPDU sent by the RD initiator, then the TXOP holder, which is RD Initiator, may not grant the reverse direction transmission to the RD requester on any link.

[0148] In one embodiment, the STA may use the PHY header to indicate the low latency traffic that needs to be delivered from the buffer and request the reverse direction grant. For example, the Disregard bits in the U-SIG field of EHT MU PPDU or EHT TB PPDU may be used for the urgent traffic indication, which shows traffic type, traffic size, or allocation time for reverse direction. This indication is sent to the recipient of the RD requester (e.g., TXOP holder to request for the reverse direction grant). The reverse direction transmission may include the reverse direction from the RD requester to the TXOP holder or from the RD requester to other ST As, which may not be the TXOP holder. The low latency traffic indication or reverse transmission request may need be included in the TXVECTOR and RXVECTOR parameters.

[0149] In another embodiment, the Enhanced CAS subfield may be used to request reverse direction transmission for P2P traffic. This P2P traffic may refer to the traffic delivered from the TXOP responder to another STA, which is not the TXOP holder. The TXOP responder indicates the traffic type (e.g., low latency traffic) to the TXOP holder and request a transmission grant (i.e., request the TXOP holder to allocate some time for this traffic delivery).

[0150] FIG. 17 illustrates the exemplary P2P scenario described above. As shown in FIG. 17, the TXOP responder T2 1704 (i.e., STA2) may have traffic data (e.g., low latency data) to be delivered to R3 1708 (i.e., STA3) during the TXOP in which T1 1702 (i.e., STAT1) is the TXOP holder and R2 1706 (i.e., STA2) is the TXOP responder. Number notation represents different STA. For example, T1 1702 may define that STA1 is a transmitter that delivers traffic to STA2 and R2 1706 may define STA2 is a receiver. T2 1706 may define that STA2 is the transmitter that delivers traffic to STA3 and R3 1708 may define STA3 as the receiver.

[0151] The embodiment proposed above may be applicable to a TXOP holder (e.g. T1 1702) that is an AP and the TXOP responder (e.g., R2 1706) is a non-AP STA. The recipient of the traffic data indicated by the TXOP responder (e.g., T2 1704) is a non-AP STA or another AP (e.g., R3 1708).

[0152] The embodiment proposed above may be applicable to the TXOP holder (e.g. T1 1702) is a non- AP STA and the TXOP responder (e.g., R2 1706) is an AP. The recipient of the traffic data indicated by the TXOP responder (e.g., T2 1704) is a non-AP STA or another AP (e.g., R3 1708). [0153] In one embodiment, the enhanced CAS subfield may include the reverse direction transmission for P2P traffic. In this enhanced CAS Control subfield, three new subfields may be included: Enhanced CAS, P2PTx, and TimeDuration.

[0154] FIG. 18 depicts an exemplary Control Information field format 1800 in an Enhanced CAS Control subfield. As shown in FIG. 18, the Control Information field format may include a AC Constraint subfield 1802, RDG/More PPDU subfield 1804, PSRT PPDU subfield 1806, Enhanced CAS subfield 1808, PSPTx subfield 1810, and Allocation Duration subfield 1812.

[0155] Table 8 below illustrations the corresponding value interpretation of the Control Information Field.

Table 8 - Example Value Interpretations of Enhanced CAS, RDG/More PPDU and P2PTX fields

[0156] In a situation where the transmitting STA is the RD requester that requests the grant of the reverse direction transmission from the TXOP holder (i.e., RD initiator), if the Enhanced CAS subfield is set to 1 , the P2PTx subfield is set to 1 , and the RDG/More PPDU Value subfield is set to O, the STA may request the RDG for P2P transmission (no RDG for P2P transmission is granted yet), for example, due to the latency sensitive traffic in its buffer; or that after RDG for P2P transmission is given, this STA has no more PPDU in this response burst but there is another P2P transmission in the next response burst (e.g., the P2P transmission for one peering STA is finished but there is another P2P transmission for another peering STA within the time allocated to the P2P transmission). If the Enhanced CAS subfield is set to 1 , the P2PTx subfield is set to 1 and the RDG/More PPDU Value subfield is set to 1 , it may indicate that the PPDU carrying the frame which is transmitted by the RD requester is followed by another PPDU transmitted to the same peering STA.

[0157] In one embodiment, the Enhanced CAS subfield may indicate if the transmission is an enhanced RD request/response. If the Enhanced CAS subfield is set to 0, then the receiving STA may treat this as a legacy CAS field and no P2P communication would be considered. The RDG/More PPDU subfield may indicate if the RD initiator/TXOP holder grants the transmission opportunity to the RD responder. If this field is set to 0, then no transmission opportunity is granted to the RD responder. The P2PTx subfield may further indicate if the P2P transmission is allowed in the granted transmission opportunity. If P2P transmission is allowed, then reverse direction transmissions are always allowed. Three subfields may be used to indicate if P2P transmission only may be allowed (but reverse direction is not allowed) for the granted transmission opportunity. In a situation where the transmitting STA is the RD initiator (e.g., the TXOP holder), if the Enhanced CAS subfield is set to 1 , the P2PTx subfield is set to 1, and the RDG/More PPDU Value subfield is set to 0, the P2P transmission and/or reverse direction transmission requested by the RD requester may not be granted (i.e., the P2P transmission is rejected and reverse direction is rejected). If the Enhanced CAS subfield is set to 1 , the P2PTx subfield is set to 1 , and the RDG/More PPDU Value subfield is set to 1 , the P2P transmission may be granted to the RD requester but reverse direction transmission may NOT be granted to the RD requester. If the RDG/More PPDU subfield is set to 1 , the Enhanced CAS subfield is set to 0, and the P2PTx subfield is set to 0, it may indicate that only the reverse direction transmission is granted but the P2P transmission between the TXOP responder and any other STA is not allowed. If the RDG/More PPDU subfield is set to 1 , the Enhanced CAS subfield is set to 1 , and the P2PTx subfield is set to 0, it may indicate that the reverse direction transmission is granted (i.e., RDG is present, and it allows for reverse transmission from the TXOP responder to the TXOP holder and the P2P transmission between the TXOP responder and other STA(s)).

[0158] The above value setting is an exemplary interpretation for the actions that the TXOP responder and the TXOP holder may take. Other combinations of value settings may be interpreted as the same actions that the TXOP responder and the TXOP holder may take as described above.

[0159] The Enhanced CAS subfield and/or P2P Tx subfield may be defined in A-Control field in the examples above. However, the Enhanced CAS subfield and/or P2P Tx subfield may be defined and carried in other field/subfield or frames to indicate the request or grant of reverse direction transmission or P2P transmission (e.g., low latency traffic delivery request or grant).

[0160] If the enhanced CAS control is transmitted by the RD requester, the Allocation Duration subfield of the enhanced CAS control subfield represents the time requested for P2P transmission; if the enhanced CAS control is transmitted by the RD initiator, the Allocation Duration subfield of the enhanced CAS control subfield represents the time allocated to P2P transmission by the RD initiator. Please note if the RD initiator rejects the P2P RDG, i.e., the RDG/More PPDU is set to 0, the Enhanced CAS subfield is set to 1 and the P2PTx subfield is set to 1 , then the RD requester may ignore the value shown in the Allocation Duration subfield sent from the RD initiator or the value of Allocation Duration may be all zeros. Alternatively, if the RD initiator (TXOP holder orAP) accepts the RD request by setting the Enhanced CAS subfield to 1 , the RDG/More PPDU subfield to 1 , the P2P Tx subfield to 1 , and decides to use MU-RTS TXS trigger frame to trigger TXOP sharing procedure for the P2P transmission between the RD requester and other STA(s), then the RD initiator may set the Allocation Duration subfield to 0, indicating that MU-RTS TXS trigger frame is followed after it receives the acknowledgement from the RD requester.

[0161] There may be many quantization ways to convert the actual allocation duration for P2P Tx to the bit value shown in the Allocation Duration subfield. In one option, Max allocation duration and Min allocation duration are defined as 111 and 001 respectively. The system may define the Max and the Min allocation duration. Then each value in the Allocation Duration subfield may be increased by

MaxAllocationDuration—MinAllocationDuration

from the previous value. For example 010 may represent the

■ . . MaxAUocationDuration-MinAUocationDuration

Value increased Dy

from Min allocation duration; 011 may

MaxAUocationDuration-MinAUocationDuration represent the value increased by

from the value represented by 010, etc. Another option is that the bit value shown in the Allocation Duration subfield represents a predefined quantized value. The difference between quantized values represented by any pair of neighboring bits may not be the same. For example, the difference between quantized values represented by 001 and 010 may not be the same as the difference between quantized values represented by 011 and 010.

[0162] The TXOP holder or the RD initiator may grant the reverse direction to the TXOP responder for P2P transmission with or without the request from the TXOP responder using the Enhanced CAS control subfield or any other fl elds/element of MAC frame or an individual MAC frame. The P2P transmission may refer to the transmissions between the RD requester (or TXOP responder) and the other STAs which are not the TXOP holder.

[0163] In one embodiment, the STA, which is the recipient of the TXOP holder, may send out the reverse direction request for P2P transmission to the TXOP holder. The allocation time for P2P transmission may also be included in the request.

[0164] FIG. 19 shows the exemplary flow chart of RD request for P2P transmission accepted by the TXOP holder. The protocol shown in FIG. 19 may be applied to the case where the TXOP holder or the RD initiator is not an AP but a non-AP STA. The TXOP holder may grant the reverse direction to the TXOP responder for the transmission between the TXOP responder (or the RD requester) and other STA(s) which do not include the TXOP holder. The signaling used for the reverse direction request may not be limited to Enhanced CAS control subfield. It may be any other fields/element of MAC frame or an individual MAC frame.

[0165] FIG. 20 illustrates an exemplary RD frame exchanges using the enhanced CAS with P2P traffic indication (the format follows the example shown in FIG. 18). The example procedure shown in FIG. 20 depicts the where the TXOP holder accepts the P2P RD request (i.e. , RDG for P2P is present).

[0166] At 2010, STA1 2002, the TXOP holder (e.g., AP), may transmit a data frame to STA2 2004.

[0167] At 2012, STA2 2004 may have urgent traffic (e.g., latency sensitive traffic) for other peering STAs (or other APs) in its buffer and would like to request reverse direction grant from STA1 2002. After receiving the data from STA1 2002, STA2 2004 may send a +HTC Blockframe in which the Enhanced CAS subfield is set to 1, the RDG/More PPDU subfield is set to 0, the P2PTx subfield is set to 1, and the Allocation Duration subfield is set to a valid value (e.g., from 1 to 7), which may give the TXOP holder an estimation on the volume of P2P traffic to be delivered.

[0168] At 2014, STA1 2002 may regain control of the TXOP and transmit a +HTC data frame to indicate that it accepts the RDG request for P2P Tx from STA22004. STA1 2002 becomes the RD initiator. In the +HTC data frame, STA1 2002 may use the Enhanced CAS control subfield and may set the Enhanced CAS subfield and the RDG subfield to 1. STA1 2002 may also set a valid value in the Allocation Duration subfield (e.g., from 1 to 7). The RD initiator may not have to set the exact the same value shown in the Allocation Duration subfield sent by STA2 2004. STA1 2002 may allocate the same, less, or more time than what is indicated in the Allocation Duration subfield sent by STA2 2004. The allocated time for P2P transmission may need to follow the duration remained in the TXOP. In the example of FIG. 20, the allocated time duration for P2PTx is same as the remaining duration of the TXOP (i.e., Allocated Duration) for P2P Tx = floor (TXOP Duration - Time for Data frame from STA1 - Time for +HTC BlockAck frame from STA2 - Time for +HTC Data frame from STA1 - Time for +HTC BlockAck frame from STA2).

[0169] At 2016 upon reception of +HTC Data frame with enhanced CAS subfield from STA1 2002, STA2 2004 may respond with the transmission of a +HTC BlockAck frame in which the RDG/More PPDU subfield is set to 1 and the P2P Tx subfield is set to 1 , indicating that a P2P PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0170] At 2018, STA2 2004 may transmit the P2P PPDU to STA32006 (the 2nd PPDU of the RD response burst) with implicit BAR ack policy for its QoS Data frames and containing legacy CAS included the RDG/More PPDU subfield set to 0, indicating this is the last PPDU in the response burst.

[0171] At 2020, upon reception of the data from STA2 2004, STA32006 may transmit a BlockAck frame to STA2 2004 that acknowledges the MPDUs transmitted by STA2 2004 in the RD response burst.

[0172] In the example indicated FIG. 20, STA2 2004 may use all the allocated time assigned by STA1 2002, the RD initiator. Alternatively, STA2 may terminate the P2P transmission earlier than the allocated time. In this case, STA2 2004 may return the control of TXOP to STA1 2002, the original TXOP holder. [0173] FIG. 21 illustrates an exemplary procedure for RD frame exchange using an Enhanced CAS subfield with P2P traffic indication where the TXOP accepts the P2P RD request and the time used for P2P transmission is the same as the allocated time by the RD initiator.

[0174] At 2110, STA1 2102, the TXOP holder (e.g., AP), may transmit a data frame to STA2 2104.

[0175] At 2112, STA2 2104 may have urgent traffic (e.g., latency sensitive traffic) for other peering STAs (or other APs) in its buffer and would like to request reverse direction grant from STA1 2102. After receiving the data from STA1 2102, STA2 2104 may send a +HTC Blockframe in which the Enhanced CAS subfield is set to 1, the RDG/More PPDU subfield is set to 0, the P2PTx subfield is set to 1, and the Allocation Duration subfield is set to a valid value (e.g., from 1 to 7), which may give the TXOP holder an estimation on the volume of P2P traffic to be delivered.

[0176] At 2114, STA1 (the RD initiator) may accept the RDG request for P2P transmission from STA2 and allocate a certain time during for the requested P2P transmission, which is shown in the Allocation Duration subfield of the enhanced CAS subfield carried the +HTC data frame sent from STA1 2102 to STA2 2104. This data frame may request an immediate block ACK response.

[0177] At 2116, STA2 2104 (the RD requester/responder) may respond with the transmission of a +HTC BlockAck frame in which the RDG/More PPDU subfield is set to 1 and the P2P Tx subfield is set to 1 , indicating that a P2P PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0178] At 2118, STA2 2004 may transmit a +HTC data frame to STA3 2106, where the +HTC data frame may include a legacy CAS with a RDG/More PPDU subfield set to 1 and indicate the last PPDU in this response burst.

[0179] At 2120, upon reception of the data from STA2 2104, STA32106 may transmit a BlockAck frame to STA2 2104 that acknowledges the MPDUs transmitted by STA2 2104 in the RD response burst.

[0180] At 2122, STA2 2104 finishes the P2P transmission earlier than the time allocated for P2P transmission and may return the TXOP to STA1 2102.

[0181] At, 2124, STA1 2102 may decode the legacy CAS control subfield with the RDG/More PPDU subfield set to 0 and regain control of the TXOP and send the data frame to STA2 2104. STA2 2104 may responds with BlockAck frame. Alternatively, STA1 2102 may start to regain control of TXOP within the allocated duration for P2P transmission and within TxPIFS boundary because the CS mechanism indicates the medium is idle after the reception of the BA frame sent from STA2.

[0182] Alternatively, after STA2 2104, the RD requester for P2P transmission, finishes the P2P transmission earlier than the allocated time duration indicated in the Allocated Duration subfield included in the enhanced CAS transmitted by STA1 2102, STA2 2104 may transmit to STA1 a +HTC QoS Null frame using legacy CAS control subfield in which the RDG/More PPDU subfield is set to 0. This indicates to STA1 that there is not more PPDU in the RD response burst. STA1 regains control of the TXOP and transmits data frame to STA2 and STA2 transmits the BlockAck frame which is solicited by STA1. Alternatively, STA2 may also transmit CF-end frame to STA1 to indicate there is no more PPDU in the RD response burst after its P2P transmission finishes earlier than the allocated duration assigned to P2P transmission by the RD initiator/TXOP holder, STA1.

[0183] FIG. 22 illustrates exemplary of RD frame exchanges using an enhanced CAS with P2P traffic indication. As shown in FIG 22, at TXOP holder, STA1 2202 accepts the P2P RD request from STA2. STA2 2204 finishes the P2P transmission earlier than the time allocated by STA1 2202 and uses +HTC QoS Null frame to indicate there is no more PPDU in the RD response burst by setting the RDG/More PPDU subfield to 1 in the legacy CAS control subfield.

[0184] At 2210, STA1 2202, the TXOP holder (e.g., AP), may transmit a data frame to STA2 2204.

[0185] At 2212, STA2 2204 may have urgent traffic (e.g., latency sensitive traffic) for other peering STAs (or other APs) in its buffer and would like to request reverse direction grant from STA1 2202. After receiving the data from STA1 2202, STA2 2204 may send a +HTC Blockframe in which the Enhanced CAS subfield is set to 1, the RDG/More PPDU subfield is set to 0, the P2PTx subfield is set to 1, and the Allocation Duration subfield is set to a valid value (e.g., from 1 to 7), which may give the TXOP holder an estimation on the volume of P2P traffic to be delivered.

[0186] At 2214, STA1 (the RD initiator) may accept the RDG request for P2P transmission from STA2 and allocate a certain time during for the requested P2P transmission, which is shown in the Allocation Duration subfield of the enhanced CAS subfield carried the +HTC data frame sent from STA1 2202 to STA2 2204. This data frame may request an immediate block ACK response.

[0187] At 2216, STA2 2104 (the RD requester/responder) may respond with the transmission of a +HTC BlockAck frame in which the RDG/More PPDU subfield is set to 1 and the P2P Tx subfield is set to 1 , indicating that a P2P PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0188] At 2218, STA2 2204 may transmit a +HTC data frame to STA3 2206, where the +HTC data frame may include a legacy CAS with a RDG/More PPDU subfield set to 1 and indicate the last PPDU in this response burst.

[0189] At 2220, upon reception of the data from STA2 2204, STA32206 may transmit a BlockAck frame to STA2 2204 that acknowledges the MPDUs transmitted by STA2 2204 in the RD response burst.

[0190] As 2222, STA2 2204 may transmit a +HTC QoS Null frame to STA1 2202 to indicate there is no more PPDU in the RD response burst by setting the RDG/More PPDU subfield to 1 in the legacy CAS control subfield.

[0191] In one embodiment, the TXOP holder (e.g., STA1) may also reject the P2P transmission request from STA2 by using the enhanced CAS control subfield with the Enhanced CAS subfield set to 1, the P2P Tx subfield set to 1 and the RDG/More PPDU subfield set to 0. [0192] FIG. 23 illustrates an exemplary P2P RD frame exchange procedure in which STA1 2302, the TXOP holder rejects the request of reverse direction transmission for P2P traffic sent from STA1 2302. In this example, after indicating the rejection of P2P RDG request at 2310, STA1 2302 may send the data transmission to STA2 2304 at 2312. The data transmission may be acknowledged by STA2 at 2314.

[0193] In one embodiment, after the RD requester receives the RDG for P2P transmission from the TXOP holder/RD initiator (e.g. AP), it may perform P2P transmission to different peering STAs.

[0194] FIG. 24 illustrates an exemplary RD frame exchanges using an enhanced CAS with a P2P transmission indication. In this example, the TXOP holder accepts the P2P reverse direction request and the RD requesters (i.e., STA1) sends data to multiple peering STAs, (e.g., STA3 and STA4). The time used for P2P transmission is the same as the time indicated in the Allocation Duration subfield set by the RD initiator, STA2.

[0195] At 2410, STA1 2410 (the RD initiator) may transmit data to STA2 2402.

[0196] At 2412, STA2 2404 may have urgent traffic (e.g., latency sensitive traffic) for other peering STAs (or other APs) in its buffer and would like to request reverse direction grant from STA1 2102. After receiving the data from STA1 2402, STA2 2404 may send a +HTC Blockframe in which the Enhanced CAS subfield is set to 1, the RDG/More PPDU subfield is set to 0, the P2PTx subfield is set to 1, and the Allocation Duration subfield is set to a valid value (e.g., from 1 to 7), which may give the TXOP holder an estimation on the volume of P2P traffic to be delivered.

[0197] At 2414, STA1 2402 may accept the RDG request for P2P transmission from STA2 2404 and allocates a certain time during for the requested P2P transmission, which is shown in the Allocation Duration subfield of the enhanced CAS subfield carried the +HTC data frame sent from STA1 to STA2. This data frame requests an immediate block ack response.

[0198] At 2416, STA2 2404 (the RD requester/responder) may respond with the transmission of a +HTC BlockAck frame in which the RDG/More PPDU subfield is set to 1 and the P2P Tx subfield is set to 1 , indicating that a P2P PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame. The P2P PPDU sent to STA2 carries an enhanced CAS which sets the Enhanced CAS subfield to 1, the RDG/More PPDU subfield to 0 and the P2P Tx subfield to 1. This setting may indicate that there is another P2P transmission after the acknowledgement sent by STA3 to STA2 in the response burst.

[0199] At 2414, STA3 2406 (the peering STA in reverse response burst) may responds with a BlockAck frame. Next, SIFs or PIFs after receiving the BA from STA3 2406, STA22404 may transmit another data frame to STA4 2408, including a legacy CAS with a RDG/More PPDU subfield set to 0. This may indicate that this is the last PPDU in this response burst.

[0200] In one embodiment, after reception of the P2P RD request from the TXOP responder (the recipient of TXOP holder), the AP, which is TXOP holder and the RD initiator, may transmit the MU-RTS TXS Trigger frame to initiate the triggered TXOP sharing procedure, which enables the P2P transmission between the RD requester and another STA within the allocated time indicated in the MU-RTS TXS Trigger frame.

[0201] FIG. 25 illustrates an exemplary procedure for RD frame exchanges using an enhanced CAS with P2P traffic indication - TXOP holder may accept the P2P RD request and initiates triggered TXOP sharing procedure.

[0202] At 2512, STA2 2542, the TXOP responder, may receive data frame from the AP 2502, the TXOP holder, and may transmit back +HTC BlockAck frame which includes the enhanced CAS control subfield to request RD transmission to the peering STA by setting the Enhanced CAS subfield to 1, the RDG/More PPDU subfield to 0, the P2P Tx subfield to 1 , and the Allocation Duration to a valid value (between 0 to 7).

[0203] At 2514, upon reception of the BlockAck frame from STA2 2504, AP 2502 may transmit the +HTC data frame to STA2 2204 including the enhanced CAS control subfield which indicates RDG to STA2 and accepts P2P transmission request from STA22504 (i.e., setting the enhanced CAS subfield to 1 , the RDG/More PPDU subfield to 1 and the P2P Tx subfield to 1). The acknowledgement policy of the data frame may be Implicit BAR.

[0204] At 2516, upon reception of the data frame from AP 2502, STA2 2504 (the RD responder) may transmit a PPDU to AP, including +HTC MPDUs with the RDG/More PPDU subfield set 0, indicating that this is the last PPDU to AP 2502 in the response burst. This PPDU may contain a BlockAck frame that is a response to the implicit block ac request of the previous PPDU sent by AP 2502.

[0205] At 2518, AP 2502 may regain control of the TXOP and transmits MU-RTS TXS Trigger frame to initiate the triggered TXOP sharing which allows STA22504, the RD requester to transmit to another STA (e.g., ST A32506, within the time allocated in MU-RTX TXS Trigger frame).

[0206] In one embodiment, the Enhanced CAS Control subfield may use one bit to indicate RDG or More PPDU or P2P Tx. FIG. 26 illustrates an exemplary format for a Control Information subfield in an Enhanced CAS Control subfield that indicates a P2P transmission request. As shown in FIG. 26, the Control Information subfield may include a AC Constraint subfield 2602, RDG/More PPDU/P2PTx subfield 2604, PSRT PPDU subfield 2606, Enhanced CAS subfield 2608, and TimeDuration subfield 2610. Table 9 below provides the The corresponding value interpretation of the various subfield.

[0207] The TimeDuration subfield 2610 may indicate that the requested allocation duration in quantized form if it is transmitted by the RD requester; or it indicates the allocated allocation duration for P2P transmission in quantized form it is transmitted by the RD initiator. In the case that the RD initiator grants the reverse direction to the TXOP responder for P2P transmission (with or without the request from the TXOP responder), it may set the Enhanced CAS subfield 2608 to 1 and RDG/More PPDU/P2P Tx subfield 2604 to 1. The corresponding TimeDuration subfield 2610 may be set to the value between 1 to 15 to indicate the quantized allocation duration for P2P transmission or it may be set to 0, indicating that it may use MU-RTS TXS triggered TXOP sharing to initiate the P2P transmission from the TXOP responder (or RD requester) to another STA. The MU- RTS TXS trigger frame may be sent after the reception of the acknowledgment from the TXOP responder/RD responder.

[0208] In a situation where the STA that transmits +HTC with the enhanced CAS control subfield is the RD requester, if RDG/More PPDU Value/P2P Tx subfield is set to 1 and the Enhanced CAS subfield is set to 1 , the RD requester (the TXOP responder) may request RDG for P2P transmission before the reverse direction is granted by the TXOP holder; or after the RDG is granted by the RD initiator, it represents there is no more PPDU in the same transmission but there is another P2P transmission after this transmission (i.e., after reception of ACK from the recipient of the current PPD if RDG/More PPDU Value/P2P Tx subfield is set to 1 and the Enhanced CAS subfield is set to 1). If RDG/More PPDU Value/P2P Tx subfield is set to 0 and the Enhanced CAS subfield is set to 1 , it may represent that the RD requester (the TXOP responder) requests RDG for reverse transmission, e.g., the transmission from the RD responder (TXOP responder) to the RD initiator (TXOP holder).

[0209] In a situation where the STA that transmits +HTC with the enhanced CAS control subfield is the RD initiator (or TXOP holder), if RDG/More PPDU Value/P2P Tx subfield is set to 1 and the Enhanced CAS subfield is set to 1, it may represent that the TXOP responder grant the reverse direction to the TXOP responder (e.g., RD requester). This RD transmission may include the transmission from the RD requester to the RD initiator or the RD requester to another STA.

Table 9 - Example Value Interpretations of Enhanced CAS and RDG/More PPDU/P2PTx Subfields

[0210] In one embodiment, a LL group ID may be assigned to a group of STAs. The LL group ID or the IDs of these STAs may be carried in a management frame (e.g., Beacon frame, FILS Discovery frame, Probe Response frame, etc.). This group of STAs may refer to the potential recipient STAs which may receive the LL traffic, or any special traffic (e.g., broadcasting traffic), in the TXOP which may not be initially assigned to these STAs. This may imply that in the TXOP, where these STAs are neither the TXOP holder or the TXOP responder, they may be the potential recipients of LL traffic from the TXOP holder or the TXOP responder if there is any LL traffic which arrives at the TXOP holder or TXOP responder during the middle of TXOP.

[0211] In one embodiment, one bit may be carried in the EHT variant Common Info field of the MU-RTS trigger frame (e.g., any bit in B22, B53 or B56-B63) to indicate that this TXOP may allow the non TXOP participant to receive or transmit the low latency traffic. This bit may be named as 3rd-Party Reception/Transmission subfield. For example, if the trigger frame is a MU-RTS (i.e., Trigger Type subfield is set to 3 in the EHT variant Common Info field of the trigger frame) and the Triggered TXOP Sharing Mode subfield is set to 3, then the 3rd-Party Reception/Transmission subfield which is set to 1 may indicate that the STA which belongs to the LL group of STAs indicated in the management frame may be neither in power save mode nor in doze mode and they may need to be awake to decode any potential package which is intended to them (e.g., LL data); it may also imply that the TXOP holder may allow the STA which belongs to the LL group ID indicated in the management frame to transmit low latency data to the TXOP holder or the TXOP receiver.

[0212] Alternatively, the LL group ID may be carried in a trigger frame, e.g., in the EHT variant Common Info field of the MU-RTS trigger frame (any bit in B22, B53 or B56-B63). If the LL group ID is carried in the Trigger frame, it may imply that the STAs which belong to the LL group ID may be the potential receiver of the low latency traffic which is not initially scheduled in this TXOP. The traffic may come in the middle of TXOP from the TXOP holder or TXOP receiver. Additionally, if the LL group ID is carried in the T rigger frame, it may imply that this TXOP allows these STAs which belong to this group ID to transmit the low latency traffic.

[0213] Additionally, the indication that allows the low latency traffic interruption during the middle of TXOP and/or the indication of the type of LL traffic that can interrupt the ongoing TXOP may be carried in the TXOP initiation frame (e.g., MU-RTS Trigger frame, RTS frame, enhanced MU-RTS Trigger frame, etc.). These indications may also be carried in the preamble of EHT PPDU (e.g., U-SIG.) The LL traffic interruption may refer to the scenario where the TXOP was initially assigned to some STAs for certain type of traffic. In the middle of TXOP, a higher priority traffic comes to one STA, which may be the TXOP holder, TXOP responder, or neither TXOP holder nor TXOP responder. The examples of TXOP interruption may include the reverse direction operation, the enhanced reversed direction operation, etc. If the indication allows the interruption from LL traffic and the incoming traffic belongs to the allowable traffic type, then the TXOP holder may grant the transmission to this STA and/or schedule this LL traffic delivery.

[0214] Although the features and elements described above are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. Although the solutions described herein consider 802.11 specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well. [0215] FIG. 27 is a flow chart providing an exemplary procedure for enhanced reverse direction. At 2702, a first STA may receive, from a second STA, a PPDU. At 2704, the first STA may transmit, to the second STA, a first frame, including an enhanced CAS subfield, wherein the enhanced CAS subfield is set to request a reverse direction transmission. At 2706, the first STA may receive, from the second STA, a second frame that indicates an acceptance of the reverse direction transmission. At 2708, the first STA may transmit, to the second STA, a third frame, the third frame including a reverse direction data transmission.

[0216] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. 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, magnetooptical 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, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is Claimed:

1. A method comprising performed by a first station (STA), the method comprising: receiving, from a second STA, a physical layer protocol data unit (PPDU); transmitting, to the second STA, a first frame, including an enhanced command and status (CAS) subfield, wherein the enhanced CAS subfield is set to request a reverse direction transmission; receiving, from the second STA, a second frame that indicates an acceptance of the reverse direction transmission; and transmitting, to the second STA, a third frame, the third frame including a reverse direction data transmission.

2. The method of claim 1 , wherein the second frame includes a legacy CAS field, including a reverse direction grant (RDG)ZMore PPDU subfield, wherein the RDG/More PPDU subfield is set to accept the reverse direction transmission.

3. The method of claim 2, wherein the RDG/More PPDU subfield is set to 1.

4. The method of claim 1, wherein the first frame is a +High-Throughput Control (+HTC) BlockAck frame.

5. The method of claim 1, wherein the second frame is a +HTC frame.

6. The method of claim 1, wherein the third frame is a +HTC PPDU frame.

7. The method of claim 1 , wherein the enhanced CAS subfield is set to 1.

8. The method of claim 1 , wherein the first frame further includes a RDG/More PPDU subfield.

9. The method of claim 1 , wherein the first STA is a non-access point (AP) STA.

10. A first station (STA) comprising: a transceiver; and a processor; wherein the transceiver and processor are configured to: receiving, from a second STA, a physical layer protocol data unit (PPDU); transmitting, to the second STA, a first frame, including an enhanced command and status (CAS) subfield, wherein the enhanced CAS subfield is set to request a reverse direction transmission; receiving, from the second STA, a second frame that indicates an acceptance of the reverse direction transmission. transmitting, to the second STA, a third frame, the third frame including a reverse direction data transmission.

11. The first STA of claim 10, wherein the second frame includes a legacy CAS field, including a reverse direction grant (RDG)ZMore PPDU subfield, wherein the RDG/More PPDU subfield is set to accept the reverse direction transmission.

12. The first STA of claim 11, wherein the RDG/More PPDU subfield is set to 1.

13. The first STA of claim 10, wherein the first frame is a +High Throughput Control (+HTC) BlockAck frame.

14. The first STA of claim 10, wherein the second frame is a +HTC frame.

15. The first STA of claim 10, wherein the third frame is a +HTC PPDU frame.

16. The first STA of claim 10, wherein the enhanced CAS subfield is set to 1.

17. The first STA of claim 10, wherein the first frame further includes a RDG/More PPDU subfield.

18. The first STA of claim 10, wherein the first STA is a non-access point (AP) STA.