Method of target wake time operation for multiple APs

Abstract

A method and signaling for a station (STA) to temporarily utilize the target wake time (TWT) service of an OBSS or inter-BSS AP is disclosed. The STA receives an indication from a primary access point (AP) in a multi-AP (MAP) service set (SS) that target wake time (TWT) operation is not provided. The STA monitors beacons from one or more secondary access points in the MAP SS, and the secondary APs accept TWT requests from overlapping basic service set (OBSS) STAs and waits for an indication that an available TWT schedule is available. The STA then sends a TWT configuration request to the secondary AP for an available TWT schedule and receives a TWT acceptance response from the secondary AP, including a TWT service period (SP).

Description

[Technical Field]

[0001] The present disclosure relates to a method for multi-AP enabled target wake time operation. [Background technology]

[0002] This application claims priority to U.S. Provisional Application No. 63 / 445,899, filed February 15, 2023, and U.S. Provisional Application No. 63 / 595,530, filed November 2, 2023, the contents of both applications being incorporated herein by reference.

[0003] Target Wake Time (TWT) operation was introduced in wireless local area networks (WLANs) to allow access points (APs) and their associated stations (STAs) to negotiate wake-up time windows during which STAs can transmit and receive traffic. The use of TWT has been extended to allow APs to manage activity within a basic service set (BSS), minimizing contention between STAs and reducing the amount of time STAs using power management modes need to remain awake. The TWT element is defined to carry information used to negotiate and advertise TWT-related information. Recent efforts have also provided a Cooperative Multi-AP (C-MAP) feature that further enhances WLANs. With C-MAP, TWT operation can be appropriately coordinated among APs in the same multi-AP (MAP) set to achieve various goals. In densely deployed systems, some STAs may be unable to participate in desired TWT or restricted TWT (rTWT) within the associated BSS. STAs should be able to join TWT / rTWT in neighboring BSSs using C-MAP, but currently there is no signaling or mechanism to enable this feature.

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals may refer to like elements and in which: [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 is a system diagram illustrating an example of a communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example of a wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary radio access network (RAN) and a further exemplary core network (CN) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 is a timing diagram illustrating an example of individual target wake time (TWT) operation in a WLAN. [Figure 3] 10 is a timing chart showing an example of a broadcast TWT operation in a WLAN. [Figure 4] FIG. 1 illustrates an example of a network diagram using a Coordinated Multi-Access Point (C-MAP) architecture according to a first embodiment. [Figure 5] FIG. 1 is a network diagram illustrating an example of a data path involving a CMAP architecture. [Figure 6] FIG. 10 is a diagram illustrating an example of a network diagram using a C-MAP architecture according to a second embodiment. [Figure 7] 1 is a network diagram in which APs in a multi-AP (MAP) set exchange MAP transmissions and related information. [Figure 8] FIG. 1 is a network signaling diagram illustrating an example of a MAP TWT procedure with inter-basic service set (BSS) indication using beacons, according to one embodiment. [Figure 9] 1 is a flowchart illustrating a station (STA) performing an exemplary MAP TWT procedure. [Figure 10] FIG. 10 is a network signaling diagram illustrating another exemplary MAP TWT procedure with beacon-free inter-BSS indication, according to one embodiment. [Figure 11] 10 is a flowchart illustrating a second exemplary MAP TWT procedure performed by a STA. DETAILED DESCRIPTION OF THE INVENTION

[0006] Aspects of the present disclosure may address one or more of the aforementioned problems and other features through an example multi-AP architecture having a Cooperative Multi-AP Set (MAP Set). In certain aspects, a C-MAP architecture is disclosed that allows inter-BSS STAs within the same MAP service set to negotiate and / or participate in TWT procedures. In a first aspect, a procedure with beacons is used, and in a second aspect, a procedure without beacons is used.

[0007] According to one aspect, a virtual access point (AP) is included in a MAP set as a logical entity. Non-co-located APs in the MAP set may belong to a virtual AP in the MAP set or may be physically co-located with other devices, such as a controller. STAs wishing to communicate with one or more APs in the MAP set may establish an association with the virtual AP.

[0008] According to further aspects, a STA is associated with a virtual AP via a physical AP in a MAP set. This physical AP may be referred to as the STA's primary AP. The remaining APs in the MAP set other than the primary AP may be referred to as the STA's secondary APs. In certain aspects, the virtual AP (i.e., all devices that share the virtual AP's service set identifier (SSID)) is defined as a MAP service set (SS). Within a MAP SS, the concept of a basic service set (BSS) is used to identify a subset of devices within the MAP SS. This consists of an AP and a group of STAs, where an AP may be the primary AP for the group of STAs. In aspects of the embodiment, an intra-BSS STA within a MAP SS may be defined as a STA that is within the MAP SS but belongs to a different BSS. An intra-BSS STA within a MAP SS is defined as a STA that belongs to the same BSS within the MAP SS. Certain further aspects relate to extended TWT elements.

[0009] A method and signaling technique for a station (STA) to access target wake time (TWT) service as an inter-BSS STA in a cooperative multi-access point (C-MAP) network is disclosed. The STA receives information indicating that a secondary access point (AP) supports inter-BSS access in the C-MAP network, and the STA sends a target wake time (TWT) setting request to the secondary AP (which may be a virtual AP in the C-MAP network). The STA may receive a TWT setting grant from the secondary AP and send a TWT switch indicator to the STA's primary AP. The STA may receive data flow from the secondary AP during a TWT service period (SP). Using the characteristics of the C-MAP network, new TWT elements and fields are defined to enable STA control by the MAP service set (SS) in intra-BSS and inter-BSS communications between the STA and the primary and secondary APs.

[0010] In another aspect, an embodiment is disclosed relating to temporary TWT membership negotiation. A method and signaling are disclosed for a station (STA) to temporarily access a target wake time (TWT) service of an OBSS or inter-BSS AP. The STA receives an indication from a primary access point (AP) in a multi-AP (MAP) service set (SS) that target wake time (TWT) operation is not provided. The STA monitors beacons from one or more secondary APs in the MAP SS and waits for an indication that the secondary AP accepts TWT requests from overlapping basic service set (OBSS) STAs and that an available TWT schedule is available. The STA then sends a TWT configuration request to the secondary AP for the available TWT schedule and receives a TWT acceptance response from the secondary AP, including a TWT service period (SP). Additional aspects are also disclosed.

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

[0012] 1A, communications system 100 includes wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be noted that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, and 102d is any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (all of which may be referred to as stations (STAs)) may be configured to transmit and receive wireless signals and may include users (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches and other wearables, head-mounted displays (HMDs), vehicles, drones, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless equipment operating in industrial and / or automated processing chain environments), consumer electronics devices, equipment operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

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

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

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

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

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

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

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

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

[0022] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location services, prepaid calling, Internet connectivity, video streaming, etc., and / or advanced security features such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that utilizes NR radio technology, the CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0025] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, 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. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements consistent with the embodiments.

[0026] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated within an electronic package or chip.

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

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

[0029] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0030] The processor 118 of the WTRU 102 may be connected to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or other types of memory storage devices. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information and store data from memory that is not physically located on the WTRU 102 (eg, memory located on a server or home computer (not shown)).

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

[0032] The processor 118 may be connected to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the broadcast interface 116 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may obtain location information by any suitable location method while remaining consistent with the present embodiments.

[0033] The processor 118 may further be connected to other peripherals 138, which may include one or more software and / or hardware modules that provide additional functionality, capabilities, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television receiver / transmitter, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR or AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors. The sensors may include one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0034] The WTRU 102 may include a full-duplex radio that transmits and receives some or all of the signals (e.g., those associated with a particular subframe in both the UL (e.g., for transmission) and DL (e.g., for reception)) simultaneously and / or simultaneously. The full-duplex radio may include an interference management unit and may reduce and / or substantially eliminate self-interference through signal processing by hardware (e.g., a choke) or a processor (e.g., a separate processing unit (not shown) or processing unit 118). In one embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all of the signals (e.g., those associated with a particular subframe in both the UL (e.g., for transmission) and DL (e.g., for reception)).

[0035] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the broadcast interface 116. The RAN 104 may also be able to communicate with the CN 106.

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

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

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

[0039] The MME 162 is connected to each eNode-B 160a, 160b, 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, enabling / disabling bearers, selecting a particular serving gateway upon initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0040] The SGW 164 may be connected to each eNode-B 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as user plane anchoring during inter-eNode B handovers, paging initiation when DL data is available for the WTRUs 102a, 102b, 102c, and context management and storage for the WTRUs 102a, 102b, 102c.

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

[0042] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, and may facilitate communications between the WTRUs 102a, 102b, 102c and traditional fixed communications equipment. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0044] In an exemplary embodiment, the other network 112 may be a wireless LAN (WLAN).

[0045] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a distribution system (DS) or other wired / wireless network that transmits and receives traffic to the BSS. Traffic to a STA originating from outside the BSS may arrive via the AP and be delivered to the STA. Traffic from a STA originating from outside the BSS may be sent to the AP and delivered to its destination. STA-to-STA traffic within a BSS may be sent via the AP, for example, with the source STA sending traffic to the AP and the AP delivering the traffic to the destination STA. STA-to-STA traffic within a BSS may be considered or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent via direct link setup (DLS) (e.g., directly) between the source and destination STAs. In a representative embodiment, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using an IBSS (e.g., all STAs) may communicate directly with each other. In this specification, the IBSS communication mode is sometimes referred to as an "ad hoc" communication mode.

[0046] When using 802.11ac infrastructure mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz bandwidth) or a dynamically configured width. The primary channel becomes the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented. In CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If a particular STA senses or detects the primary channel and / or determines that it is busy, the STA may back off. In a given BSS, one STA (e.g., only one station) may transmit at any given time.

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

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

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

[0050] WLAN systems that support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by a STA that supports the smallest bandwidth operating mode among all STAs in the active BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for STAs that only support 1 MHz mode (e.g., MTC-type devices), even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) configuration may depend on the state of the primary channel. For example, if the primary channel is busy because STAs that only support 1 MHz operating mode are transmitting to the AP, all available frequency bands may be considered busy, even if most of the available frequency bands are idle.

[0051] In the United States, the frequency bands in which 802.11ah may be used are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 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.

[0052] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

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

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

[0056] Each gNB 180a, 180b, 180c is associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, support network slicing, DC, interconnection between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0058] 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 function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support of network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low Latency Communications (URLLC) access, services relying on enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and non-3GPP access technologies such as WiFi.

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

[0060] The UPFs 184a, 184b may be connected to any one of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which provides the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 and facilitates communication between the WTRUs 102a, 102b, 102c. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing a mobility anchor.

[0061] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0062] 1A-1D and the corresponding description thereof, one or more, or all, of the functions described herein for any one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or other apparatus 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 some or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0063] The emulation device may be designed to implement one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more functions, or all functions, to test other devices in a communication network while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network. One or more emulation devices may perform one or more functions, or all functions, while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly connected to other devices for the purpose of performing tests and / or tests using wireless communications.

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

[0065] Target Wake Time (TWT) and Limited TWT are discussed. Target Wake Time (TWT) operation was first introduced in 802.11ah. It was designed to allow an access point (AP) and its associated STAs to negotiate a wake-up window during which STAs can send and receive traffic. 802.11ax extends the use of TWT to allow an AP to manage activity within a BSS. This minimizes contention between STAs and allows STAs using power management modes to reduce the amount of time they need to remain awake. TWT elements are defined to carry information used to negotiate and advertise TWT-related information. Two types of TWT are defined: broadcast TWT and individual TWT.

[0066] Referring to FIG. 2, an example of individual TWT operations 200 associated with 802.11ax is shown. A TWT-scheduled STA (e.g., STA1) may send a TWT request to a TWT-responding STA (e.g., AP) to establish a triggered TWT agreement. The AP accepts the TWT agreement. The AP may send an unsolicited TWT response to STA2 to establish a triggered TWT agreement with STA2. The AP may then initiate a triggered TWT service period (SP) 205 with a trigger frame 207. STA1 and STA2 may respond with a PS-Poll frame and a QoS Null frame, respectively, to indicate their readiness to communicate with the AP.

[0067] Referring to Figure 3, an example of broadcast TWT operation 300 related to 802.11ax is shown. A TWT-scheduled STA (i.e., STA1) may negotiate with the TWT-scheduling AP for an initial wake target beacon transmission time (TBTT) to listen for beacon frames. The AP may advertise a broadcast TWT element in the beacon 305. The AP may then initiate a trigger-enabled TWT service period (SP) 310. In the TWT SP 310, one or more STAs may wake up and communicate with the AP.

[0068] The IEEE Standards Committee approved the IEEE 802.11be Task Group (TG) based on the Project Authorization Request (PAR) and Standards Development Criteria (CSD) developed by the Extremely High Throughput (EHT) Study Group (SG). 802.11be introduced Restricted TWT (R-TWT), which is designed to prioritize delay-sensitive traffic by including a Restricted TWT traffic information field in the broadcast TWT element.

[0069] The IEEE 802.11 Ultra-High Reliability (UHR) Study Group was formed to study the next major revision of the IEEE 802.11 standard following 802.11be. UHR was formed to explore the possibility of improving reliability, supporting low-latency traffic, further increasing peak throughput, and improving the efficiency of IEEE 802.11 networks.

[0070] Cooperative multi-access point (C-MAP) transmission has been discussed in the 802.11be and Ultra High Rate Radio (UHR) Special Working Group (SG). Some of the schemes considered include cooperative multi-AP OFDMA (co-OFDMA), cooperative multi-AP TDMA (co-TDMA), cooperative multi-AP spatial reuse (CSR), cooperative beamforming / nulling (CBF), and joint transmission (JTX).

[0071] In the context of cooperative multi-AP, several terms are defined. - Sharing AP: EHT AP that acquires the TXOP and initiates multi-AP cooperation. Shared AP: An EHT AP that is the target of multi-AP transmission coordination by a shared AP. - AP candidate set: A set of APs that can initiate or participate in multi-AP collaboration.

[0072] As mentioned above, C-MAP may better coordinate TWT operations among APs in the same multi-AP (MAP) set to achieve different objectives. In densely deployed systems, some STAs may not be able to participate in desired TWT / rTWT within their associated BSS. In various embodiments, STAs may need to access TWT / rTWT functionality from APs in neighboring BSSs with C-MAP.

[0073] Referring to FIG. 4, in one example multi-AP architecture 400, multiple non-co-located APs (e.g., AP1, AP2, AP3) may form a cooperative multi-AP set (MAP set) 410. There may be one virtual AP 412 in the MAP set 410. The virtual AP 412 may be a logical entity. Non-co-located APs in the MAP set 410 may belong to the virtual AP 412. The virtual AP 412 may be physically co-located with any AP in the MAP set 410. In another embodiment, the virtual AP 412 may be physically co-located with another device, such as a controller. STAs (e.g., STA11, STA21, STA31) that wish to communicate with one or more APs in the MAP set 410 may associate with the virtual AP 412.

[0074] In one exemplary method, a STA may associate with a virtual AP 412 via an AP in the MAP set 410. This physical AP may be referred to as the STA's primary AP. The remaining APs in the MAP set 412 other than the primary AP may be referred to as the STA's secondary APs. In this architecture, a service set (SS) of the virtual AP is defined; that is, all devices that share the service set identifier (SSID) of the virtual AP 412 are defined as the MAP service set (SS). Within a MAP SS, the concept of a basic service set (BSS) is carried forward to identify a subset of devices within the MAP SS, which consists of an AP and a group of STAs, where an AP may be the primary AP for the group of STAs. An intra-BSS STA within a MAP SS is defined as a STA within the MAP SS but belonging to a different BSS. An intra-BSS STA within a MAP SS is a STA that belongs to the same BSS within the MAP SS.

[0075] In the example architecture 400 shown in Figure 4, non-co-located access points (AP1, AP2, AP3) form a MAP set 410. STA11 may associate with a virtual AP 412 through AP1, and similar procedures may apply to other STAs and APs. As shown in the figure, AP1 is the primary AP for STA11, and AP2 is the primary AP for STA21. STA11, STA21, and STA31 in this example are non-co-located STAs.

[0076] In the first example C-MAP architecture 400 of FIG. 4 (referred to as C-MAP Architecture I), a STA primarily communicates with a primary AP. In special cases, a STA may communicate with a primary AP and / or a secondary AP. Examples of these special cases may include, but are not limited to, (i) when a STA roams from one primary AP to another, (ii) when a STA transmits certain traffic (e.g., low-latency traffic) via a secondary AP (e.g., the traffic passes through either the primary or secondary AP), and (iii) when a STA is involved in a joint multi-AP transmission procedure, e.g., a joint MAP MIMO procedure, a joint sounding procedure, etc.

[0077] Referring to FIG. 5, an exemplary data path flow 500 in a C-MAP architecture is shown. A virtual AP 512 may route data to one or more APs (e.g., AP1, AP2, AP3) in the MAP set as shown. The virtual AP 512 may route most of the data traffic of non-AP STAs (e.g., STA11, STA21, STA31) to their primary AP. The virtual AP 512 may route a portion 520 of the non-AP STAs' data traffic to one or more secondary APs in the special case described above, as well as to the primary AP. In one example, non-co-located APs may operate on the same channel. In another example, non-co-located APs may operate on different channels. In yet another example, non-co-located APs may operate on partially overlapping channels. Any of the C-MAP architectures discussed can be easily extended to cases where one or more APs in the MAP set may be replaced by AP multi-link devices (MLDs), which may be active on one or more links.

[0078] Referring to FIG. 6, a second exemplary C-MAP architecture 600 is shown, also referred to as C-MAP architecture II. In this example multi-AP architecture 600, multiple non-co-located APs (e.g., AP1, AP2, and AP3) may form a cooperative multi-AP set (C-MAP set) 610. There may be one virtual AP 612 within the MAP set 610. The virtual AP 612 is a logical entity, and non-co-located APs within the MAP set 610 may belong to the virtual AP 612. The virtual AP 612 may be physically co-located with an AP within the MAP set 610. Alternatively, the virtual AP 612 may be physically co-located with another device, such as a controller. A STA that wishes to communicate with one or more APs within the MAP set 610 associates with one AP within the MAP set. The associated AP may be referred to as a primary AP to the STAs within the MAP set 610, and other APs within the MAP set may be referred to as secondary APs to the STAs. Terms such as MAP SS, inter-BSS STA, and intra-BSS STA may be similar to those defined in the exemplary C-MAP Architecture I of FIG. 4. The primary difference between Architecture I of FIG. 4 and Architecture II of FIG. 6 is that, for example, in Architecture I of FIG. 4, STA11 is associated with virtual AP 412 through primary AP1, whereas in Architecture II of FIG. 6, STA11 is associated with AP1, which in turn is attached to virtual AP 612. In Architecture I, there may not be a shared data path between APs, so data and other context may need to roam between APs as needed. In Architecture II, there may be a shared data path between APs, so data may be available from multiple APs.

[0079] Referring to FIG. 7, an exemplary data path flow 700 is shown in which APs (e.g., AP1, AP2, and AP3) in a MAP set exchange information for MAP-related transmissions. When multiple APs in a MAP set are involved in a transmission, the APs may communicate with each other via wired or wireless media 715, 720 as shown in FIG. 7 to exchange control, management, or data frames. While example 700 shows a router 710 providing separate data paths for the APs in the MAP set, embodiments are not limited in this respect. In the exemplary Architecture II shown in FIG. 6, non-co-located APs AP1, AP2, and AP3 form a MAP set. STA11 may establish an association with AP1, and similar procedures may apply to other STAs and APs. AP1 is the primary or associated AP for STA11, and AP2 is the primary or associated AP for STA21. STA11, STA21, and STA31 in this example are non-co-located STAs.

[0080] As shown in Figure 7, APs in a MAP set may exchange MAP transmission-related information. In one example, non-co-located APs may operate on the same channel. In another example, non-co-located APs may operate on different channels. In yet another example, non-co-located APs may operate on partially overlapping channels. This architecture can be easily extended to cases where one or more APs in a MAP set may be replaced by one or more AP MLDs that may be active on one or more links.

[0081] In another embodiment, an extended TWT / rTWT procedure within a MAP set may be used. In this embodiment, a TWT / rTWT announced by an AP in the MAP set may allow STAs associated with virtual APs in the MAP set to participate. When a STA advertises or negotiates a TWT service period, the STA includes an inter-BSS STA indication subfield in the TWT element or other element / field / subfield to indicate that (i) the AP can use this element / subfield to indicate whether the advertised / negotiated TWT allows participation of inter-BSS STAs within the MAP SS (i.e., STAs associated with a virtual AP in the MAP SS but whose primary AP is not the advertised AP), and / or (ii) the STA can use this element / subfield to indicate whether the STA is within the BSS of an AP in the MAP SS, or whether the STA's primary AP or associated AP is an AP capable of transmitting and receiving TWT elements. In some embodiments, STAs and APs that support MAP TWT operation may indicate this in a capability element, such as a UHR capability element or other element.

[0082] 8 and 9, an exemplary embodiment referred to as Procedure I is shown. FIG. 8 illustrates a network messaging diagram. FIG. 9 illustrates a method for a STA (e.g., STA11 of FIG. 8) performing Procedure I. In the exemplary procedure 800 of FIG. 8, a beacon frame 802 TWT may be used to advertise TWTs that inter-BSS STAs within a MAP SS may be allowed to participate in. Aspects of the procedure of this embodiment may modify conventional broadcast TWT procedures.

[0083] In the exemplary procedure 800, there are two access points (APs) in the MAP SS: AP1 and AP2. As shown and described, a STA (i.e., STA11) has a primary AP (i.e., AP1) and a secondary AP (i.e., AP2). Thus, in this example, STA11 is an intra-BSS STA with respect to AP1 and an inter-BSS STA with respect to AP2. In this example, AP1 may advertise (e.g., via beacon 802) that its TWT / rTWT schedule is full and may not accept new members. STA11 may then monitor transmissions (e.g., beacon 805) of one or more secondary APs (i.e., AP2) in the MAP set. AP2 may advertise its TWT / rTWT schedule via beacon 805 and may accept inter-BSS STAs in the MAP SS. STA11 may then negotiate with AP2 and join its TWT / rTWT schedule / process.

[0084] Details of procedure I are shown with reference to Figures 8 and 9. Note that one or more steps shown in Figure 8 may be combined or omitted entirely. In this example, AP1 may transmit a beacon frame 802 or other management frame advertising a TWT element, a restricted TWT element, a broadcast TWT element, or an individual TWT element. The advertisement element may indicate, for example, (i) the negotiation type subfield is set to =2 (or other indication) to indicate that this TWT element is used to advertise a TWT schedule; (ii) the restricted TWT schedule information subfield is set to, for example, =2, to indicate that the TWT is full and the AP may not be able to accept new members to the TWT, or that other signaling may be used to indicate that AP1 may not accept new members; and / or (iii) the inter-BSS STA indication subfield is set to, for example, =0 or =1, to indicate whether inter-BSS STAs are allowed to participate in the TWT / rTWT.

[0085] In this exemplary embodiment, AP1 may include a C-MAP element in the same beacon frame 802. The C-MAP element may indicate one or more of a virtual AP MAC address or virtual AP ID for identifying a virtual AP, an AP1 ID in the MAP SS, a fully active AP ID / address in the MAP SS (this subfield / field may indicate all APs in the MAP SS), and / or a selected AP ID / address in the MAP SS. This subfield / field may indicate a proposed AP for STAs in the MAP SS to communicate with (e.g., join a TWT). In one example, this subfield may include a bitmap, with each bit corresponding to an AP in the MAP SS.

[0086] 8, when STA11 receives a beacon frame 802 transmitted from AP1, it may realize that it may not be able to participate in TWT / rTWT because the TWT / rTWT schedule is full. STA11 may monitor other APs in the MAP set or the AP proposed by AP1. STA11 may receive a beacon frame (e.g., beacon 805) transmitted from an AP (e.g., AP2) in a MAP SS other than the primary AP (e.g., AP1). In the beacon frame 805, AP2 may include a TWT element, a limited TWT element, a broadcast TWT element, or an individual TWT element, which may indicate one or more of the following:

[0087] - TWT ID subfield and / or Extended TWT ID subfield for uniquely identifying a TWT within a MAP SS. If the TWT ID field alone is not sufficient to uniquely identify a TWT within a MAP SS, the Extended TWT ID may be used in conjunction with the TWT ID to indicate the TWT within the MAP SS. Alternatively, the TWT ID and AP ID may be used together to uniquely identify a TWT within a MAP SS.

[0088] The Negotiation Type subfield may be set to =2 (or other indicative value) to indicate that this TWT element is used to advertise a TWT SP.

[0089] The Restricted TWT Schedule Information subfield may be set to, for example, =1 or =3, indicating that the TWT is active and that the AP is open to accepting new members to the TWT service provider.

[0090] The Inter BSS STA Indication subfield may be set to 1, for example, to indicate that the AP allows inter BSS STAs within the MAP SS to participate in TWT / rTWT.

[0091] In this example procedure, AP2 may include a C-MAP element in the same beacon frame 805, which may indicate, for example, (i) a virtual AP MAC address or virtual AP ID for identifying the virtual AP, (ii) the AP1 ID in the MAP SS, (iii) a fully active AP ID / address in the MAP SS (this subfield / field may indicate all APs in the MAP SS), and / or (iv) a selected AP ID / address in the MAP SS. This subfield / field may indicate a list of APs / BSSs in the MAP SS with which the STA may be allowed to communicate (e.g., participate in TWT) with the AP. In one example, this subfield may be a bitmap, with each bit corresponding to an AP in the MAP SS.

[0092] Upon receiving a beacon frame from AP2, STA11 may consider joining the TWT / rTWT advertised / scheduled by AP2. In this case, STA11 may transmit a TWT setup frame 807 or other management / control frame to AP2 as a request to join the TWT / rTWT. The setup frame 807 may include one or more TWT elements and / or other elements / fields (e.g., C-MAP-related elements). For example, in one exemplary TWT element, the Negotiation Type subfield may be set to 3 to indicate that this TWT / rTWT element is used for TWT negotiation. For example, the Inter BSS STA Indication subfield may be set to 1 to indicate that the STA requesting the TWT (e.g., STA11) is an inter BSS STA in the MAP SS. The TWT Setup Command Value subfield may be set to Request TWT to indicate a request for TWT scheduling. The TWT ID field may be set to a value indicating a specific TWT (with which the requesting STA intends to join). Alternatively, this field may be set to a special value to indicate that the requesting STA may not know the TWT ID to join in. One or more additional subfields / elements may be used for the proposed TWT parameters.

[0093] In certain embodiments, information may be transmitted in the TWT element or other elements / fields / frames and may be aggregated and transmitted in frame 807 transmitted by STA 11. For example, information such as a virtual AP address / ID (this field may identify a virtual AP in the MAP SS), a primary AP address / ID (this field may identify a primary AP of the requesting STA), and / or a selected AP ID / address (this field may indicate a neighboring AP in the MAP SS to which STA 11 attempted but failed to join the TWT / rTWT schedule) may be transmitted in a C-MAP element.

[0094] If AP2 accepts the TWT request, it may respond to STA11 with a TWT configuration frame 809 (or other management / control signal). This configuration frame 809 may include one or more TWT elements and / or other elements / fields (e.g., C-MAP-related elements). In one example, the TWT element may include a Negotiation Type subfield set to 3 (or other indication value) to indicate that this TWT / rTWT element is used for TWT negotiation, an Inter-BSS STA Indication subfield set to 1 to indicate that the TWT responding STA (e.g., AP2) will allow inter-BSS STAs to join in the MAP SS, a TWT Configuration Command Value subfield set to Accept TWT (or other value) to indicate acceptance of the TWT request, and / or a TWT ID. The TWT ID may be set to a value indicating the specific TWT to which the responding STA (AP2) will allow the requesting STA (STA11) to join.

[0095] In some embodiments, the following information may be stored in the TWT element or in a separate element / field / frame and aggregated and transmitted in frame 809 sent by AP2. For example, the following information may be stored in the C-MAP element: Virtual AP Address / ID (this field may identify the virtual AP of the MAP SS), Primary AP Address / ID (this field may identify the primary AP (e.g., AP1) of the requesting STA), Responding AP Address / ID (this field may identify the responding AP (e.g., AP2)), Temporary AID Assignment (this field may allow the TWT responding STA (e.g., AP2) to assign a temporary AID to the inter-BSS TWT requesting STA (e.g., STA11), which the TWT requesting STA may use to identify itself in the accepted TWT SP). The temporary AID may have a validity period. As an example, the temporary AID may be valid only for the duration of the accepted TWT SP.

[0096] Additional information in the C-MAP element may include the responding AP's (AP2's) Timing Synchronization Function (TSF) timer and other timing-related parameters. This field may be used by an inter-BSS STA (i.e., STA11) to synchronize with the secondary AP (i.e., AP2) and accurately estimate the TWT start time. In one example, the TSF offset field may be used to indicate the time difference between the primary AP and the responding AP. If STA11 misses the TWT configuration frame 809 from AP2, it may continue to monitor for beacon frames from its associated AP or APs in the MAP SS.

[0097] 8, STA11 may send a TWT / TID switch frame 812 (or other management / control frame) to AP1 to indicate that one or more traffic flows for STA11 may need to be moved to another AP (e.g., AP2) within the MAP SS. The traffic switch may occur in one or more TWT service periods (SPs). Exemplary fields / subfields of the TWT / TID switch frame 812 may include: AP ID / Address (this field may indicate a destination / secondary AP to which a portion of the traffic flow to STA11 may need to be moved within the MAP set); TID Information (this field may indicate that traffic for the corresponding TID may be moved to AP2); TWT ID (this field may indicate a TWT schedule in which the STA plans to participate, advertised by the AP identified in the AP ID / Address field, to transmit the traffic flow identified in the TID Information field); and Scheduling Information at the Destination / Secondary AP (this field may hold scheduling information for a Service Period (SP) or a series of SPs in which the STA plans to participate, of the AP identified by the AP ID / Address). The scheduling information may indicate the start time of an SP and / or the duration of an SP. In the case of a series of SPs, the time interval between two SPs may also be included in the scheduling information. The TWT / TID switch frame may also include a security key, a package number (PN), a sequence number (SN), etc.

[0098] AP1 may transfer data from STA11 to AP2 using one or more frames 820. In one example, AP1 may transfer the data using a relay-associated frame format. AP2 may then start TWT / rTWT at the scheduled time. The TWT SP may be a trigger-enabled TWT 823 or a trigger-disabled TWT. After the TWT SP or multiple TWT SPs, AP2 may transfer data from STA11 to AP1 using one or more frames 835. In one example, AP2 may use a relay-associated frame format to transfer the data.

[0099] Note that the above procedure can be used to allow a TWT member STA or STAs to temporarily join a TWT SP scheduled by an OBSS AP. For example, STA11 can be a member of a TWT scheduled by AP1 or an associated STA of AP1. AP1 can broadcast in the current beacon frame 802 that the TWT SP in the current, next, or next few beacon intervals may be full, busy, or overloaded (e.g., by using a newly defined subfield (e.g., TWT SP Busy subfield) or by reusing the Limited TWT Schedule Information subfield) and advise member STAs or other eligible STAs to temporarily join a TWT SP scheduled by the OBSS AP. Meanwhile, AP2 can transmit a beacon frame 805 and advertise that it allows OBSS or inter-BSS STAs to temporarily sign up for TWT membership using newly defined subfields (e.g., Temporary OBSS TWT Configuration Indication, Temporary OBSS TWT Validity Period, etc.). Upon receiving beacon frame 802 from AP1 and beacon frame 805 from AP2, a TWT member STA of AP1 or an associated STA of AP1 (e.g., STA11) may transmit frame 807 (e.g., a TWT setup frame or other type of frame) to request temporary membership in the TWT scheduled by AP2. AP2 may respond by granting or denying the temporary membership request. In certain embodiments, STA11 and AP2 negotiate the temporary membership validity period through a frame exchange. For example, they may include a "Temporary Membership Validity Period" subfield / field in the frames they exchange.

[0100] Referring to FIG. 9, an exemplary method 900 for a station (STA) operating in a C-MAP network similar to that of FIG. 8 is shown. The STA (e.g., STA11) monitors 905 transmissions (e.g., beacons) from a primary AP (e.g., AP1), indicating that the primary AP's TWT / rTWT schedule is full. In one example, this is indicated by the primary AP being notified with a TWT Schedule Information subfield of 2. The STA monitors 910 transmissions (e.g., beacons) from one or more secondary APs (e.g., inter-BSS AP2) in the C-MAP SS and can determine whether the secondary AP allows TWT / rTWT participation for OBSS or inter-BSS STAs, as well as available TWT / rTWT schedules. In this specification, OBSS STAs and inter-BSS STAs are similar. An inter-BSS STA is a STA associated with a different BSS, while an OBSS STA is a STA associated with an overlapping BSS whose channel may overlap with the primary AP's BSS. In one example, the monitored transmission from the secondary AP may include an Inter-BSS STA indication of 1 and a TWT schedule information subfield of 1 or 3. The STA then transmits a TWT setup frame at 915 requesting participation in the TWT / rTWT of the secondary AP. If the STA receives a response from the secondary AP not accepting the TWT setup at 920, the STA continues to monitor transmissions from the primary AP and / or other secondary APs at 910, waiting for an indication that a TWT / rTWT is granted or available. If the STA receives a TWT acceptance from the secondary AP at 920, the STA transmits a TWT / TID switch frame to the primary AP at 925, notifying it that at least some traffic flow has transitioned to the secondary AP. The STA may then participate in the TWT service period negotiated with the secondary AP at 930.

[0101] As shown in FIG. 10 , in another exemplary method 1000, referred to as Procedure II, beacon frames may not be used to advertise the TWT of the primary AP (i.e., AP1), nor may beacon frames by secondary APs that allow inter-BSS STAs in the MAP SS to participate. Instead, in these embodiments, the STA may negotiate the TWT SP directly with the primary AP and / or secondary AP. In the exemplary method 1000 shown in FIG. 10 , there are two APs, AP1 and AP2, in the MAP SS, and the primary AP of the STA (i.e., STA11) is AP1 and the secondary AP is AP2. Therefore, STA11 is an intra-BSS STA with respect to AP1 and an inter-BSS STA with respect to AP2. In this example, STA11 may transmit a request frame 1002 (e.g., a TWT setup frame or other type of frame) requesting a TWT / rTWT schedule from AP1. AP1 may send a response frame 1004 (e.g., a TWT configuration frame or other type of frame) denying the request because AP1's TWT schedule is full (or for other reasons). STA11 may then send a request frame 1015 requesting a TWT / rTWT schedule from AP2, and AP2 may accept the request via response frame 1017. Note that one or more steps shown in Figure 10 may be combined or omitted entirely, as method 1000 of Figure 10 is intended to represent a particular scenario for general understanding.

[0102] As shown in the figure, STA11 may send a TWT configuration frame 1002 or other management / control frame to AP1 as a request to join a TWT / rTWT. The configuration frame 1002 may include one or more TWT elements and / or other elements / fields (e.g., C-MAP-related elements). In one example, the TWT element may include a negotiation type subfield set to 0 or 3 to indicate that this TWT element is used to negotiate an individual TWT schedule or a broadcast TWT schedule, a TWT setup command field set to request / demand / propose TWT, an inter-BSS STA indication subfield set to 0 to indicate that the STA is an intra-BSS STA with respect to AP1, and a TWT ID. As with the previous embodiment, the TWT ID field may be set to a value indicating the specific TWT the requesting STA intends to join or to a value indicating that the TWT ID is unknown.

[0103] In certain embodiments, information may be stored in the TWT element or other elements / fields / frames and aggregated and transmitted in the request frame 1002, 1015 sent by the STA 11. For example, information such as a virtual AP address / ID field identifying a virtual AP in the MAP SS, a primary AP address / ID field identifying the primary AP of the requesting STA, and / or a selected AP ID / address field indicating neighboring APs in the MAP SS with which the STA 11 can communicate or from which the STA 11 can receive signals in at least one modulation and coding scheme (MCS) may be stored in the C-MAP element. As an example, the STA 11 may need to measure received power, received signal strength indication (RSSI), signal-to-noise ratio (SNR), signal-to-noise ratio (SINR), or other air quality measurements for received signals from APs in the same MAP SS. If the measurement value exceeds a predefined / predetermined or signaled threshold, the STA may add the secondary AP to a selected AP list and report it to the primary AP.

[0104] As further shown in the example of FIG. 10, AP1 may send a response frame 1004 (e.g., a TWT configuration frame) or other management / control signal to STA11. AP1 may reject the TWT request 1002 and propose additional APs that can provide TWT opportunities within the MAP SS. If the negotiation type subfield is set to =2 or =3, the previous TWT process or definition may be modified to include the presence / validation of the restricted TWT schedule information subfield. In some embodiments, the response frames 1004, 1017 may include one or more TWT elements and / or other elements / fields (e.g., C-MAP-related elements). As an example, the TWT element may include a negotiation type subfield set to =2 or =3 to indicate that this TWT element is used to negotiate an individual or broadcast TWT schedule, respectively. If the negotiation type subfield is set to =3, a new rule is defined that enables the restricted TWT schedule information subfield, according to one embodiment. In this case, the Limited TWT Schedule Information subfield may be set to =2 to indicate that the TWT / rTWT schedule is full.

[0105] The exemplary TWT element may further include an Inter-BSS STA Indication subfield set to 1 to indicate the TWT responding STA (e.g., AP2) that allows the inter-BSS STA in the MAP SS to join, and a TWT Configuration Command Value subfield set to Rejected TWT (or other value) to indicate that the TWT request was rejected. One option is to indicate the reason for the rejection within the TWT element, e.g., rejection due to a full TWT schedule. The Responding TWT element may further include a TWT ID set to a value indicating the particular TWT for which the responding STA rejected the requesting STA to join.

[0106] The information may be transmitted in the TWT element or other elements / fields / frames, and may be aggregated and transmitted in a frame transmitted by AP1, including, for example, a virtual AP address / ID field identifying the virtual AP of the MAP SS, a primary AP address / ID field identifying the requesting STA's primary AP (e.g., AP1), a selected AP address / ID field identifying candidate secondary APs in the MAP SS (which may be able to provide TWT / rTWT opportunities to inter-BSS STAs in the MAP SS), and / or a temporary AID assignment field by which the primary AP (e.g., AP1) assigns a temporary AID to the TWT requesting STA (e.g., STA11) so that the requesting STA can identify itself when communicating with secondary APs in the MAP SS. In one embodiment, the temporary AID may have a finite validity period, for example, as provided by the primary AP.

[0107] If STA11 misses the TWT configuration frame 1004 from AP1, STA11 may have several options. For example, STA11 may continue to monitor beacon frames from its associated AP or from APs in its MAP SS. Additionally or alternatively, STA11 may retransmit the TWT configuration frame 1002 to AP1, or STA11 may transmit the TWT configuration frame to another AP (e.g., frame 1015 to AP2).

[0108] STA11 may check the "Selected AP Address / ID" field proposed by the primary AP and / or its own "Selected AP Address / ID" field to identify secondary APs that can provide TWT / rTWT opportunities to inter-BSS STAs in the MAP SS. Alternatively, STA11 may monitor beacon frames from other APs in the MAP SS to detect TWT / rTWT opportunities. STA11 may then transmit a TWT configuration frame 1015 or other management / control frame to the secondary AP (e.g., AP2) to request participation in AP2's TWT / rTWT. In some embodiments, the configuration request frame 1015 may include one or more TWT elements and / or other elements / fields (e.g., C-MAP-related elements). An example TWT element may include a Negotiation Type subfield set to 0 or 3 (indicating negotiating an individual / broadcast TWT schedule, respectively), a TWT Configuration Command field set to Request / Demand / Proposed TWT, an Inter BSS STA Indication subfield set to 1 (indicating the STA is an intra-BSS STA with respect to the AP), a TWT ID field, and / or Proposed TWT parameters. The TWT ID field may be set to a value indicating the specific TWT requested to join or to a value indicating that the TWT ID is unknown.

[0109] The information may be stored in this TWT element or in another element / field / frame and aggregated and transmitted in frame 1015 transmitted by STA11, and may include, for example, a virtual AP address / ID field identifying the virtual AP of the MAP SS, a primary AP address / ID field identifying the primary AP of the requesting STA, and / or a selected AP ID / address field indicating a TWT / rTWT schedule to which STA11 attempted to join a neighboring AP in the MAP SS but was rejected, which may be transmitted to the C-MAP element.

[0110] As shown in FIG. 10, AP2 may send a response frame 1017 (e.g., a TWT setup frame or other management / control messaging) to STA11 indicating that it may accept the TWT request. The response TWT setup frame 1017 may include one or more TWT elements and / or other elements / fields (e.g., C-MAP-related elements). An exemplary TWT element may include a negotiation type subfield set to =0 (individual TWT schedule) or =3 (broadcast TWT schedule), indicating that the TWT is used to negotiate an individual or broadcast TWT schedule, respectively. When the negotiation type subfield is set to =3, a new rule is provided that enables the restricted TWT schedule information subfield. In this case, the restricted TWT schedule information field is set to =1 to indicate that the TWT / rTWT schedule is enabled. The TWT element may further include an Inter BSS STA Indication field set to 1 to indicate that AP2 allows an Inter BSS STA (e.g., STA11) in the MAP SS to join, a TWT Configuration Command Value field set to Accept TWT (or other value) to indicate that the TWT request is accepted, and / or a TWT ID field set to a specific value to indicate the specific TWT in which the requesting STA (STA11) is allowed to join.

[0111] The information may be transmitted in the TWT element or a separate element / field / frame, and may be aggregated and transmitted in frame 1017 transmitted by AP2, including a Virtual AP Address / ID field identifying the virtual AP of the MAP SS, a Primary AP Address / ID field identifying the requesting STA's primary AP (e.g., AP1), and / or a Temporary AID Assignment field that allows the TWT responding STA (e.g., AP2) to assign a temporary AID to the inter-BSS TWT requesting STA (e.g., STA11) so that the TWT requesting STA can use it to identify itself within the accepted TWT SP. The temporary AID may have an expiration date. As an example, the temporary AID may be valid only for the validity period of the accepted TWT SP. The TWT element may further include the TSF timer or other timing-related parameters of the responding AP (AP2). The TSF timer field may be used by the inter-BSS STA (i.e., STA11) to synchronize with the secondary AP (i.e., AP2) and accurately estimate the start time of the TWT. In one example, a TSF offset field may be included to indicate the time difference between the primary AP and the responding AP.

[0112] If STA11 misses the TWT setting frame 1017 from AP2, STA11 may have several options. For example, STA11 may monitor beacon frames from its associated AP or from APs in its MAP SS. Additionally or alternatively, STA11 may retransmit the TWT setting frame 1015 to AP2, or STA11 may transmit another TWT setting frame to another AP (not shown).

[0113] Similar to step 1, in method 1000, STA11 may transmit a TWT / TID switch frame 1018 (or other management / control frame) to AP1 to indicate that a portion of the traffic flow for STA11 may need to be moved to another AP (e.g., AP2) within the MAP SS. The traffic switch may occur in one or more TWT service periods (SPs). An exemplary TWT / TID switch frame 1018 may include an AP ID / address field indicating a destination / secondary AP within the MAP set to which a portion of the traffic flow for STA11 needs to be moved, a TID information field indicating that traffic for the corresponding TID may be moved to AP2, a TWT ID field indicating a TWT schedule in which the STA will join the AP identified in the AP ID / address field to transmit the traffic flow identified in the TID information field, and / or a destination / secondary AP scheduling information field conveying scheduling information regarding the service period (SP) or set of SPs of the AP identified by the AP ID / address in which the STA will join. In one example, the scheduling information may include the start time of the SP, the duration of the SP, and if the SPs are consecutive, the time interval between two SPs.

[0114] AP1 may transfer data from STA11 to AP2 using one or more frames 1020. For example, AP1 may transfer the data using a relay-associated frame format. AP2 then starts TWT / rTWT at the scheduled time. The TWT SP may be a trigger-enabled TWT 1023 or a trigger-disabled TWT. After the TWT SP or after multiple TWT SPs, AP2 may transfer data from STA11 to AP1 using one or more frames 1035. For example, AP2 may use a relay-associated frame format to transfer the data.

[0115] Referring to FIG. 11 , a method 1100 for a STA operating in Procedure II is shown. First, the STA transmits a request frame to a primary AP in a MAP SS requesting TWT acceptance into the primary AP's TWT schedule 1105. The STA receives a TWT response from the primary AP 1110. If the received TWT response denies the STA participation in the primary AP's TWT schedule (because it is full, for other reasons, or because the response was lost) 1115, the STA may transmit a TWT request to a secondary AP in the MAP SS, where the secondary AP is identified using the instructions or determination in any of the above-described embodiments 1120. The STA receives a TWT response from the secondary AP 1125. If the received TWT response also does not permit the STA to participate in TWT 1130, the STA may continue to request TWT participation from the primary AP or another secondary AP in the MAP SS (or both) until it is permitted to participate in the TWT schedule of the responding AP 1135.

[0116] If the access point granting the TWT is not the primary AP (i.e., the granting access point is a secondary AP) 1140, the STA sends a TWT / TID switch frame informing the primary AP of the traffic flow movement as described above, and the STA uses the TWT for the negotiated service period granted by the granting access point 1150.

[0117] Note that in steps I and II above, TWT schedule full is used as the reason for TWT / rTWT transfer between APs in a MAP SS, but transfers may also be triggered by other reasons. Note that the terms field and subfield may be used interchangeably.

[0118] In another embodiment, referred to as exemplary procedure III, APs / STAs within a MAP SS, or APs supporting coordinated multi-AP transmission or coordinated MAP TWT transmission, may automatically support inter-BSS TWT operation. During the association procedure, the AP and STA may exchange capabilities to support coordinated multi-AP transmission or coordinated MAP TWT transmission. In this case, the TWT elements transmitted by the AP and STA may enable inter-BSS TWT operation without explicit notification. Thus, STAs may request TWT directly from the primary and secondary APs. The AP may advertise TWT and accept membership from associated STAs and inter-BSS STAs within the MAP SS. In this way, TWT operation may be performed at the MAP level rather than per AP level.

[0119] Enhanced TWT elements are described below. As disclosed in the following embodiments, a predefined TWT element may need to be modified to include full or partial MAP TWT related information. In one example, a new subfield "Inter BSS Indication" may be defined for the TWT element using one or more reserved bits. For example, the control field of the TWT element is modified as shown in Table 1 below. The modified control field includes an "Inter BSS Indication" subfield.

[0120] [Table 1]

[0121] In one embodiment, if the Inter BSS Indication bit is set, more detailed MAP-related information may be included in the TWT element. For example, a MAP SS Information subfield may be present, as shown in Tables 2 and 3 below. This subfield may be optionally present if the Inter BSS Indication subfield is set to 1.

[0122] [Table 2]

[0123] [Table 3]

[0124] An exemplary MAP SS Information subfield has the format shown in Table 4 and may include one or more of the following fields / subfields: a Virtual AP Address / ID field identifying a virtual AP of the MAP SS; a Primary AP Address / ID field identifying the primary AP of the requesting STA; and / or a Selected AP ID / Address field. The meaning of the last-listed field may depend on the associated Sender Role subfield. If the Sender Role subfield indicates that the sender is a non-AP STA, the Selected AP ID / Address field may indicate a neighboring AP in the MAP SS with which the STA can communicate. If the Sender Role subfield indicates that the sender is an AP, the Selected AP ID / Address field may indicate a neighboring AP in the MAP SS that the AP recommends for communication with the STA and / or that provides a TWT schedule similar to one the STA may request. For example, the Selected AP ID / Address field may indicate an AP in the MAP SS that provides a TWT schedule similar to one the STA may request. In one example, this field is a bitmap, with each bit indicating whether the corresponding AP is selected / recommended. The size of the bitmap may depend on the number of active APs in the MAP SS.

[0125] The Temporary AID subfield allows the TWT Responding STA (e.g., AP2) to assign a temporary AID to the Inter-BSS TWT Requesting STA (e.g., STA11), which the TWT Requesting STA may use to identify itself in the accepted TWT SP. If the Sender Role subfield indicates that the sender of the TWT element is an AP, this field may additionally be present and the TWT Configuration Command Value subfield may be set to "Accept TWT".

[0126] The TSF subfield can be used by inter-BSS STAs to synchronize with the secondary AP and accurately estimate the start time of the TWT. In one approach, the TSF field can indicate the time difference or TSF offset between the primary AP and the secondary AP. In another approach, it can include part of the timestamp field. For example, if the timestamp field is 8 octets, this TSF field can carry bits n through m of the timestamp field, where 0≦n≦m≦63.

[0127] [Table 4]

[0128] Although the features and components of the present invention are described in particular combinations in preferred embodiments, each feature or component can be used alone without the other features and components of the preferred embodiments, or can be used in various combinations with or without the other features and components of the present invention.

[0129] Although the solutions described herein take into account 802.11 specific protocols, it is understood that the solutions described herein are not limited to this scenario and are applicable to other wireless systems as well.

[0130] Although the design and procedure examples use SIFS to illustrate various interframe spacings, any other interframe spacing, such as RIFS, AIFS, DIFS, or any other agreed-upon time interval, is applicable to the same solution.

[0131] Some figures may show 4 RBs per TXOP as an example, but the actual number of RBs / channels / bandwidth used may vary.

[0132] In the embodiments, a full schedule is used as an example to indicate that the AP may not be able to accept a TWT request from a non-AP STA in the above procedure, but there may be other reasons or different signaling that indicate that the AP will not accept a TWT request, and therefore the embodiments are not limited in this respect.

[0133] While features or elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features or elements. Furthermore, the methods described herein may be implemented as a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in conjunction with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method for a station (STA), comprising: receiving an indication from a primary access point (AP) that the primary AP does not provide target wake time (TWT) operation for the STA; monitoring beacons from one or more secondary APs in a multi-access point (MAP) service set (SS) for indications indicating that the one or more secondary APs will accept overlapping basic service set (OBSS) STAs requesting an available TWT schedule; sending a TWT configuration message to a secondary AP among the one or more secondary APs; receiving a TWT accept message from the secondary AP, the TWT accept message including an indication of a TWT service period (SP); A method comprising:

2. The method of claim 1 , further comprising: transmitting a TWT traffic identifier (TID) switch frame to the primary AP indicating that the STA's traffic flow has been transferred to the secondary AP.

3. 2. The method of claim 1, wherein the indication received from the primary AP comprises a beacon frame including a Cooperative MAP (C-MAP) element indicating at least one of the one or more secondary AP or virtual AP identifiers in the MAP SS.

4. 2. The method of claim 1, wherein monitoring beacons from the one or more secondary APs comprises determining whether the monitored beacons indicate APs that allow inter-BSS STAs in the MAP SS to participate in TWT or restricted TWT (rTWT).

5. The method of claim 3 , wherein the virtual AP identifier specifies a virtual AP that includes logical entities associated with the primary AP and the one or more secondary APs in the MAP SS.

6. The method of claim 1 , wherein the TWT setup message includes an Inter-BSS STA indication subfield indicating that the STA is associated with an AP of the MAP SS.

7. The method of claim 3 , wherein the C-MAP element includes an ID of the primary AP in the MAP SS and a media access control (MAC) address or ID that identifies the virtual AP.

8. 2. The method of claim 1, wherein the TWT accept message includes a temporary association ID (AID) for the STA to identify itself as an inter-BSS TWT STA in the accepted TWT service period (SP).

9. A station (STA), a transceiver and a processor communicatively connected to the transceiver, wherein the transceiver and the processor: receiving an indication from a primary access point (AP) that the primary AP does not provide target wake time (TWT) operation for the STA; monitoring beacons from one or more secondary APs in a multi-access point (MAP) service set (SS) for indications indicating that the one or more secondary APs will accept overlapping basic service set (OBSS) STAs requesting an available TWT schedule; Sending a TWT configuration message to one secondary AP of the one or more secondary APs; receiving a TWT accept message from the secondary AP, the TWT accept message including an indication of a TWT service period (SP); The STA is configured as follows.

10. The STA of claim 9 , wherein the transceiver and the processor are further configured to transmit a TWT traffic identifier (TID) switch frame to the primary AP indicating that the STA's traffic flow has been transferred to the secondary AP.

11. 10. The STA of claim 9, wherein the indication received from the primary AP comprises a beacon frame including a cooperative MAP (C-MAP) element indicating at least one of the one or more secondary AP or virtual AP identifiers in the MAP SS.

12. 10. The STA of claim 9, wherein monitoring beacons from the one or more secondary APs comprises the transceiver and the processor configured to determine whether the monitored beacons indicate an AP that allows inter-BSS STAs in the MAP SS to participate in TWT or restricted TWT (rTWT).

13. The STA of claim 11 , wherein the virtual AP identifier specifies a virtual AP that includes logical entities associated with the primary AP and the one or more secondary APs in the MAP SS.

14. The STA of claim 9 , wherein the TWT setup message includes an Inter-BSS STA indication subfield indicating that the STA is associated with an AP of the MAP SS.

15. The STA of claim 11 , wherein the C-MAP element includes an ID of the primary AP in the MAP SS and a media access control (MAC) address or ID that identifies the virtual AP.

16. 10. The STA of claim 9, wherein the TWT accept message includes a temporary association ID (AID) for the STA to identify itself as an inter-BSS TWT STA during the accepted TWT service period (SP).

17. A method for an access point (AP), comprising: Sending an indication to an associated station (STA) in a multi-AP (MAP) service set (SS) that the AP will not provide target wake time (TWT) operation to the STA, the indication including identification information of one or more secondary APs in the MAP SS that may accept overlapping basic service set (OBSS) STAs to participate in the TWT; receiving a TWT traffic identifier (TID) switch frame from the associated STA, indicating that the traffic flow of the associated STA has been forwarded to one of the one or more secondary APs in a MAP SS, after the secondary AP accepts a TWT configuration request from the STA; A method for providing

18. 18. The method of claim 17, wherein the transmitted indication comprises a beacon frame including a Cooperative MAP (C-MAP) element indicating the one or more secondary APs and virtual AP identifiers in the MAP SS.

19. The method of claim 18 , wherein the virtual AP identifier specifies a virtual AP that includes logical entities associated with the AP and the one or more secondary APs in the MAP SS.

20. The method of claim 18, wherein the C-MAP element includes a Media Access Control (MAC) address or ID that identifies the virtual AP.

Images