Enhanced reverse 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 including an enhanced CAS subfield to a second STA, wherein the enhanced CAS subfield is set to request reverse transmission; receiving, from a second STA, a second frame indicating acceptance of reverse transmission; and transmitting a third frame to the second STA, the third frame comprising a reverse data transmission.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] 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

[0003] 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 including an enhanced command and status (CAS) subfield to the second STA, wherein the enhanced CAS subfield is set to request reverse transmission; receiving a second frame indicating acceptance of reverse transmission from the second STA; and transmitting a third frame to the second STA, wherein the third frame includes reverse data transmission.

[0004] The second frame may include a legacy CAS field, including an RDG / More PPDU subfield, wherein the RDG / More PPDU subfield is set to accept reverse transmissions. The RDG / More PPDU subfield may be set to 1. The first frame may be a +HTCBlockAck frame. The second frame may be a +HTC frame. The third frame may be a +HTC PPDU frame. The enhanced CAS subfield may be set to 1. The first frame may further include an RDG / More PPDU subfield. The first STA may be a non-access point (AP) STA. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0007] Figure 1B is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communications system is shown in FIG.

[0008] Figure 1C is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system illustrated in FIG.

[0009] Figure 1Dis a diagram illustrating that according to an embodiment, Figure 1A A system diagram of a further example RAN and a further example CN for use within the communication system illustrated in FIG.

[0010] Figure 2 is an example of a MAC frame format;

[0011] Figure 3 is an example of a High Throughput (HT) control field format;

[0012] Figure 4 is an example of a control subfield of the High Efficiency (HE) variant HT control field format;

[0013] Figure 5 is an example of controlling the format of subfields;

[0014] Figure 6 is an example of the format of the control information subfield in the command and status (CAS) control subfield;

[0015] Figure 7 is an example of the HE MAC capability information field format;

[0016] Figure 8 This is an example of the HE 6 GHz Band Capability Element format;

[0017] Figure 9 is an example of the capability information field format;

[0018] Figure 10 This is an example of the trigger frame format in 802.11ax;

[0019] Figure 11 is an example of a common information field in a trigger frame;

[0020] Figure 12 is an example of a user information field in a trigger frame;

[0021] Figure 13 is an example of the control information subfield format in the enhanced CAS control subfield;

[0022] Figure 14 is an example process instructing a transmission opportunity (TXOP) responder to transmit a reverse direction (RD) request and the TXOP holder to accept the RD request;

[0023] Figure 15 is an example of RD frame exchange using enhanced CAS;

[0024] Figure 16 is an example of a control information subfield in a multi-link device (MLD) enhanced CAS control subfield;

[0025] Figure 17 This is an example of a P2P business scenario;

[0026] Figure 18 is an example of the control information subfield format in the enhanced CAS control subfield indicating a P2P transfer request;

[0027] Figure 19 is an example process of a RD request for peer-to-peer (P2P) transmission accepted by a TXOP holder;

[0028] Figure 20 is an example procedure for RD frame exchange using enhanced CAS with P2P traffic indication, where the TXOP accepts P2P RD requests and the time used for P2P transmission is the same as the time allocated by the RD initiator;

[0029] Figure 21 is an example procedure for RD frame exchange using enhanced CAS with P2P traffic indication, where the TXOP accepts P2P RD requests and the time for P2P transmission is shorter than the time allocated by the RD initiator;

[0030] Figure 22 is an example procedure for RD frame exchange using enhanced CAS with P2P traffic indication, wherein the TXOP holder accepts a P2P RD request with a time for P2P transmission that is shorter than the time allocated by the RD initiator, and the RD requester transmits a QoS null frame including conventional CAS with RDG / More PPDU set to 0;

[0031] Figure 23 is an example procedure for RD frame exchange using enhanced CAS with P2P traffic indication, where the TXOP rejects the P2P RD request;

[0032] Figure 24 is an example of an RD frame exchange using enhanced CAS with P2P traffic indication, where a TXOP holder accepts a P2P RD request and the RD requester sends data to multiple peer STAs;

[0033] Figure 25 is an example of an RD frame exchange using enhanced CAS with P2P traffic indication, where the TXOP holder accepts the P2P RD request and initiates a triggered TXOP sharing procedure;

[0034] Figure 26 is an example of a control information subfield format in an enhanced CAS control subfield indicating a P2P transfer request; and

[0035] Figure 27is a flow chart of an exemplary process for providing enhanced reverse. DETAILED DESCRIPTION

[0036] Figure 1A FIG1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and the like.

[0037] like Figure 1A As shown in FIG, a communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular 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 device, a head-mounted display (HMD), a vehicle, a drone, medical devices 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 process chain), consumer electronic devices, devices operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0038] The communication 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 communication 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 NodeB, an eNodeB (eNB), a Home NodeB, a Home eNodeB, a next generation NodeB (such as a gNodeB (gNB), a New Radio (NR) NodeB), a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0039] Base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

[0044] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, for example, 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 / from multiple types of base stations (e.g., eNBs and gNBs).

[0045] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio 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 (GERAN), and the like.

[0046] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106.

[0047] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1AAlthough not shown in the figures, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0048] 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 that provides 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) from 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 networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0049] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0050] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown in FIG, 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

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

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

[0053] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in FIG. 1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0054] The transceiver 120 may be configured to modulate signals to be 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, for example, enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0055] The processor 118 of the WTRU 102 may be coupled to 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) and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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. Furthermore, 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, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0057] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (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 acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0058] The processor 118 may be further coupled to other peripherals 138, which may include one or more software modules 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 video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

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

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

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

[0062] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. Figure 1C As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

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

[0065] The SGW 164 may be connected to each of the eNode Bs 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-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0067] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication 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.

[0068] Even though the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

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

[0070] 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 to or an interface with 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 and destined for a STA may reach the AP and be delivered to the STA. Traffic originating from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a 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 point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) a source and destination STA using 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 (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0071] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented in an 802.11 system. For CSMA / CA, STAs (e.g., each STA) including the AP can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a specific STA, the specific STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0072] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0073] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two non-contiguous 80MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be separably subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0074] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., for maintaining very long battery life).

[0075] WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA (that supports the minimum bandwidth operating mode) from among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can 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) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because a STA (that only supports the 1 MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

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

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

[0078] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 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, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0079] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerologies. For example, 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 varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).

[0080] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use 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 an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connecting to another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve 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.

[0081] 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 UL and / or DL, support of network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, and the like. Figure 1D As shown in , gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0082] Figure 1DThe CN 106 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and possibly data networks (DNs) 185 a, 185 b. Although the aforementioned elements are depicted 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.

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

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

[0085] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0086] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, 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 may connect to the local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0087] Given that Figures 1A-1D as well as Figures 1A-1D

[0015] As described herein, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0089] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0090] 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 to or an interface with 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 and destined for a STA arrives through the AP and is delivered to the STA. Traffic originating from a STA destined for a destination outside the BSS is sent to the AP for delivery to the destination. Traffic between STAs within the BSS can also be sent through the AP, with the source STA sending traffic to the AP, and the AP delivering the traffic to the destination STA.

[0091] By using the 802.11ac infrastructure mode of operation, the AP can transmit beacons on a fixed channel (typically the primary channel). This channel can be 20 MHz wide and is the operating channel of the BSS. This channel is also used by STAs to establish connections 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, every STA (including the AP) can sense the primary channel. If the channel is detected to be busy, the STA backs off. Therefore, in a given BSS, only one STA can transmit at any given time.

[0092] In 802.11n, high throughput (HT) STAs can also use 40 MHz wide channels for communication. This is achieved by combining the main 20 MHz channel with adjacent 20 MHz channels to form a 40 MHz wide contiguous channel.

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

[0094] To improve spectral efficiency, 802.11ac has 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). For 802.11ah, the possibility of using downlink MU-MIMO is also currently being considered. It is important to note that since downlink MU-MIMO, as it is used in 802.11ac, uses the same symbol timing for multiple STAs, interference from waveform transmission to multiple STAs is not a problem. However, all STAs involved in MU-MIMO transmission with the AP must use the same channel or frequency band, which limits the operating bandwidth to the minimum channel bandwidth supported by the STAs included in the MU-MIMO transmission with the AP.

[0095] A STA may be able to construct a subset of frames for transmission and decode a (possibly different) subset of frames upon receipt for verification. The specific subset of frames that a STA constructs and decodes may be determined by the functionality supported by that particular STA. A STA may be able to use the Frame Check Sequence (FCS) to verify each received frame and interpret certain fields from the MAC header of all frames.

[0096] STAs can transmit frames using only the frame format developed in the IEEE 802.11 standard. The MAC frame format consists of a set of fields that appear in a fixed order in all frames.

[0097] Figure 2The general MAC frame format 200 of the protocol version 0 (PV0) MPDU is depicted. Figure 2 As shown in , 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.

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

[0099] The HT Control field 218 may be transmitted by non-China Millimeter Wave Multi-Gigabit (non-CMMG) STAs. Three variants are possible: HT variant, VHT variant, and HE variant. The variant formats can be distinguished by the values ​​of B0 and B1. Figure 3 Three variations of the HT Control field 218 are illustrated.

[0100] Figure 4 An example format 400 of the A Control (Aggregation Control) subfield of the HE variant HT Control field is shown. Figure 4 As shown in FIG, the A control subfield may include a control list subfield 402 and a padding subfield 404. In addition, the A control subfield may be 30 bits in length. The control list subfield contains one or more control subfields.

[0101] Figure 5 The following figure shows an example format of the control subfield. Figure 5 As shown in , 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. For each value of the unreserved control ID subfield 502, the length of the control information subfield 504 may be fixed. The values ​​of the control ID subfield 502 and the associated lengths of the control information subfield 504 are defined in Table 1 below.

[0102]

[0103] Table 1 - Control ID subfield values

[0104] The control information subfield in the CAS control subfield contains command and status (CAS) control. Figure 6 An example format 600 of the control information subfield in the CAS control subfield is illustrated.

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

[0106] 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 contain RD data frames from the same AC or a higher priority AC, as defined in 10.29.4 (Rules for RD Responders) of the IEEE Std 802.11-REVme / D1.0: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification (December 2021).

[0107] 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. If the PPDU is a PSRT PPDU, the PSRT PPDU subfield is set to 1; otherwise, it is set to 0.

[0108]

[0109] Table 2 - AC Constraint Subfield Values

[0110]

[0111] Table 3 - RDG / More PPDU subfield values

[0112] A HE STA declares itself as a HE STA by transmitting the HE Capability Element. The HE Capability Element contains the Element ID, Length, Element ID Extension, HE MAC Capability Information, HE PHY Capability Information, Supported HE-MCS and NSS Sets, and PPE Threshold (optional) subfields. Figure 7 An example format 700 of the HE MAC Capability Information field is illustrated.

[0113] A HE STA operating in the 6 GHz band may declare its extended capabilities by transmitting the HE 6 GHz Band Capability element. Figure 8 An example format 800 of the HE 6 GHz Band Capability element is shown. Figure 8 As shown in FIG, 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.

[0114] Figure 9 An example format 900 of the capability information field 808 is shown. Figure 9 As shown in , 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 saver field 910, an RD responder subfield 912, an Rx antenna mode consistency subfield 914, a Tx antenna mode consistency subfield 916 and a reserved subfield 918.

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

[0116]

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

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

[0119] An RD exchange sequence may include the transmission of a PPDU by a 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 that transmits this PPDU is referred to as the RD initiator. The rules for the 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).

[0120] An RD exchange sequence may include the transmission of one or more PPDUs (RD response burst) by the STA addressed in the MPDU of the RDG PPDU. The first (or only) PPDU of the RD response burst contains at most one immediate BlockAck or Ack frame. The last (or only) PPDU of the RD response burst contains any MPDU that needs to be a response to an immediate BlockAck or Ack frame. The STA that transmits the RD response burst is called the RD responder. The rules for the RD responder apply only during a single RD exchange sequence (i.e., after receiving the RDG PPDU and until a PPDU is transmitted by the RD responder) where the RDG / More PPDU subfield is equal to 0.

[0121] The RD exchange sequence may include the transmission of a PPDU by the RD initiator, the PPDU including an immediate BlockAck frame or an Ack frame (RD initiator final PPDU). The last PPDU of the RD response burst may require the transmission of a PPDU.

[0122] The transmission of an MPDU by a HE RD initiator including a CAS Control subfield with the RDG / More PPDU subfield set to 1 may indicate that the duration indicated by the Duration / ID subfield may be used for the RD Response Burst and the RD Initiator Final PPDU (if present). In frames transmitted during a TXOP, a HE STA RD initiator with the RDG / More PPDU subfield in the CAS Control subfield set to 1 may set the AC Constraint subfield in the CAS Control subfield to 1.

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

[0124] The RD responder may ensure that its PPDU(s) transmission and any expected responses fall entirely within the remaining TXOP or SP duration, as indicated by the Duration / ID field of the MPDU within the RDG PPDU. The RD responder may not transmit an MPDU (either individually or aggregated within an A-MPDU) that is not one of the following frames: (1) Ack; (2) Compressed BlockAck; (3) Compressed BlockAckReq; (4) Extended Compressed BlockAck; (5) Extended Compressed BlockAckReq; (6) Multi-STA BlockAck; (7) QoS Data; (8) Management; and / or (9) Basic Trigger.

[0125] During an RD response burst, any PPDU transmitted by the RD responder may contain at least one MPDU with an Address 1 field that matches the MAC address of the RD initiator, or at least one trigger frame addressed to the RD initiator, and traffic for STAs other than the RD initiator in a VHTMU PPDU, S1GMU PPDU, or HE MU PPDU may not increase the duration of the PPDU beyond the duration required to transmit the traffic to the RD initiator. The RD responder may not transmit a frame that is not a basic trigger frame and results in a response with an Address 1 field that does not match the MAC address of the RD initiator after a SIFS. The RD responder may not transmit any PPDU with a CH_BANDWIDTH wider than the CH_BANDWIDTH of the PPDU containing the frame(s) delivering the RD Grant. An RD responder transmitting a basic trigger frame may set the CS Required subfield to 1 and may allocate a number of streams to the RD initiator that is no less than the number of streams of the RD initiator's last PPDU. If the RD initiator sets the RDG / More PPDU field to 1 in the +HTC frame transmitted during the TXOP and sets the AC Constraint subfield in the frame to 1, the RD responder may set the Preferred AC subfield of the Trigger-Related 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 block acknowledgment response, a BlockAck frame may be included in the first PPDU of the response.

[0126] Trigger frames were first introduced in IEEE 802.11ax. They can be used to allocate resources and trigger single-user or multi-user access. Figure 10 An exemplary trigger frame format 1000 is shown. Figure 10 As shown in , the trigger frame may 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 .

[0127] Figure 11 An exemplary common information field format 1100 is illustrated. Figure 11As shown in the figure, the common information field may include a trigger type subfield 1102, a UL length subfield 1104, a More TF subfield 1106, a CS required subfield 1108, a ULBW subfield 1110, a GI and HE-LTF mode subfield 1112, a MU-MIMO HE-LTF mode subfield 1114, a HE-LTF symbol number and midamble period subfield 1116, a UL STBC 1118, an LDPC additional symbol segment subfield 1120, an AP Tx power subfield 1122, a Pre-FEC filling factor subfield 1124, a PE disambiguation 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-related common information subfield 1136.

[0128] Figure 12 Figure 1 shows exemplary user information fields for all trigger types except the Null Feedback Report Poll (NFRP) trigger. Figure 12 As shown in , the user information field 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, a UL target received power field 1214, a reserved field 1216, and a trigger-related user information field 1218.

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

[0130]

[0131] Table 5 - Trigger Types

[0132] "Reverse transmission" is the transmission of data from the TXOP responder to the TXOP holder. In 802.11, a STA can acquire the wireless medium (WM) and become a TXOP holder. The TXOP holder can allow reverse transmission by transmitting a PPDU containing one or more +HTC fields, where the RDG / More PPDU subfield is set to 1. The STA that transmits the PPDU can be called the RD initiator (also known as the TXOP holder). The addressed STA of the PPDU can be called the TXOP responder or RD responder. Upon receiving the PPDU, the RD responder can respond with an acknowledgment and reverse data transmission. For existing solutions, the RD initiator is the STA that can initiate the process. The RD responder may not be able to request RD transmission.

[0133] In an embodiment, the enhanced RD process may include reusing the signaling defined in the +HTC field. Any other mechanism or signaling may be used to summarize the enhanced RD process. Generally, the TXOP responder and / or any STA may request enhanced reverse transmission by transmitting a frame with an RD request. The TXOP holder may authorize RD by transmitting a frame with an RD grant. The TXOP responder may then start an RD data burst transmission or request additional resources for the RD burst. For P2P transmission, any other mechanism or signaling may be used to summarize the process. Generally, the TXOP responder and / or any STA may request enhanced reverse / P2P transmission by transmitting a frame with an RD request and / or a P2P request. The TXOP holder may authorize RD and / or P2P by transmitting a frame with an RD / P2P grant. Next, the TXOP responder may start an RD transmission and / or a P2P data burst transmission, or request additional resources for the RD / P2P burst. The RD request, RD authorization, P2P request and / or P2P authorization 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, etc.

[0134] 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). A series of features that have been discussed in the EHT SG and 802.11be to achieve the goals of increasing peak throughput and improving efficiency include: multiple APs, multi-band / multi-link, 320 MHz bandwidth, and new designs for 6 GHz channel access.

[0135] The RD protocol in 802.11ax is initiated by the TXOP holder. However, in many scenarios (e.g., delay-sensitive traffic entering the TXOP holder's receiving STA), the receiving STA may need to deliver the traffic as quickly 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 enables the TXOP holder's receiving STA to indicate delay-sensitive traffic to the TXOP holder (e.g., through enhanced CAS) and request data transmission from the receiving STA to the TXOP holder.

[0136] The RD protocol in the 802.11ax specification enables the exchange of RD frames, which authorizes data transmission from a receiving STA to the TXOP holder. With the increase in traffic volume and the number of devices, there is an increasing number of services among peer STAs, especially those that are latency-sensitive. Therefore, a simple yet effective protocol is needed to enable peer-to-peer (P2P) communication through enhanced CAS.

[0137] During an ongoing TXOP, some data transmission (e.g., low-latency traffic) may arrive at 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 receiving STA is not in power saving mode and is available to receive data, it may be necessary to have a mechanism to make potential receiving STAs available during this situation (especially in the case of low-latency traffic delivery).

[0138] In one embodiment, the enhanced CAS subfield may be included in the control information subfield of the CAS control subfield containing enhanced CAS control. Figure 13 FIGURE 1 illustrates an exemplary control information field in the enhanced CAS control subfield. Figure 13 As shown in FIG, the control information field may include an AC constraint subfield 1302, an RDG / More PPDU subfield 1304, a PSRT PPDU subfield 1306, an enhanced CAS subfield 1308, and a reserved subfield 1310. The enhanced CAS control may enable a receiving STA of a TXOP holder to request the TXOP holder to authorize reverse transmission due to incoming unexpected traffic (e.g., delay-sensitive traffic).

[0139] Table 6 below illustrates example value interpretations for the Enhanced CAS and RDG / More PPDU fields. In Table 6, the RD requester may be the receiving STA of the TXOP holder. When the RDG / More PPDU subfield in the Control Information subfield sent by the RD requester is set to 0 and the Enhanced CAS subfield is set to 1, this may indicate that the receiving TXOP holder or RD requester is requesting the TXOP holder to grant reverse transmission in the next round. One factor leading to this request may be incoming delay-sensitive traffic, which may have strict delay requirements.

[0140]

[0141] Table 6 - Example Value Interpretation of Enhanced CAS and RDG / More PPDU Subfields

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

[0143] In an embodiment, a receiving STA of a TXOP holder may send an RD request to the TXOP holder, and the request may be included in the +HTC field that is sent along with a Block Acknowledgement (BA) frame when receiving a data frame from the TXOP holder.

[0144] Figure 14 An exemplary flow chart is provided that depicts a TXOP responder transmitting an RD request using enhanced CAS and a TXOP holder accepting the RD request. The RD requester may carry the reverse request in any other part of the MAC header, field, subfield, element, or in a separate MAC frame.

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

[0146] At 1404, upon receiving the PPDU sent from STA1, STA2, which has low-latency traffic in its buffer, may act as an RD requester and respond to the PPDU with a Transmit+HTC BlockAck frame with the Enhanced CAS subfield set to 1 and the RDG / More PPDU subfield set to 0. This setting may indicate that STA2 requests STA1 to authorize a reverse transmission, which may be an emergency traffic transmission.

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

[0148] At 1408, upon receiving the RDG, STA2, acting as both the RD requester and the RD responder, may respond by transmitting a +HTC BlockAck frame with the Enhanced 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 transmits a +HTC PPDU (the second PPDU of the RD response burst) with the Enhanced CAS subfield set to 1 and RG / 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 an RDG from STA2.

[0149] At 1410, upon receiving an enhanced CAS indicating an RD request from STA2, STA1 (acting as the RD initiator) can regain control of the TXOP and transmit a +HTC BlockAck frame addressed to STA2 to acknowledge the MPDU transmitted by STA2 in the RD response and RD request bursts. The +HTC blockAck includes a traditional CAS control subfield with the RDG / More PPDU subfield set to 1. This indicates that STA1 agrees to grant RD to STA2 based on its request. At 1412, STA2 (RD requester and RD responder) can transmit a PPDU to STA1 that contains QoS data + HTC MPDU with an implicit BAR acknowledgment policy and the RDG / More PPDU subfield set to 0. This indicates that it is the only PPDU in the RD response burst. At 1414, STA1 can transmit a BlockAck (BA) frame to STA2 that acknowledges the MPDU transmitted by STA2 in the RD response burst.

[0150] Figure 15 An example of an enhanced frame exchange is provided, which shows an RD request sent from a TXOP holder, a TXOP responder, and a receiver. Figure 15 As shown in , at 1510 STA1 1502 (TXOP holder) may transmit a PPDU containing an MPDU addressed to STA2 1504. This PPDU may require an immediate block acknowledgement (BA) response from STA2 1504.

[0151] At 1512, upon receiving the PPDU sent from STA1 1502, STA2 1504, which has low-latency traffic in its buffer, may act as an RD requester and respond to the PPDU with a Transmit+HTC BlockAck frame with the Enhanced 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 authorize a reverse transmission, which may be an emergency traffic transmission.

[0152] At 1514, upon receiving the +HTC BlockAck frame from STA21504, STA11502 may regain control of the TXOP, agree to authorize reverse transmission to STA21504, and indicate RDG using a +HTC data frame with legacy CAS by setting the RDG / More PPDU subfield in the CAS Control subfield to 1.

[0153] At 1516, upon receiving the RDG, STA2 1504, acting as both the RD requester and the RD responder, may respond by transmitting a +HTC BlockAck frame with the Enhanced 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 transmits a +HTC PPDU (the second PPDU of the RD response burst) with the Enhanced CAS subfield set to 1 and RG / 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 an RDG from STA2 1504.

[0154] At 1518, upon receiving the enhanced CAS subfield indicating an RD request from STA21504, STA11502 (acting as the RD initiator) can regain control of the TXOP and transmit a +HTC BlockAck frame addressed to STA2 to acknowledge the MPDU transmitted by STA21504 in the RD response and RD request bursts. The +HTC blockAck includes a traditional CAS control subfield with the RDG / More PPDU subfield set to 1. This indicates that STA1 agrees to grant RD to STA21504 based on its request. At 1520, STA21504 (RD requester and RD responder) can transmit a PPDU to STA11502, which contains QoS data + HTC MPDU with an implicit BAR confirmation policy and the RDG / More PPDU subfield set to 0. This indicates that it is the only PPDU in the RD response burst. At 1522 , STA1 1502 may transmit a BlockAck (BA) frame to STA2 1504 acknowledging the MPDU transmitted by STA2 1504 in the RD response burst.

[0155] RD requesters can also use Figure 13 The reserved bits shown in are used to indicate service-related parameters (eg, service type, service size, etc.).

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

[0157] In one embodiment, the RD Requester field may be included in the Capability Information field of the HE 6 GHz Band Capability element or the EHT MAC Capability Information field or any other capability information field. Table 7 below provides an exemplary RD Requester field that may be present in the HE 6 GHz Band Capability element or the EHT MAC Capability Information field or any other capability information field.

[0158]

[0159] Table 7 - Example RD Requestor Subfield of HE 6 GHz Band Capability Element or EHT MAC Capability Information Field

[0160] In one embodiment, the enhanced CAS control subfield may include link information of a multi-link device (MLD) STA.

[0161] Figure 16 An example of the control information field in the MLD enhanced CAS control subfield format 1600 is shown. Figure 16 As shown in FIG, the control information field in the MLD Enhanced CAS Control subfield may include an AC Constraint subfield 1602, an RDG / More PPDU subfield 1604, a PSRT PPDU subfield 1606, an Enhanced CAS subfield 1608, and a Link ID subfield 1610. The Link ID field may be included in the Enhanced CAS Control subfield. Table 7 below provides an explanation of example values ​​for the RDG / More PPDU, Enhanced CAS, and Link ID subfields.

[0162]

[0163] Table 7 - Example Value Interpretation of RDG / More PPDU, Enhanced CAS, and Link ID Subfields

[0164] Figure 16Table 7 and Table 7 illustrate that when the transmitting STA is an RD requester, if the Enhanced 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 can request RDG for the next transmission on the link indicated in the Link ID field. If the transmitting STA is an RD initiator that authorizes reverse transmission to the receiving STA of the TXOP holder (i.e., the RD initiator), if the Enhanced CAS subfield is set to 1 and the RDG / More PPDU value is set to 1, the authorized reverse transmission may exist 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 sent by the RD initiator, the TXOP holder as the RD initiator may not authorize reverse transmission to the RD requester on any link.

[0165] In one embodiment, the STA can use the PHY header to indicate the low-latency service that needs to be delivered from the buffer and request reverse authorization. For example, the Disregard bit in the U-SIG field of the EHT MU PPDU or EHT TB PPDU can be used for emergency service indication, which shows the reverse service type, service size, or allocation time. This indication is sent to the recipient of the RD requester (e.g., the TXOP holder requesting reverse authorization). Reverse transmission may include reverse transmission from the RD requester to the TXOP holder or from the RD requester to other STAs that may not be TXOP holders. The low-latency service indication or reverse transmission request may need to be included in the TXVECTOR and RXVECTOR parameters.

[0166] In another embodiment, the enhanced CAS subfield can be used to request reverse transmission of 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 transmission authorization (i.e., requests that the TXOP holder allocate some time for the traffic delivery).

[0167] Figure 17 The above exemplary P2P scenario is shown in FIG. Figure 17As shown in Figure 1, TXOP responder T2 1704 (i.e., STA2) may have service data (e.g., low-latency data) to deliver to R3 1708 (i.e., STA3) during a TXOP. T1 1702 (i.e., STA1) is the TXOP holder, and R2 1706 (i.e., STA2) is the TXOP responder. Numeric symbols represent different STAs. For example, T1 1702 may define STA1 as a transmitter delivering services to STA2, while R2 1706 may define STA2 as a receiver. T2 1706 may define STA2 as a transmitter delivering services to STA3, while R3 1708 may define STA3 as a receiver.

[0168] The above-mentioned embodiments can be applied to the case where the TXOP holder (e.g., T1 1702) is an AP and the TXOP responder (e.g., R2 1706) is a non-AP STA. The recipient of the traffic data indicated by the TXOP responder (e.g., T2 1704) is a non-AP STA or another AP (e.g., R3 1708).

[0169] The above-mentioned embodiments can be applied to the case where 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).

[0170] In one embodiment, the enhanced CAS subfield may include reverse transmission of P2P services. In this enhanced CAS control subfield, three new subfields may be included: enhanced CAS, P2PTx, and TimeDuration.

[0171] Figure 18 An exemplary control information field format 1800 in the enhanced CAS control subfield is depicted. Figure 18 As shown in , the control information field format may include an AC constraint subfield 1802 , an RDG / More PPDU subfield 1804 , a PSRT PPDU subfield 1806 , an enhanced CAS subfield 1808 , a PSPTx subfield 1810 , and an allocation duration subfield 1812 .

[0172] Table 8 below illustrates the corresponding value interpretations of the control information fields.

[0173]

[0174]

[0175] Table 8 - Example Value Interpretation of Enhanced CAS, RDG / More PPDU, and P2PTX Fields

[0176] In the case where the transmitting STA is an RD requester requesting authorization for reverse transmission from the TXOP holder (i.e., the RD initiator), if the Enhanced CAS subfield is set to 1, the P2PTx subfield is set to 1, and the RDG / More PPDU Value subfield is set to 0, the STA may request RDG for P2P transmission (RDG for P2P transmission has not yet been authorized), for example, due to delay-sensitive traffic in its buffer; or after giving RDG for P2P transmission, the STA no longer has a PPDU in the response burst, but there is another P2P transmission in the next response burst (for example, the P2P transmission of one peer STA is completed, but there is another P2P transmission of another peer STA within the time allocated for P2P transmission). If the Enhanced CAS subfield is set to 1, the P2PTx subfield is set to 1, and the RDG / More PPDU Value subfield is set to 1, it may indicate that the PPDU carrying the frame transmitted by the RD requester is followed by another PPDU transmitted to the same peer STA.

[0177] In one embodiment, the Enhanced CAS subfield may indicate whether the transmission is an enhanced RD request / response. If the Enhanced CAS subfield is set to 0, the receiving STA may treat this as a traditional CAS field and will not consider P2P communication. The RDG / More PPDU subfield may indicate whether the RD initiator / TXOP holder has granted a transmission opportunity to the RD responder. If this field is set to 0, no transmission opportunity is granted to the RD responder. The P2PTx subfield may further indicate whether P2P transmission is allowed during the granted transmission opportunity. If P2P transmission is allowed, reverse transmission is always allowed. Three subfields may be used to indicate whether only P2P transmission is allowed (but not reverse transmission) for the granted transmission opportunity. If the transmitting STA is the RD initiator (e.g., TXOP holder), if the Enhanced CAS subfield is set to 1, the P2PTx subfield is set to 1, and the RDG / More PPDU Value subfield is set to 0, the P2P transmission and / or reverse transmission requested by the RD requester may not be granted (i.e., P2P transmission is denied and reverse transmission is denied). If the Enhanced CAS subfield is set to 1, the P2PTx subfield is set to 1, and the RDG / More PPDU Value subfield is set to 1, P2P transmission may be authorized to the RD requester, but reverse transmission may not be authorized to the RD requester. If the RDG / More PPDU subfield is set to 1, the Enhanced CAS subfield is set to 0, and the P2PTx subfield is set to 0, it may indicate that only reverse transmission is authorized, but P2P transmission between the TXOP responder and any other STA is not allowed. If the RDG / More PPDU subfield is set to 1, the Enhanced CAS subfield is set to 1, and the P2PTx subfield is set to 0, it may indicate that reverse transmission is authorized (i.e., RDG exists and it allows reverse transmission from the TXOP responder to the TXOP holder and P2P transmission between the TXOP responder and (one or more) other STAs).

[0178] The above value settings are exemplary explanations of actions that can be taken by the TXOP responder and the TXOP holder. Other combinations of value settings can be interpreted as the same actions that can be taken by the TXOP responder and the TXOP holder as described above.

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

[0180] If the enhanced CAS Control is transmitted by the RD requester, the Allocation Duration subfield of the Enhanced CAS Control subfield indicates the requested time for P2P transmission; if the enhanced CAS Control is transmitted by the RD initiator, the Allocation Duration subfield of the Enhanced CAS Control subfield indicates the time allocated by the RD initiator for P2P transmission. Note that if the RD initiator rejects the P2P RDG, that is, the RDG / More PPDU is set to 0, the Enhanced CAS subfield is set to 1, and the P2PTx subfield is set to 1, the RD requester may ignore the value shown in the Allocation Duration subfield sent from the RD initiator, or the value of the Allocation Duration subfield may be all zeros. Alternatively, if the RD initiator (TXOP holder or AP) accepts the RD request by setting the Enhanced 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 process for P2P transmission between the RD requester and (one or more) other STAs, the RD initiator can set the Allocation Duration subfield to 0, indicating that the MU-RTS TXS Trigger frame follows after it receives an acknowledgment from the RD requester.

[0181] There may be many ways to quantize the actual allocation duration of a P2P Tx into the bit value shown in the Allocation Duration subfield. In one option, the maximum allocation duration and the minimum allocation duration are defined as 111 and 001 respectively. The system may define the maximum and minimum allocation durations. Each value in the Allocation Duration subfield may then be incremented from the previous value. For example, 010 can indicate an increase from the minimum allocated duration 011 can represent an increase from the value represented by 010. Another option is for the bit values ​​shown in the Allocation Duration subfield to represent predefined quantization values. The difference between the quantization values ​​represented by any pair of adjacent bits may not be the same. For example, the difference between the quantization values ​​represented by 001 and 010 may be different from the difference between the quantization values ​​represented by 011 and 010.

[0182] The TXOP holder or RD initiator may use the enhanced CAS control subfield or any other field / element of the MAC frame or a separate MAC frame to authorize the reverse direction of P2P transmission to the TXOP responder with or without a request from the TXOP responder. P2P transmission may refer to transmission between the RD requester (or TXOP responder) and other STAs that are not the TXOP holder.

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

[0184] Figure 19 An exemplary flow diagram illustrating an RD request for P2P transmission accepted by a TXOP holder is shown. Figure 19 The protocol shown in

[15] can be applied to situations where the TXOP holder or RD initiator is not an AP but a non-AP STA. For transmissions between a TXOP responder (or RD requester) and one or more other STAs excluding the TXOP holder, the TXOP holder can authorize the TXOP responder to request a reverse direction. The signaling for the reverse direction request is not limited to the enhanced CAS control subfield. It can be any other field / element of the MAC frame or a separate MAC frame.

[0185] Figure 20 Illustrated is an exemplary RD frame exchange using enhanced CAS with P2P traffic indication (format follows Figure 18 ). Figure 20 The example process shown in depicts a case where the TXOP holder accepts the P2P RD request (ie, the P2P RDG exists).

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

[0187] At 2012, STA2 2004 may have urgent traffic (e.g., delay-sensitive traffic) in its buffer for other peer STAs (or other APs) and wants to request a reverse direction grant from STA1 2002. After receiving data from STA1 2002, STA2 2004 may send a +HTC Blockframe with the Enhanced CAS subfield set to 1, the RDG / MorePPDU subfield set to 0, the P2PTx subfield set to 1, and the Allocation Duration subfield set to a valid value (e.g., from 1 to 7), which may give the TXOP holder an estimate of the amount of P2P traffic to be delivered.

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

[0189] At 2016, upon receiving a +HTC data frame with an enhanced CAS subfield from STA12002, STA22004 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 a P2P PPDU will follow SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

[0190] At 2018, STA22004 may transmit a P2P PPDU (the 2nd PPDU of the RD response burst) to STA32006, which uses the implicit BAR acknowledgment policy of its QoS data frame and contains a traditional CAS including the RDG / More PPDU subfield set to 0, indicating that this is the last PPDU in the response burst.

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

[0192] exist Figure 20In the example shown, STA2 2004 can use all the allocated time allocated by STA1 2002 (i.e., the RD initiator). Alternatively, STA2 can terminate the P2P transmission earlier than the allocated time. In this case, STA2 2004 can return control of the TXOP to STA1 2002, the original TXOP holder.

[0193] Figure 21 An exemplary process of RD frame exchange using an enhanced CAS subfield with P2P traffic indication is illustrated, where the TXOP accepts P2P RD requests and the time used for P2P transmission is the same as the time allocated by the RD initiator.

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

[0195] At 2112, STA2 2104 may have urgent traffic (e.g., delay-sensitive traffic) in its buffer for other peer STAs (or other APs) and wants to request a reverse direction grant from STA1 2102. After receiving data from STA1 2102, STA2 2104 may send a +HTC Blockframe with the Enhanced CAS subfield set to 1, the RDG / MorePPDU subfield set to 0, the P2PTx subfield set to 1, and the Allocation Duration subfield set to a valid value (e.g., from 1 to 7), which may give the TXOP holder an estimate of the amount of P2P traffic to be delivered.

[0196] At 2114, STA1 (RD initiator) may accept the RDG request for P2P transmission from STA2 and allocate a specific time during the requested P2P transmission, as indicated in the Allocated Duration subfield of the Enhanced CAS subfield carried in the +HTC data frame sent from STA1 2102 to STA2 2104. This data frame may request an immediate Block ACK response.

[0197] At 2116, STA22104 (RD requester / responder) 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 a P2P PPDU will follow SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

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

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

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

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

[0202] Alternatively, after STA2 2104 (i.e., the RD requester of the P2P transmission) completes the P2P transmission earlier than the allocated time duration indicated in the allocated duration subfield included in the enhanced CAS transmitted by STA1 2102, STA2 2104 may transmit a +HTC QoS empty 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, and STA2 transmits the BlockAck frame requested by STA1. Alternatively, STA2 may 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 completes earlier than the allocated duration allocated to the P2P transmission by STA1, the RD initiator / TXOP holder.

[0203] Figure 22 The figure shows an example of RD frame exchange using enhanced CAS with P2P service indication. Figure 22As shown in FIG, at the TXOP holder, STA1 2202 accepts the P2P RD request from STA2. STA2 2204 completes the P2P transmission earlier than the time allocated by STA1 2202 and uses a +HTC QoS empty frame 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.

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

[0205] At 2212, STA2 2204 may have urgent traffic (e.g., delay-sensitive traffic) in its buffer for other peer STAs (or other APs) and wants to request a reverse direction grant from STA1 2202. After receiving data from STA1 2202, STA2 2204 may send a +HTC Blockframe with the Enhanced 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., from 1 to 7), which may give the TXOP holder an estimate of the amount of P2P traffic to be delivered.

[0206] At 2214, STA1 (RD initiator) may accept the RDG request for P2P transmission from STA2 and allocate a specific time for the requested P2P transmission period, as shown in the Allocated Duration subfield of the Enhanced CAS subfield carried in the +HTC data frame sent from STA1 2202 to STA2 2204. This data frame may request an immediate Block ACK response.

[0207] At 2216, STA22104 (RD requester / responder) 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 a P2P PPDU will follow SIFS or RIFS after the end of the PPDU containing the BlockAck frame.

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

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

[0210] As 2222, STA22204 may transmit a +HTC QoS null frame to STA12202 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.

[0211] In one embodiment, the TXOP holder (e.g., STA1) can also reject the P2P transmission request from STA2 by using the enhanced CAS control subfield, where the enhanced CAS subfield is set to 1, the P2P Tx subfield is set to 1, and the RDG / More PPDU subfield is set to 0.

[0212] Figure 23 An exemplary P2P RD frame exchange process is illustrated in which STA1 2302, the TXOP holder, rejects a request for reverse transmission of P2P traffic sent from STA1 2302. In this example, after indicating the 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.

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

[0214] Figure 24 This figure illustrates an example RD frame exchange using enhanced CAS with P2P transmission indication. In this example, the TXOP holder accepts the P2P reverse request, and the RD requester (i.e., STA1) sends data to multiple peer 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.

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

[0216] At 2412, STA2 2404 may have urgent traffic (e.g., delay-sensitive traffic) in its buffer for other peer STAs (or other APs) and wants to request a reverse direction grant from STA1 2102. After receiving data from STA1 2402, STA2 2404 may send a +HTC Blockframe with the Enhanced 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., from 1 to 7), which may give the TXOP holder an estimate of the amount of P2P traffic to be delivered.

[0217] At 2414, STA1 2402 may accept the RDG request for P2P transmission from STA2 2404 and allocate a specific time during the P2P transmission for the request, as indicated in the Allocated Duration subfield of the Enhanced CAS subfield of the +HTC data frame sent from STA1 to STA2 that carries the request for an immediate block ACK response.

[0218] At 2416, STA2 2404 (RD requester / responder) may respond with the 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 a P2P PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame. The P2P PPDU sent to STA2 carries enhanced CAS, which sets the Enhanced CAS subfield to 1, the RDG / More PPDU subfield to 0, and the P2P Tx subfield to 1. This setting may indicate that there will be another P2P transmission after STA3 sends an acknowledgment to STA2 in the response burst.

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

[0220] In one embodiment, upon receiving a P2P RD request from a TXOP responder (the receiver of a TXOP holder), the AP, which is the TXOP holder and the RD initiator, may transmit a MU-RTS TXS trigger frame to initiate a triggered TXOP sharing process, which enables P2P transmission between the RD requester and another STA within the allocated time indicated in the MU-RTS TXS trigger frame.

[0221] Figure 25 An exemplary process of RD frame exchange using enhanced CAS with P2P traffic indication is illustrated—a TXOP holder can accept a P2P RD request and initiate a triggered TXOP sharing process.

[0222] At 2512, STA22542, the TXOP responder, may receive a data frame from AP 2502 (the TXOP holder) and may transmit back a +HTC BlockAck frame including an enhanced CAS control subfield to request RD transmission to the peer STA by setting the enhanced CAS subfield to 1, the RDG / More PPDU subfield to 0, the P2P Tx subfield to 1, and the allocation duration to a valid value (between 0 and 7).

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

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

[0225] At 2518, AP 2502 may regain control of the TXOP and transmit a MU-RTS TXS Trigger frame to initiate triggered TXOP sharing, which allows STA2 2504 (i.e., the RD requester) to transmit to another STA (e.g., to STA3 2506 within the time allocated in the MU-RTS TXS Trigger frame).

[0226] In one embodiment, the enhanced CAS control subfield may use one bit to indicate RDG or MorePPDU or P2P Tx. Figure 26 FIGURE 1 illustrates an exemplary format of a control information subfield indicating a P2P transmission request in an enhanced CAS control subfield. Figure 26 As shown in FIG, the control information subfield may include an AC constraint subfield 2602, an RDG / More PPDU / P2PTx subfield 2604, a PSRT PPDU subfield 2606, an enhanced CAS subfield 2608, and a TimeDuration subfield 2610. Table 9 below provides an explanation of the corresponding values ​​of each subfield.

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

[0228] In the case where the STA transmitting +HTC with the Enhanced CAS Control subfield is the RD requester, if the RDG / More PPDU Value / P2P Tx subfield is set to 1 and the Enhanced CAS subfield is set to 1, the RD requester (TXOP responder) can request RDG for P2P transmission before the reverse direction is authorized by the TXOP holder; or after the RDG is authorized by the RD initiator, it indicates that there is no more PPDU in the same transmission, but there is another P2P transmission after this transmission (i.e., after receiving an ACK from the receiver of the current PPD if the RDG / More PPDU Value / P2P Tx subfield is set to 1 and the Enhanced CAS subfield is set to 1). If the RDG / More PPDU Value / P2P Tx subfield is set to 0 and the Enhanced CAS subfield is set to 1, it may indicate that the RD requester (TXOP responder) requests RDG for the reverse direction transmission, such as a transmission from the RD responder (TXOP responder) to the RD initiator (TXOP holder).

[0229] If the STA transmitting +HTC with the enhanced 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 enhanced CAS subfield is set to 1, it may indicate that the TXOP responder authorizes the reverse direction to the TXOP responder (e.g., RD ​​requester). This RD transmission may include transmission from the RD requester to the RD initiator or from the RD requester to another STA.

[0230]

[0231]

[0232] Table 9 - Enhanced CAS and RDG / More PPDU / P2PTx Subfield Example Value Interpretation

[0233] In one embodiment, an LL group ID can be assigned to a group of STAs. The LL group ID or the IDs of these STAs can 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 in a TXOP (e.g., broadcast traffic), which may not have been 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 any LL traffic arrives at the TXOP holder or TXOP responder during the middle of the TXOP.

[0234] In one embodiment, a bit (e.g., bits B22, B53, or any of bits B56-B63) may be carried in the EHT variant Common Information field of a MU-RTS trigger frame to indicate that the TXOP may allow non-TXOP participants to receive or transmit low-latency traffic. This bit may be named the 3rd Party Receive / Transmit subfield. For example, if the trigger frame is a MU-RTS (i.e., the Trigger Type subfield in the EHT variant Common Information field of the trigger frame is set to 3) and the Triggered TXOP Shared Mode subfield is set to 3, then the 3rd Party Receive / Transmit subfield set to 1 may indicate that STAs belonging to the LL group of the STA 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 packets (e.g., LL data) intended for them; this also means that the TXOP holder may allow STAs belonging to the LL group ID indicated in the management frame to transmit low-latency data to the TXOP holder or TXOP receiver.

[0235] 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 in B56-B63) of the MU-RTS trigger frame. If the LL group ID is carried in the trigger frame, this may mean that STAs belonging to the LL group ID may be potential recipients of low-latency traffic that was not originally scheduled in the TXOP. The traffic may come from the middle of the TXOP of the TXOP holder or TXOP receiver. In addition, if the LL group ID is carried in the trigger frame, this may mean that the TXOP allows these STAs belonging to the group ID to transmit low-latency traffic.

[0236] In addition, an indication that low-latency service interruption is allowed during the middle of a TXOP and / or an indication of the type of LL service that can interrupt an ongoing TXOP may be carried in a TXOP initiation frame (e.g., a MU-RTS trigger frame, an RTS frame, an enhanced MU-RTS trigger frame, etc.). These indications may also be carried in the preamble (e.g., U-SIG) of the EHT PPDU. LL service interruption may refer to a scenario in which a TXOP is initially allocated to some STAs for certain types of services. In the middle of a TXOP, higher priority services arrive at a STA, which may be a TXOP holder, a TXOP responder, or neither a TXOP holder nor a TXOP responder. Examples of TXOP interruption may include reverse operation, enhanced reverse operation, etc. If the indication allows interruption from LL services and the incoming services belong to an allowable service type, the TXOP holder may authorize the STA to transmit and / or schedule the LL service delivery.

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

[0238] Figure 27 27 is a flow chart of an exemplary process for providing enhanced reverse transmission. 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 enhanced CAS subfield to the second STA, wherein the enhanced CAS subfield is set to request reverse transmission. At 2706, the first STA may receive a second frame from the second STA indicating acceptance of reverse transmission. At 2708, the first STA may transmit a third frame to the second STA, the third frame including reverse data transmission.

[0239] Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the 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. A method performed by a first station (STA), the method comprising: receiving a physical layer protocol data unit (PPDU) from a second STA; transmitting a first frame including an enhanced command and status (CAS) subfield to a second STA, wherein the enhanced CAS subfield is set to request a reverse transmission; receiving a second frame from the second STA indicating acceptance of reverse transmission; as well as A third frame is transmitted to the second STA, where the third frame includes reverse data transmission.

2. The method of claim 1 , wherein the second frame comprises a legacy CAS field, including a Reverse Direction Grant (RDG) / More PPDU subfield, wherein the RDG / More PPDU subfield is set to accept reverse transmission.

3. The method of claim 2, wherein the RDG / More PPDU subfield is set to 1. The method of claim 1 , wherein the first frame is a +High Throughput Control (+HTC) BlockAck frame. The method of claim 1 , wherein the second frame is a +HTC frame. The method of claim 1 , wherein the third frame is a +HTC PPDU frame.

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

8. The method of claim 1, wherein the first frame further comprises 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), comprising: transceiver; as well as processor; The transceiver and processor are configured as follows: receiving a physical layer protocol data unit (PPDU) from a second STA; transmitting a first frame including an enhanced command and status (CAS) subfield to a second STA, wherein the enhanced CAS subfield is set to request a reverse transmission; receiving a second frame from the second STA indicating acceptance of reverse transmission; A third frame is transmitted to the second STA, where the third frame includes reverse data transmission.

11. The first STA of claim 10, wherein the second frame comprises a legacy CAS field, including a Reverse Direction Grant (RDG) / More PPDU subfield, wherein the RDG / More PPDU subfield is set to accept reverse transmission. 12 . The first STA according to claim 11 , wherein the RDG / More PPDU subfield is set to 1.

13. The first STA of claim 10, wherein the first frame is a +High Throughput Control (+HTC) BlockAck frame. The first STA according to claim 10 , wherein the second frame is a +HTC frame. 15 . The first STA of claim 10 , wherein the third frame is a +HTC PPDU frame.

16. The first STA of claim 10, wherein the Enhanced CAS subfield is set to 1. 17 . The first STA of claim 10 , wherein the first frame further comprises an RDG / More PPDU subfield.

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

Images