[go: up one dir, main page]

WO2024206387A1 - Procédés d'échange d'état de trafic multi-ap et conception d'uora améliorée - Google Patents

Procédés d'échange d'état de trafic multi-ap et conception d'uora améliorée Download PDF

Info

Publication number
WO2024206387A1
WO2024206387A1 PCT/US2024/021606 US2024021606W WO2024206387A1 WO 2024206387 A1 WO2024206387 A1 WO 2024206387A1 US 2024021606 W US2024021606 W US 2024021606W WO 2024206387 A1 WO2024206387 A1 WO 2024206387A1
Authority
WO
WIPO (PCT)
Prior art keywords
status report
twt
buffer status
buffer
stas
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/021606
Other languages
English (en)
Inventor
Hanqing Lou
Zinan Lin
Rui Yang
Xiaofei Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of WO2024206387A1 publication Critical patent/WO2024206387A1/fr
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports

Definitions

  • Coordinated multi-access point (AP) transmissions may be used to increase spectrum efficiency and reduce latency.
  • each AP may need to know the buffer and/or traffic status of other APs so that they may coordinate with each other.
  • conventional mechanisms to request and report buffer and/or traffic status between APs may be inadequate for this function.
  • target wake time (TWT) operations may be used to allow APs and their associated stations (STAs) to negotiate wake-up time periods during which the STAs may transmit and receive traffic, allowing for “doze” or reduced power states between such time periods.
  • TWT target wake time
  • STAs stations
  • a trigger frame is used to schedule the uplink transmission. If a TWT member STA has low latency traffic, it may have to wait for the AP to transmit a trigger frame to schedule its UL transmission, adding delays and potentially violating quality of service (QoS) requirements for the low latency traffic.
  • QoS quality of service
  • FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented
  • FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG 1A according to an embodiment;
  • WTRU wireless transmit/receive unit
  • FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;
  • RAN radio access network
  • CN core network
  • FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG 1A according to an embodiment
  • FIG. 2 is a diagram of an example of individual TWT operation described in 802.11ax, according to some implementations;
  • FIG. 3 is a diagram of an example of broadcast TWT operation with optional TBTT negotiation described in 802.11 ax, according to some implementations;
  • FIG. 4 shows a Subchannel Utilization element format, according to some implementations
  • FIG. 5 is a signal flow diagram showing two schemes for APs to exchange buffer status information, according to some implementations.
  • FIG. 6 shows an exemplary User Info field format for use in an AP BSRP Trigger frame, according to some implementations
  • FIG. 7 is a diagram showing an example of traditional and enhanced UORA in TWT, according to some implementations.
  • FIG. 8 is a flow chart of an embodiment of a method for exchanging traffic status information amongst APs in a MAP group.
  • Table 1 is a non-exhaustive list of acronyms that may be used herein.
  • FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA singlecarrier FDMA
  • ZT-UW-DFT-S- OFDM zero-tail unique-word discrete Fourier transform Spread OFDM
  • UW-OFDM unique word OFDM
  • FBMC filter bank multicarrier
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs wireless transmit/receive units
  • RAN radio access network
  • ON core network
  • PSTN public switched telephone network
  • Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and
  • UE user equipment
  • PDA personal digital assistant
  • HMD head-
  • the communications systems 100 may also include a base station 114a and/or a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or the other networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum
  • a cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • beamforming may be used to transmit and/or receive signals in desired spatial directions.
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • LTE-A Pro LTE-Advanced Pro
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g , an eNB and a gNB).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.11 i.e., Wireless Fidelity (WiFi)
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 1X, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System
  • the base station 114b in FIG 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the CN 106.
  • the RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like.
  • QoS quality of service
  • the CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT.
  • the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links).
  • the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. 1 B is a system diagram illustrating an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others.
  • GPS global positioning system
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • 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 wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit)
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li- ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like.
  • FM frequency modulated
  • the peripherals 138 may include one or more sensors.
  • the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.
  • the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and/or simultaneous.
  • the full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118).
  • the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e g., for transmission) or the DL (e g., for reception)).
  • a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e g., for transmission) or the DL (e g., for reception)).
  • FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the GN 106.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • MME mobility management entity
  • SGW serving gateway
  • PGW packet data network gateway
  • PGW packet data network gateway
  • the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA
  • the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface.
  • the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • packet-switched networks such as the Internet 110
  • the CN 106 may facilitate communications with other networks
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
  • the other network 112 may be a WLAN.
  • a WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP.
  • the AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS.
  • Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs.
  • Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations.
  • DS Distribution System
  • Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA
  • the traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic.
  • the peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS).
  • the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems.
  • the STAs e.g., every STA, including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off.
  • One STA (e.g., only one station) may transmit at any given time in a given BSS.
  • High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels
  • the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels.
  • a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
  • the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
  • IFFT Inverse Fast Fourier Transform
  • time domain processing may be done on each stream separately
  • the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA.
  • the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
  • MAC Medium Access Control
  • Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah.
  • the channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11ah relative to those used in 802.11n, and 802.11ac.
  • 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum
  • 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum.
  • 802.11 ah may support Meter Type Control/Machine- Type Communications (MTC), such as MTC devices in a macro coverage area.
  • MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g , only support for) certain and/or limited bandwidths
  • the MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
  • WLAN systems which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS.
  • the bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes.
  • Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.
  • STAs e.g., MTC type devices
  • NAV Network Allocation Vector
  • the available frequency bands which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.
  • FIG. 1 D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the CN 106.
  • the RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment.
  • the gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the gNBs 180a, 180b, 180c may implement MIMO technology
  • gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c.
  • the gNB 180a may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • the gNBs 180a, 180b, 180c may implement carrier aggregation technology.
  • the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum.
  • the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology.
  • WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).
  • CoMP Coordinated Multi-Point
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).
  • TTIs subframe or transmission time intervals
  • the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
  • WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band.
  • WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c.
  • WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
  • eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.
  • Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • the CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • SMF Session Management Function
  • the AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node.
  • the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like.
  • PDU protocol data unit
  • Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
  • the AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface.
  • the SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface.
  • the SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
  • the SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like.
  • a PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.
  • the CN 106 may facilitate communications with other networks
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • IMS IP multimedia subsystem
  • the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
  • one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).
  • the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
  • the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
  • the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment.
  • the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network
  • the emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.
  • RF circuitry e.g., which may include one or more antennas
  • 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 or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in and out of the BSS.
  • Traffic to STAs that originates from outside the BSS arrives through the AP and is delivered to the STAs.
  • Traffic originating from STAs to destinations outside the BSS is sent to the AP to be delivered to the respective destinations
  • Traffic between STAs within the BSS may also be sent through the AP where the source STA sends traffic to the AP and the AP delivers the traffic to the destination STA.
  • Such traffic between STAs within a BSS is really peer-to-peer traffic.
  • Such peer-to-peer traffic may also be sent directly between the source and destination STAs with a direct link setup (DLS) using an 802.11e DLS or an 802 11z tunneled DLS (TDLS).
  • DLS direct link setup
  • TDLS 802 11z tunneled DLS
  • a WLAN using an Independent BSS (IBSS) mode has no AP, and/or STAs, communicating directly with each other. This mode of communication is referred to as an “ad-hoc” mode of communication.
  • IBSS Independent BSS
  • the AP may transmit a beacon on a fixed channel, usually the primary channel.
  • This channel may be 20 MHz wide, and is the operating channel of the BSS.
  • This channel is also used by the STAs to establish a connection with the AP.
  • the fundamental channel access mechanism in an 802.11 system is Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA).
  • CSMA/CA Carrier Sense Multiple Access with Collision Avoidance
  • every STA, including the AP will sense the primary channel. If the channel is detected to be busy, the STA backs off. Hence only one STA may transmit at any given time in a given BSS.
  • High Throughput (HT) STAs may also use a 40 MHz wide channel for communication. This is achieved by combining the primary 20 MHz channel, with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and 160 MHz wide channels.
  • the 40 MHz and 80 MHz channels are formed by combining contiguous 20 MHz channels similar to 802.11 n described above.
  • A160 MHz channel may be formed either by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, this may also be referred to as an 80+80 configuration.
  • the data after channel encoding, is passed through a segment parser that divides it into two streams. IFFT, and time domain, processing are done on each stream separately The streams are then mapped on to the two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is sent to the MAC.
  • Sub 1 GHz modes of operation are supported by 802.11 af, and 802.11 ah.
  • the channel operating bandwidths, and carriers, are reduced relative to those used in 802.11n, and 802.11 ac.
  • 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum
  • 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum.
  • a possible use case for 802.11 ah is support for Meter Type Control (MTC) devices in a macro coverage area.
  • MTC devices may have limited capabilities including only support for limited bandwidths, but also include a requirement for a very long battery life.
  • WLAN systems which support multiple channels, and channel widths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which is 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. The bandwidth of the primary channel is therefore limited by the STA, of all ST As operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide if there are STAs (e.g.
  • MTC type devices that only support a 1 MHz mode even if the AP, and other STAs in the BSS, may support a 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes. All carrier sensing, and NAV settings, depend on the status of the primary channel; e.g., if the primary channel is busy, for example, due to a STA supporting only a 1 MHz operating mode is transmitting to the AP, then the entire available frequency bands are considered busy even though majority of it stays idle and available.
  • the available frequency bands which may be used by 802.11 ah are from 902 MHz to 928 MHz. In Korea it is from 917.5 MHz to 923.5 MHz; and in Japan, it is from 916 5 MHz to 9275 MHz.
  • the total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.
  • Target wake time (TWT) operation was originally introduced in 802.11 ah. It was designed to allow an AP and its associated STAs to negotiate a wake-up time period during which the STAs may transmit and receive traffic. 802.11 ax extended the usage of TWT to allow an AP to manage activity in the BSS in order to minimize contention between STAs and reduce the required amount of time that a STA utilizing a power management mode needs to be awake.
  • the TWT element is defined to carry information used to negotiate and advertise TWT related information. TWTs may include broadcast TWTs and unicast or individual TWTs (or device or STA-specific TWTs).
  • a TWT scheduled STA e.g., STA1 204
  • the AP 202 may accept the TWT agreement and transmit a TWT response 210 to notify the STA 1 204 of the agreement.
  • the AP 202 may also, in some implementations, send an unsolicited TWT response 214 to STA2 206 to setup a trigger enabled TWT agreement with STA2.
  • the TWT agreements may specify when the next trigger will occur or next TWT period 218 will begin, and STA 1 204 may enter a doze or low-power state 216 (e.g. disabling a primary transceiver and activating a secondary transceiver; switching a primary receiver to a low power or sleep mode; or otherwise disabling or modifying operations from an active mode to a sleep or doze mode) and STA 2 206 may similarly enter a doze state 220.
  • each STA may maintain the doze state for a specified time based on the TWT responses 210, 214.
  • each STA may monitor or listen on the channel via a low power transceiver or transceiver in a low power mode for a trigger from the AP.
  • the AP 202 may subsequently start a T rigger-enabled TWT service period (SP) 222 with a T rigger frame 224.
  • STA1 204 and STA2206 may respond with a PS-Poll frame 226 and a QoS Null frame 228 respectively to indicate they are awake and ready to communicate with the AP (e.g. including receiving data in a DL MU PPDU 232 from the AP 202 and responding with acknowledgements 234A, 234B; transmitting data (not illustrated), etc.).
  • the STAs may return to a doze state 236A, 236B in some implementations until a subsequently scheduled trigger broadcast.
  • a TWT scheduled STA e.g., STA1 304, may negotiate (process 308) with a TWT scheduling AP 302 for the first wake target Beacon Transmission Time (TBTT) 314 to listen to the Beacon frame, e.g. via TWT request 310 and response 312.
  • TBTT Beacon Transmission Time
  • the STA 304 may then enter a doze state 316A (and either listen for a beacon broadcast via a lower power transceiver or transceiver in a low power mode, or wake up at the designated time by enabling or activating a high power transceiver or high power mode) (STA 2 306 may already be in a doze state 316B).
  • the AP 302 may advertise the broadcast TWT element 322 in the Beacon 320, indicating when the trigger 328 will be sent, and again, the STA (as well as other STAs such as STA 2 306) may enter a doze state 324 until the designated time. Then the AP 302 may start a Trigger- enabled TWT service period (SP) 326. In the TWT SP, one or more STAs may wake up and communicate with the AP (e.g via PS-Polls, nulls, acknowledgements, PPDU transmissions, etc. 330-338B as shown).
  • SP Trigger- enabled TW
  • Restricted TWT (R-TWT, or rTWT) was introduced in 802.11 be.
  • R-TWT is designed to prioritize latency sensitive traffic by including a Restricted TWT Traffic Info field in the broadcast TWT element.
  • the schemes having been 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).
  • Co-OFDMA Coordinated Multi-AP OFDMA
  • Co-TDMA Coordinated Multi-AP TDMA
  • CSR Coordinated Multi-AP Spatial Reuse
  • CBF Coordinated beamforming/nulling
  • JTX Joint Transmission
  • coordinated multi-AP transmissions may increase spectrum efficiency and reduce latency.
  • An AP may need to know the buffer/traffic status of other APs so that it may coordinate with the APs.
  • the mechanism to request and report buffer/traffic status between APs may not be defined for systems that do not implement the systems and methods discussed herein
  • a Trigger frame is typically used to schedule the uplink transmission. If a TWT member STA has low latency traffic, it may have to wait for the AP to transmit a Trigger frame to schedule its UL transmission.
  • Uplink orthogonal frequency division multiple access (OFDMA)-based random access (UORA) transmissions which are trigger based, may be modified via implementations of the systems and methods discussed herein to give any STA or a group of STAs a chance for UL random access. Accordingly, a TWT member STA that has low latency traffic may use the UORA opportunity to transmit UL data.
  • OFDMA orthogonal frequency division multiple access
  • UORA random access
  • APs may form a multiple AP (MAP) group statically or dynamically.
  • MAP multiple AP
  • APs may need to know some information about other APs (e.g., in the MAP group), for example, whether other APs have buffered traffic; whether other APs are fully loaded; operation channel widths and available subchannels for other APs, etc.
  • Various implementations of the systems and methods discussed herein may be used by APs to exchange that information either at the BSS level or TXOP level.
  • a frame exchange in the BSS level may be considered as long term and relatively static or semi static information which may be valid for the duration of a Beacon interval or even multiple beacon intervals.
  • the frame exchanges in the TXOP level may be considered as short term and dynamic information which may be valid in for a TXOP duration.
  • a sharing AP may be an AP which may be the owner of the wireless medium during a TXOP.
  • the sharing AP may share the acquired medium with other APs (e.g., in the MAP group)
  • the other APs in the BSS may be referred to as shared APs
  • an AP low latency traffic indication is used.
  • APs may announce their aggregated buffer status or low latency buffer status to other APs using a broadcast frame such as a Beacon frame.
  • APs may exchange or communicate their aggregated buffer status or low latency buffer status to other APs using control/management frames over the air.
  • M ulti-AP Traffic Report Request/Response frames may be defined and used for APs to exchange traffic load related information.
  • MAP traffic related information may be carried in a newly defined element/field .
  • APs may include the MAP traffic related elements/fields in a Beacon frame, or a MAP related request/response frame. Such information announcements/exchanges may happen periodically, or may be provided in response to a request (e.g. unicast or broadcast request for information).
  • APs that support low latency traffic delivery may also announce the average access delay for low latency traffic within the BSS.
  • an Average Low Latency Traffic Access Delay element/field which may be carried in management/control frames may be used.
  • the format of the Average Low Latency T raffic Access Delay element is shown in T able 2, below.
  • the AP Low Latency (LL) Traffic Average Access Delay field may have a fixed length (e.g. be an n-bit field) or may have a variable length and associated length field, in various implementations.
  • the field values may be a scaled representation of the average medium access delay for all distributed coordination function (DCF) and enhanced distributed channel access function (EDCAF) transmitted frames measured from the time the DCF or EDCAF low latency sensitive media access control protocol data unit (MPDU) is ready for transmission (e g., when the DCF begins CSMA/CA access) until the actual frame transmission start time.
  • DCF distributed coordination function
  • EDCAF enhanced distributed channel access function
  • MPDU low latency sensitive media access control protocol data unit
  • Non-QoS APs average the access delays for all DCF transmitted frames.
  • QoS APs average the access delays for all enhanced distributed channel access function (EDCA) transmitted frames of all ACs/TIDs.
  • the Average Low Latency T raffic Access Delay element may be detailed with DL and UL average access delays as shown in Table 3. In the example element shown, there are separate AP Downl i nk/UpI i nk Low Latency T raffic Average Access Delay fields.
  • APs which support low latency traffic delivery may also announce the minimum delay bound requirement for low latency traffic within its BSS.
  • a BSS Traffic element/field which may be carried in management/control frames may be used for this purpose.
  • the BSS Traffic element/field may be used to carry a set of parameters that define the average or worst QoS expectations of 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) in the BSS.
  • ACs access categories
  • TIDs traffic identifiers
  • traffic IDs or TIDs may comprise one or more identifiers usable by higher layer entities to distinguish medium access control (MAC) service data units (MSDUs) to MAC entities that support quality of service (QoS) within the MAC data service.
  • TIDs may be provided via a subfield of a MAC frame in some implementations, or in any other type and form of frame.
  • a TID subfield may be part of a frame control field of a MAC header or payload.
  • the TID may comprise a string, bitmap, or any other such data format.
  • APs may use the BSS Traffic element/field to exchange traffic status and requirements for the active STAs in their BSS.
  • the BSS Traffic element may carry one or more of the AP LL Traffic Average Access Delay field, AP DL LL Traffic Average Access Delay, and/or AP UL LL T raffic Average Access Delay field as mentioned above.
  • the BSS T raffic element/field may carry some or all of the following:
  • Access Category or TID field this field may indicate one or more access categories or TIDs the QoS related parameters contained in the element.
  • Direction field this field may indicate DL traffic or UL traffic or peer to peer (P2P) traffic the QoS related parameters contained in the element are related
  • Minimum Delay Bound field this field may contain an unsigned integer that specifies the minimum delay bound among all STAs in the BSS in the direction (DL or UL or P2P) and/or with the access categories/TIDs specified in the element.
  • Average Delay Bound field this field may contain an unsigned integer that specifies the average delay bound among all STAs in the BSS in the direction (DL or UL or P2P) and/or with the access categories/TIDs specified in the element.
  • the Maximum Service Interval field contains an unsigned integer that specifies the maximum interval, in microseconds, between the start of two consecutive SPs that are allocated for DL or UL or P2P frame exchange sequences, depending on the Direction field carried in the element, in the BSS. The value 0 indicates that this parameter is unspecified.
  • Minimum Service Interval in the BSS field contains an unsigned integer that specifies the Minimum interval, in microseconds, between the start of two consecutive SPs that are allocated for DL or UL or P2P frame exchange sequences, depending on the Direction field carried in the element, in the BSS. The value 0 indicates that this parameter is unspecified.
  • data may be forwarded among access points in a P2P exchange, in other implementations, may be replaced by direct link transmission.
  • T able 4 illustrates an example of contents of the BSS T raffic element/field. It is noted that not all of the elements/field are necessary to be present, and the order may be changed. Table 4: BSS Traffic element/field
  • FIG. 4 illustrates an example embodiment of a Subchannel Utilization element 400, which may be used to indicate subchannel utilizations.
  • Subchannel utilization ratio (subchannel busy time [/(measurement time)
  • the Subchannel busy time is defined to be the number of microseconds during which the carrier sensing (CS) mechanism has indicated a subchannel busy indication.
  • the measurement time is the interval during which the subchannel busy time is measured. With this definition, it is noted that a per subchannel CS mechanism may be required.
  • the definition of Subchannel utilization ratio may be related to statistics of the usage of preamble puncturing. For example:
  • Subchannel utilization ratio (subchannel punctured time [/(subchannel busy time)
  • the subchannel punctured time is defined to be the number of microseconds during which the CS mechanism has indicated a channel busy indication and the subchannel is punctured.
  • the subchannel utilization element 400 shown in Figure 4 may be used to indicate if the subchannel is well utilized.
  • the information may be used for the MAP coordination (e.g., C-OFDMA)
  • an AP may exchange an AP Buffer Status Report for Bursty Traffic.
  • APs may need to exchange bursty buffer status between each other, so the AP which may acquire the medium may share the transmit opportunity with other APs. Or multiple APs may coordinate to share a service period or a transmit opportunity properly.
  • Figure 5 is a signal flow diagram 500 illustrating two exemplary schemes (510, 520) that may be variously employed to allow APs or other devices (e.g. APs 502, 504, 506) to exchange buffer status information with each other.
  • APs or other devices e.g. APs 502, 504, 506
  • An AP may set the AP BSR Support subfield in the UHR/EHT+ Capabilities element it transmits to 1 if it supports transmitting/receiving BSRP frames and BSR frames.
  • an AP e.g., AP1 502
  • AP1 502 may check with one or more APs 504, 506 in the same MAP group to determine what kind of buffered traffic they may have.
  • the sharing AP may transmit an AP Buffer Status Report Poll (AP BSRP) frame 512 (or any other type of frame) to one or more APs in the MAP group (e.g., AP2 and AP3 in this example) to request the shared APs to report AP buffer status or AP traffic load status.
  • AP BSRP frame may be a Trigger frame, which may trigger the concurrent responses (Buffer Status Reports (BSRs) 514, 516) from AP2 and AP3.
  • BSRs Buffer Status Reports
  • the sharing AP (AP1) may transmit the frame (e.g., a BSRP Trigger frame) using a non-HT duplicate PPDU so that it may repeat in every 20MHz subchannel.
  • AP1 may indicate some or all of the following information:
  • the AP BSRP may include a Trigger Type subfield in the Common Info field in the Trigger frame, and may indicate the Trigger frame is a AP BSRP;
  • the AP BSRP may include one or more User Info fields.
  • the User Info field of the Trigger frame may have the format show in Figure 6. Some subfields may have modified meanings.
  • a User Info field 600 of an AP BSRP Trigger frame is shown.
  • the AID12/AP ID subfield may uniquely identify either a STA or an AP in the service set operated by the MAP group
  • an AP ID may be within a predetermined range (e.g the range 2008 to 2044 or 2047 to 4094 which are currently reserved in 802.11 ax).
  • the AP ID may be assigned or chosen when the AP joins or starts the MAP group.
  • the RU Allocation subfield and PS160 subfield of the User Info field of the AP BSRP Trigger frame may be used to indicate the RU/MRU assigned to an STA to transmit a trigger based PPDU.
  • the resource is allocated from the sharing AP (e g., AP1 ) to a shared AP (e.g., AP2 or AP3).
  • AP1 , AP2 and AP3 may have different operation channel width, primary channel and punctured channels.
  • the same RU Allocation subfield and PS 160 subfield transmitted from different APs may refer to different RUs.
  • each AP in the MAP group may know the operation channel width, primary channel and punctured channels of the other APs.
  • the RU Allocation subfield and PS160 subfield may correspond to the transmitting AP’s channel width, primary channel and puncture channels.
  • the sharing AP may allocate RUs/subchannels to a shared AP if the shared AP is able to transmit or receive on the allocated RUs/subchannels.
  • the shared AP may use sharing AP’s operation channel width, primary channel location and punctured channels to locate the RUs/subchannels assigned by the sharing AP through the RU Allocation subfield and the PS160 subfield in the Trigger frame.
  • the responding PPDU may be transmitted over RUs in units of 20MHz.
  • the RU Allocation subfield and PS 160 subfield may be redesigned to allocate each intended shared AP one or more 20MHz subchannels.
  • the RU Allocation subfield when set to values from 0 to n 1 -1 may indicate 20MHz subchannel from the lowest frequency to the highest frequency. If the maximum supported bandwidth is 320MHz, n1 may be set to 16 or 8 (in the case that PS160 subfield is used together with RU Allocation subfield to identify a RU).
  • the RU Allocation subfield set to value from n1 to n2-1 may indicate the non-overlapping 40MHz subchannel from the lowest frequency to the highest frequency and so on.
  • the sharing AP is recommended to allocate a sharing AP its primary 20MHz subchannel if possible.
  • the Trigger Dependent User Info subfield of the User Info field of the AP BSRP Trigger frame shown in FIG. 6 may indicate what kind of buffer status the sharing AP is soliciting.
  • the sharing AP may request the shared AP to report the total buffer status, or buffer status for low latency traffic, or buffer status for one or more TID or AC etc.
  • the sharing AP may also include a delay duration field.
  • the shared AP may be request to report buffer size which needs to be transmitted within the delay duration.
  • Trigger Dependent User Info subfield to carry the BSR type information as an example here, it may be carried in other subfield/fields.
  • the Trigger frame carries the AP BSRP transmitted by the sharing AP as an example
  • the above mentioned information may be carried by other frames, fields or elements.
  • AP2 504 and AP3506 may respond with an AP BSR frame/field/element 514, 516.
  • the BSR frame/field/element may be carried in a Trigger based (TB) PPDU on the assigned RU. Or if the assigned RU may occupy full subchannel(s), the BSR frame/field/element may be carried in a non-HT PPDU, or UHR/UHR+ PPDU. UHR+ PPDU may refer any future generation of PPDUs
  • the exemplary design of the AP BSR frame/field/element may include one or more of the following information:
  • Delay Duration indicates a time duration by which the AP may be requested to complete transmission of the reported buffered data.
  • Queue Size Total indicates the amount of traffic for all ACs/TIDs for all STAs to be transmitted within a duration identified by Delay Duration subfield.
  • “Scheme 2” 520 illustrates an implementation with individual BSRP trigger frames.
  • An AP e.g., AP1 502 may acquire the medium and is considered as a sharing AP.
  • AP1 502 may check with one or more APs 504, 506 in the same MAP group what kind of buffered traffic they may have. With this scheme, AP1 may check the buffer status of the shared APs sequentially.
  • a sharing AP may transmit a BSRP frame/field/element 522, 526 to shared AP 504, 506 (e g., AP2/AP3) to solicit a BSR 524, 528.
  • the transmission of the BSRP frame/field/element 522, 526 may be coded and modulated in a 20 Hz subchannel and repeat in the rest of the 20MHz subchannels within the operation bandwidth of AP1 502.
  • the BSRP frame/field/element 522, 526 may be carried in a non-HT duplicate PPDU.
  • the transmission of the BSRP frame/field/element 522, 526 may be carried in the overlapping subchannels of API’s 502 and AP2/AP3’s operating channel.
  • the BSRP frame/field/element 522, 526 may carry information such as described below: AP ID/AP address: this field may identify the receiving/shared AP 504, 506 (e.g , AP2/AP3) uniquely in the MAP group.
  • Requested Buffer Type this may indicate what kind of buffer the sharing AP 502 is soliciting.
  • the sharing AP may request each shared AP to report the buffer status of low latency traffic. Then it may ask the AP to report total buffer size that may need to be completed within a delay period.
  • the sharing AP may include a Delay Duration and a Buffer Size subfields. Note, more than one of the requested buffer type may be requested from the sharing AP. If one type is indicated/included, then the corresponding bitmap or subfield listed below may present. So the type indication may be served as a present indication of some subfields.
  • Total Buffer Size this may indicate the total buffer size of the shared AP (e g., AP2/AP3) is requested.
  • Buffer Size per TID/AC this may indicate the total buffer size per TID or AC of the shared AP (e g., AP2/AP3) is requested.
  • Total Buffer Size within a Delay Duration this may indicate the total buffer size within a delay duration of the shared AP (e.g., AP2/AP3) is requested.
  • Buffer Size per TID/AC within a Delay Duration this may indicate the total buffer size per TID or AC within a delay duration of the shared AP (e.g., AP2/AP3) is requested.
  • this may indicate the aggregated UL buffer status the shared AP may estimate.
  • the shared AP may receive BSRs, QoS Characteristics elements, SCS Descriptor elements etc from non-AP STAs to indicate the traffic/buffer status of each STA.
  • the shared AP may aggregate the information together and form this aggregated estimated UL buffer status report.
  • the aggregation may be per TID/AC/SCS.
  • the aggregation may be per TID/AC/SCS within a time period by which the buffered traffic may need to be delivered.
  • Delay Duration/Bound this may indicate a period the shared AP is requested to report buffer status within the period.
  • Access Category bitmap this may indicate the ACs for which the buffer status is requested. In one method, the ACs are requested by using other format than the bitmap
  • TID bitmap this may indicate the TIDs for which the buffer status is requested. In one method, the TIDs are requested by using other format than the bitmap.
  • Buffer Size Unit this may indicate the Buffer Size Unit. For example, in Octets, or in 256 Octets, 2048 Octets etc.
  • the shared AP may transmit a BSR frame/field/element 524, 526 to sharing AP 502 (e.g., AP1) to report its buffer status.
  • the transmission of the BSR frame/field/element 524, 526 may be coded and modulated in a 20MHz subchannel and repeat in the rest of the 20MHz subchannels within the overlapping operation channel of the shared AP and the sharing AP.
  • the BSR frame/field/element may be carried in a non-HT duplicate PPDU.
  • the BSR field may be carried in MAC header.
  • the BSR frame/field/element may be aggregated with other frames/field/element and carried in the MAC body.
  • the BSR frame/field/element may carry information such as:
  • this field may identify the reporting/shared AP (e.g., AP2/AP3) uniquely in the MAP group
  • Reported Buffer Type this may indicate what kind of buffer status the sharing AP is reporting.
  • the exemplary Requested Buffer Type may include the information identified below in paragraphs [0124] to [0131],
  • Total Buffer Size this may indicate the total buffer size of the shared AP (e g., AP2/AP3) is reported.
  • Buffer Size per TID/AC this may indicate the total buffer size per TID or AC of the shared AP (e g., AP2/AP3) is reported.
  • Total Buffer Size within a Delay Duration this may indicate the total buffer size within a delay duration of the shared AP (e.g., AP2/AP3) is reported
  • Buffer Size per TID/AC within a Delay Duration this may indicate the total buffer size per TID or AC within a delay duration of the shared AP (e.g., AP2/AP3) is reported.
  • Delay Duration/Bound this may indicate a period the shared AP is reporting buffer status within the period.
  • Access Category bitmap this may indicate the ACs for which the buffer status is reported. In one method, the ACs are requested by using other format than the bitmap
  • TID bitmap this may indicate the TIDs for which the buffer status is reported. In one method, the TIDs are requested by using other format than the bitmap.
  • Buffer Size Unit this may indicate the Buffer Size Unit. For example, in Octets, or in 256 Octets, 2048 Octets etc.
  • FIG. 8 is a flow chart of an embodiment of a method 800 for exchanging traffic status information amongst APs in a MAP group.
  • a first AP or sharing AP may determine whether traffic information should be exchanged or is required from other APs of the MAP group. This may be done periodically (e.g. every n microseconds, minutes, or any other interval), based on a transmission period (e.g. every TWT service period, every other TWT service period, etc.), or dynamically as needed (e.g. due to detection of changing channel conditions, when an AP joins or leaves the MAP, when new devices are detected, in response to a request from another AP, etc.).
  • the AP may be able to dynamically select between simultaneous or sequential polling Accordingly, at 804, the AP may determine which scheme is in use in some implementations; or the scheme may be preconfigured and step 804 may be skipped (or rather, may be implicit due to the use of a preconfigured scheme).
  • the AP may transmit a traffic or buffer status report poll frame.
  • the BSRP frame may include any of the features or elements discussed above, including AP identifiers, RU allocations, coding type, receive power, trigger dependent user information, options fields or type indicators, or any other type and form of information.
  • the BSRP frame may be transmitted to all other APs in the MAP group.
  • the AP may receive a buffer status report frame from a second AP (or first shared AP) of the MAP group.
  • the BSR frame may include any of the features or elements discussed above, including buffer sizes or allocations, access categories, delay bound or duration information, etc
  • the AP may determine whether other APs are in the MAP group that have not responded. If so, 808-810 may be repeated as other BSR frames are received. In some implementations, 810 may be implicit and the AP may wait a predetermined polling time for report frames to be received from the other APs. Upon expiration of the polling time 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.
  • the AP may select a shared AP in the MAP group. Selecting the other AP may be done randomly, in order according to a list of identifiers, in order of when the shared AP joined the MAP group (e.g. with IDs being added to an ordered list as each AP joins or leaves), in order of oldest prior report to newest (e.g.
  • the AP may select the first shared AP for first polling; this may be useful for instances in which only a few reports may be received within a polling time), or any other type and form of order or selection.
  • the AP may transmit a traffic or buffer status report poll frame.
  • the BSRP frame may include any of the features or elements discussed above, and may include an identifier of the selected shared AP, as well as RU allocations, coding type, receive power, trigger dependent user information, options fields or type indicators, or any other type and form of information.
  • the BSRP frame may be transmitted using a shared subchannel or overlapping subchannel between the sharing AP and shared AP, in some implementations (e.g. a 20 MHz subchannel in an overlapping channel).
  • the AP may receive a buffer status report frame from the selected AP.
  • the BSR frame may include any of the features or elements discussed above, including buffer sizes or allocations, access categories, delay bound or duration information, etc.
  • the AP may determine whether other APs are in the MAP group that have not been polled and/or whether there is sufficient time remaining in the service period to poll other APs. If so, 812-816 may be repeated one or more times
  • multiple iterations of 812-816 may be performed simultaneously or semi-simultaneously. That is, in such implementations, at 812 a first shared AP may be selected, and at 814 at BSRP frame may be transmitted to the selected AP. 816 may be temporarily skipped, and 812 and 814 may be repeated for a second shared AP. Then 816 may be performed as BSR frames are received from both the first shared AP and second shared AP. This may be useful in implementations in which there is a significant delay between transmission of the BSRP frame and receipt of the corresponding BSR frame (e g. due to processing or measurement at the shared AP) such that an additional BSRP frame may be transmitted between the transmission and receipt.
  • a TWT/rTWT schedule which may require membership, may include enhanced uplink orthogonal frequency division multiple access (OFDMA)-based random access (UORA) transmissions.
  • OFDMA orthogonal frequency division multiple access
  • UORA random access
  • a TWT/rTWT schedule with Broadcast TWT ID subfield set to a value greater than 0 may include an enhanced UORA transmission.
  • a TWT SP with one or more RA-RUs is a TWT SP corresponding to a Broadcast TWT Parameter Set field in a TWT element that has a Broadcast TWT ID subfield equal to 0 or other values, Flow Type subfield equal to 0, Trigger subfield equal to 1 , and a Broadcast TWT Recommendation subfield equal to 2.
  • An associated non-AP STA that supports the TWT and enhanced UORA procedure upon receiving a Beacon frame from its associated AP carrying a TWT element indicating a schedule for TWT SP(s) with RA-RU, may enter the doze state if no other condition requires it to be awake. The STA may transition to awake state at the start of a TWT SP with RA-RU and follow the enhanced UORA procedure.
  • FIG. 7 shows a portion of a signal flow diagram (with non-AP STAs not illustrated) of an example of the traditional UORA and the enhanced UORA in TWTs described herein.
  • An AP 702 may transmit a Beacon frame 704, which may carry (e.g. in a header and/or payload) a TWT Parameter Set 706.
  • the TWT Parameter set 706 may contain one or more TWT elements 708. In this example, it may contain at least two TWT elements 708.
  • the first TWT element 708 may be a traditional TWT element, which may comprise or set a Broadcast TWT ID subfield to 0, Flow Type subfield to 0, Trigger subfield to 1 , and a Broadcast TWT Recommendation subfield to 2. These subfields indicate the TWT SP contains at least one RA-RU assignment which may allow all the non-AP STAs to access during a TWT SP period 710 (e.g. UORA available for all non-AP STAs. Note the combination of the signaling in the TWT element disclosed here may be considered as an example to indicate the TWT SP contains a RA-RU assignment which may allow all non- AP STAs to access during the TWT SP. Other signaling combinations may be possible.
  • the second TWT element 708 may be an enhanced TWT element in accordance with the described embodiment, which may set Broadcast TWT ID subfield greater than 0, Flow Type subfield to 0, Trigger subfield to 1 , and a Broadcast TWT Recommendation subfield to 2.
  • These subfields indicate a TWT SP period 712 contains at least one RA-RU assignment which may allow a group of non-AP STAs to access, referred to as an enhanced UORA Trigger procedure, which may be used in the TWT SP(s) 712.
  • an enhanced UORA Trigger procedure which may be used in the TWT SP(s) 712.
  • Note the combination of the signaling in the TWT element disclosed here may be considered as an example to indicate the TWT SP contains an enhanced UORA Trigger procedure. Other signaling combinations may be possible.
  • the combination of subfields may indicate which RA-RU assignment(s) non- AP STAs which have membership with the TWT are allowed to access.
  • the combination of subfields may indicate which RA-RU assignment(s) are allocated by an enhanced Trigger frame and the Trigger frame may indicate which group of non-AP STAs are allowed to access the RA-RUs.
  • the enhanced Trigger frame may carry one or more of the below information:
  • this subfield may be carried in the Common Info field to indicate the version of Trigger frame. For example, if this is a HE Trigger frame, a EHT Trigger frame or an enhanced Trigger frame for any future generation of 802.11 protocols.
  • the PHY Version Identifier subfield in the Special User Info field in the Trigger frame may be set to a value to indicate this is an enhanced Trigger frame.
  • one or more currently reserved values for Trigger Type subfield in Common Info field in Trigger frame may be used to indicate the Trigger frame may be an enhanced Trigger frame.
  • one or more bits or combination of the some bits in U-SIG Disregard And Validate subfield in Special User Info field in the Trigger frame may indicate the enhanced Trigger frame.
  • an Enhanced Special User Info field may be defined.
  • the Enhanced Special User Info field may be identified by a special value set to AID12 subfield. For example, when AID12 subfield is set to 2008 (or in the range of 2008 to 2044), then the Trigger frame may contain enhanced Trigger information.
  • AID12 subfield in the enhanced User Info field in the Trigger frame may be set to a special value (e g., a value that is reserved now in 11 be) to indicate the RA-RUs allocated in the User Info field is for an enhanced UORA.
  • a special value e g., a value that is reserved now in 11 be
  • the special value for the AID12 subfield may be in the range of 2008 to 2044.
  • the AID 12 subfield may be set to a value of 1 to indicate the RA-RU allocated 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
  • the low latency traffic may be identified by the R-TWT DL/UL TIDs if the enhanced Trigger frame is transmitted within a R-TWT SP.
  • the AID12 subfield may be set to a value of 2 to indicate the RA-RU allocated by the Trigger frame may be used to transmit low latency traffic by a R-TWT member STA.
  • the AID12 subfield may be set to a value of 3 to indicate the RA-RU allocated by the T rigger 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 the RA-RU allocated by the Trigger frame may be used to transmit any traffic by a R-TWT member STA. In some embodiments, a predefined range of AIDs may indicate a group of STAs.
  • AID12 values 2008-2016 may be reserved for group AIDs used for enhanced Trigger frames If a group AID is identified in a User Info field in an enhanced Trigger frame, the corresponding group of STAs may be able to transmit uplink in the assigned RU. Since more than one STA may be in the group, each STA may perform UORA channel access. STAs with similar requirements or characteristics may be assigned to a group identified by a group AID. For example, STAs that have uplink low latency traffic may be assigned to a group. For example, STAs that have uplink low latency traffic with a similar delay bound or delay requirement may be assigned to a group. An AP may transmit an individually addressed frame to a STA to assign a group AID to the STA.
  • the AP may use the group AID to trigger UORA transmissions from any STAs in the group.
  • This method may be used together with R-TWT/TWT procedure or used independently outside the R-TWT/TWT SPs.
  • Delay bound may be used as a measurement in the example, but other latency related measurements may also be used herein (e.g. round trip time, processing latency, etc ).
  • several AID12 values may be used to indicate the priority of the low latency traffic or the urgency of the low latency traffic. For example, there may be a predefined table to map AID12 values to delay bounds.
  • AID12 value is value 1
  • the STAs with delay bound smaller than or equal to the corresponding delay bound value 1 in the table may be allowed to access the RA-RU allocated in the User Info field, and so on. In this way, the AP is able to further classify the low latency traffic with finer resolution.
  • UORA Trigger Group this subfield may be carried in the Trigger Dependent User Info subfield or other places in the enhanced User Info field in the Trigger frame or other places in the Trigger frame
  • Value 2 allow all non-AP STAs which support enhanced UORA and is associated with the AP to access.
  • Value 3 allow all non-AP STAs which support enhanced UORA to access.
  • the non-AP STAs may not necessarily associated with the AP.
  • Value 4 allow non-AP STAs which support enhanced UORA and are members of the TWT/rTWT to access and have latency sensitive traffic to access.
  • Value 5 allow all non-AP STAs which support enhanced UORA and is associated with the AP and have latency sensitive traffic to access.
  • Value 6 allow all non-AP STAs which support enhanced UORA and have latency sensitive traffic to access.
  • the non-AP STAs may not necessarily associated with the AP.
  • Value 7 allow all APs or all APs in the MAP group which support enhanced UORA to access.
  • non-AP STAs may not be allowed to access the RA-RU when the value is indicated.
  • Value 8 allow all STAs which have certain QoS class level which may be determined during the association and/or negotiation processes in the BSS that those STAs reside
  • the QoS level may be classified in terms of latency requirement, power consumption level in a time duration, data rate limit, etc.
  • UORA Trigger Group values may be used to indicate the priority of the low latency traffic or the urgency of the low latency traffic. For example, there may be a predefined table to map UORA Trigger Group values to delay bounds. If UORA Trigger Group value is value 1 , then the STAs with delay bound smaller than or equal to the corresponding delay bound value 1 in the table may be allowed to access the RA-RU allocated in the User Info field and so on. In this way, the AP is able to further classify the low latency traffic with finer resolution. Note we use delay bound as a measurement in the example, but other latency related measurements may also be used herein.
  • the UORA Trigger Group may be signaled using an AID 12 subfield. Predetermined AID12 values may be reserved to signal UROA Trigger Group information in various implementations.
  • STAs and APs which support enhanced Trigger frame and Trigger based transmission may indicate their capability in a Capabilities element.
  • STAs and APs which support enhanced UORA transmission may indicate their capability in a Capabilities element.
  • random access (RA) transmissions are enabled in a R-TWT STAs and APs that support random access transmission in R-TWT may indicate their capability in a Capabilities element.
  • an AP may announce a broadcast TWT or a R-TWT and indicate the TWT/R-TWT SP that may allow non-AP STAs (e.g., STAs associated with the AP, STAs which set up the membership with the TWT/R-TWT etc.) to perform random access, either CSMA/CA access or UORA access. Based on this information, TWT/R-TWT member STAs or non-member STAs may choose to stay awake and contend for the channel during the TWT/R-TWT SP.
  • non-AP STAs e.g., STAs associated with the AP, STAs which set up the membership with the TWT/R-TWT etc.
  • the Broadcast TWT Recommendation Subfield may be reused.
  • the Broadcast TWT Recommendation subfield may be set to 4 to indicate the negotiated TWT is a R-TWT. If the R-TWT setup was successful, an R-TWT ID may be assigned uniquely identify the R-TWT.
  • the Broadcast TWT ID subfield may be set to the R-TWT ID so that the member STAs know this is a R-TWT SP.
  • the Broadcast TWT Recommendation subfield may be set to 2 to indicate the R-TWT/TWT may contain RA-RUs. This allows the non-member STAs to be aware of the potential RA-RU allocations available in the TWT/R-TWT.
  • the Restricted TWT Schedule Info field may be set to a value of 0,1, or 2 to indicate the R- TWT scheduling AP is the AP corresponding to the transmitted BSSID.
  • the Trigger subfield may be set to 1 to indicate the TWT is Trigger enabled.
  • the TWT element may be carried in the Multiple BSSID element and outside of the Multiple BSSID element. The following rules may be applied:
  • the Broadcast TWT ID subfield may set to 31 to indicate that the TWT element is corresponding to a non-transmitted BSSID.
  • the Broadcast TWT Recommendation subfield may be set to 2 to indicate the R-TWT/TWT may contain RA-RUs. This allows the non-member STAs to aware the potential RA-RU allocations available in the TWT/R-TWT.
  • the Restricted TWT Schedule Info field may be set to value 3 to indicate the R-TWT scheduling AP is the AP corresponding to a non-transmitted BSSID.
  • the Trigger subfield may be set to 1 to indicate the TWT is Trigger enabled. A combination of one or more above mentioned fields/subfields may be used to identify that the corresponding TWT is an R-TWT.
  • the Broadcast TWT ID subfield may set to the R-TWT ID so that the member STAs may know this is a R-TWT SP.
  • the Broadcast TWT Recommendation subfield may be set to 2 to indicate the R-TWT/TWT may contain RA-RUs. This allows the non-member STAs to be aware the potential RA-RU allocations available in the TWT/R-TWT.
  • the Restricted TWT Schedule Info field may be set to a value of 0,1, or 2 to indicate the R-TWT scheduling AP is the AP corresponding to the transmitted BSSID.
  • the Trigger subfield may be set to 1 to indicate the TWT is Trigger enabled.
  • the members of the R-TWT may use the R-TWT ID to identify the R-TWT.
  • STAs that support UORA transmissions in a R-TWT on reception of the TWT element, they may consider it as a R-TWT.
  • the STAs may notice that RA-RU/UORA transmissions may be available in the R-TWT. If a STA has uplink traffic, it may prepare to transmit in the R-TWT SP if an UORA Trigger frame or an enhanced UORA Trigger frame is received. Otherwise, the STA may choose to switch to power save mode during the R-TWT SP. Note, a STA may follow the R-TWT rule to terminate its transmission or TXOP before the R-TWT SP.
  • legacy STAs which do not support UORA transmissions in a R-TWT
  • the legacy STAs will consider it as a normal TWT instead of a R-TWT.
  • the legacy STAs may notice that RA-RU/UORA transmissions may be available in the TWT. If a legacy STA has uplink traffic, it may prepare to transmit in the TWT SP if an UORA Trigger frame or an enhanced UORA Trigger frame is received. Otherwise, the legacy STA may choose to switch to power save mode during the TWT SP.
  • legacy STA may not follow the R-TWT rule to terminate its transmission or TXOP before the R-TWT SP since it may not notice this is a R-TWT SP.
  • legacy STAs may participate the RA-RU/UORA transmissions within a R- TWT since they may interpret the R-TWT as a normal TWT.
  • the disclosed embodiments focus on enabling UORA transmissions in R-TWT. However, it may be extended to enable random access transmissions in R-TWT.
  • the random access transmissions includes UORA transmissions and traditional CSMA/CA channel access transmissions.
  • the Broadcast TWT Recommendation subfield may be set to 2 to indicate the R-TWT/TWT may contain RA-RUs or random access transmissions
  • a new Field/Subfield may be used to enable RA transmission in R-TWT.
  • a new field/subfield or a reserved value of an existing field/su bfield may be used to indicate the TWT is a R-TWT with RA-RU/UORA/random access transmissions.
  • the random access transmissions may refer to a general random access scheme including UORA/RA-RU transmissions and traditional CSMA/CA access.
  • one reserved value (value 5 in the example) for Broadcast TWT Recommendation field may be used to indicate a R-TWT with RA-RU/UORA/random access transmissions, as shown in Table 7.
  • Table 5 Broadcast TWT Recommendation field for a broadcast TWT element with R-TWT UORA support
  • the AP may set the Broadcast TWT Recommendation field to value 5.
  • the members of the R-TWT may be configured to recognize the value as indicating that RA- RU/UORA/random-access transmissions are allowed or enabled.
  • STAs which may support UORA/random access transmissions in a R-TWT and that are not a member of the R-TWT, on reception of the TWT element, they may consider the TWT as a R-TWT with UORA/random access opportunities. These STAs may notice that RA-RU/UORA/random access transmissions may be available in the R-TWT. If a STA has uplink traffic, it may prepare to transmit in the R- TWT SP if an UORA Trigger frame or an enhanced UORA Trigger frame is transmitted or traditional CSMA/CA access is allowed. Otherwise, the STAs may choose to switch to power save mode during the R- TWT SP. Note, a STA may follow the R-TWT rule to terminate its transmission orTXOP before the R-TWT SP.
  • Legacy STAs which do not support UORA/random access transmissions in a R-TWT may not understand the value in the Broadcast TWT Recommendation field and may not participate in the UORA transmissions within the R-TWT.
  • the enhanced STAs which understand the new signaling may have more chances to participate the UORA/random access transmissions as compared to legacy STAs.
  • the R-TWT scheduling AP may trigger member R-TWT scheduled STAs first to facilitate them to deliver their QoS data frames of R-TWT DL/UL TIDs. Then the AP may transmit a trigger frame or enhanced trigger frame with RA-RU to solicit responses from any STAs associated with the AP or AP/MLD or AP collocated with the R-TWT scheduling AP if they have UL traffic or have UL QoS traffic corresponding to the UL TIDs.
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des transmissions à multi-AP coordonnés qui peuvent augmenter l'efficacité du spectre et réduire la latence. Un AP peut avoir besoin de connaître l'état de tampon/trafic d'autres AP de sorte qu'il puisse se coordonner avec les AP. Plusieurs modes de réalisation divulgués permettent un rapport d'état mis en mémoire tampon entre de multiples AP. En outre, des modes de réalisation divulgués concernent un mécanisme UORA pour une transmission de trafic à faible latence au moyen de RA-RU.
PCT/US2024/021606 2023-03-30 2024-03-27 Procédés d'échange d'état de trafic multi-ap et conception d'uora améliorée Pending WO2024206387A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202363455710P 2023-03-30 2023-03-30
US63/455,710 2023-03-30
US202363537018P 2023-09-07 2023-09-07
US63/537,018 2023-09-07
US202363547025P 2023-11-02 2023-11-02
US63/547,025 2023-11-02

Publications (1)

Publication Number Publication Date
WO2024206387A1 true WO2024206387A1 (fr) 2024-10-03

Family

ID=90826492

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/021606 Pending WO2024206387A1 (fr) 2023-03-30 2024-03-27 Procédés d'échange d'état de trafic multi-ap et conception d'uora améliorée

Country Status (2)

Country Link
TW (1) TW202439843A (fr)
WO (1) WO2024206387A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200120544A1 (en) * 2018-10-15 2020-04-16 Mediatek Singapore Pte. Ltd. Mechanisms of status reporting and protected period setting for coordinated transmission in multiple ap system
US20230078104A1 (en) * 2019-12-20 2023-03-16 Canon Kabushiki Kaisha Method and apparatus for coordinating multi-user multi-access point transmissions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200120544A1 (en) * 2018-10-15 2020-04-16 Mediatek Singapore Pte. Ltd. Mechanisms of status reporting and protected period setting for coordinated transmission in multiple ap system
US20230078104A1 (en) * 2019-12-20 2023-03-16 Canon Kabushiki Kaisha Method and apparatus for coordinating multi-user multi-access point transmissions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PASCAL VIGER (CANON): "CR for Low Latency BSR", vol. 802.11 EHT; 802.11be, no. 3, 13 January 2022 (2022-01-13), pages 1 - 12, XP068188304, Retrieved from the Internet <URL:https://mentor.ieee.org/802.11/dcn/21/11-21-1577-03-00be-cr-for-low-latency-bsr.pptx> [retrieved on 20220113] *

Also Published As

Publication number Publication date
TW202439843A (zh) 2024-10-01

Similar Documents

Publication Publication Date Title
US20250220674A1 (en) Joint communication and sensing aided beam management for nr
US10880835B2 (en) Methods for efficient medium access for wake up radios
EP4316158A1 (fr) Trame de déclenchement améliorée et ses variantes
CN110800220A (zh) Mimo信道接入
JP2024528443A (ja) Ｗｌａｎシステムにおける拡張サブチャネル選択的伝送の有効化
US20230100162A1 (en) Power efficient broadcasting in wlan
US20240349398A1 (en) Systems, apparatus and methods for enhancing broadcast services in wireless local area networks
WO2024173663A1 (fr) Procédés pour une opération de temps de réveil cible activée par de multiples ap
WO2024178423A1 (fr) Procédés, architectures, appareils et systèmes pour une opération de temps de réveil cible négociée multi-ap
JP2025512931A (ja) 無線ローカルエリアネットワークにおける空間再利用送信
WO2024206387A1 (fr) Procédés d&#39;échange d&#39;état de trafic multi-ap et conception d&#39;uora améliorée
KR20250168518A (ko) 다중-ap 트래픽 상태 교환을 위한 방법들 및 향상된 uora 설계
WO2025175301A1 (fr) Accès au canal secondaire coordonné à ap multiples dans des systèmes wi-fi
EP4527139A1 (fr) Opérations de stations eht améliorées pour réutilisation spatiale, rtwt et emlmr
WO2024178206A1 (fr) Procédés pour une opération de temps de réveil cible à chevauchement coordonné à ap multiples
WO2025151740A1 (fr) Procédés d&#39;accès à un canal non primaire dans des systèmes wlan
WO2024178345A1 (fr) Procédures de détection améliorées
WO2025174965A1 (fr) Systèmes, procédés et dispositifs associés au délestage de gnb de planification sl
EP4666729A1 (fr) Procédés pour une opération de temps de réveil cible activée par de multiples ap

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24720983

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112025020865

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: KR1020257035892

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2024720983

Country of ref document: EP

Ref document number: 202517104964

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2024720983

Country of ref document: EP

Effective date: 20251030

WWP Wipo information: published in national office

Ref document number: 202517104964

Country of ref document: IN