Extended Reverse Direction in WLAN

Abstract

A method performed by a first station (STA) may include receiving a physical layer protocol data unit (PPDU) from a second STA; transmitting a first frame to the second STA including an extended CAS subfield, where the extended CAS subfield is set to request a reverse transmission; receiving a second frame from the second STA indicating acceptance of the reverse transmission; and transmitting a third frame to the second STA, where the third frame includes a reverse data transmission.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) 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 of the Invention

[0002] A method performed by a first station (STA) may include receiving a physical layer protocol data unit (PPDU) from a second STA; transmitting a first frame to the second STA including an extended command and status (CAS) subfield, where the extended CAS subfield is set to request a reverse transmission; receiving a second frame from the second STA indicating acceptance of the reverse transmission; and transmitting a third frame to the second STA, where the third frame includes a reverse data transmission.

[0003] The second frame may include a legacy CAS field including an RDG / More PPDU subfield, where the RDG / More PPDU subfield is set to accept reverse 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 extended CAS subfield may be set to 1. The first frame may further include an RDG / More PPDU subfield. The first STA may be a non-access point (AP) STA. [Brief explanation 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, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that can be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 2] An example of a MAC frame format is shown below. [Figure 3] 1 is an example of a high throughput (HT) control field format. [Figure 4] 1 is an example of a control subfield in a high-efficiency (HE) modified HT control field format. [Figure 5] 1 is an example of a control subfield format. [Figure 6] 1 is an example of a control information subfield format within a Command and Status (CAS) control subfield. [Figure 7] 1 is an example of a HE MAC capability information field format. [Figure 8] This is an example of the HE 6GHz band capability element format. [Figure 9] 10 is an example of a capability information field format. [Figure 10] This is an example of a trigger frame format for 802.11ax. [Figure 11] 1 is an example of a common information field in a trigger frame. [Figure 12] 10 is an example of a user information field of a trigger frame. [Figure 13] 1 is an example of a control information subfield format within an extended CAS control subfield. [Figure 14] 1 is an exemplary procedure for a transmit opportunity (TXOP) responder to send a reverse direction (RD) request and for a TXOP holder to indicate acceptance of the RD request. [Figure 15] This is an example of an RD frame exchange using extended CAS. [Figure 16] 1 is an example of a control information subfield within a multi-link device (MLD) extended CAS control subfield. [Figure 17] This is an example of a P2P traffic scenario. [Figure 18] 10 is an example of a control information subfield format in an extended CAS control subfield indicating a P2P transmission request. [Figure 19] 1 is an example of a procedure for a RD request for a peer-to-peer (P2P) transmission that is accepted by a TXOP holder. [Figure 20] 10 is an exemplary procedure for RD frame exchange using extended CAS with P2P traffic indication, where the TXOP accepts a P2P RD request and the time used for P2P transmission is the same as the time assigned by the RD initiator. [Figure 21] 10 is an exemplary procedure for RD frame exchange using extended CAS with P2P traffic indication when a TXOP accepts a P2P RD request and the time used for P2P transmission is less than the time allocated by the RD initiator. [Figure 22]10 is an exemplary procedure for an RD frame exchange using extended CAS with P2P traffic indication, in which the TXOP holder accepts the P2P RD request, the time used for the P2P transmission is less than the time allocated by the RD initiator, and the RD requester sends a QoS null frame containing a legacy CAS with RDG / More PPDU set to 0. [Figure 23] 10 is an exemplary procedure for RD frame exchange using extended CAS with P2P traffic indication, where the TXOP denies the P2P RD request. [Figure 24] 1 is an example of an RD frame exchange using extended CAS with P2P traffic indication, in which a TXOP holder accepts a P2P RD request and an RD requester transmits data to multiple peering STAs. [Figure 25] 10 is an example of an RD frame exchange using extended CAS with P2P traffic indication, in which the TXOP holder accepts the P2P RD request and initiates the triggered TXOP sharing procedure. [Figure 26] 10 is an example of a control information subfield format in an extended CAS control subfield indicating a P2P transmission request. [Figure 27] 10 is a flowchart providing an example procedure for an extended reverse direction. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, and the like, to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access schemes, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tailed 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.

[0006] 1A, communications system 100 may include wireless transmit receive units (WTRUs) 102a, 102b, 102c, and 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, and 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 user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, 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 (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated processing chain), a consumer electronics device, a device network operating over commercial and / or industrial wireless, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

[0008] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with 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 transceiver for each sector of the cell. In some embodiments, the base station 114a may employ multiple-input multiple output (MIMO) technology and 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.

[0009] 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).

[0010] More specifically, as noted above, the communications system 100 may be a multiple-access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c of the RAN 104 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 communications 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).

[0011] In one 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).

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

[0013] 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 jointly perform LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

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

[0015] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, but may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, or other location. 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 establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

[0016] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, mobility, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid 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 understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0018] 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 a base station 114a that can use cellular-based wireless technology and a base station 114b that can use IEEE 802 wireless technology.

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

[0020] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), other types of integrated circuits (ICs), a state machine, etc. 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 understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0021] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., 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, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0022] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use 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.

[0023] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals 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 to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0024] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. 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 home computer (not shown).

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

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

[0027] 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 electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), 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, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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.

[0028] The WTRU 102 may include a full-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe) on both the UL (e.g., for transmission) and DL (e.g., for reception) in parallel and / or simultaneously. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through 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 transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on either the UL (e.g., for transmission) or DL ​​(e.g., for reception) in parallel and / or simultaneously.

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

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

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

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

[0033] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. 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.

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

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

[0036] 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 landline communications devices. For example, the CN 106 may include or 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 other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0037] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

[0038] In an exemplary embodiment, the other network 112 may be a WLAN.

[0039] 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 interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within a BSS may be transmitted, for example, through the AP, where the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between (e.g., directly between) a source STA and a destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

[0040] When using 802.11ac infrastructure mode operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a wide 20 MHz bandwidth) or a dynamically configured width. The primary channel may be the operating channel of the BSS and may be used by 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 an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is detected / sensed 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 in a given BSS at any given time.

[0041] High throughput (HT) STAs may use 40 MHz wide channels for communication, for example, through combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

[0043] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metered control / machine-based communications (MTC), such as MTC devices within macro coverage areas. MTC devices may have limited functionality, including support (e.g., support only) of specific bandwidths and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0044] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STA from among all STAs operating in the BSS that support the smallest bandwidth operating mode. In the 802.11ah example, the primary channel of a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration may depend on the status of the primary channel. For example, if the primary channel is busy because a STA (which only supports 1 MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the available frequency band remains idle.

[0045] In the United States, the available frequency band that can be used with 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah is 6MHz to 26MHz depending on the country code.

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

[0047] The RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using, for example, multiple antennas. In an embodiment, the gNBs 180a, 180b, and 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, and the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0048] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with 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 the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., different lengths of absolute time including and / or lasting different numbers of OFDM symbols).

[0049] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0050] 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 for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0051] 1D 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 shown as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0054] The UPFs 184a, 184b may be connected to one or more 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 UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policy, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchors, etc.

[0055] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts 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 other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to the local DNs 185a, 185b via the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0056] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices 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 simulate network and / or WTRU functions.

[0057] The emulation device may be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while 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 tests using over-the-air wireless communication.

[0058] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication 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.

[0059] 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 into and out of the BSS. Traffic originating from outside the BSS to a STA arrives through the AP and is delivered to the STA. Traffic originating from a STA to a destination outside the BSS is sent to the AP for delivery to the respective destination. Traffic between STAs within a 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.

[0060] Using the 802.11ac infrastructure mode of operation, an AP may transmit beacons 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 may also be used by STAs to establish a connection with the AP. The basic channel access mechanism in 802.11 systems is carrier sense multiple access with collision avoidance (CSMA / CA). In this mode of operation, STAs, including the AP, can sense the primary channel. If the channel is detected to be busy, the STA backs off. Therefore, only one STA may transmit at any given time within a given BSS.

[0061] In 802.11n, high-throughput (HT) STAs may also use 40 MHz-wide channels for communication, which is achieved by combining a primary 20 MHz channel with adjacent 20 MHz channels to form a 40 MHz-wide contiguous channel.

[0062] In 802.11ac, very high throughput (VHT) STAs can support channels of 20 MHz, 40 MHz, 80 MHz, and 160 MHz width. The 40 MHz and 80 MHz channels are formed by combining contiguous 20 MHz channels, similar to 802.11n described above. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels, which may also be referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data is passed through a segment parser that splits the data into two streams. An inverse discrete Fourier transform (IDFT) operation and time-domain processing are performed separately for each stream. The streams are then mapped to two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is transmitted to the MAC.

[0063] To improve spectral efficiency, 802.11ac introduced the concept of downlink multi-user MIMO (MU-MIMO) transmission to multiple STAs in the same symbol time frame, e.g., during a downlink OFDM symbol. The possible use of downlink MU-MIMO is also currently being considered for 802.11ah. It is important to note that because downlink MU-MIMO uses the same symbol timing for multiple STAs, as used in 802.11ac, interference of waveform transmissions to multiple STAs is not an issue. However, all STAs involved in MU-MIMO transmission with the AP must use the same channel or band, which limits the operating bandwidth to the smallest channel bandwidth supported by the STAs involved in MU-MIMO transmission with the AP.

[0064] A STA may be able to construct a subset of frames for transmission and decode a (potentially different) subset of frames upon verification following receipt. The particular subset of frames that a STA constructs and decodes may be determined by the capabilities supported by that particular STA. A STA may be able to verify all received frames using a Frame Check Sequence (FCS) and interpret some fields from the MAC header of all frames.

[0065] STAs may transmit frames using only the frame format developed in the IEEE 802.11 standard. The MAC frame format comprises a set of fields that occur in a fixed order in every frame.

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

[0067] The HT Control field 218 may always be present in control wrapper frames, and is present in QoS Data, (802.11ax) QoS Null, and management frames, as determined by the +HTC subfield of the Frame Control field defined in IEEE 802.11.

[0068] The HT control field 218 may be transmitted by non-China millimeter wave multi-gigabit (non-CMMG) STAs. It may have three variants: HT variant, VHT variant, and HE variant. The variant formats may be distinguished by the values ​​of B0 and B1. Figure 3 shows the three variants of the HT control field 218.

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

[0070] 5 shows an example format of the control subfield. As shown in FIG. 5, the control subfield may include a control ID subfield 502 and a 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 lengths of the control information subfield 504 are defined in Table 1 below.

[0071] [Table 1]

[0072] The control information subfield within the CAS control subfield contains command and status (CAS) controls. Figure 6 shows an example format 600 of the control information subfield within the CAS control subfield.

[0073] As shown in FIG. 6, the control information subfields within the CAS control subfield may include an AC constraint subfield 602, a RDG / More PPDU subfield 604, a PSRT PPDU subfield 606, and a reserved subfield 608.

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

[0075] 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 a PSRT PPDU. The PSRT PPDU subfield is set to 1 if the PPDU is a PSRT PPDU, and is set to 0 otherwise.

[0076] [Table 2]

[0077] [Table 3]

[0078] An HE STA declares itself as an HE STA by sending an HE Capability element. The HE Capability element includes the following subfields: Element ID, Length, Element ID Extension, HE MAC Capability Information, HE PHY Capability Information, Supported HE-MCS and NSS Set, and PPE Threshold (optional). Figure 7 shows an example format 700 of the HE MAC Capability Information field.

[0079] An HE STA operating in the 6 GHz band may declare its extended capabilities by transmitting an HE 6 GHz band capability element. Figure 8 shows an example format 800 of an HE 6 GHz band capability element. As shown in Figure 8, the HE 6 GHz band capability element may include an element ID field 802, a length field 804, an element ID extension field 806, and a capability information field 808. The element ID 802, length, and element ID extension field 806 are defined in the 802.11 IEEE standard.

[0080] 9 illustrates an example format 900 of the capability information field 808. As shown in FIG. 9, the capability information field 808 may include a minimum MPDU start interval subfield 902, a maximum A-MPDU length index subfield 904, a maximum MPDU length subfield 906, a reserved subfield 908, an SM power save subfield 910, an RD responder subfield 912, an Rx antenna pattern consistency subfield 914, a Tx antenna pattern consistency subfield 916, and a reserved subfield 918.

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

[0082] [Table 4]

[0083] An HT STA can indicate support for 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. The STA may set the RD Responder subfield to 1 in frames it transmits that include an HT Capabilities element in the 2.4 GHz or 5 GHz band, and may set the RD Responder subfield to 1 in frames it transmits that include an HE 6 GHz Band Capabilities element in the 6 GHz band if dot11RDResponderOptionImplemented is true. Otherwise, the STA may set the RD Responder subfield to 0. For non-HE HT STAs, the RDG / More PPDU subfield and AC Restrictions subfield may be present in the HTC field. For HE STAs, the RDG / More PPDU subfield and AC Restrictions subfield may be present in the CAS Control subfield.

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

[0085] An RD exchange sequence may include the transmission of one or more PPDUs (RD response bursts) by the STAs addressed in the MPDUs of the RDG PPDU. The first (or only) PPDU of an RD response burst contains at most one immediate BlockAck or Ack frame. The last (or only) PPDU of an RD response burst contains any MPDU that requires 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 RD responders apply only during a single RD exchange sequence, i.e., following the reception of an RDG PPDU, until the transmission of a PPDU by the RD responder with the RDG / More PPDU subfield equal to 0.

[0086] The RD exchange sequence may include the transmission of a PPDU by the RD initiator (RD initiator last PPDU) containing an immediate BlockAck frame or Ack frame. The transmission of the PPDU may be necessitated by the last PPDU of the RD response burst.

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

[0088] The recipient of an RDG may reject the RDG by (1) not sending frames following the RDG PPDU if a response is not required, and / or (2) sending a control response frame aggregated with other MPDUs with the RDG / More PPDU subfield set to 0.

[0089] The RD responder may ensure that its PPDU transmission and any expected responses fit entirely within the remaining TXOP or SP period, as indicated in the MPDU duration / ID field in the RDG PPDU. The RD responder may not transmit (individually or aggregated within an A-MPDU) any 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.

[0090] Any PPDU transmitted by the RD responder during an RD response burst may include at least one MPDU with an Address 1 field matching the RD initiator's MAC address or at least one trigger frame addressing the RD initiator; including traffic for 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 traffic to the RD initiator. The RD responder may not transmit frames that are not basic trigger frames and that result in a post-SIFS response with an Address 1 field that does not match the RD initiator's MAC address. The RD responder may not transmit PPDUs with a CH_BANDWIDTH wider than the CH_BANDWIDTH of the PPDU containing the frame that delivered the RD grant. An RD responder sending a basic trigger frame may set the CS Request subfield to 1 and may allocate a number of streams for the RD initiator that is not smaller than the number of streams in the RD initiator's last PPDU. If the RD initiator sets the RDG / More PPDU field to 1 in a +HTC frame sent 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 Information field in the trigger frame to the same AC as the last frame received from the RD initiator. If the RDG PPDU also requires an immediate BlockAck response, the BlockAck frame may be included in the first PPDU of the response.

[0091] Trigger frames were first introduced in IEEE 802.11ax. Trigger frames can be used to allocate resources and trigger single or multi-user access. FIG. 10 shows an example trigger frame format 1000. As shown in FIG. 10, the trigger frame can include a frame control field 1002, a duration field 1004, a TA field 1008, a common information field 1010, a user information field 1012, a blank field 1014, a user information field 1016, a padding field 1018, and an FCS field 1020.

[0092] 11 shows an example common information field format 1100. As shown in FIG. 11, the common information field may include a trigger type subfield 1102, a UL length subfield 1104, an additional TF subfield 1106, a CS request subfield 1108, a UL BW subfield 1110, a GI and HE-LTF mode subfield 1112, a MU-MIMO HE-LTF mode subfield 1114, a number of HE-LTF symbols and midamble periodicity subfield 1116, a UL STBC 1118, an LDPC extra symbol segment subfield 1120, an AP Tx power subfield 1122, a pre-FEC padding factor subfield 1124, a PE disambiguity subfield 1126, a UL spatial reuse subfield 1128, a Doppler subfield 1130, a UL HE-SIG-A2 reserved subfield 1132, a reserved subfield 1134, and a trigger-dependent common information subfield 1136.

[0093] 12 shows exemplary user information fields for all trigger types except the Null Feedback Report Poll (NFRP) trigger. As shown in FIG. 12, the user information fields may include an AID12 field 1202, an RU allocation field 1204, a UL FEC coding type field 1206, a UL HE-MCS field 1208, a UL DCM field 1210, an SS allocation / RA RU information field 1212, an UL target received power field 1214, a reserved field 1216, and a trigger-dependent user information field 1218.

[0094] Table 5 below provides possible values ​​for the Trigger Type subfield within the Common Information field.

[0095] [Table 5]

[0096] A "reverse transmission" is a transmission in which data is sent from a TXOP responder to a TXOP holder. In 802.11, a STA can acquire the wireless medium (WM) and become a TXOP holder. A TXOP holder can grant a reverse transmission by transmitting a PPDU containing one or more +HTC fields with the RDG / More PPDU subfield set to 1. The STA transmitting this PPDU can be referred to as the RD initiator (also the TXOP holder). The STA addressed in the PPDU is sometimes referred to as the TXOP responder or RD responder. Upon receiving the PPDU, the RD responder can respond with an acknowledgment and a reverse data transmission. In existing schemes, the RD initiator is the STA that can initiate the procedure. An RD responder may not be able to request an RD transmission.

[0097] In an embodiment, the extended RD procedure may include reusing the signaling defined in the +HTC field. The extended RD procedure may be generalized using any other mechanism or signaling. In general, the TXOP responder and / or any STA can request an extended reverse direction transmission by sending a frame with an RD request. The TXOP holder can grant RD by sending a frame with an RD grant. The TXOP responder can then initiate an RD data burst transmission or request additional resources for the RD burst. For P2P transmission, the procedure may be generalized using any other mechanism or signaling. In general, the TXOP responder and / or any STA can request an extended reverse direction / P2P transmission by sending a frame with an RD request and / or a P2P request. The TXOP holder can grant RD and / or P2P by sending a frame with an RD / P2P grant. The TXOP responder can then initiate an RD transmission and / or a P2P data burst transmission or request additional resources for the RD / P2P burst. The RD request, RD grant, P2P request, and / or P2P grant may be a field / subfield included in a frame, or an element / subelement included in a frame, or a control / action frame, or a management frame, or the like.

[0098] The primary use cases and applications of EHT include high-throughput and low-latency applications such as (1) video over WLAN, (2) augmented reality (AR), and (3) virtual reality (VR). The list of features discussed in EHT SG and 802.11be to achieve the goals of increased peak throughput and improved efficiency includes the following: multi-AP, multi-band / multi-link, 320 MHz bandwidth, and new designs for 6 GHz channel access.

[0099] The RD protocol in 802.11ax is initiated by the TXOP holder. However, in many scenarios (e.g., latency-sensitive traffic entering the recipient STA of the TXOP holder), the recipient STA may need to deliver the traffic as soon as possible due to low latency requirements. Given the strict latency requirements of this type of traffic, it may be desirable to design a protocol that allows the recipient STA of the TXOP holder to indicate latency-sensitive traffic to the TXOP holder (e.g., via extended CAS) and request data transmission from the recipient STA to the TXOP holder.

[0100] The RD protocol in the 802.11ax specification enables RD frame exchanges that allow data transmission from the recipient STA of a TXOP holder to the TXOP holder. As traffic volume and the number of devices increase, there is more traffic, especially latency-sensitive traffic, at peering STAs. Therefore, a simple yet effective protocol is needed to enable peer-to-peer (P2P) communication over extended CAS.

[0101] During an ongoing TXOP, some data transmission (e.g., low latency traffic) may come to the TXOP responder or TXOP holder. The recipient of this data may be a STA that is neither the TXOP responder nor the TXOP holder. To ensure that the recipient STA is not in a power-save mode and is available to receive data, especially in the case of low latency traffic delivery, it may be necessary to have a mechanism to make the potential recipient STA available during this situation.

[0102] In one embodiment, the extended CAS subfield may be included in a control information subfield within a CAS control subfield that includes the extended CAS control. Figure 13 shows an example control information field within the extended CAS control subfield. As shown in Figure 13, the control information field may include an AC constraint subfield 1302, a RDG / More PPDU subfield 1304, a PSRT PPDU subfield 1306, an extended CAS subfield 1308, and a reserved subfield 1310. The extended CAS control may allow a recipient STA of a TXOP holder to request the TXOP holder to allow reverse transmission due to the arrival of unexpected traffic (e.g., latency-sensitive traffic).

[0103] Table 6 below shows an example value interpretation of the Extended CAS and RDG / More PPDU fields. In Table 6, the RD requestor may be the recipient STA of the TXOP holder. If the RDG / More PPDU subfield is set to 0 and the Extended CAS subfield is set to 1 in the control information subfield transmitted by the RD requestor, it may indicate that the recipient TXOP holder or the RD requestor requests the TXOP holder to allow reverse transmission in the next round. One factor causing this request may be due to incoming latency-sensitive traffic, which may have strict latency requirements.

[0104] [Table 6]

[0105] The reverse request may be included in any other part of the MAC header, field, subfield, element, or may be sent in an individual MAC frame.

[0106] In one embodiment, the recipient STA of the TXOP holder may send an RD request to the TXOP holder, which may be included in the +HTC field sent along with a BlockAck (BA) frame upon receiving a data frame from the TXOP holder.

[0107] 14 provides an exemplary flowchart showing a TXOP responder sending a RD request using extended CAS and a TXOP holder accepting the RD request. The RD requester may carry the reverse direction request in any other part of the MAC header, field, subfield, element, or may be sent in an individual MAC frame.

[0108] As shown in Figure 14, at 1402, STA1 (TXOP holder) may transmit a PPDU containing an MPDU addressed to STA2. This PPDU may require an immediate BlockAck (BA) response from STA2.

[0109] At 1404, upon receiving the PPDU transmitted from STA1, STA2, which has low latency traffic in its buffer, may act as an RD requestor and respond to the PPDU with a transmission of a +HTC BlockAck frame with the Extended CAS subfield set to 1 and the RDG / More PPDU subfield set to 0. This setting may indicate that STA2 requests STA1 to allow a reverse direction transmission, which may be an urgent traffic transmission.

[0110] At 1406, upon receiving the +HTC BlockAck frame from STA2, STA1 regains control of the TXOP and agrees to allow reverse transmission to STA2, and may indicate RDG by setting the RDG / More PPDU subfield to 1 in the CAS Control subfield using a +HTC data frame with legacy CAS.

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

[0112] At 1410, upon receiving an extended CAS indicating an RD request from STA2, STA1 (acting as the RD initiator) may regain control of the TXOP and may transmit a +HTC BlockAck frame addressed to STA2 to acknowledge the MPDU sent by STA2 in the RD response and RD request burst. This +HTC blockAck includes a legacy CAS control subfield with the RDG / More PPDU subfield set to 1, indicating that STA1 agrees to grant RD to STA2 according to its request. At 1412, STA2 (RD requestor and RD responder) may transmit a PPDU to STA1 containing QoS data +HTC MPDU with an implicit BAR ack policy and the RDG / More PPDU subfield set to 0, representing the only PPDU in the RD response burst. At 1414, STA1 may transmit a BlockAck (BA) frame to STA2 acknowledging the MPDU sent by STA2 in the RD response burst.

[0113] Figure 15 provides an example of an extended frame exchange showing an RD request sent from a TXOP holder, a recipient of a TXOP responder. As shown in Figure 15, at 1510, STA1 1502 (the TXOP holder) may transmit a PPDU containing an MPDU addressed to STA2 1504. This PPDU may require an immediate BlockAck (BA) response from STA2 1504.

[0114] At 1512, upon receiving the PPDU transmitted from STA1 1502, STA2 1504, which has low latency traffic in its buffer, may act as an RD requestor and respond to the PPDU with a transmission of a +HTC BlockAck frame with the Extended CAS subfield set to 1 and the RDG / More PPDU subfield set to 0. This setting may indicate that STA2 1504 requests STA1 1502 to allow a reverse direction transmission, which may be an urgent traffic transmission.

[0115] At 1514, upon receiving the +HTC BlockAck frame from STA2 1504, STA1 1502 regains control of the TXOP and agrees to allow reverse transmission to STA2 1504, and may indicate RDG by setting the RDG / More PPDU subfield in the CAS Control subfield to 1 using a +HTC data frame with legacy CAS.

[0116] At 1516, upon receiving the RDG, STA2 1504, acting as the RD requestor and RD responder, may respond with a transmission of a +HTC BlockAck frame with the Extended CAS subfield set to 0 (i.e., legacy CAS) and the RDG / More PPDU subfield set to 1, indicating that another PPDU will follow SIFS or RIFS after the end of the PPDU containing the BlockAck frame. STA2 1504 then transmits a +HTC PPDU (the second PPDU of the RD response burst) with the Extended CAS subfield set to 1 and RDG / More PPDU=0. This setting may indicate to STA1 1502 that there are no more PPDUs in this response burst and that there is a request for RDG from STA2 1504.

[0117] At 1518, upon receiving the extended CAS subfield indicating an RD request from STA2 1504, STA1 1502 (acting as the RD initiator) may regain control of the TXOP and may transmit a +HTC BlockAck frame addressed to STA2 to acknowledge the MPDU sent by STA2 1504 in the RD response and RD request burst. This +HTC blockAck includes a legacy CAS control subfield with the RDG / More PPDU subfield set to 1, indicating that STA1 agrees to grant RD to STA2 1504 according to its request. At 1520, STA2 1504 (RD requestor and RD responder) may transmit a PPDU to STA1 1502 containing the QoS data +HTC MPDU with the implicit BAR ack policy and the RDG / More PPDU subfield set to 0, representing the only PPDU in the RD response burst. At 1522, STA1 1502 may send a BlockAck (BA) frame to STA2 1504 acknowledging the MPDU sent by STA2 1504 in the RD response burst.

[0118] The RD requestor may also indicate traffic-related parameters (e.g., traffic type, traffic size, etc.) using reserved bits shown in FIG.

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

[0120] In one embodiment, the RD Requestor field may be included in either the Capability Information field of the HE 6GHz Band Capability element, or the EHT MAC Capability Information field, or any other Capability Information field. Table 7 below provides exemplary RD Requestor fields that may be present in the HE 6GHz Band Capability element, or the EHT MAC Capability Information field, or any other Capability Information field.

[0121] [Table 7]

[0122] In one embodiment, the extended CAS control subfield may contain link information for multi-link device (MLD) STAs.

[0123] Figure 16 shows an example of a control information field in an MLD extended CAS control subfield format 1600. As shown in Figure 16, the control information field within the MLD extended CAS control subfield may include an AC constraint subfield 1602, a RDG / More PPDU subfield 1604, a PSRT PPDU subfield 1606, an extended CAS subfield 1608, and a link ID subfield 1610. The link ID field may be included in the extended CAS control subfield. Table 7 below provides example value interpretations for the RDG / More PPDU, extended CAS, and link ID subfields.

[0124] [Table 8]

[0125] 16 and Table 7 show that in a situation where the transmitting STA is an RD requester, if the extended CAS subfield is set to 1, the RDG / More PPDU field is set to 0, and the Link ID field is set to a value between 0 and 15, the transmitting STA may request RDG for its next transmission on the link indicated in the Link ID field. If the transmitting STA is an RD initiator that authorizes the recipient STA of the TXOP holder (i.e., the RD initiator) to transmit backward, when the extended CAS subfield is set to 1 and the RDG / More PPDU value is set to 1, the authorized backward transmission may be on 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 transmitted by the RD initiator, the TXOP holder that is the RD initiator may not authorize the RD requester to transmit backward on any link.

[0126] In one embodiment, a STA may use the PHY header to indicate low-latency traffic that needs to be delivered from the buffer and request a reverse direction grant. For example, the ignore bit in the U-SIG field of the EHT MU PPDU or EHT TB PPDU may be used for an urgent traffic indication indicating the traffic type, traffic size, or reverse direction allocation time. This indication is sent to the recipient of the RD requester (e.g., the TXOP holder requesting the reverse direction grant). Reverse direction transmissions may include from the RD requester to the TXOP holder or from the RD requester to another STA that may not be the TXOP holder. The low-latency traffic indication or reverse direction transmission request may need to be included in the TXVECTOR and RXVECTOR parameters.

[0127] In another embodiment, the extended CAS subfield can be used to request a reverse transmission for P2P traffic. This P2P traffic can refer to traffic delivered from the TXOP responder to another STA that is not the TXOP holder. The TXOP responder indicates the traffic type (e.g., low latency traffic) to the TXOP holder and requests permission to transmit (i.e., requests the TXOP holder to allocate some time for this traffic delivery).

[0128] FIG. 17 illustrates the exemplary P2P scenario described above. As shown in FIG. 17, 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 a TXOP where T1 1702 (i.e., STAT1) is the TXOP holder and R2 1706 (i.e., STA2) is the TXOP responder. Numerical notations represent different STAs. For example, T1 1702 may define STA1 as the transmitter delivering traffic to STA2, and R2 1706 may define STA2 as the receiver. T2 1706 may define STA2 as the transmitter delivering traffic to STA3, and R3 1708 may define STA3 as the receiver.

[0129] The above proposed embodiment may be applicable to a TXOP holder (e.g., T1 1702) that is an AP and a TXOP responder (e.g., R2 1706) that 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).

[0130] The above proposed embodiment may be applicable when 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).

[0131] In one embodiment, the Extended CAS subfield may contain reverse transmissions for P2P traffic. This Extended CAS control subfield may contain three new subfields: Extended CAS, P2PTx, and Duration.

[0132] 18 illustrates an example control information field format 1800 within an extended CAS control subfield. As shown in FIG. 18, the control information field format may include an AC constraint subfield 1802, an RDG / More PPDU subfield 1804, a PSRT PPDU subfield 1806, an extended CAS subfield 1808, a PSPTx subfield 1810, and an allocation duration subfield 1812.

[0133] Table 8 below shows the interpretation of the corresponding values ​​of the control information fields.

[0134] [Table 9]

[0135] In a situation where the transmitting STA is an RD requestor requesting permission for a reverse direction transmission from the TXOP holder (i.e., the RD initiator), if the Extended 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 STA may request RDG for a P2P transmission, for example, due to latency-sensitive traffic in its buffer, or after being granted RDG for a P2P transmission (RDG for a P2P transmission is not yet granted), and this STA has no more PPDUs in this response burst, but there is another P2P transmission in the next response burst (e.g., a P2P transmission for one peering STA has finished, but there is another P2P transmission for another peering STA within the time allocated for the P2P transmission). When the Extended 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 a PPDU carrying a frame sent by the RD requestor is followed by another PPDU sent to the same peering STA.

[0136] In one embodiment, the Extended CAS subfield may indicate whether the transmission is an Extended RD Request / Response. If the Extended CAS subfield is set to 0, the receiving STA may treat it as a legacy CAS field and P2P communication is not considered. The RDG / More PPDU subfield may indicate whether the RD initiator / TXOP holder grants the RD responder a transmission opportunity. If this field is set to 0, the RD responder is not granted a transmission opportunity. The P2PTx subfield may further indicate whether P2P transmissions are allowed in the granted transmission opportunity. If P2P transmissions are allowed, reverse transmissions are always allowed. Three subfields may be used to indicate whether only P2P transmissions may be allowed for the granted transmission opportunity (but not the reverse direction). In a situation where the transmitting STA is the RD initiator (e.g., the TXOP holder), if the Extended CAS subfield is set to 1, the P2PTx subfield is set to 1, and the RDG / More PPDU Value subfield is set to 0, P2P transmission and / or reverse direction transmission requested by the RD requestor may not be allowed (i.e., P2P transmission is rejected and reverse direction is rejected). If the Extended CAS subfield is set to 1, the P2PTx subfield is set to 1, and the RDG / More PPDU Value subfield is set to 1, P2P transmission may be allowed for the RD requestor, but reverse direction transmission may not be allowed for the RD requestor. If the RDG / More PPDU subfield is set to 1, the Extended CAS subfield is set to 0, and the P2PTx subfield is set to 0, this may indicate that only reverse direction transmission is allowed, and that P2P transmission between the TXOP responder and other STAs is not allowed. If the RDG / More PPDU subfield is set to 1, the Extended CAS subfield is set to 1, and the P2PTx subfield is set to 0, it may indicate that backward transmission is allowed (i.e., RDG is present, allowing backward transmission from the TXOP responder to the TXOP holder, and P2P transmission between the TXOP responder and other STAs).

[0137] The above value settings are exemplary interpretations of the actions that the TXOP responder and TXOP holder can take. Other combinations of value settings can be interpreted as the same actions that the TXOP responder and TXOP holder can take as described above.

[0138] The Extended CAS subfield and / or the P2P Tx subfield may be defined in the A-Control field in the above example. However, the Extended CAS subfield and / or the P2P Tx subfield may be defined and carried in other fields / subfields or frames to indicate a request or permission for reverse transmission or P2P transmission (e.g., a request or permission for low latency traffic delivery).

[0139] When the extended CAS control is sent by the RD requester, the Allocation Duration subfield of the Extended CAS Control subfield represents the time requested for the P2P transmission, and when the extended CAS control is sent by the RD initiator, the Allocation Duration subfield of the Extended CAS Control subfield represents the time allocated to the P2P transmission by the RD initiator. Note that if the RD initiator rejects the P2P RDG, i.e., the RDG / More PPDU is set to 0, the Extended CAS subfield is set to 1, and the P2PTx subfield is set to 1, the RD requester may ignore the value indicated in the Allocation Duration subfield sent by the RD initiator, or the value of the Allocation Duration may be all zeros. Alternatively, if the RD initiator (TXOP holder or AP) accepts the RD request by setting the Extended CAS subfield to 1, the RDG / More PPDU subfield to 1, and the P2P Tx subfield to 1, and decides to use the MU-RTS TXS trigger frame to trigger the TXOP sharing procedure for P2P transmission between the RD requester and other STAs, the RD initiator may set the Allocation Duration subfield to 0 to indicate that an MU-RTS TXS trigger frame will follow after receiving an acknowledgment from the RD requester.

[0140] There can be many quantization methods to convert the actual allocation duration of P2P Tx into the bit value indicated in the Allocation Duration subfield. In one option, the maximum and minimum allocation durations are defined as 111 and 001, respectively. The system can define the maximum and minimum allocation durations. Then, each value in the Allocation Duration subfield is

[0141]

number

[0142]

number

[0143]

number

[0144] The TXOP holder or RD initiator can use the extended CAS control subfield or any other field / element of the MAC frame or individual MAC frame to grant the TXOP responder reverse direction for P2P transmission, with or without a request from the TXOP responder. P2P transmission can refer to transmission between the RD requester (or TXOP responder) and other STAs that are not the TXOP holder.

[0145] In one embodiment, the STA that is the recipient of the TXOP holder may send a reverse request for P2P transmission to the TXOP holder. The allocated time for the P2P transmission may also be included in the request.

[0146] Figure 19 shows an example flowchart of an RD request for P2P transmission accepted by a TXOP holder. The protocol shown in Figure 19 may be applied when the TXOP holder or RD initiator is a non-AP STA rather than an AP. The TXOP holder can grant the TXOP responder a reverse direction for transmission between the TXOP responder (or RD requester) and other STAs that do not include the TXOP holder. The signaling used for the reverse direction request may not be limited to the extended CAS control subfield. It may be any other field / element of the MAC frame or an individual MAC frame.

[0147] Figure 20 shows an example RD frame exchange using extended CAS with P2P traffic indication (the format follows the example shown in Figure 18). The example procedure shown in Figure 20 illustrates the case where the TXOP holder accepts the P2P RD request (i.e., an RDG for P2P exists).

[0148] At 2010, STA1 2002, which is a TXOP holder (eg, an AP), may transmit a data frame to STA2 2004.

[0149] At 2012, STA2 2004 may have urgent traffic (e.g., latency-sensitive traffic) for another peering STA (or other AP) in its buffer and wishes to request a reverse direction grant from STA1 2002. After receiving the data from STA1 2002, STA2 2004 may transmit a +HTC Block frame with the Extended CAS subfield set to 1, the RDG / More PPDU subfield set to 0, the P2PTx subfield set to 1, and the Allocation Duration subfield set to a valid value (e.g., 1 to 7), which may give the TXOP holder an estimate as to the amount of P2P traffic to be delivered.

[0150] At 2014, STA1 2002 may transmit a +HTC data frame to indicate that it has regained control of the TXOP and will accept the RDG request for P2P Tx from STA2 2004. STA1 2002 becomes the RD initiator. In the +HTC data frame, STA1 2002 may use the Extended CAS Control subfield and set the Extended CAS and RDG subfields to 1. STA1 2002 may also set a valid value (e.g., 1 to 7) in the Allocation Duration subfield. The RD initiator may not need to set the exact same value indicated in the Allocation Duration subfield sent by STA2 2004. STA1 2002 may allocate the same, less, or more time than indicated in the Allocation Duration subfield sent by STA2 2004. The allocated time for P2P transmission may need to last for the duration remaining in the TXOP. In the example of Figure 20, the allocated time period for P2PTx is the same as the remaining period (i.e., allocation period) of the TXOP for P2P Tx = floor (TXOP period - 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).

[0151] At 2016, upon receiving the +HTC data frame with the extended CAS subfield from STA1 2002, STA2 2004 may respond with a transmission of a +HTC BlockAck frame with the RDG / More PPDU subfield set to 1 and the P2P Tx subfield set to 1, indicating that the P2P PPDU follows a SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0152] At 2018, STA2 2004 may have an implicit BAR ack policy for its QoS data frame and may transmit a P2P PPDU (the second PPDU of the RD response burst) to STA3 2006 that includes legacy CAS with the RDG / More PPDU subfield set to 0, indicating that this is the last PPDU in the response burst.

[0153] At 2020, upon receiving the data from STA2 2004, STA3 2006 may send a BlockAck frame to STA2 2004 acknowledging the MPDU sent by STA2 2004 in the RD response burst.

[0154] 20, STA2 2004 may use all of the allocated time allocated by the RD initiator, STA1 2002. Alternatively, STA2 may end the P2P transmission earlier than the allocated time. In this case, STA2 2004 may return control of the TXOP to the original TXOP holder, STA1 2002.

[0155] FIG. 21 shows an example procedure for an RD frame exchange using an extended CAS subfield with a P2P traffic indication, where the TXOP accepts a P2P RD request and the time used for P2P transmission is the same as the time assigned by the RD initiator.

[0156] At 2110, STA1 2102, which is a TXOP holder (eg, an AP), may transmit a data frame to STA2 2104.

[0157] At 2112, STA2 2104 may have urgent traffic (e.g., latency-sensitive traffic) for another peering STA (or other AP) in its buffer and wishes to request a reverse direction grant from STA1 2102. After receiving the data from STA1 2102, STA2 2104 may transmit a +HTC Block frame with the Extended CAS subfield set to 1, the RDG / More PPDU subfield set to 0, the P2PTx subfield set to 1, and the Allocation Duration subfield set to a valid value (e.g., 1 to 7), which may give the TXOP holder an estimate as to the amount of P2P traffic to be delivered.

[0158] At 2114, STA1 (the RD initiator) may accept the RDG request for a P2P transmission from STA2 and allocate a specific time for the requested P2P transmission, which is indicated in the Allocation Duration subfield of the Extended CAS subfield that carried the +HTC data frame sent from STA1 2102 to STA2 2104. This data frame may require an immediate BlockACK response.

[0159] At 2116, STA2 2104 (RD Requestor / Requestor) may respond with a transmission of a +HTC BlockAck frame with the RDG / More PPDU subfield set to 1 and the P2P Tx subfield set to 1, indicating that the P2P PPDU follows SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0160] At 2118, STA2 2004 can transmit a +HTC data frame to STA3 2106, which can include a legacy CAS with the RDG / More PPDU subfield set to 1, indicating the last PPDU in this response burst.

[0161] At 2120, upon receiving the data from STA2 2104, STA3 2106 may transmit a BlockAck frame to STA2 2104 acknowledging the MPDU sent by STA2 2104 in the RD response burst.

[0162] At 2122, STA2 2104 may end its P2P transmission earlier than the time allotted for the P2P transmission and return a TXOP to STA1 2102.

[0163] At 2124, STA1 2102 can decode the legacy CAS control subfield with the RDG / More PPDU subfield set to 0, regain control of the TXOP, and transmit a data frame to STA2 2104. STA2 2104 may respond with a BlockAck frame. Alternatively, STA1 2102 can begin regaining control of the TXOP within the allocated period for P2P transmission and within a TxPIFS boundary because the CS mechanism indicates the medium is idle after receiving the BA frame transmitted from STA2.

[0164] Alternatively, after STA2 2104, the RD requester for the P2P transmission, ends its P2P transmission earlier than the allocated time period indicated in the Allocation Duration subfield included in the extended CAS sent by STA1 2102, STA2 2104 can transmit a +HTC QoS Null frame to STA1 using the legacy CAS control subfield with the RDG / More PPDU subfield set to 0. This indicates to STA1 that there are no more PPDUs in the RD response burst. STA1 regains control of the TXOP and transmits a data frame to STA2, which transmits the BlockAck frame requested by STA1. Alternatively, STA2, the RD initiator / TXOP holder, can also transmit a CF-end frame to STA1 to indicate that there are no more PPDUs in the RD response burst after its P2P transmission ends earlier than the allocated time period assigned to the P2P transmission by STA1.

[0165] Figure 22 shows an example of an RD frame exchange using extended CAS with P2P traffic indication. As shown in Figure 22, in the TXOP holder, STA1 2202 accepts a P2P RD request from STA2. STA2 2204 ends its P2P transmission earlier than the time allotted by STA1 2202 and indicates there will be no more PPDUs in the RD response burst by setting the RDG / More PPDU subfield to 1 in the legacy CAS control subfield using a +HTC QoS Null frame.

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

[0167] At 2212, STA2 2204 may have urgent traffic (e.g., latency-sensitive traffic) for another peering STA (or other AP) in its buffer and wishes to request a reverse direction grant from STA1 2202. After receiving the data from STA1 2202, STA2 2204 may transmit a +HTC Block frame with the Extended CAS subfield set to 1, the RDG / More PPDU subfield set to 0, the P2PTx subfield set to 1, and the Allocation Duration subfield set to a valid value (e.g., 1 to 7), which may give the TXOP holder an estimate as to the amount of P2P traffic to be delivered.

[0168] At 2214, STA1 (the RD initiator) may accept the RDG request for a P2P transmission from STA2 and allocate a specific time for the requested P2P transmission, which is indicated in the Allocation Duration subfield of the Extended CAS subfield that carried the +HTC data frame sent from STA1 2202 to STA2 2204. This data frame may require an immediate BlockACK response.

[0169] At 2216, STA2 2104 (RD Requestor / Requestor) may respond with a transmission of a +HTC BlockAck frame with the RDG / More PPDU subfield set to 1 and the P2P Tx subfield set to 1, indicating that the P2P PPDU follows SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0170] At 2218, STA2 2204 can transmit a +HTC data frame to STA3 2206, which can include a legacy CAS with the RDG / More PPDU subfield set to 1, indicating the last PPDU in this response burst.

[0171] At 2220, upon receiving the data from STA2 2204, STA3 2206 may send a BlockAck frame to STA2 2204 acknowledging the MPDU sent by STA2 2204 in the RD response burst.

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

[0173] In one embodiment, the TXOP holder (e.g., STA1) can also reject a P2P transmission request from STA2 by using an Extended CAS Control subfield with the Extended CAS subfield set to 1, the P2P Tx subfield set to 1, and the RDG / More PPDU subfield set to 0.

[0174] 23 shows an example P2P RD frame exchange procedure in which STA1 2302, the TXOP holder, rejects a request for reverse transmission for P2P traffic sent from STA1 2302. In this example, after indicating rejection of the P2P RDG request at 2310, STA1 2302 may send a data transmission to STA2 2304 at 2312. The data transmission may be acknowledged by STA2 at 2314.

[0175] In one embodiment, after an RD requestor receives an RDG for P2P transmission from a TXOP holder / RD initiator (eg, an AP), the RD requestor can perform P2P transmission to a different peering STA.

[0176] 24 shows an example RD frame exchange using extended CAS with P2P transmission indication. In this example, the TXOP holder accepts a P2P reverse request, and the RD requestor (i.e., STA1) transmits 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.

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

[0178] At 2412, STA2 2404 may have urgent traffic (e.g., latency-sensitive traffic) for another peering STA (or other AP) in its buffer and wishes to request a reverse direction grant from STA1 2102. After receiving the data from STA1 2402, STA2 2404 may transmit a +HTC Block frame with the Extended CAS subfield set to 1, the RDG / More PPDU subfield set to 0, the P2PTx subfield set to 1, and the Allocation Duration subfield set to a valid value (e.g., 1 to 7), which may give the TXOP holder an estimate as to the amount of P2P traffic to be delivered.

[0179] At 2414, STA1 2402 may accept the RDG request for a P2P transmission from STA2 2404 and allocate a specific time for the requested P2P transmission, which is indicated in the Allocation Duration subfield of the Extended CAS subfield that carried the +HTC data frame sent from STA1 to STA2. This data frame requests an immediate BlockACK response.

[0180] At 2416, STA2 2404 (RD Requestor / Requestor) may respond with transmission of a +HTC BlockAck frame with the RDG / More PPDU subfield set to 1 and the P2P Tx subfield set to 1, indicating that the P2P PPDU follows SIFS or RIFS after the end of the PPDU containing the BlockAck frame. The P2P PPDU sent to STA2 carries an Extended CAS with the Extended CAS subfield set to 1, the RDG / More PPDU subfield set to 0, and the P2P Tx subfield set to 1. This setting may indicate that there will be another P2P transmission after the acknowledgment sent by STA3 to STA2 in the response burst.

[0181] At 2414, STA3 2406 (the peering STA in the reverse response burst) may respond with a BlockAck frame. Then, SIFS or RIFS after receiving the BA from STA3 2406, STA2 2404 may send another data frame to STA4 2408 including legacy CAS with the RDG / More PPDU subfield set to 0, which may indicate that this is the last PPDU in this response burst.

[0182] In one embodiment, after receiving a P2P RD request from a TXOP responder (the recipient of the TXOP holder), the AP that is the TXOP holder and RD initiator can send an MU-RTS TXS trigger frame to start a triggered TXOP sharing procedure, which allows P2P transmission between the RD requester and another STA within the allocated time indicated in the MU-RTS TXS trigger frame.

[0183] FIG. 25 shows an exemplary procedure for RD frame exchange using extended CAS with P2P traffic indication, in which the TXOP holder can accept the P2P RD request and initiate the triggered TXOP sharing procedure.

[0184] At 2512, STA2 2542, the TXOP responder, may receive a data frame from AP 2502, the TXOP holder, and may send back a +HTC BlockAck frame including an Extended CAS Control subfield to request an RD transmission to the peering STA by setting the Extended CAS subfield to 1, the RDG / More PPDU subfield to 0, the P2P Tx subfield to 1, and the Allocation Period to a valid value (between 0 and 7).

[0185] At 2514, upon receiving the BlockAck frame from STA2 2504, the AP 2502 may transmit a +HTC data frame to STA2 2204 including an Extended CAS Control subfield indicating RDG to STA2 and accepting the P2P transmission request from STA2 2504 (i.e., setting the Extended CAS subfield to 1, the RDG / More PPDU subfield to 1, and the P2P Tx subfield to 1). The acknowledgement policy for the data frame may be implicit BAR.

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

[0187] At 2518, AP 2502 regains control of the TXOP and can send an MU-RTS TXS trigger frame to initiate triggered TXOP sharing, thereby allowing STA2 2504, the RD requestor, to transmit to another STA (e.g., STA3 2506) within the time allocated in the MU-RTX TXS trigger frame.

[0188] In one embodiment, the extended CAS control subfield may use one bit to indicate RDG, More PPDU, or P2P Tx. Figure 26 shows an example format of a control information subfield within the extended CAS control subfield indicating a P2P transmission request. As shown in Figure 26, the control information subfield may include an AC constraint subfield 2602, an RDG / More PPDU / P2PTx subfield 2604, a PSRT PPDU subfield 2606, an extended CAS subfield 2608, and a duration subfield 2610. Table 9 below provides the corresponding value interpretations of the various subfields.

[0189] The duration subfield 2610 may indicate the requested allocation duration in quantized form if the requested allocation duration is sent by the RD requestor and indicates the allocated allocation duration for P2P transmission in quantized form sent by the RD initiator. If the RD initiator grants the reverse direction to the TXOP responder for P2P transmission (with or without a request from the TXOP responder), the RD initiator can set the extended CAS subfield 2608 to 1 and the RDG / More PPDU / P2P Tx subfield 2604 to 1. The corresponding duration subfield 2610 can be set to a value between 1 and 15 to indicate the quantized allocation duration for P2P transmission, or can be set to 0 to indicate that the MU-RTS TXS trigger TXOP sharing may be used to initiate a P2P transmission from the TXOP responder (or RD requestor) to another STA. The MU-RTS TXS trigger frame may be sent after receiving an acknowledgment from the TXOP responder / RD responder.

[0190] In a situation where the STA sending a +HTC with an Extended CAS Control subfield is the RD Requestor, if the RDG / More PPDU Value / P2P Tx subfield is set to 1 and the Extended CAS subfield is set to 1, the RD Requestor (TXOP Responder) may request RDG for a P2P transmission before the reverse direction is granted by the TXOP holder, and after RDG is granted by the RD Initiator, this indicates that there are no more PPDUs for the same transmission, but that there will be another P2P transmission after this transmission (i.e., after receiving an ACK from the recipient of the current PPD, if the RDG / More PPDU Value / P2P Tx subfield is set to 1 and the Extended CAS subfield is set to 1). If the RDG / More PPDU Value / P2P Tx subfield is set to 0 and the Extended CAS subfield is set to 1, this can indicate that the RD requestor (TXOP responder) requests an RDG for a reverse transmission, e.g., a transmission from the RD responder (TXOP responder) to the RD initiator (TXOP holder).

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

[0192] [Table 10]

[0193] In one embodiment, an 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 management frames (e.g., beacon frames, FILS discovery frames, probe response frames, etc.). This group of STAs may refer to potential recipient STAs that may receive LL traffic or any special traffic (e.g., broadcast traffic) in a TXOP that may not be initially assigned to these STAs. This may mean that in a TXOP, if these STAs are neither the TXOP holder nor the TXOP responder, they may be potential recipients of LL traffic from the TXOP holder or TXOP responder if there is LL traffic that arrives at the TXOP holder or TXOP responder in the course of the TXOP.

[0194] In one embodiment, one bit (e.g., any bit in B22, B53, or B56-B63) may be carried in the EHT variant common information field of the MU-RTS trigger frame to indicate that this TXOP allows non-TXOP participants to receive or transmit low-latency traffic. This bit may be named the Third Party Receive / Transmit subfield. For example, if the trigger frame is MU-RTS (i.e., the Trigger Type subfield is set to 3 in the EHT variant common information field of the trigger frame) and the Trigger TXOP Sharing Mode subfield is set to 3, a Third Party Receive / Transmit subfield set to 1 may indicate that STAs belonging to the LL group of STAs indicated in the management frame may not be in power save mode or doze mode and may need to wake up to decode any potential packages (e.g., LL data) intended for them, and may also mean that the TXOP holder allows STAs belonging to the LL group ID indicated in the management frame to transmit low-latency data to the TXOP holder or TXOP receiver.

[0195] Alternatively, the LL group ID can be carried in the trigger frame, for example, in the EHT variant common information field (B22, B53, or any bit among B56-B63) of the MU-RTS trigger frame. If the LL group ID is carried in the trigger frame, it may mean that the STAs belonging to the LL group ID may be potential receivers of low-latency traffic that is not initially scheduled in this TXOP. Traffic may come from the TXOP holder or TXOP receiver in the middle of the TXOP. Furthermore, if the LL group ID is carried in the trigger frame, it may mean that this TXOP enables these STAs belonging to this group ID to send low-latency traffic.

[0196] Furthermore, an indication allowing low-latency traffic interruption midway through a TXOP and / or an indication of the type of LL traffic that can interrupt an ongoing TXOP may be carried in a TXOP initiation frame (e.g., an MU-RTS trigger frame, an RTS frame, an extended MU-RTS trigger frame, etc.). These indications may also be carried in the preamble of an EHT PPDU (e.g., a U-SIG). LL traffic interruption may refer to a scenario in which a TXOP is initially allocated to several STAs for a particular type of traffic. In the middle of a TXOP, higher priority traffic arrives at one STA, which may be the TXOP holder, the TXOP responder, or neither the TXOP holder nor the TXOP responder. Examples of TXOP interruption may include reverse operation, extended reverse operation, etc. If the indication allows interruption from LL traffic and the incoming traffic belongs to an allowed traffic type, the TXOP holder may allow transmission to this STA and / or schedule this LL traffic delivery.

[0197] Although the above-described features and elements are described in preferred embodiments in particular combinations, each feature or element can be used alone without other features and elements of the preferred embodiments, or in various combinations with other features and elements of the invention, or without other features and elements of the invention. While the solutions described herein consider the specific protocol of 802.11, it will be understood that the solutions described herein are not limited to this scenario and are applicable to other wireless systems.

[0198] 27 is a flowchart providing an example procedure for an extended reverse link. At 2702, a first STA may receive a PPDU from a second STA. At 2704, the first STA may transmit a first frame including an extended CAS subfield to the second STA, where the extended CAS subfield is set to request a reverse link transmission. At 2706, the first STA may receive a second frame from the second STA indicating acceptance of the reverse link transmission. At 2708, the first STA may transmit a third frame to the second STA, where the third frame includes a reverse link data transmission.

[0199] Although features and elements are described above in particular combinations, those skilled in the art will understand 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 embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, 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

1. 1. A method, performed by a first station (STA), comprising: receiving a physical layer protocol data unit (PPDU) from a second STA; transmitting a first frame including an extended Command and Status (CAS) subfield to the second STA, the extended CAS subfield being set to request a reverse transmission; receiving a second frame from the second STA indicating acceptance of the reverse transmission; transmitting a third frame to the second STA, the third frame comprising a reverse data transmission.

2. 2. The method of claim 1, wherein the second frame includes a legacy CAS field that includes a reverse direction grant (RDG) / More PPDU subfield, the RDG / More PPDU subfield being 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. 2. The method of claim 1, wherein the extended CAS subfield is set to 1.

8. The method of claim 1 , wherein the first frame further includes an 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), A transceiver; a processor, The transceiver and the processor receiving a physical layer protocol data unit (PPDU) from a second STA; transmitting a first frame including an extended Command and Status (CAS) subfield to the second STA, the extended CAS subfield being set to request a reverse transmission; receiving a second frame from the second STA indicating acceptance of the reverse transmission; and transmitting a third frame to the second STA, the third frame comprising a reverse data transmission.

11. 11. The first STA of claim 10, wherein the second frame includes a legacy CAS field that includes a reverse direction grant (RDG) / More PPDU subfield, the RDG / More PPDU subfield being 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 +HTC (High Throughput Control) 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 extended CAS subfield is set to 1.

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

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

Images