Method for multi-AP traffic state exchange and enhanced UORA design

Abstract

Coordinated multi-AP transmission improves spectral efficiency and reduces latency. APs may need to know the buffer / traffic status of other APs in order to cooperate with them. Several embodiments disclosed provide buffered status reports between multiple APs. Furthermore, the disclosed embodiments provide a UORA mechanism for low-latency traffic transmission using RA-RU.

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 455,710, filed Mar. 30, 2023; U.S. Provisional Patent Application No. 63 / 537,018, filed Sep. 7, 2023; and U.S. Provisional Patent Application No. 63 / 547,025, filed Nov. 2, 2023, each of which is incorporated by reference in its entirety.

Background Art

[0002] Coordinated multi-access point (AP) transmission can be used to improve spectral efficiency and reduce latency. To achieve this, each AP may need to know the buffers and / or traffic states of other APs so that they can cooperate with each other. However, conventional mechanisms for requesting and reporting buffer and / or traffic states between APs can be insufficient for this function.

[0003] [[ID=1,8]]Furthermore, target wake time (TWT) operation is used to enable an AP and its associated station (STA) to negotiate a wake-up time period during which the STA can transmit and receive traffic, so that a “doze” or reduced power state can be possible during such time periods. In an embodiment called triggered TWT, trigger frames are used to schedule uplink transmissions. If a TWT member STA has low latency traffic, there will be a delay because the AP has to wait to transmit a trigger frame to schedule its UL transmission, and in some cases, it may violate the quality of service (QoS) requirements for low latency traffic.

Brief Description of the Drawings

[0004] A more detailed understanding can be obtained from the following explanation, which is given as an example in conjunction with the attached drawings, where similar reference figures in the drawings indicate similar elements.

[0005] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown in Figure 1A, according to an embodiment. [Figure 1C] This is a system diagram illustrating exemplary radio access network (RAN) and exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to an embodiment. [Figure 1D] This is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in Figure 1A, according to an embodiment. [Figure 2] This figure shows examples of individual TWT operations described in 802.11ax, according to several embodiments. [Figure 3] This is a diagram illustrating an example of broadcast TWT operation with an optional TBTT negotiation as described in 802.11ax, according to several embodiments. [Figure 4] This figure shows the subchannel utilization element format in several different configurations. [Figure 5] This is a signal flow diagram illustrating two schemes for APs to exchange buffer status information, according to several embodiments. [Figure 6] This figure shows an exemplary user information field format for use in AP BSRP trigger frames, according to several embodiments. [Figure 7] This figure shows examples of conventional and extended UORA for TWT according to several embodiments. [Figure 8] This is a flowchart illustrating an embodiment of a method for exchanging traffic status information between APs within a MAP group.

Mode for Carrying Out the Invention

[0006] Table 1 is a non-exhaustive list of acronyms that may be used in this specification.

[0007]

Table 1-1

[0008]

Table 1-2

[0009]

Table 1-3

[0010]

Table 1-4

[0011]

Table 1-5

[0012] <00000�7>

Table 1-6

[0013] Figure 1A illustrates an exemplary 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, messages, and broadcasts to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may 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 eigenword discrete Fourier transform spread OFDM (ZT UW DFT-S OFDM), eigenword OFDM (UW-OFDM), resource block filtering OFDM, filter bank multicarrier (FBMC), and similar.

[0014] As shown in FIG. 1A, 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, but it should 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. For example, the WTRUs 102a, 102b, 102c, 102d, which may also be referred to as stations (STAs) in some cases, may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial scenarios and / or automation process chain scenarios), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may also be referred to interchangeably as a UE.

[0015] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be next-generation NodeBs such as base station transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home nodeBs, home eNodeBs, gNodeBs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, and similar devices. Although base stations 114a and 114b are depicted as single elements, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0016] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and similar devices. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell can provide coverage for radio services to a particular geographic area, which may be relatively fixed or change over time. This cell may further be divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in some embodiments, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology, and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0017] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio 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).

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

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

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

[0021] In the embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base stations 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0022] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), GSM®, Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), and similar technologies.

[0023] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home enode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as businesses, homes, vehicles, campuses, industrial facilities, aerial walkways (e.g., for drone use), roads, and the like. In some embodiments, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106.

[0024] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or VoIP services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobile requirements, and so on. CN106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security features such as user authentication. Although not shown in Figure 1A, it should be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 or different RATs. For example, in addition to being connected to RAN104, which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0025] CN106 can also function as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing legacy telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as the Transmit Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include other CNs connected to one or more RANs, but these CNs may employ the same RAT as RAN104 or different RATs.

[0026] Some or all of the WTRUs 102a, 102b, 102c, and 102d of the communication system 100 may include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c, shown in Figure 1A, may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114b, which may employ IEEE 802 radio technology.

[0027] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a GPS chipset 136, and / or other peripherals 138. It should be understood that the WTRU 102 may include any subcombination of the aforementioned elements while maintaining consistency with the embodiment.

[0028] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors coupled 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 can perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0029] The transmitting / receiving element 122 may be configured to transmit signals to a base station (e.g., base station 114a) via the air interface 116, or to receive signals from a base station (e.g., base station 114a). For example, in some embodiments, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In embodiments, the transmitting / receiving element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It should be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of radio signals.

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

[0031] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate with multiple RATs, such as NR and IEEE 802.11.

[0032] The processor 118 of the WTRU102 is 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 can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and can store data in that memory. Non-removable memory 130 may include RAM, ROM, a hard disk, or any other type of memory storage device. Removable memory 132 may include a SIM card, memory stick, SD memory card, and similar. In other embodiments, the processor 118 can access information from memory not physically located in the WTRU 102, such as a server or home computer (not shown), and store data in that memory.

[0033] The processor 118 can receive power from the power supply 134 and may be configured to distribute and / or control power to other components of the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 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.

[0034] The processor 118 may also be coupled to a GPS chipset 136 which can be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information by any suitable location determination method while maintaining consistency with the embodiment.

[0035] The processor 118 may also be coupled with other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography and / or video), a USB port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, accelerometer, Hall effect sensor, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biosensor, humidity sensor, and the like.

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

[0037] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 can also communicate with CN106.

[0038] RAN104 may include eNode-B160a, 160b, and 160c, but it should be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In some embodiments, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may use multiple antennas, for example, to transmit and / or receive radio signals to and from WTRU102a.

[0039] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, and similar matters. As shown in Figure 1C, the eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0040] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While these elements are depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0041] The MME162 may be connected via the S1 interface to each of the eNode-B162a, 162b, and 162c within RAN104 and can function as a control node. For example, the MME162 may be responsible for user authentication of WTRU102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c, and similar tasks. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0042] The SGW164 can be connected to each of the eNodeB160a, 160b, and 160c within the RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during inter-eNodeB handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, managing and remembering the context of WTRU102a, 102b, and 102c, and so on.

[0043] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0044] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed telephone line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 may also provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0045] Although the WTRU is depicted as a wireless terminal in Figures 1A to 1D, in some typical embodiments, it is intended that such a terminal may be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0046] In a typical embodiment, the other network 112 may be a WLAN.

[0047] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. The APs may have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that brings traffic into and / or out of the BSS. Traffic originating outside the BSS to an STA may arrive via an AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to an AP to be delivered to its respective destination. Traffic between STAs within the BSS may also be sent via an AP; for example, a source STA may send traffic to an AP, which can then deliver that traffic to a destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In some typical embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs (e.g., all STAs) within or using IBSS may communicate directly with each other. The IBSS mode of communication may, in this specification, be referred to as the “ad-hoc” mode of communication.

[0048] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., 20 MHz wideband) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some typical embodiments, carrier-sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, that particular STA may backoff. A single STA (e.g., just one station) may transmit at any given time on a given BSS.

[0049] High-throughput (HT) STAs can use a 40MHz wide channel for communication by, for example, combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0050] Ultra-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. 160MHz channels can be formed by combining eight consecutive 20MHz channels or two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In an 80+80 configuration, data may be passed through a segment parser that can split the data into two streams after channel encoding. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the above operation of the 80+80 configuration may be reversed, and the combined data may be sent to a media access control (MAC).

[0051] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications (MTC), such as MTC devices in the macro-coverage region. MTC devices may have limited capabilities, such as support for specific and / or limited bandwidths (e.g., support only). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0052] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports 1 MHz mode (e.g., only 1 MHz), even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because of an STA (which only supports 1MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though the majority of the available frequency band is idle.

[0053] 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. The total available bandwidth for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.

[0054] Figure 1D is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN 106.

[0055] RAN104 may include gNB180a, 180b, and 180c, but it should be understood that RAN104 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In some embodiments, gNB180a, 180b, and 180c can implement MIMO technology. For example, gNB180a and 180b may utilize beamforming to transmit signals to and from gNB180a, 180b, and 180c. Thus, gNB180a may use multiple antennas to transmit and / or receive radio signals to and from WTRU102a, for example. In the embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be in the unlicensed spectrum, and the remaining component carriers may be in the licensed spectrum. In the embodiment, gNB180a, 180b, and 180c can implement coordinated multipoint (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0056] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerical values. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., encompassing a varying number of OFDM symbols and / or continuing over varying absolute time lengths).

[0057] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without also accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c may use one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using unlicensed band signals. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement the DC principle to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0058] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling during UL and / or DL, support for network slicing, interworking between DC, NR and E-UTRA, routing of user plane data for user plane functions (UPF) 184a and 184b, routing of control plane information for access and mobility management functions (AMF) 182a and 182b, and similar functions. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0059] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although the aforementioned elements are depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0060] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c within RAN104 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible tier (NAS) signaling, mobility management, and similar tasks. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on enhanced large-scale mobile broadband (eMBB) access, services for MTC access, and similar services. AMF182a, 182b can provide control plane functionality for switching between RAN104 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.

[0061] SMF183a and 183b may be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and similar. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0062] UPF184a and 184b may be connected via the N3 interface to one or more of the gNB180a, 180b, and 180c in RAN104, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 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, and providing mobility anchors.

[0063] CN106 can facilitate communication with other networks. For example, CN106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may also provide WTRU102a, 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 some embodiments, WTRU102a, 102b, 102c may be connected to local DN185a, 185b via UPF184a, 184b through an N3 interface with UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0064] Considering Figures 1A to 1D and their corresponding descriptions, one or more, or all, of the functions described herein may be implemented by one or more emulation devices (not shown) with respect to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein. These emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0065] Emulation devices may be designed to perform tests on one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all of the functions of other devices in a communications network while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network. One or more emulation devices may perform one or more or all of the functions of other devices while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for testing and / or may perform testing using wireless communication.

[0066] One or more emulation devices can perform one or more functions, including all of them, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0067] A WLAN in Infrastructure Basic Service Set (BSS) mode typically has an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP typically has access to or interfaces with a distribution system (DS) or another type of wired / wireless network that brings traffic into and out of the BSS. Traffic originating outside the BSS to an STA arrives via the AP and is delivered to the STA. Traffic originating from an STA to an outside BSS destination is sent to the AP for delivery to its respective destination. Traffic between STAs within the BSS may also be sent via the AP, with the source STA sending traffic to the AP, which then delivers that traffic to the destination STA. Such traffic between STAs within the BSS is essentially peer-to-peer traffic. Such peer-to-peer traffic may also be sent directly between the source STA and the destination STA using 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode has no APs and / or STAs that communicate directly with each other. This mode of communication is called "ad-hoc" mode.

[0068] Using the 802.11ac infrastructure operating mode, an AP can transmit beacons on a fixed channel, which is typically the primary channel. This channel can be 20 MHz wide and is the operating channel for the BSS. This channel is also used by STAs to establish connections with the AP. The basic channel access mechanism for 802.11 systems is carrier-sensing multiple access with collision avoidance (CSMA / CA). In this operating mode, all STAs, including the AP, sense the primary channel. If the channel is detected to be busy, the STA backs off. Therefore, only one STA can transmit on a given BSS at any given time.

[0069] In 802.11n, high-throughput (HT) STAs can also use 40MHz wide channels for communication. This is achieved by combining a primary 20MHz channel with an adjacent 20MHz channel to form a continuous 40MHz wide channel.

[0070] In 802.11ac, ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and 160MHz wide channels. 40MHz and 80MHz channels are formed by combining consecutive 20MHz channels, similar to 802.11n described above. 160MHz channels can be formed by combining eight consecutive 20MHz channels or two discontinuous 80MHz channels, which is sometimes referred to as an 80+80 configuration. In an 80+80 configuration, data is passed through a segment parser that, after channel coding, splits it into two streams. IFFT and time-domain processing are performed separately for each stream. The streams are then mapped to the two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is sent to the MAC.

[0071] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. For these specifications, the channel operating bandwidth and carrier are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. A possible use case for 802.11ah is support for meter-type control (MTC) devices in macro coverage areas. MTC devices may have limited functionality, including only limited bandwidth support, but may also have requirements for very long battery life.

[0072] WLAN systems that support multiple channels and channel widths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel designated as the primary channel. The primary channel may, but not necessarily, have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. Thus, the bandwidth of the primary channel is limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1MHz wide if there is an STA (e.g., an MTC type device) that can only support 1MHz mode, even if the AP and other STAs in the BSS can support 2MHz, 4MHz, 8MHz, 16MHz, or other channel bandwidth operating modes. Full carrier sensing and NAV settings are determined by the state of the primary channel. For example, if the primary channel is busy because of an STA that supports only 1MHz operating mode and transmits to the AP, the entire available frequency band is considered busy, even though most of it remains idle and available.

[0073] In the United States, the available frequency band for use with 802.11ah is from 902 MHz to 928 MHz. In South Korea, it is from 917.5 MHz to 923.5 MHz, and in Japan, it is from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.

[0074] Target Wake Time (TWT) operation was originally introduced in 802.11ah. It was designed to allow APs and their associated STAs to negotiate a wake-up period during which STAs can send and receive traffic. In 802.11ax, the use of TWTs was extended to allow APs to manage activity within the BSS in order to minimize contention between STAs and to reduce the time required for STAs utilizing power management modes to wake up. A TWT element is defined to carry information used to negotiate and advertise TWT-related information. A TWT can include a broadcast TWT and unicast or individual TWTs (or device or STA-specific TWTs).

[0075] An example of individual TWT operation as described in 802.11ax is shown in the signal flow diagram in Figure 2. A TWT-scheduled STA (e.g., STA1 204) can send a TWT request 208 to a TWT response STA (e.g., AP202) to establish a trigger-enabled TWT agreement. AP202 can accept the TWT agreement and send a TWT response 210 to notify STA1 204 of the agreement. In some embodiments, AP202 may also send an unrequested TWT response 214 to STA2 206 to establish a trigger-enabled TWT agreement with STA2. A TWT agreement can specify when the next trigger will occur or when the next TWT period 218 will begin, allowing STA1 204 to enter a dose state or low-power state 216 (for example, by disabling the primary transceiver and activating the secondary transceiver, switching the primary receiver to low-power mode or sleep mode, or separately by disabling or modifying the operation from active mode to sleep mode or dose mode), and STA2 206 can similarly enter a dose state 220. In some embodiments, each STA can maintain a dose state for a specified time based on TWT responses 210, 214. In other embodiments, each STA can monitor or listen on the channel with a low-power transceiver or a transceiver in low-power mode in response to a trigger from the AP.

[0076] AP202 can then use trigger frame 224 to initiate a trigger-enabled TWT service period (SP) 222. STA1 204 and STA2 206 can respond with PS-Poll frame 226 and QoS Null frame 228, respectively, indicating that they are awake and ready to communicate with the AP (including, for example, receiving data from AP202 in DL MU PPDU 232 and responding with acknowledgments 234A, 234B; and transmitting data (not shown)). After the TWT SP period 222, in some embodiments, the STAs can return to dose states 236A, 236B until a scheduled trigger broadcast is subsequently broadcast.

[0077] An example of broadcast TWT operation as described in 802.11ax is shown in signal flow diagram 300 of Figure 3. A TWT-scheduled STA (e.g., STA1 304) can negotiate with the TWT scheduling AP 302 to listen for beacon frames via, for example, a TWT request 310 and response 312 to the first wake target beacon transmit time (TBTT) 314 (process 308). At that time, STA 304 can enter dose state 316A (and can also wake up at a specified time by listening for beacon broadcasts via a low-power transceiver or a transceiver in low-power mode, or by enabling or activating a high-power transceiver or high-power mode) (STA2 306 may already be in dose state 316B). AP302 can advertise a broadcast TWT element 322 with beacon 320 to indicate when a trigger 328 will be sent, and furthermore, this STA (as well as other STAs such as STA2 306) can enter a dose state 324 for a specified time. AP302 can then initiate a trigger-enabled TWT service period (SP) 326. During the TWT SP, one or more STAs can wake up and communicate with the AP (e.g., via 330-338B, such as the illustrated PS-Poll, NULL, ACK, PPDU transmission).

[0078] The IEEE Standards Committee approved the IEEE 802.11be Task Group (TG) based on the Project Approval Request (PAR) and Standardization Development Standard (CSD) developed by the EHT SG. Limited TWTs (R-TWT or rTWT) were introduced in 802.11be. R-TWTs are designed to prioritize latency-sensitive traffic by including a limited TWT traffic information field in the broadcast TWT element.

[0079] The IEEE 802.11 Ultra-High Reliability (UHR) Study Group was formed in September 2022. UHR is considered the next major revision to the IEEE 802.11 standard, following 802.11be, which is currently in the working group letter voting stage. UHR was formed to improve the reliability of IEEE 802.11 networks, support low-latency traffic, further increase peak throughput, and improve efficiency.

[0080] Coordinated multi-AP (C-MAP) transmission has been discussed in 802.11be and UHR SG. Schemes discussed include coordinated multi-AP OFDMA (co-OFDMA), coordinated multi-AP TDMA (co-TDMA), coordinated multi-AP spatial reuse (CSR), coordinated beamforming / nulling (CBF), and joint transmission (JTX).

[0081] In the context of coordinated multi-AP, several terms may be used herein, including a “shared AP” or EHT AP that acquires a TXOP and initiates multi-AP coordination; a “shared AP” or EHT AP that coordinates for multi-AP transmission by sharing an AP; and an “AP candidate set” or set of APs that can initiate or participate in multi-AP coordination. Other terms may be used without limitation in relation to these or other AP embodiments.

[0082] As discussed above, in some embodiments, coordinated multi-AP transmission can improve spectral efficiency and reduce latency. APs may need to know the buffer / traffic status of other APs in order to cooperate with them. For systems that do not implement the systems and methods discussed herein, there may be no defined mechanism for requesting and reporting buffer / traffic status between APs.

[0083] Secondly, in trigger-enabled TWT / rTWTs, trigger frames are typically used to schedule uplink transmissions. If a TWT member STA has low-latency traffic, it may have to wait for the AP to send a trigger frame in order to schedule its UL transmission. Trigger-based, uplink orthogonal frequency-division multiplexed access (OFDMA) based random access (UORA) transmissions can be modified by implementations of the systems and methods discussed herein to give any STA or group of STAs an opportunity for UL random access. Thus, a TWT member STA with low-latency traffic can use the opportunity of UORA to transmit uplink data.

[0084] In some embodiments, the problems identified above can be addressed by buffered status reports between APs. Specifically, in some embodiments, APs may statically or dynamically form multiple AP (MAP) groups. To coordinate MAP transmissions, APs may need to know some information about other APs (e.g., within the MAP group), such as whether other APs have buffered traffic, whether other APs are fully loaded, the operating channel width and available subchannels of other APs, etc. Various embodiments of the systems and methods discussed herein may be used by APs to exchange this information at the BSS level or the TXOP level. For example, frame exchange at the BSS level may be considered long-term and relatively static or quasi-static information, which may be valid for the duration of a beacon interval, and even for the duration of multiple beacon intervals. Frame exchange at the TXOP level may be considered short-term and dynamic information, which may be valid for the duration of a TXOP.

[0085] As discussed above, a sharing AP may be an AP that is the owner of the radio medium during a TXOP. A sharing AP may share the acquired medium with other APs (e.g., within a MAP group). Other APs within a BSS are sometimes called sharing APs.

[0086] In some embodiments, AP low-latency traffic indication is used. APs can announce their aggregate buffer status or low-latency buffer status to other APs using broadcast frames, such as beacon frames. In some embodiments, APs exchange or transmit their aggregate buffer status or low-latency buffer status with other APs using radio control / management frames. For example, multi-AP traffic report request / response frames may be defined and used by APs to exchange traffic load-related information. In another example, MAP traffic-related information may be carried in newly defined elements / fields. APs may include MAP traffic-related elements / fields within beacon frames or within MAP-related request / response frames. Such information announcements / exchanges may occur periodically or be provided in response to requests (e.g., unicast or broadcast requests for information).

[0087] In some embodiments, APs supporting low-latency traffic delivery may also notify the average access delay of low-latency traffic within the BSS. In some embodiments, an average low-latency traffic access delay element / field may be used, which may be carried in the management / control frame. The format of the average low-latency traffic access delay element is shown in Table 2 below. The AP low-latency (LL) traffic average access delay field may have a fixed length (e.g., an n-bit field) or a variable length and associated length field in various embodiments. The field value may be a scaled representation of the average media access delay, measured from the point when the DCF or EDCAF low-latency sensitive Media Access Control Protocol data units (MPDUs) of all Distributed Coordination Function (DCF) and Extended Distributed Channel Access Function (EDCAF) transmitted frames are ready to transmit by the actual frame transmission start time (e.g., when the DCF initiates CSMA / CA access). Non-QoS APs average the access delay of all DCF transmitted frames. The QoS AP averages the access delay of all Extended Distributed Channel Access (EDCA) transmitted frames for all AC / TIDs.

[0088] [Table 2]

[0089] In some embodiments, the mean low-latency traffic access delay element may be detailed using DL and UL mean access delays, as shown in Table 3. The exemplary elements shown include separate AP downlink / uplink low-latency traffic mean access delay fields.

[0090] [Table 3]

[0091] In some embodiments, an AP supporting low-latency traffic delivery may also announce minimum latency limit requirements for low-latency traffic within its BSS. In some embodiments, BSS traffic elements / fields, which may be carried in a management / control frame, may be used for this purpose. BSS traffic elements / fields may be used to carry a set of parameters defining the average or worst-case QoS expectation for all traffic flows, or low-latency-related traffic flows, or traffic flows related to one or more selected access categories (ACs) or TIDs (traffic identifiers) within the BSS. For example, a traffic ID or TID may include one or more identifiers available to higher-tier entities to distinguish MAC entities and MAC service data units (MSDUs) that support quality of service (QoS) within a MAC data service. The TID may be provided via a subfield in a MAC frame, or in any other type and form of frame, in some embodiments. For example, in some embodiments, the TID subfield may be part of a frame control field in the MAC header or payload. The TID may include a string, a bitmap, or any other such data format. APs can use BSS traffic elements / fields to exchange traffic status and requirements with active STAs within their BSS. Thus, once an AP plans to share its acquired transmission opportunities, it can share them with APs having more urgent latency requirements or higher traffic loads. BSS traffic elements can carry one or more of the AP LL traffic average access delay fields, AP DL traffic average access delay fields, and / or AP UL traffic average access delay fields mentioned above. Furthermore, BSS traffic elements / fields can carry some or all of the following: Access Category or TID Field: This field may indicate one or more access categories or TIDs, which are QoS-related parameters encompassed by this element. Direction field: This field can indicate DL traffic, UL traffic, or peer-to-peer (P2P) traffic to which the QoS-related parameters contained within this element relate. Minimum delay limit field: This field may contain an unsigned integer specifying the minimum delay limit between all STAs in the BSS, in a direction (DL, UL, or P2P) and / or with the access category / TID specified within the element. Average delay limit field: This field can contain an unsigned integer specifying the average delay limit between all STAs in the BSS, along with the direction (DL, UL, or P2P) and / or the access category / TID specified within the element. Maximum Service Interval Field within BSS: The Maximum Service Interval field contains an unsigned integer that specifies the maximum interval in microseconds between the start of two consecutive SPs within a BSS, which are assigned to DL, UL, or P2P frame exchange sequences depending on the direction field carried within the element. A value of 0 indicates that this parameter is not specified. BSS Minimum Service Interval Field: The Minimum Service Interval field contains an unsigned integer that specifies the minimum interval in microseconds between the start of two consecutive SPs within a BSS, which are assigned to DL, UL, or P2P frame exchange sequences depending on the direction field carried within the element. A value of 0 indicates that this parameter is not specified. In some embodiments, data may be transferred between access points during P2P exchange, while in other embodiments, this may be replaced by direct link transmission.

[0092] Table 4 below shows examples of BSS traffic element / field content. Note that not all elements / fields need to be present, and their order can be changed.

[0093] [Table 4]

[0094] Figure 4 shows an exemplary embodiment of a subchannel utilization element 400 that may be used to indicate subchannel utilization. The subchannel utilization list field may contain N subchannel utilization subfields, where N may be determined by the channel operating width. In some embodiments, the subchannels are in units of 20 MHz. If the channel operating width is K MHz, then N = K / 20. In some embodiments, each subchannel utilization subfield may carry a quantized value of the subchannel utilization rate. Here, Subchannel utilization rate = (Subchannel busy time) / (Measurement time)

[0095] Subchannel busy time is defined as the number of microseconds during which the carrier sensing (CS) mechanism indicates subchannel busy. Measurement time is the interval at which subchannel busy time is measured. Note that this definition may necessitate a separate CS mechanism for each subchannel.

[0096] In some embodiments, the definition of subchannel utilization may be associated with usage statistics for preamble puncturing. For example, Subchannel utilization rate = (Subchannel puncturing time) / (Subchannel busy time)

[0097] The subchannel puncturing time is defined as being in microseconds, during which the CS mechanism indicates a channel busy state and the subchannel is punctured.

[0098] The subchannel utilization element 400 shown in Figure 4 can be used to indicate whether the subchannel is being utilized appropriately. This information can be used for MAP adjustment (e.g., C-OFDMA).

[0099] In another embodiment, an AP may exchange AP buffer status reports with bursty traffic. Since APs may need to exchange bursty buffer statuses with each other, APs that can acquire the medium can share transmission opportunities with other APs. Alternatively, multiple APs can coordinate to appropriately share service periods or transmission opportunities.

[0100] Figure 5 is a signal flow diagram 500 illustrating two exemplary schemes (510, 520) that can be used in various ways to enable APs or other devices (e.g., AP502, 504, 506) to exchange buffer status information with each other.

[0101] An AP can set the AP BSR Support subfield within the UHR / EHT+Capabilities element if it supports sending and receiving BSRP and BSR frames, and it sends 1.

[0102] In Scheme 1 510 (illustrated in Figure 5), an AP (e.g., AP1 502) can acquire the medium and is considered a shared AP. AP1 502 can identify one or more APs 504, 506 within the same MAP group and determine what kind of buffered traffic they may have.

[0103] For example, in some embodiments, a shared AP (AP1) may send an AP Buffer Status Report Pole (AP BSRP) frame 512 (or any other type of frame) to one or more APs in the MAP group (AP2 and AP3 in this example) to request the shared AP to report the AP buffer status or AP traffic load status. In one exemplary embodiment, the AP BSRP frame may be a trigger frame that can trigger concurrent responses (Buffer Status Reports (BSRs) 514, 516) from AP2 and AP3. The shared AP (AP1) may send the frame (e.g., the BSRP trigger frame) using a non-HT duplicate PPDU so that it can be repeated every 20MHz subchannel. In the AP BSRP frame, AP1 may show some or all of the following information: • AP BSRP can include a trigger type subfield within the trigger frame's common information field to indicate that the trigger frame is AP BSRP, and • AP BSRP may include one or more user information fields. The user information fields in the trigger frame may have the format shown in Figure 6. Some subfields may have modified meanings.

[0104] Referring to Figure 6, an exemplary embodiment of the user information field 600 of the AP BSRP trigger frame is shown. The AID12 / AP ID subfield can uniquely identify an STA or AP within the service set operated by the MAP group. In many embodiments, the AP ID can be within a predetermined range (e.g., the ranges currently reserved in 802.11ax, 2008 to 2044 or 2047 to 4094). The AP ID may be assigned or selected when the AP joins or starts a MAP group.

[0105] The RU allocation subfield and PS160 subfield of the user information field in an AP BSRP trigger frame may be used to indicate the RU / MRU assigned to the STA to send a trigger-based PPDU. Here, the resource is allocated from the sharing AP (e.g., AP1) to the shared APs (e.g., AP2 or AP3). AP1, AP2, and AP3 may have different operating channel widths, primary channels, and punctured channels. Therefore, the same RU allocation subfield and PS160 subfield sent from different APs may point to different RUs. In some embodiments, each AP in a MAP group may know the operating channel widths, primary channels, and punctured channels of the other APs. When a sharing AP sends a trigger frame to one or more APs in a MAP group, the RU allocation subfield and PS160 subfield may correspond to the channel width, primary channel, and punctured channel of the sending AP. The sharing AP may allocate an RU / subchannel to the shared AP if the shared AP can send or receive on the allocated RU / subchannel. A shared AP can use the operating channel width, primary channel position, and punctured channel of the shared AP to position the RU / subchannel assigned by the shared AP via the RU allocation subfield and PS160 subfield in the trigger frame. In another embodiment, when the intended receiver of the trigger frame is an AP, the responding PPDU may be transmitted over the RU in units of 20 MHz. The RU allocation subfield and PS160 subfield may be redesigned to allocate each intended shared AP to one or more 20 MHz subchannels. For example, when the RU allocation subfield is set to a value from 0 to n1-1, it indicates 20 MHz subchannels from the lowest frequency to the highest frequency. If the maximum supported bandwidth is 320 MHz, n1 may be set to 16 or 8 (when the PS160 subfield is used together with the RU allocation subfield to identify the RU).The RU allocation subfields set to values ​​from n1 to n2-1 can represent non-overlapping 40MHz subchannels from the lowest frequency to the highest frequency, and so on. In some embodiments, shared APs are encouraged to allocate their primary 20MHz subchannels if possible.

[0106] The trigger-dependent user information subfield of the user information field in the AP BSRP trigger frame shown in Figure 6 can indicate what type of buffer status the sharing AP is requesting. For example, a sharing AP might request the sharing AP to report the total buffer status, or the buffer status for low-latency traffic, or one or more buffer statuses such as TID or AC. The sharing AP may also include a delay duration field. The sharing AP might be requested to report the buffer size that needs to be sent within the delay duration. Note that while the trigger-dependent user information subfield is used here as an example to carry BSR type information, it may also be sent in other subfields / fields.

[0107] Note that, as described here, trigger frames carry AP BSRPs sent by shared APs, for example. The information mentioned above may be carried by other frames, fields, or elements.

[0108] Returning to Figure 5, upon receiving AP BSRP frame 512, AP2 504 and AP3 506 may respond with AP BSR frames / fields / elements 514, 516. The BSR frames / fields / elements may be carried in a trigger-based (TB) PPDU on the assigned RU. Alternatively, if the assigned RU can occupy all subchannels, the BSR frames / fields / elements may be carried in a non-HT PPDU or a UHR / UHR+PPDU. UHR+PPDU may refer to any future generation of PPDU. An exemplary design of an AP BSR frame / field / element may include one or more of the following information: Delay duration: Indicates the duration of time during which the AP may be required to complete the transmission of the reported buffered data. Total queue size: All AC / TIDs for all STAs indicate the amount of traffic to be sent within the duration identified by the delay time subfield.

[0109] In another embodiment, referring further to Figure 5, “Scheme 2” 520 illustrates an embodiment using individual BSRP trigger frames. An AP (e.g., AP1 502) can acquire the medium and is considered a shared AP. AP1 502 can determine what kind of buffered traffic one or more APs 504, 506 within the same MAP group may have. This scheme allows AP1 to continuously check the buffer status of the shared APs.

[0110] A shared AP (e.g., AP1 502) can transmit BSRP frames / fields / elements 522, 526 to shared APs 504, 506 (e.g., AP2 / AP3) to request BSRs 524, 528. The transmission of BSRP frames / fields / elements 522, 526 is encoded and modulated on a 20MHz subchannel and can be repeated on the remainder of the 20MHz subchannel within AP1 502's operating bandwidth. For example, BSRP frames / fields / elements 522, 526 may be carried in a non-HT overlapping PPDU. Alternatively, the transmission of BSRP frames / fields / elements 522, 526 may be carried on overlapping subchannels of AP1 502 and AP2 / AP3's operating channels. BSRP frames / fields / elements 522, 526 can carry information such as: AP ID / AP Address: This field uniquely identifies the receiving / shared AP504, 506 (e.g., AP2 / AP3) within the MAP group. Requested Buffer Type: This can indicate what kind of buffer the shared AP502 is requesting. For example, a shared AP might request each shared AP to report the buffer status for low-latency traffic. It could then request the AP to report the total buffer size that may need to be completed within the delay period. In this example, the shared AP might include a delay duration subfield and a buffer size subfield. Note that multiple requested buffer types may be requested by the shared AP. If one type is shown / included, the corresponding bitmap or subfields listed below may exist. Thus, the type display serves as a current display of several subfields. Total buffer size: This can indicate that the total buffer size of the shared APs (e.g., AP2 / AP3) is being requested. Buffer size per TID / AC: This can indicate that the buffer size per TID / AC for shared APs (e.g., AP2 / AP3) is being requested. Total buffer size during delay duration: This can indicate that the total buffer size during the delay duration of the shared APs (e.g., AP2 / AP3) is being requested. Buffer size per TID / AC within the delay duration: This can indicate that the total buffer size per TID or AC within the delay duration of the shared APs (e.g., AP2 / AP3) is being requested. Aggregated Estimated UL Buffer Status: This can indicate the aggregated UL buffer status that a shared AP can estimate. For example, a shared AP can receive BSR, QoS characteristic elements, SCS descriptor elements, etc., from non-AP STAs to indicate the traffic / buffer status of each STA. The shared AP can aggregate this information and create this aggregated estimated UL buffer status report. In one method, the aggregation may be per TID / AC / SCS. In another method, the aggregation may be per TID / AC / SCS within the time period during which buffered traffic may need to be delivered. Delay duration / limit: This can indicate the period during which the shared AP is required to report the buffer status. Access Category Bitmap: This can indicate the requested access code (AC) for the buffer status. In one case, the AC is requested using a format other than a bitmap. TID Bitmap: This can indicate the TID for which the buffer status is requested. In one case, the TID is requested using a format other than a bitmap. Buffer size unit: This can indicate the buffer size in units, for example, in octets, i.e., 256 octets, 2048 octets, etc.

[0111] Referring further to Scheme 2 520 shown in Figure 5, a shared AP (e.g., AP2 / AP3) can transmit BSR frames / fields / elements 524, 526 to a shared AP 502 (e.g., AP1) to report its buffer status. The transmission of BSR frames / fields / elements 524, 526 is encoded and modulated on a 20MHz subchannel and can be repeated on the remainder of the 20MHz subchannel within the overlapping operating channels of the shared AP and the sharing APs. For example, BSR frames / fields / elements may be carried in a non-HT overlapping PPDU. BSR fields may be carried in the MAC header. BSR frames / fields / elements may be aggregated with other frames / fields / elements and carried in the MAC body. BSR frames / fields / elements can carry information such as: AP ID / AP Address: This field uniquely identifies the reporting / shared AP (e.g., AP2 / AP3) within the MAP group. Reported buffer type: This can indicate what type of buffer status the shared AP is reporting. An example requested buffer type may include the information identified in paragraphs

[0123] through

[0130] below. Total buffer size: This indicates that the total buffer size of the shared APs (e.g., AP2 / AP3) is reported. Buffer size per TID / AC: This may indicate that the total buffer size per TID or AC for shared APs (e.g., AP2 / AP3) is reported. Total buffer size during delay duration: This indicates that the total buffer size during the delay duration of shared APs (e.g., AP2 / AP3) is reported. Buffer size per TID / AC within the delay duration: This may indicate that the total buffer size per TID or AC within the delay duration of shared APs (e.g., AP2 / AP3) is reported. Delay duration / limit: This can indicate the period during which the shared AP is reporting the buffer status. Access Category Bitmap: This can indicate the Access Control (AC) from which the buffer status is reported. In one case, the AC is requested using a format other than a bitmap. TID Bitmap: This can indicate the TID from which the buffer status is reported. In one case, the TID is requested using a format other than a bitmap. Buffer size unit: This can indicate the buffer size in units, for example, in octets, i.e., 256 octets, 2048 octets, etc.

[0112] Figure 8 is a flowchart illustrating an embodiment of method 800 for exchanging traffic state information between APs within a MAP group. In 802, the first AP or a shared AP can determine whether traffic information should be exchanged or is required by other APs in the MAP group. This can be done periodically (e.g., every n microseconds, n minutes, or any other arbitrary interval), based on transmission intervals (e.g., every TWT service period, every other TWT service period, etc.), or dynamically as needed (e.g., due to detecting changing channel states, when an AP joins or leaves the MAP, when a new device is detected, in response to a request from another AP, etc.).

[0113] As discussed above, different schemes (concurrent polling or broadcast polling, and sequential polling) may be used. In some embodiments, only one scheme may be used. In other embodiments, the AP may be able to dynamically select between concurrent polling and sequential polling. Thus, in 804, the AP may, in some embodiments, determine which scheme is in use, or the scheme may be pre-configured and step 804 may be omitted (or rather, implicit due to the use of a pre-configured scheme).

[0114] If simultaneous polling (Scheme 1) is in use, on 806, the AP may send a traffic or buffer status report pole frame. The BSRP frame may contain any of the features or elements discussed above, including the AP identifier, RU allocation, coding type, received power, trigger-dependent user information, an optional field or type indicator, or any other type and form of information. The BSRP frame may be sent to all other APs in the MAP group.

[0115] In 808, the AP can receive a buffer status report frame from the second AP (or the first shared AP) in the MAP group. The BSR frame may contain any of the features or elements discussed above, such as buffer size or allocation, access category, delay limit or duration information.

[0116] In 810, the AP can determine if there are other APs in the MAP group that have not responded. If so, 808–810 may be repeated as other BSR frames are received. In some embodiments, 810 may be implicit, and the AP may wait for a predetermined polling time for report frames to be received from other APs. Once the polling time has expired, or when all other reports have been received, the AP may process the received information and repeat 802–810 as needed, or periodically as discussed above.

[0117] In sequential polling operation or scheme 2, 812, an AP can select a shared AP within a MAP group. The selection of other APs can be random, in order according to a list of identifiers, in the order in which the shared APs joined the MAP group (e.g., IDs are added to the ordering list as each AP joins or leaves), in order from the oldest report to the newest (e.g., if the first shared AP has not provided a BSR frame n times and the second shared AP has not provided a BSR frame m times, and n > m, the AP can select the first shared AP for the first poll, which can be useful when only a very small number of reports may be received within the polling time), or in any other arbitrary type and form of order or selection.

[0118] In 814, an AP can transmit a traffic or buffer status report pole frame. A BSRP frame may contain any of the features or elements discussed above, and may include the identifier of the selected shared AP, as well as RU allocation, coding type, received power, trigger-dependent user information, option fields or type indicators, or any other type and form of information. In some embodiments (e.g., 20MHz subchannels in overlapping channels), a BSRP frame may be transmitted using a shared subchannel or overlapping subchannel between the sharing AP and the shared AP.

[0119] In 816, an AP can receive a buffer status report frame from a selected AP. The BSR frame may contain any of the features or elements discussed above, including buffer size or allocation, access category, delay limit or duration information, etc.

[0120] In step 818, the AP can determine if there are any other APs in the MAP group that have not been polled, and / or if there is enough time remaining in the service period to poll those other APs. If so, steps 812-816 may be repeated once or multiple times.

[0121] In an alternative embodiment of Scheme 2, multiple iterations of 812-816 may occur simultaneously or quasi-simultaneously. That is, in such an embodiment, a first shared AP may be selected at 812, and a BSRP frame may be sent to the selected AP at 814. 816 may be temporarily skipped, and 812 and 814 may be repeated for a second shared AP. Next, 816 may be performed when a BSR frame has been received from both the first and second shared APs. This may be useful in embodiments where there is a significant delay (e.g., due to processing or measurement at the shared AP) between the transmission of a BSRP frame and the reception of the corresponding BSR frame, allowing additional BSRP frames to be transmitted between transmission and reception.

[0122] In another embodiment, the disclosure covers enhanced UORA transmissions. In some embodiments, a TWT / rTWT schedule that may require membership may include enhanced uplink orthogonal frequency division multiplexing access (OFDMA) based random access (UORA) transmissions. A TWT / rTWT schedule in which the broadcast TWT ID subfield is set to a value greater than 0 may include enhanced UORA transmissions.

[0123] A TWT SP with one or more RA-RUs is a TWT SP corresponding to a broadcast TWT parameter set field within a TWT element that has a broadcast TWT ID subfield equal to 0 or other value, a flow type subfield equal to 0, a trigger subfield equal to 1, and a broadcast TWT recommendation subfield equal to 2. An associated non-AP STA supporting TWT and the Extended UORA procedure may enter a dozed state when it receives a beacon frame from its associated AP carrying a TWT element indicating the schedule of a TWT SP with RA-RUs, unless other conditions require it to become awake. The STA can transition to an awake state at the start of a TWT SP with RA-RUs and follow the Extended UORA procedure.

[0124] The conventional UORA procedure may allow all non-AP STAs to access their assigned RA-RU. In contrast, the extended UORA procedure may allow groups of non-AP STAs to compete for their assigned RA-RU. The trigger frame for extended UORA transmission may be modified to enable this functionality.

[0125] Figure 7 shows a portion of a signal flow diagram illustrating examples of conventional UORA and extended UORA in the TWT described herein (non-AP STAs are not shown). AP702 can transmit a beacon frame 704 that can carry a TWT parameter set 706 (e.g., in the header and / or payload). The TWT parameter set 706 can contain one or more TWT elements 708. In this example, it can contain at least two TWT elements 708.

[0126] The first TWT element 708 may be a conventional TWT element that can be configured or set to have a broadcast TWT ID subfield of 0, a flow type subfield of 0, a trigger subfield of 1, and a broadcast TWT recommendation subfield of 2. These subfields indicate that the TWT SP includes at least one RA-RU allocation that can be made accessible to all non-AP STAs during the TWT SP period 710 (e.g., a UORA available to all non-AP STAs). Note that the signaling combinations within the TWT element disclosed herein may be considered examples of how the TWT SP includes an RA-RU allocation that can be made accessible to all non-AP STAs during the TWT SP. Other signaling combinations may also be possible.

[0127] The second TWT element 708 may be an extended TWT element according to the described embodiment, where the broadcast TWT ID subfield can be set to a value greater than 0, the flow type subfield to 0, the trigger subfield to 1, and the broadcast TWT recommendation subfield to 2. These subfields indicate that the TWT SP period 712 contains at least one RA-RU allocation that may enable a group of non-AP STAs to access what is called an extended UORA trigger procedure, which may be used in the TWT SP(s) 712. Note that the signaling combinations within the TWT elements disclosed herein may be considered examples of how the TWT SP contains an extended UORA trigger procedure. Other signaling combinations may also be possible. In some embodiments, the subfield combinations may indicate which RA-RU allocations a non-AP STA with membership in the TWT is enabled to access. In other embodiments, the subfield combinations may indicate which RA-RU allocations are allocated by an extended trigger frame, and the trigger frame may indicate which group of non-AP STAs is enabled to access the RA-RU.

[0128] An extended trigger frame can carry one or more of the following information: Trigger Version: This subfield may be carried in the Common Information field to indicate the version of the trigger frame. For example, this could be an HE trigger frame, an EHT trigger frame, or an extended trigger frame for future generations of the 802.11 protocol. In some embodiments, the PHY Version Identifier subfield of the Special User Information field in the trigger frame may be set to a value to indicate that it is an extended trigger frame. In some embodiments, one or more values ​​currently reserved for the Trigger Type subfield of the Common Information field in the trigger frame may be used to indicate that the trigger frame may be an extended trigger frame. In some embodiments, one or more bits, or a combination of bits, in the U-SIG Ignore and Validate subfields of the Special User Information field in the trigger frame may indicate an extended trigger frame. In some embodiments, an Extended Special User Information field may be defined. The Extended Special User Information field may be identified by a special value set in the AID12 subfield. For example, when the AID12 subfield is set to 2008 (or in the range of 2008 to 2044), the trigger frame may contain extended trigger information.

[0129] The AID12 subfield of the extended user information field in the trigger frame may be set to a special value (e.g., a value now reserved in 11be) to indicate that the RA-RU assigned to the user information field is for the extended UORA. For example, the special value of the AID12 subfield may be in the range of 2008 to 2044. In some embodiments, the AID12 subfield may be set to a value of 1 to indicate that the RA-RU assigned by the trigger frame may be used to transmit low-latency traffic by any associated STA, including R-TWT member STAs or non-member STAs. In some embodiments, if the extended trigger frame is transmitted within an R-TWT SP, the low-latency traffic may be identified by the R-TWT DL / UL TID. In some embodiments, the AID12 subfield may be set to a value of 2 to indicate that the RA-RU assigned by the trigger frame may be used to transmit low-latency traffic by an R-TWT member STA. In some embodiments, the AID12 subfield may be set to a value of 3 to indicate that the RA-RU assigned by the trigger frame may be used to transmit any traffic by any associated STA, including R-TWT member STAs or non-member STAs. In some embodiments, the AID12 subfield may be set to a value of 4 to indicate that the RA-RU assigned by the trigger frame may be used to transmit any traffic by R-TWT member STAs. In some embodiments, a predefined range of AIDs may indicate a group of STAs. For example, AID12 values ​​2008-2016 may be reserved for group AIDs used in extended trigger frames. If a group AID is identified in the user information field within an extended trigger frame, the corresponding group of STAs may be able to transmit uplinks with their assigned RUs. Since multiple STAs may be in a group, each STA may be able to perform UORA channel access. STAs with similar requirements or characteristics may be assigned to the group identified by the group AID.For example, STAs with uplink low-latency traffic may be assigned to a group. For example, STAs with uplink low-latency traffic having similar latency limits or latency requirements may be assigned to a group. An AP can assign a group AID to an STA by sending individually addressed frames to that STA. The AP can then use the group AID to trigger UORA transmissions from any STA in the group. This method may be used in conjunction with the R-TWT / TWT procedure or independently outside of the R-TWT / TWT SP. While latency limits may be used as a measurement in this example, other latency-related measurements may also be used herein (e.g., round-trip time, processing latency, etc.). In some embodiments, several AID12 values ​​may be used to indicate the priority or urgency of low-latency traffic. For example, there may be a predefined table for mapping AID12 values ​​to latency limits. If the AID12 value is 1, STAs whose latency limit is less than or equal to the corresponding latency limit value of 1 in the table may be made able to access the RA-RU assigned in the user information field, and so on. In this way, the AP can further classify low-latency traffic with finer resolution. UORA Trigger Group: This subfield can be carried elsewhere in the trigger-dependent user information subfield or extended user information field within the trigger frame, or elsewhere within the trigger frame. Several example UORA trigger group value settings are given below: Value 1: Supports Extended UORA and is a member of TWT / rTWT, allowing non-AP STA access. Value 2: Supports Extended UORA and is associated with AP, allowing all non-APSTA users to access it. Value 3: Supports Extended UORA, allowing all non-APSTA devices to access it. Non-APSTA devices do not necessarily need to be associated with AP. Value 4: Supports Extended UORA, is a member of TWT / rTWT, and allows non-APSTA access to latency-sensitive traffic. Value 5: Supports Extended UORA, is associated with an AP, and allows access from all non-APSTA devices with latency-sensitive traffic. Value 6: Supports Extended UORA and allows access to all non-APSTA devices with latency-sensitive traffic. Non-APSTA devices do not necessarily have to be associated with an AP. Value 7: Supports Extended UORA, allowing all APs or all APs within a MAP group to access it. In one case, when this value is set, non-APSTA may not be able to access RA-RU. Value 8: Enables all STAs with a specific QoS class level to which they may be determined to be present during the coupling and / or negotiation process in BSS. QoS levels can be classified by latency requirements, power consumption levels over time, and data transfer rate limits.

[0130] In some embodiments, several UORA trigger group values ​​may be used to indicate the priority or urgency of low-latency traffic. For example, there may be a predefined table for mapping UORA trigger group values ​​to latency limits. If the UORA trigger group value is 1, STAs whose latency limit is less than or equal to the corresponding latency limit value of 1 in the table may be allowed to access the RA-RU assigned in the user information field, and so on. In this way, the AP can further classify low-latency traffic with finer resolution. Note that while latency limits are used as a metric in this example, other latency-related metrics may also be used in this specification.

[0131] In some embodiments, UORA trigger groups may be identified using the AID12 subfield. Predefined AID12 values ​​may be reserved in various embodiments to identify UORA trigger group information.

[0132] STAs and APs that support extended trigger frames and trigger-based transmissions can indicate their capabilities in their capability elements. Similarly, STAs and APs that support extended UORA transmissions can indicate their capabilities in their capability elements.

[0133] In another embodiment, random access (RA) transmission is enabled in the R-TWT. STAs and APs that support random access transmission in the R-TWT can indicate their capability with a capability element.

[0134] In some embodiments, the AP can announce a broadcast TWT or R-TWT and can also indicate a TWT / R-TWT SP that allows non-AP STAs (e.g., STAs associated with the AP, STAs that have established membership with the TWT / R-TWT) to perform random access (either CSMA / CA access or UORA access). Based on this information, a TWT / R-TWT member STA or non-member STA can choose to remain awake during the TWT / R-TWT SP and compete for a channel.

[0135] In some embodiments for carrying this out, the broadcast TWT recommendation subfield may be reused. When the STA is negotiating a TWT with the AP, the broadcast TWT recommendation subfield may be set to 4 to indicate that the TWT being negotiated is an R-TWT. If the R-TWT setup is successful, an R-TWT ID may be assigned to uniquely identify that R-TWT.

[0136] When an AP corresponding to a transmitted BSSID advertises its own BSS R-TWT schedule, it can follow this procedure: Firstly, the broadcast TWT ID subfield may be set to R-TWT ID, so that the member STA knows that this is an R-TWT SP. Secondly, the broadcast TWT recommendation subfield may be set to 2 to indicate that R-TWT / TWT can encompass RA-RU. This allows non-member STAs to know the potential RA-RU allocations available in TWT / R-TWT. Thirdly, the limited TWT schedule information field may be set to a value of 0, 1, or 2 to indicate that the R-TWT scheduling AP is the AP corresponding to the transmitted BSSID. Fourth, the trigger subfield may be set to 1 to indicate that the TWT is trigger-enabled.

[0137] When an AP corresponding to a transmitted BSSID advertises an R-TWT schedule for an untransmitted BSSID within the same set of multiple BSSIDs, the TWT element can be carried within and outside of multiple BSSID elements. The following rules may apply:

[0138] First, when a TWT element is transported outside of a BSSID element, the following fields / subfields may be set based on the rules below: The Broadcast TWT ID subfield may be set to a value of 31 to indicate that the TWT element corresponds to a non-transmitted BSSID. The Broadcast TWT Recommendation subfield may be set to a value of 2 to indicate that the R-TWT / TWT may contain RA-RUs. This allows non-member STAs to know about the potential RA-RU allocations available in the TWT / R-TWT. The Limited TWT Schedule Information field may be set to a value of 3 to indicate that the R-TWT scheduling AP is the AP corresponding to a non-transmitted BSSID. The Trigger subfield may be set to a value of 1 to indicate that the TWT is trigger-enabled. A combination of one or more of the above fields / subfields may be used to identify that the corresponding TWT is an R-TWT.

[0139] When a TWT element is carried inside a BSSID element, the following fields / subfields may be set based on the rules below: The Broadcast TWT ID subfield may be set to R-TWT ID so that member STAs know that this is an R-TWT SP. The Broadcast TWT Recommendation subfield may be set to 2 to indicate that the R-TWT / TWT may contain RA-RUs. This allows non-member STAs to know the potential RA-RU allocations available in the TWT / R-TWT. The Limited TWT Schedule Information field may be set to a value of 0, 1, or 2 to indicate that the R-TWT scheduling AP is the AP corresponding to the transmitted BSSID. The Trigger subfield may be set to 1 to indicate that the TWT is trigger enabled.

[0140] Regarding the members of an R-TWT, they can use an R-TWT ID to identify the R-TWT.

[0141] For STAs that support UORA transmission in R-TWT, upon receiving a TWT element, they may consider it an R-TWT. The STA can recognize that RA-RU / UORA transmission is available in R-TWT. If the STA has uplink traffic, it may be ready to transmit in R-TWT SP if a UORA trigger frame or extended UORA trigger frame is received. Otherwise, the STA may choose to switch to power-saving mode during R-TWT SP. Note that the STA may follow R-TWT rules to terminate its transmission or TXOP before R-TWT SP.

[0142] For legacy STAs that do not support UORA transmission in R-TWTs, upon receiving a TWT element, the legacy STA will treat it as a regular TWT rather than an R-TWT. The legacy STA can recognize that RA-RU / UORA transmission is available in the TWT. If the legacy STA has uplink traffic, it can prepare to transmit in the TWT SP if a UORA trigger frame or extended UORA trigger frame is received. Otherwise, the legacy STA can choose to switch to power-saving mode during the TWT SP. Note that since the legacy STA cannot recognize that this is an R-TWT SP, it does not need to follow R-TWT rules to terminate its transmission or TXOP before the R-TWT SP.

[0143] By using this method, legacy STAs can participate in RA-RU / UORA transmissions within R-TWTs, as they can interpret R-TWTs as regular TWTs.

[0144] The disclosed embodiments focus on enabling UORA transmission in an R-TWT. However, it can be extended to enable random access transmission in an R-TWT, where random access transmission includes UORA transmission and conventional CSMA / CA channel access transmission. In one method, the broadcast TWT recommendation subfield may be set to 2 to indicate that the R-TWT / TWT may include RA-RU or random access transmission.

[0145] In another embodiment, a new field / subfield may be used to enable RA transmission in the R-TWT. In this embodiment, the new field / subfield, or a reserved value of an existing field / subfield, may be used to indicate that the TWT is an R-TWT with RA-RU / UORA / random access transmission. Here, random access transmission may refer to a general random access scheme that includes UORA / RA-RU transmission and conventional CSMA / CA access.

[0146] In some embodiments, as shown in Table 5, one reserved value in the broadcast TWT recommendation field (value 5 in the example) may be used to indicate an R-TWT with RA-RU / UORA / random access transmissions.

[0147] [Table 5]

[0148] When an AP configures or announces an R-TWT that has UORA / Random Access transmissions, the AP may set the Broadcast TWT Recommendation field to value 5. Members of the R-TWT may be configured to accept values ​​indicating that RA-RU / UORA / Random Access transmissions are enabled or allowed.

[0149] For STAs that can support UORA / random access transmissions in an R-TWT but are not members of an R-TWT, upon receiving a TWT element, they may consider that TWT to be an R-TWT with UORA / random access opportunities. These STAs can recognize that RA-RU / UORA / random access transmissions may be available in an R-TWT. If an STA has uplink traffic, it may be ready to transmit in an R-TWT SP if a UORA trigger frame or an extended UORA trigger frame is transmitted, or if conventional CSMA / CA access is enabled. Otherwise, the STA may choose to switch to power-saving mode during the R-TWT SP. Note that the STA may follow R-TWT rules to terminate its transmission or TXOP before the R-TWT SP.

[0150] Legacy STAs that do not support UORA / Random Access transmission in R-TWT cannot understand the values ​​of the Broadcast TWT Recommended fields and therefore cannot participate in UORA transmission within R-TWT. By using this method, extended STAs that understand the new signaling have more opportunities to participate in UORA / Random Access transmission compared to legacy STAs.

[0151] In a trigger-enabled R-TWT SP, an R-TWT scheduling AP can first trigger member R-TWT scheduled STAs to facilitate their transmission of their QoS data frames for the R-TWT DL / UL TID. The AP can then send a trigger frame or an extended trigger frame with an RA-RU to request a response from any STA associated with the AP or AP / MLD, or from APs located at the same location as the R-TWT scheduling AP, if they have UL traffic or UL QoS traffic corresponding to the UL TID.

[0152] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as ROM, RAM, registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). A software-associated processor may be used to implement a high-frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. The first access point (AP) sends a buffered status report pole frame to one or more APs in a group of multiple APs (MAPs), The first AP receives buffer status reports from each of the one or more APs in the MAP group, A method that includes this.

2. The method according to claim 1, wherein the first AP shares a transmission opportunity with one or more APs in the MAP group using the received buffer status report.

3. The method according to claim 1 or claim 2, wherein the buffer status report includes AP identifier (ID) information.

4. The method according to any one of claims 1 to 3, wherein the buffer status report includes buffer type information, total buffer size information, buffer size information for each access category, total buffer size information during the delay period, buffer size information for each access category during the delay period, or buffer size unit information.

5. The method according to any one of claims 1 to 4, wherein the buffer status report includes delay limit information.

6. The method according to any one of claims 1 to 5, wherein the buffer status report includes an access category bitmap or a traffic identifier (TID) bitmap.

7. The buffer status report pole frame is a first buffer status report pole frame, the buffer status report is a first buffer status report received from a second AP of the MAP group, and the method is The first AP transmits a second buffer status report pole frame to the third AP of the MAP group. The first AP receives the second buffer status report from the third AP, The method according to any one of claims 1 to 6, further comprising:

8. The method according to claim 7, wherein the first buffer status report pole frame is transmitted on a first 20 MHz subchannel within the overlapping operating channels of the first AP and the second AP.

9. The method according to claim 8, wherein the second buffer status report pole frame is transmitted on a second 20 MHz subchannel within the overlapping operating channels of the first AP and the third AP.

10. The method according to claim 7, wherein the first buffer status report pole frame includes an identifier for a second AP, and the second buffer status report pole frame includes an identifier for a third AP.

11. An access point (AP), One or more transmitters configured to send buffered status report pole frames to one or more APs in a multi-AP (MAP) group, One or more receivers configured to receive buffer status reports from each of the one or more APs in the MAP group, AP is equipped.

12. The AP according to claim 11, further comprising one or more processors configured to share transmission opportunities with one or more APs of the MAP group using the received buffer status report.

13. The buffer status report includes AP identifier (ID) information, according to claim 11 or claim 12.

14. The AP according to any one of claims 11 to 13, wherein the buffer status report includes buffer type information, total buffer size information, buffer size information for each access category, total buffer size information during the delay period, buffer size information for each access category during the delay period, or buffer size unit information.

15. The AP according to any one of claims 11 to 14, wherein the buffer status report includes delay limit information.

16. The AP according to any one of claims 11 to 15, wherein the buffer status report includes an access category bitmap or a traffic identifier (TID) bitmap.

17. The buffer status report pole frame is a first buffer status report pole frame, and the buffer status report is a first buffer status report received from the second AP of the MAP group. The one or more transmitters are further configured to transmit a second buffered status report pole frame to the third AP of the MAP group. The one or more receivers are further configured to receive a second buffer status report from the third AP. AP according to any one of claims 11 to 16.

18. The AP according to claim 17, wherein the first buffer status report pole frame is transmitted on a first 20 MHz subchannel within the overlapping operating channels of the AP and the second AP.

19. The AP according to claim 18, wherein the second buffer status report pole frame is transmitted on a second 20 MHz subchannel within the overlapping operating channels of the AP and the third AP.

20. The AP according to claim 19, wherein the first buffer status report pole frame includes an identifier for a second AP, and the second buffer status report pole frame includes an identifier for a third AP.

Images