Method and apparatus for performing target waketime-based communication in a wireless LAN system

Abstract

A method and apparatus for operating in a wireless LAN system are disclosed. In one embodiment of the present disclosure, a method performed by an STA in a wireless LAN system includes the steps of receiving a first frame from a first access point (AP) including a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field, and decoding the first frame, wherein the first broadcast TWT parameter set includes first information and a first broadcast TWT identifier (ID) related to a first restricted TWT (R-TWT) service period (SP) scheduled by the first AP, and the second information and second TWT ID related to a second R-TWT SP scheduled by the second AP may be included in the second broadcast TWT parameter set.

Description

Technical Field

[0001] The present disclosure relates to communication operations in a wireless local area network (WLAN) system, and more particularly, to a method and apparatus for performing target wake time (TWT)-based communication in a next-generation wireless LAN system.

Background Art

[0002] New technologies for improving the transmission rate, increasing the bandwidth, improving the reliability, reducing errors, and reducing latency in a wireless local area network (WLAN) have been introduced. Among wireless LAN technologies, the IEEE (Institute of Electrical and Electronics Engineers) 802.11 series of standards can be referred to as Wi-Fi. For example, technologies recently introduced into the wireless LAN include enhancements for the very high throughput (VHT) of the 802.11ac standard, enhancements for the high efficiency (HE) of the IEEE 802.11ax standard, and the like.

[0003] In order to provide a more improved wireless communication environment, improvement technologies for extremely high throughput (EHT) are being discussed. For example, technologies for increased bandwidth, efficient utilization of multiple bands, multiple input multiple output (MIMO) to support increased spatial streams, and technologies for multi-access point (AP) coordination are being studied. In particular, various technologies for supporting traffic with low latency or real-time characteristics are being studied. In addition, new technologies for supporting ultra-high reliability (UHR), including improvements or extensions of EHT technology, are being discussed.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The technical problem addressed by this disclosure is to provide a method and apparatus for performing TWT-based communication in a wireless LAN system.

[0005] The technical problem addressed in this disclosure is to provide a method and apparatus for performing operations on a restricted-time-to-Wt (R) service period (SP) scheduled by a neighboring AP in a multi-basic service set (BSS) environment.

[0006] The technical challenges addressed in this disclosure are not limited to those mentioned above, and other technical challenges not mentioned will be clearly understood by those with ordinary skill in the art to which this disclosure pertains from the following description. [Means for solving the problem]

[0007] A method performed by a station (STA) in a wireless LAN system according to one embodiment of the present disclosure includes the steps of receiving a first frame from a first access point (AP) including a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field, and decoding the first frame, wherein the first broadcast TWT parameter set includes first information and a first broadcast TWT identifier (ID) related to a first restricted TWT (R-TWT) service period (SP) scheduled by the first AP, and the second information and second TWT ID related to a second R-TWT SP scheduled by the second AP may be included in the second broadcast TWT parameter set.

[0008] In yet another embodiment of the present disclosure, a method performed by a first access point (AP) in a wireless LAN system includes the steps of: receiving second information relating to a second restricted target wake time (R-TWT) service period (SP) from a second AP; and transmitting a first beacon frame containing first information relating to a first R-TWT SP and the second information to a first station (STA), wherein the first beacon frame includes a first broadcast TWT parameter set field and a second broadcast TWT parameter set field, the first broadcast TWT parameter set field includes the first information and a first broadcast TWT ID, and the second broadcast TWT parameter set field may include the second information and a second broadcast TWT ID. [Effects of the Invention]

[0009] Various embodiments of this disclosure can provide a method and apparatus for performing TWT-based communication in a wireless LAN system.

[0010] Various embodiments of this disclosure provide a method and apparatus for performing operations on R-TWT SPs scheduled by neighboring APs in a multi-BSS environment.

[0011] Various embodiments of this disclosure can provide a method and apparatus for protecting the OBSS (overlapping basic service set) R-TWT SP announced by AP.

[0012] The effects derived from this disclosure are not limited to those mentioned above, and any other effects not mentioned above will be clearly understood by a person with ordinary skill in the art to which this disclosure pertains from the following description. [Brief explanation of the drawing]

[0013] The accompanying drawings, included as part of the detailed description to aid in understanding this disclosure, provide examples of the disclosure and illustrate the technical features of the disclosure together with the detailed description. [Figure 1] This is a block diagram illustrating an example of a wireless communication device according to one embodiment of the present disclosure. [Figure 2] This figure shows an exemplary structure of a wireless LAN system to which this disclosure can be applied. [Figure 3] This diagram illustrates the link setup process to which this disclosure applies. [Figure 4] This diagram illustrates the backoff process to which this disclosure applies. [Figure 5] This diagram illustrates the CSMA / CA baseframe transmission operation to which this disclosure can be applied. [Figure 6] This figure illustrates an example of a frame structure used in a wireless LAN system to which this disclosure can be applied. [Figure 7] This figure shows an example of a PPDU as defined in the IEEE 802.11 standard to which this disclosure applies. [Figure 8] This figure illustrates an example of individual TWT operation to which this disclosure can be applied. [Figure 9] This figure illustrates an example of a broadcast TWT operation to which this disclosure can be applied. [Figure 10] This diagram illustrates an example of the TWT information element format. [Figure 11] This is a diagram illustrating an example of the individual TWT parameter set field format. [Figure 12] This is a diagram illustrating an example of the broadcast TWT parameter set field format. [Figure 13] This diagram illustrates an example of a field format related to restricted TWT operation. [Figure 14]A diagram for explaining a method by which a STA performs an overhearing operation in a multi-BSS environment according to an embodiment of the present disclosure. [Figure 15] A flowchart for explaining the operation of a STA according to an embodiment of the present disclosure. [Figure 16] A diagram for explaining the operation of a first AP according to an embodiment of the present disclosure. [Figure 17] A diagram for explaining the operation by which a STA protects an OBSS R-TWT SP according to an embodiment of the present disclosure. [Figure 18] A diagram for explaining the configuration of a field including information related to an OBSS R-TWT according to an embodiment of the present disclosure. [Figure 19] A diagram for explaining the operation of an AP for making an OBSS R-TWT SP known according to an embodiment of the present disclosure. [Figure 20] A diagram for explaining the operation of an AP for making an overlapping silence interval known according to an embodiment of the present disclosure. [Figure 21] A diagram for explaining an AP's R-TWT SP notification method according to STA types according to an embodiment of the present disclosure. [Figure 22] A diagram for explaining the TB PPDU transmission / reception procedure between a transmitting STA and a receiving STA according to an example of the present disclosure.

Mode for Carrying Out the Invention

[0014] Hereinafter, preferred embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. The detailed description disclosed below together with the accompanying drawings is for explaining exemplary embodiments of the present disclosure and is not for showing the only embodiments in which the present disclosure can be implemented. The following detailed description includes specific details for providing a complete understanding of the present disclosure. However, it is understood by those skilled in the art that the present disclosure can be implemented without such specific details.

[0015] In some cases, to avoid ambiguity of the concepts in this disclosure, known structures and devices may be omitted, or they may be shown in the form of block diagrams focusing on the core function of each structure and device.

[0016] In this disclosure, when one component is “connected,” “joined,” or “linked” to another component, this may include not only a direct connection but also an indirect connection in which other components exist between them. Also, in this disclosure, the terms “includes” or “have” identify the presence of the referred features, stages, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, stages, operations, elements, components and / or groups thereof.

[0017] In this disclosure, terms such as "first," "second," etc., are used solely to distinguish one component from another, and are not used to limit the components, nor do they limit the order or importance of the components unless specifically mentioned. Therefore, within the scope of this disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment may be referred to as a first component in another embodiment.

[0018] The terms used in this disclosure are for illustrative purposes relating to specific embodiments and are not intended to limit the scope of the claims. As used in the description of the embodiments and in the attached claims, singular forms are intended to include plural forms unless otherwise specified in the context. The terms "and / or" used in this disclosure may refer to one of the related enumerated items, or to any and all possible combinations of two or more of them. In this disclosure, a " / " between words has the same meaning as "and / or" unless otherwise specified.

[0019] The examples in this disclosure may be applied to various wireless communication systems. For example, the examples in this disclosure may be applied to wireless LAN systems. For example, the examples in this disclosure may be applied to IEEE 802.11a / g / n / ac / ax standard-based wireless LANs. Furthermore, the examples in this disclosure may be applied to newly proposed IEEE 802.11bn (or UHR) standard-based wireless LANs. In addition, the examples in this disclosure may be applied to next-generation standard-based wireless LANs following IEEE 802.11bn. Moreover, the examples in this disclosure may be applied to cellular wireless communication systems. For example, they may be applied to cellular wireless communication systems based on 3GPP (3rd Generation Partnership Project: registered trademark: hereinafter the same) standard LTE (Long Term Evolution) series technologies and 5G NR (New Radio) series technologies.

[0020] The following describes the technical features to which the examples in this disclosure may apply.

[0021] Figure 1 is a block diagram illustrating an example of a wireless communication device according to one embodiment of the present disclosure.

[0022] The first device 100 and the second device 200 illustrated in Figure 1 may be replaced with various terms such as terminal, wireless device, WTRU (Wireless Transmit Receive Unit), UE (User Equipment), MS (Mobile Station), UT (user terminal), MSS (Mobile Subscriber Station), MSS (Mobile Subscriber Unit), SS (Subscriber Station), AMS (Advanced Mobile Station), WT (Wireless terminal), or simply user. Furthermore, the first device 100 and the second device 200 may be replaced with various terms such as access point (AP), BS (Base Station), fixed station, Node B, BTS (base transceiver system), network, AI (Artificial Intelligence) system, RSU (roadside unit), repeater, router, relay, gateway, etc.

[0023] The devices 100 and 200 illustrated in Figure 1 can also be referred to as stations (STA). For example, the devices 100 and 200 illustrated in Figure 1 can be referred to by various terms such as transmitting device, receiving device, transmitting STA, and receiving STA. For example, STA 110 and 200 can play the role of an AP (access point) or a non-AP. That is, in this disclosure, STA 110 and 200 may have AP and / or non-AP functions. When STA 110 and 200 have AP functions, they can simply be called APs, and when STA 110 and 200 have non-AP functions, they can simply be called STAs. In addition, in this disclosure, AP may be represented as AP STA.

[0024] Referring to Figure 1, the first device 100 and the second device 200 can send and receive wireless signals using various wireless LAN technologies (e.g., the IEEE 802.11 series). The first device 100 and the second device 200 may include interfaces to the medium access control (MAC) layer and the physical layer (PHY) in accordance with the IEEE 802.11 standard.

[0025] Furthermore, the first device 100 and the second device 200 can also further support various communication standards other than Wi-Fi technology (e.g., 3GPP LTE series, 5G NR series standards, etc.). The devices of this disclosure may also be embodied in various devices such as mobile phones, vehicles, personal computers, Augmented Reality (AR) equipment, and Virtual Reality (VR) equipment. In addition, the STA of this specification can support various communication services such as voice calls, video calls, data communication, autonomous driving, Machine-Type Communication (MTC), Machine-to-Machine (M2M), Device-to-Device (D2D), and Internet of Things (IoT).

[0026] The first device 100 includes one or more processors 102 and one or more memories 104, and may further include one or more transceivers 106 and / or one or more antennas 108. The processor 102 may control the memories 104 and / or the transceivers 106 and be configured to embody the descriptions, functions, procedures, suggestions, methods and / or operation diagrams of this disclosure. For example, the processor 102 may process information in the memory 104 to generate first information / signals and then transmit a radio signal containing the first information / signals via the transceiver 106. Alternatively, the processor 102 may receive a radio signal containing second information / signals via the transceiver 106 and then store information obtained from signal processing of the second information / signals in the memory 104. The memory 104 may be linked to the processor 102 and can store various information relating to the operation of the processor 102. For example, memory 104 may store software code that executes some or all of a process controlled by processor 102, or that contains instructions for executing the descriptions, functions, procedures, suggestions, methods and / or operation sequence diagrams in this disclosure. Here, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to embody wireless LAN technology (e.g., IEEE 802.11 series). Transceiver 106 may be coupled with processor 102 and can transmit and / or receive radio signals via one or more antennas 108. Transceiver 106 may include a transmitter and / or receiver. Transceiver 106 may be used synonymously with RF (Radio Frequency) unit. In this disclosure, device may also mean communication modem / circuit / chip.

[0027] The second device 200 includes one or more processors 202, one or more memories 204, and may further include one or more transceivers 206 and / or one or more antennas 208. The processor 202 may control the memories 204 and / or the transceivers 206 and be configured to embody the descriptions, functions, procedures, suggestions, methods and / or operation sequence diagrams disclosed herein. For example, the processor 202 may process information in the memory 204 to generate third information / signals and then transmit a radio signal containing the third information / signals via the transceiver 206. Alternatively, the processor 202 may receive a radio signal containing fourth information / signals via the transceiver 206 and then store information obtained from signal processing of the fourth information / signals in the memory 204. The memory 204 may be linked to the processor 202 and can store various information related to the operation of the processor 202. For example, memory 204 may store software code that executes some or all of the processes controlled by processor 202, or that contains instructions for executing the descriptions, functions, procedures, suggestions, methods and / or operation sequence diagrams disclosed in this disclosure. Here, processor 202 and memory 204 may be part of a communication modem / circuit / chip designed to embody wireless LAN technology (e.g., IEEE 802.11 series). Transceiver 206 may be coupled with processor 202 and may transmit and / or receive radio signals via one or more antennas 208. Transceiver 206 may include a transmitter and / or receiver. Transceiver 206 may be used synonymously with RF unit. In this disclosure, device may also mean communication modem / circuit / chip.

[0028] The hardware elements of devices 100,200 are described in more detail below. However, one or more protocol layers may be embodied by one or more processors 102,202. For example, one or more processors 102,202 can embodied one or more layers (e.g., functional layers such as PHY and MAC). One or more processors 102,202 can generate one or more PDUs (Protocol Data Units) and / or one or more SDUs (Service Data Units) by means of the descriptions, functions, procedures, proposals, methods and / or operation sequence diagrams in this disclosure. One or more processors 102,202 can generate messages, control information, data, or information by means of the descriptions, functions, procedures, proposals, methods and / or operation sequence diagrams in this disclosure. One or more processors 102,202 can generate signals (e.g., baseband signals) containing PDUs, SDUs, messages, control information, data, or information by the functions, procedures, proposals and / or methods of this disclosure and provide them to one or more transceivers 106,206. One or more processors 102,202 can receive signals (e.g., baseband signals) from one or more transceivers 106,206 and obtain PDUs, SDUs, messages, control information, data, or information by the descriptions, functions, procedures, proposals, methods and / or operation sequence diagrams of this disclosure.

[0029] One or more processors 102,202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102,202 may be embodied by hardware, firmware, software, or a combination thereof. For example, one or more ASICs (Application Specific Integrated Circuits), one or more DSPs (Digital Signal Processors), one or more DSPDs (Digital Signal Processing Devices), one or more PLDs (Programmable Logic Devices), or one or more FPGAs (Field Programmable Gate Arrays) may be included in one or more processors 102,202. The descriptions, functions, procedures, proposals, methods and / or operation sequence diagrams disclosed in this disclosure may be embodied using firmware or software, and the firmware or software may be embodied to include modules, procedures, functions, etc. Firmware or software configured to perform the descriptions, functions, procedures, suggestions, methods and / or sequence diagrams disclosed in this disclosure may be contained in one or more processors 102,202 or stored in one or more memories 104,204 and driven by one or more processors 102,202. The descriptions, functions, procedures, suggestions, methods and / or sequence diagrams disclosed in this disclosure may be embodied by firmware or software in the form of code, instructions and / or sets of instructions.

[0030] One or more memories 104,204 may be connected to one or more processors 102,202 and can store various forms of data, signals, messages, information, programs, code, instructions and / or commands. One or more memories 104,204 may consist of ROM, RAM, EPROM, flash memory, hard drives, registers, cache memory, computer-readable storage media and / or combinations thereof. One or more memories 104,204 may be located inside and / or outside of one or more processors 102,202. Furthermore, one or more memories 104,204 may be connected to one or more processors 102,202 by various technologies such as wired or wireless connections.

[0031] One or more transceivers 106,206 can transmit user data, control information, radio signals / channels, etc., as referred to in the methods and / or operation sequence diagrams of this disclosure, to one or more other devices. One or more transceivers 106,206 can receive user data, control information, radio signals / channels, etc., as referred to in the descriptions, functions, procedures, proposals, methods and / or operation sequence diagrams disclosed in this disclosure, from one or more other devices. For example, one or more transceivers 106,206 may be coupled with one or more processors 102,202 to transmit and receive radio signals. For example, one or more processors 102,202 can control one or more transceivers 106,206 to transmit user data, control information or radio signals to one or more other devices. Also, one or more processors 102,202 can control one or more transceivers 106,206 to receive user data, control information or radio signals from one or more other devices. Furthermore, one or more transceivers 106,206 may be connected to one or more antennas 108,208, and one or more transceivers 106,206 may be configured to transmit and receive user data, control information, radio signals / channels, etc., as referred to in the descriptions, functions, procedures, proposals, methods and / or operation sequence diagrams disclosed in this disclosure, via one or more antennas 108,208. In this disclosure, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers 106,206 may convert the received user data, control information, radio signals / channels, etc., from RF band signals to baseband signals for processing using one or more processors 102,202. One or more transceivers 106,206 may convert the user data, control information, radio signals / channels, etc., processed by one or more processors 102,202, from baseband signals to RF band signals. To this end, one or more transceivers 106,206 may include (analog) oscillators and / or filters.

[0032] For example, either STA100 or STA200 can perform the intended operation of an AP, and the other STA100 or STA200 can perform the intended operation of a non-AP STA. For example, the transceivers 106 and 206 in Figure 1 can perform the transmission and reception of signals (e.g., packets or PPDUs (Physical Layer Protocol Data Units) conforming to IEEE 802.11a / b / g / n / ac / ax / be / bn, etc.). Furthermore, in this disclosure, the operation of various STAs generating transmission and reception signals or performing data processing and calculations in advance for transmission and reception signals may be performed by the processors 102 and 202 in Figure 1. For example, an example of an operation that generates transmit / receive signals or performs data processing or calculations in advance for transmit / receive signals may include: 1) an operation to determine / acquire / construct / calculate / decode / encode bit information of fields contained within the PPDU (SIG (signal), STF (short training field), LTF (long training field), Data, etc.); 2) an operation to determine / construct / acquire time resources and frequency resources (e.g., subcarrier resources) used for fields contained within the PPDU (SIG, STF, LTF, Data, etc.); 3) an operation to determine / construct / acquire specific sequences (e.g., pilot sequence, STF / LTF sequence, extra sequence applied to SIG) used for fields contained within the PPDU (SIG, STF, LTF, Data, etc.); 4) power control operations and / or power saving operations applied to the STA; and 5) operations related to determining / acquiring / constructing / calculating / decoding / encoding the ACK signal. Furthermore, in the following example, various pieces of information used by various STAs for determining / acquiring / composing / calculating / decoding / encoding the transmit / receive signals (e.g., information about fields / subfields / control fields / parameters / power, etc.) may be stored in memories 104,204 in Figure 1.

[0033] In the following, downlink (DL) refers to the link for communication from AP STA to non-AP STA, and downlink PPDU / packets / signals, etc., may be transmitted and received through the downlink. In downlink communication, the transmitter may be part of AP STA, and the receiver may be part of non-AP STA. Uplink (UL) refers to the link for communication from non-AP STA to AP STA, and uplink PPDU / packets / signals, etc., may be transmitted and received through the uplink. In uplink communication, the transmitter may be part of non-AP STA, and the receiver may be part of AP STA.

[0034] Figure 2 shows an exemplary structure of a wireless LAN system to which this disclosure can be applied.

[0035] The structure of a wireless LAN system may consist of multiple components. A wireless LAN may be provided that supports transparent STA mobility to higher layers through the interaction of multiple components. A BSS (Basic Service Set) corresponds to the basic structural block of a wireless LAN. Figure 2 illustrates the existence of two BSSs (BSS1 and BSS2), with each BSS containing two STAs as members (STA1 and STA2 are included in BSS1, and STA3 and STA4 are included in BSS2). In Figure 2, the ellipses representing the BSSs may be understood as representing the coverage area where the STAs included in that BSS maintain communication. This area can be called a BSA (Basic Service Area). When an STA moves outside a BSA, it can no longer communicate directly with other STAs within that BSA.

[0036] Ignoring the DS shown in Figure 2, the most basic type of BSS in a wireless LAN is the Independent BSS (IBSS). For example, an IBSS can have a minimal form consisting of only two STAs. For instance, assuming other components are omitted, BSS1 consisting only of STA1 and STA2, or BSS2 consisting only of STA3 and STA4, could be considered typical examples of an IBSS. Such a configuration is possible when STAs can communicate directly without APs. Furthermore, this type of wireless LAN is not pre-planned and configured, but can be configured when the LAN requires it, and can be called an ad-hoc network. Since an IBSS does not include APs, there is no centralized management entity. That is, in an IBSS, STAs are managed in a distributed manner. In an IBSS, all STAs may be mobile STAs, and connection to a distributed system (DS) is not permitted, forming a self-contained network.

[0037] STA membership in the BSS can change dynamically due to actions such as STAs being added or removed, or STAs entering or leaving the BSS area. To become a member of the BSS, an STA can join the BSS using a synchronization process. To access all services of the BSS-based structure, an STA must be associated with the BSS. Such associations may be configured dynamically and may include the use of Distribution System Services (DSS).

[0038] In a wireless LAN, the direct distance between STAs may be limited by the PHY performance. While this distance limit may be sufficient in some cases, there may be situations requiring communication between STAs over longer distances. Distributed systems (DS) may be configured to support extended coverage.

[0039] DS refers to a structure in which BSSs are interconnected. Specifically, as shown in Figure 2, BSSs may exist as components of an extended form of a network composed of multiple BSSs. DS is a logical concept and may be identified by the characteristics of the Distributed System Medium (DSM). In this regard, Wireless Medium (WM) and DSM may be logically distinct. Each logical medium is used for a different purpose and by different components. These mediums are neither limited to being the same nor limited to being different. The flexibility of wireless LAN structures (DS structures or other network structures) can be explained by the fact that multiple mediums are logically distinct from one another. That is, wireless LAN structures can be embodied in various ways, and each embodied example may be identified independently by its physical characteristics.

[0040] DS can support mobile devices by providing seamless integration of multiple BSSs and offering the necessary logical services for handling destination addresses. DS may also include a portal component that acts as a bridge for connecting wireless LANs with other networks (e.g., IEEE 802.X).

[0041] An AP (Application Programming Object) is an entity that enables a coupled non-AP STA (Systematization System) to access the DS (Data Storage System) via the WM (Web Module) and also possesses the functionality of an STA. Data can be moved between the BSS (Base System Storage) and the DS via the AP. For example, STA2 and STA3, shown in Figure 2, possess the functionality of an STA while also providing the ability for coupled non-AP STAs (STA1 and STA4) to access the DS. Furthermore, since all APs are essentially STAs, all APs are addressable entities. The address used by the AP for communication on the WM and the address used by the AP for communication on the DSM (Data Storage System) do not necessarily have to be the same. A BSS consisting of an AP and one or more STAs can be called an infrastructure BSS.

[0042] Data transmitted from one of the STAs connected to an AP to the AP's STA address is always received on an uncontrolled port and may be processed by an IEEE 802.1X port access entity. Alternatively, once a controlled port is authenticated, the transmitted data (or frame) may be forwarded to a DS.

[0043] An Extended Service Set (ESS) may be added to the aforementioned DS structure to provide even broader coverage.

[0044] An ESS (Service Set Network) refers to a network of arbitrary size and complexity composed of DSs (Distributed Service Sets) and BSSs (Blockchain Service Sets). An ESS can be a collection of BSSs connected to a single DS. However, an ESS cannot contain a DS. A key feature of an ESS network is that it appears as an IBSS (Internet Link Control Service Set) at the LLC (Logical Link Control) layer. STAs (Stage Attacks) within an ESS can communicate with each other, and mobile STAs can move transparently to the LLC from one BSS to another (within the same ESS). APs (Access Points) within an ESS may have the same SSID (Service Set Identification). An SSID is distinct from a BSSID, which is the identifier for a BSS.

[0045] In wireless LAN systems, no assumptions are made regarding the relative physical location of BSSs, and any of the following forms are possible: BSSs may partially overlap, which is a commonly used form to provide continuous coverage. BSSs do not have to be physically connected, and logically there is no limit to the distance between BSSs. BSSs may also be located in the same physical location, which may be used to provide redundancy. One (or more) IBSS or ESS networks may physically exist in the same space as one (or more) ESS networks. This may include ESS network configurations when an ad hoc network operates in the location where an ESS network exists, when physically overlapping wireless networks are configured by different organizations, or when two or more different access and security policies are required at the same location.

[0046] Figure 3 is a diagram illustrating the link setup process to which this disclosure can be applied.

[0047] For an STA to set up a link to a network and send and receive data, it must first discover the network, perform authentication, establish an association, and carry out security authentication procedures. The link setup process can be called the session initiation process or session setup process. Alternatively, the discovery, authentication, association, and security setting processes of the link setup process can be collectively referred to as the association process.

[0048] In step S310, the STA can perform a network discovery operation. The network discovery operation may include the STA's scanning operation. That is, in order for the STA to access a network, it must find a network that it can join. Before joining a wireless network, the STA must identify a compatible network, and the process of identifying networks in a specific area is called scanning.

[0049] There are two scanning methods: active scanning and passive scanning. Figure 3 illustrates a network discovery operation that includes the active scanning process. In active scanning, the STA performing the scanning sends a probe request frame to search for nearby APs while moving between channels, and waits for a response. The responder sends a probe response frame to the STA that sent the probe request frame. Here, the responder may be the STA that last sent a beacon frame in the BSS of the channel being scanned. In BSS, APs send beacon frames, so APs become the responders, while in IBSS, STAs within IBSS alternately send beacon frames, so the responders are not constant. For example, an STA that sends a probe request frame on channel 1 and receives a probe response frame on channel 1 can save the BSS-related information contained in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning in the same way (i.e., send and receive probe requests / responses on channel 2).

[0050] Although not shown in Figure 3, scanning may also be performed using a passive scanning method. In passive scanning, the STA performing the scanning waits for beacon frames while switching channels. A beacon frame is one of the management frames defined in IEEE 802.11, and is transmitted periodically to announce the presence of a wireless network, allowing the scanning STA to find and join the wireless network. In BSS, APs are responsible for periodically transmitting beacon frames, while in IBSS, STAs within IBSS transmit beacon frames alternately. When the scanning STA receives a beacon frame, it stores the BSS information contained in the beacon frame and records the beacon frame information on each channel while moving to other channels. An STA that has received a beacon frame can store the BSS-related information contained in the received beacon frame and move to the next channel to perform scanning on the next channel in the same way. Comparing active scanning and passive scanning, active scanning has the advantage of less delay and power consumption compared to passive scanning.

[0051] After the STA discovers the network, an authentication process may be performed in step S320. This authentication process can be called the first authentication process to clearly distinguish it from the security setup operation in step S340, which will be described later.

[0052] The authentication process involves the STA sending an authentication request frame to the AP, and the AP responding by sending an authentication response frame to the STA. The authentication frame used in the authentication request / response corresponds to the management frame.

[0053] The authentication frame may include information such as the authentication algorithm number, authentication transaction sequence number, status code, challenge text, Robust Security Network (RSN), and Finite Cyclic Group. This is just an example of some of the information that may be included in the authentication request / response frame, and may be replaced by other information or may contain additional information.

[0054] The STA can send an authentication request frame to the AP. Based on the information contained in the received authentication request frame, the AP can decide whether or not to allow authentication to the STA. The AP can provide the STA with the result of the authentication process using an authentication response frame.

[0055] After the STA has been successfully authenticated, the association process may take place in step S330. The association process includes the STA sending an association request frame to the AP, and the AP sending an association response frame to the STA in response.

[0056] For example, an association request frame may include information about various capacities, such as the beacon listen interval, SSID (service set identifier), supported rates, supported channels, RSN, mobility domain, supported operating classes, TIM broadcast request (Traffic Indication Map Broadcast request), and interworking service capacity. For example, an association response frame may include information about various capacities, such as the status code, AID (Association ID), support rates, EDCA (Enhanced Distributed Channel Access) parameter set, RCPI (Received Channel Power Indicator), RSNI (Received Signal to Noise Indicator), mobility domain, timeout interval (e.g., association comeback time), overlapping BSS scan parameters, TIM broadcast response, and QoS (Quality of Service) map. This is an example of some of the information that may be included in a join request / response frame, and may be replaced by other information or may include additional information.

[0057] After the STA is successfully connected to the network, the security setup process may be performed in step S340. The security setup process in step S340 can also be described as an authentication process using RSNA (Robust Security Network Association) requests / responses, and the authentication process in step S320 can be called the first authentication process, while the security setup process in step S340 can simply be called the authentication process.

[0058] The security setup process in stage S340 may include, for example, a process of private key setup using a four-way handshake with an EAPOL (Extensible Authentication Protocol over LAN) frame. Furthermore, the security setup process may be performed using a security method not defined in the IEEE 802.11 standard.

[0059] Figure 4 is a diagram illustrating the backoff process to which this disclosure can be applied.

[0060] In wireless LAN systems, the basic access mechanism of MAC (Medium Access Control) is the CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance) mechanism. The CSMA / CA mechanism is also called the Distributed Coordination Function (DCF) of IEEE 802.11 MAC, and basically employs a "listen before talk" access mechanism. With this type of access mechanism, an AP and / or STA can perform a Clear Channel Assessment (CCA) to sense the radio channel or medium within a predetermined time interval (e.g., DIFS Inter-Frame Space) before initiating transmission. If the sensing determines that the medium is idle, the AP and / or STA will begin transmitting a frame through that medium. On the other hand, if the medium is perceived as occupied or busy, the AP and / or STA will not begin transmitting itself, but will wait for a delay period (e.g., a random backoff period) for medium access before attempting to transmit a frame. By applying a random backoff period, multiple STAs are expected to attempt to transmit frames after waiting for different periods of time from each other, thus minimizing collisions.

[0061] Furthermore, the IEEE 802.11 MAC protocol provides HCF (Hybrid Coordination Function). HCF is based on the aforementioned DCF and PCF (Point Coordination Function). PCF is a polling-based synchronous access method that periodically polls so that all receiving APs and / or STAs can receive data frames. HCF also has EDCA (Enhanced Distributed Channel Access) and HCCA (HCF Controlled Channel Access). EDCA is a competition-based access method for a provider to provide data frames to multiple users, while HCCA uses a non-competition-based channel access method with a polling mechanism. In addition, HCF includes a media access mechanism to improve the QoS (Quality of Service) of wireless LANs and can transmit QoS data during both the Contention Period (CP) and the Contention Free Period (CFP).

[0062] Refer to Figure 4 to explain the operation based on the random backoff period. When a medium that was occupied / busy changes to idle, multiple STAs can attempt to transmit data (or frames). As a way to minimize collisions, each STA can select a random backoff count and wait for the corresponding slot time before attempting to transmit. The random backoff count has a pseudo-random integer value and may be determined to any one of the values ​​in the range of 0 to CW, where CW is the Contention Window parameter value. The CW parameter is initially given as CWmin, but can take twice that value in case of transmission failure (e.g., if an ACK for a transmitted frame is not received). When the CW parameter value becomes CWmax, the STA can attempt to transmit data while maintaining the CWmax value until successful data transmission occurs, at which point it is reset to the CWmin value. The CW, CWmin, and CWmax values ​​are 2 n It is preferable to set it to -1 (n=0,1,2,...).

[0063] Once the random backoff process begins, the STA continues to monitor the media while counting down the backoff slots according to the determined backoff count value. When the media is monitored as occupied, the countdown stops and it waits; when the media becomes idle, the remaining countdown resumes.

[0064] In the example in Figure 4, when a packet to be transmitted reaches the MAC of STA3, STA3 can immediately transmit the frame after confirming that the medium is idle for DIFS only. The remaining STAs monitor the occupied / busy state of the medium and wait. Meanwhile, data to be transmitted may also be generated in STA1, STA2, and STA5. When each STA monitors the medium as idle, after waiting for DIFS only, it can count down the backoff slot using a random backoff count value of its choice. Assume that STA2 selects the minimum backoff count value and STA1 selects the maximum backoff count value. That is, the example illustrates a case where the remaining backoff time for STA5 is shorter than the remaining backoff time for STA1 when STA2 finishes its backoff count and begins transmitting a frame. STA1 and STA5 pause their countdown and wait for a while while STA2 occupies the medium. When STA2's occupation ends and the medium becomes idle again, STA1 and STA5 wait for DIFS only before resuming the paused backoff count. In other words, frame transmission can begin after counting down the remaining backoff slots equal to the remaining backoff time. Since STA5's remaining backoff time was shorter than STA1's, STA5 begins frame transmission. Data to transmit may also occur in STA4 while STA2 is occupying the medium. From STA4's perspective, when the medium becomes idle, it can wait for DIFS, then count down using a random backoff count value of its choosing, and begin frame transmission. The example in Figure 4 shows a case where STA5's remaining backoff time coincidentally matches STA4's random backoff count value, in which case a collision may occur between STA4 and STA5. If a collision occurs, neither STA4 nor STA5 will receive an ACK, and data transmission will fail. In this case, STA4 and STA5 can double their CW value, select a random backoff count value, and then perform the countdown.STA1 waits while the medium is occupied by transmissions from STA4 and STA5. When the medium becomes idle, STA1 waits only for DIFS, and can begin transmitting frames after the remaining backoff time has elapsed.

[0065] As illustrated in Figure 4, data frames are used to transmit data forwarded to higher layers and may be transmitted after a backoff that occurs after DIFS has elapsed, from the time the medium becomes idle. Furthermore, management frames are used to exchange management information that is not forwarded to higher layers and are transmitted after a backoff that occurs after an IFS such as DIFS or PIFS (Point Coordination Function IFS) has elapsed. Subtypes of management frames include beacons, association request / response, re-association request / response, probe request / response, and authentication request / response. Control frames are used to control access to the medium. Control frames can be subtypes of frames such as RTS (Request-To-Send), CTS (Clear-To-Send), ACK (Acknowledgment), PS-Poll (Power Save-Poll), Block ACK (BlockAck), Block ACK Request (BlockACKReq), NDP Announcement (null data packet announcement), and Trigger. Control frames are sent after a backoff that occurs after DIFS if they are not a response frame to a previous frame, and without a backoff after SIFS (short IFS) if they are a response frame to a previous frame. The type and subtype of a frame may be identified by the type field and subtype field in the frame control (FC) field.

[0066] A Quality of Service (QoS) STA can transmit a frame after an arbitration IFS (AIFS) for the access category (AC) to which the frame belongs, i.e., after a backoff that occurs after AIFS[i] (where i is a value determined by the AC). Frames for which AIFS[i] is available can be data frames, management frames, or control frames that are not response frames.

[0067] Figure 5 is a diagram illustrating the CSMA / CA baseframe transmission operation to which this disclosure can be applied.

[0068] As mentioned earlier, the CSMA / CA mechanism includes not only physical carrier sensing, where the STA directly senses the medium, but also virtual carrier sensing. Virtual carrier sensing is intended to compensate for problems that can occur in medium access, such as the hidden node problem. For virtual carrier sensing, the STA's MAC can utilize the Network Allocation Vector (NAV). The NAV is a value that indicates to other STAs the time remaining until the medium becomes available, used by an STA that is currently using or authorized to use the medium. Therefore, the value set as the NAV corresponds to the period during which the STA sending the frame is scheduled to use the medium, and STAs receiving the NAV value are prohibited from accessing the medium during that period. For example, the NAV may be set based on the value of the "duration" field in the frame's MAC header.

[0069] In the example shown in Figure 5, we assume that STA1 is attempting to transmit data to STA2, and STA3 is in a position where it can overhear some or all of the frames transmitted and received between STA1 and STA2.

[0070] In CSMA / CA baseframe transmission operation, a mechanism utilizing RTS / CTS frames may be applied to reduce the possibility of collisions between transmissions from multiple STAs. In the example in Figure 5, while STA1 is transmitting, carrier sensing by STA3 may determine that the medium is idle. That is, STA1 may be a hidden node for STA3. Alternatively, in the example in Figure 5, while STA2 is transmitting, carrier sensing by STA3 may determine that the medium is idle. That is, STA2 may be a hidden node for STA3. By exchanging RTS / CTS frames before data transmission and reception between STA1 and STA2, it is possible to prevent STAs outside the transmission range of either STA1 or STA2, or STAs outside the carrier sensing range for transmissions from STA1 or STA3, from attempting to occupy the channel during data transmission and reception between STA1 and STA2.

[0071] Specifically, STA1 can determine whether a channel is in use or not using carrier sensing. In terms of physical carrier sensing, STA1 can determine the channel's occupied or idle state based on the energy magnitude or signal correlation detected from the channel. In terms of virtual carrier sensing, STA1 can determine the channel's occupied state using a network allocation vector (NAV) timer.

[0072] STA1 can send an RTS frame to STA2 after backoff if the channel is idle during DIFS. STA2, upon receiving an RTS frame, can send a CTS frame, which is a response to the RTS frame, to STA1 after SIFS.

[0073] If STA3 cannot overhear CTS frames from STA2 but can overhear RTS frames from STA1, STA3 can use the duration information contained in the RTS frames to set the NAV timer for subsequent consecutive frame transmission periods (e.g., SIFS + CTS frame + SIFS + data frame + SIFS + ACK frame). Alternatively, if STA3 cannot overhear RTS frames from STA1 but can overhear CTS frames from STA2, STA3 can use the duration information contained in the CTS frames to set the NAV timer for subsequent consecutive frame transmission periods (e.g., SIFS + data frame + SIFS + ACK frame). In other words, STA3 can set NAV based on overhearing one or more RTS or CTS frames from at least one of STA1 or STA2. If STA3 receives a new frame before the NAV timer expires, it can update the NAV timer using the duration information contained in the new frame. STA3 will not attempt to access the channel until the NAV timer expires.

[0074] When STA1 receives a CTS frame from STA2, it can send a data frame to STA2 after SIFS from the time the CTS frame reception is complete. If STA2 successfully receives the data frame, it can send an ACK frame, which is a response to the data frame, to STA1 after SIFS. When the NAV timer expires, STA3 can use carrier sensing to determine whether the channel is in use or not. If STA3 determines that the channel is not being used by another terminal between the expiration of the NAV timer and DIFS, it can attempt to access the channel after the random backoff conflict window (CW) has passed.

[0075] Figure 6 is a diagram illustrating an example of a frame structure used in a wireless LAN system to which this disclosure can be applied.

[0076] The PHY layer can prepare the MPDU (MAC PDU) to be transmitted based on instructions or primitives (meaning a set of instructions or parameters) from the MAC layer. For example, when the PHY layer receives an instruction from the MAC layer requesting it to start transmitting, it switches to transmit mode and can assemble the information provided by the MAC layer (e.g., data) into a frame and transmit it. Also, when the PHY layer detects a valid preamble in the frame it is receiving, it monitors the preamble header and sends an instruction to the MAC layer to signal that the PHY layer has started receiving.

[0077] Thus, information transmission and reception in wireless LAN systems are performed in the form of frames, and for this purpose, the Physical Layer Protocol Data Unit (PPDU) frame format is defined.

[0078] A basic PPDU may include an STF (Short Training Field), an LTF (Long Training Field), a SIG (SIGNAL) field, and a Data field. The most basic (e.g., non-HT (High Throughput) PPDU format shown in Figure 7) may consist only of an L-STF (Legacy-STF), an L-LTF (Legacy-LTF), an L-SIG (Legacy-SIG) field, and a Data field. Depending on the type of PPDU format (e.g., HT-mixed format PPDU, HT-greenfield format PPDU, VHT (Very High Throughput) PPDU, etc.), additional (or other types of) RL-SIG, U-SIG, non-legacy SIG fields, non-legacy STF, non-legacy LTF (i.e., xx-SIG, xx-STF, xx-LTF (e.g., xx is HT, VHT, HE, EHT, etc.)) may be included between the L-SIG field and the Data field. More specific details will be discussed later, referring to Figure 7.

[0079] STF is a signal used for signal detection, AGC (Automatic Gain Control), diversity selection, and precise time synchronization, while LTF is a signal used for channel estimation and frequency error estimation. In essence, STF and LTF are signals for synchronizing the OFDM physical layer and for channel estimation.

[0080] The SIG field may contain various information related to PPDU transmission and reception. For example, the L-SIG field consists of 24 bits and may include a 4-bit Rate field, a 1-bit Reserved bit, a 12-bit Length field, a 1-bit Parity field, and a 6-bit Tail field. The RATE field may contain information about the data modulation and coding rate. For example, the 12-bit Length field may contain information about the length or time duration of the PPDU. For example, the value of the 12-bit Length field may be determined based on the type of PPDU. For example, for non-HT, HT, VHT, or EHT PPDUs, the value of the Length field may be determined to be a multiple of 3. For example, for HE PPDUs, the value of the Length field may be determined to be a multiple of 3 + 1 or a multiple of 3 + 2.

[0081] The data field may include a SERVICE field, a PSDU (Physical Layer Service Data Unit), and PPDU TAIL bits, and may also include padding bits if necessary. Some bits of the SERVICE field may be used for synchronizing the descramble at the receiving end. The PSDU corresponds to the MAC PDU defined in the MAC layer and may contain data generated / used in higher layers. The PPDU TAIL bits may be used to return the encoder to a 0 state. Padding bits may be used to adjust the length of the data field to a predetermined unit.

[0082] MAC PDUs are defined by various MAC frame formats, and a basic MAC frame consists of a MAC header, frame body, and FCS (Frame Check Sequence). MAC frames are composed of MAC PDUs and may be transmitted / received by a PSDU, which is the data portion of the PPDU format.

[0083] The MAC header includes fields such as Frame Control, Duration / ID, and Address. The Frame Control field may contain control information necessary for transmitting / receiving frames. The Duration / ID field may be set to the time required to transmit the frame. The Address subfield can indicate the frame's receiver address, transmitter address, destination address, and source address, and some Address subfields may be omitted. Sequence Control, QoS Control, and HT Control subfields are also included, and the specific contents of each subfield of the MAC header can be found in the IEEE 802.11 standard document.

[0084] The null data PPDU (NDP) format refers to a form of PPDU format that does not include data fields. In other words, NDP is a frame format that includes the PPDU preamble (i.e., L-STF, L-LTF, L-SIG fields, and if present, also non-legacy SIG, non-legacy STF, and non-legacy LTF fields) in a general PPDU format, but does not include the rest (i.e., data fields).

[0085] Figure 7 shows an example of a PPDU as defined in the IEEE 802.11 standard to which this disclosure applies.

[0086] Standards such as IEEE 802.11a / g / n / ac / ax use various forms of PPDU. The basic PPDU format (IEEE 802.11a / g) includes L-LTF, L-STF, L-SIG, and Data fields. The basic PPDU format can also be referred to as the non-HT PPDU format (Figure 7(a)).

[0087] The HT PPDU format (IEEE 802.11n) further includes the HT-SIG, HT-STF, and HT-LFT(s) fields in addition to the basic PPDU format. The HT PPDU format shown in Figure 7(b) can be referred to as the HT-mixed format. The HT-greenfield format PPDU may be further defined, which does not include L-STF, L-LTF, and L-SIG, and consists of the HT-GF-STF, HT-LTF1, HT-SIG, one or more HT-LTF, and Data fields (not shown).

[0088] An example of the VHT PPDU format (IEEE 802.11ac) further includes the VHT SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields in addition to the basic PPDU format (Figure 7(c)).

[0089] An example of the HE PPDU format (IEEE 802.11ax) further includes the RL-SIG (Repeated L-SIG), HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF(s), and PE (Packet Extension) fields in addition to the basic PPDU format (Figure 7(d)). Depending on the specific example of the HE PPDU format, some fields may be omitted or their lengths may change. For example, the HE-SIG-B field is included in the HE PPDU format for multiple users (MU), while it is not included in the HE PPDU format for single users (SU). Also, the HE trigger-based (TB) PPDU format does not include HE-SIG-B, and the length of the HE-STF field may be changed to 8us. The HE ER (Extended Range) SU PPDU format does not include the HE-SIG-B field, and the length of the HE-SIG-A field may be changed to 16us. For example, RL-SIG may be configured identically to L-SIG. Based on the presence of RL-SIG, the receiving STA can determine that the received PPDU is either an HE PPDU or an EHT PPDU, as described later.

[0090] The EHT PPDU format may include the EHT MU (multi-user) format shown in Figure 7(e) and the EHT TB (trigger-based) PPDU format shown in Figure 7(f). The EHT PPDU format is similar to the HE PPDU format in that it includes an RL-SIG following the L-SIG, but it may also include a U (universal)-SIG, EHT-SIG, EHT-STF, and EHT-LTF following the RL-SIG.

[0091] The EHT MU PPDU in Figure 7(e) corresponds to a carry PPDU that carries one or more data (or PSDUs) for one or more users. In other words, the EHT MU PPDU may be used for either SU transmission or MU transmission. For example, the EHT MU PPDU may correspond to a PPDU for one receiving STA or multiple receiving STAs.

[0092] The EHT TB PPDU in Figure 7(f) omits the EHT-SIG compared to the EHT MU PPDU. An STA that receives a trigger for UL MU transmission (e.g., a trigger frame or TRS (triggered response scheduling)) can perform UL transmission based on the EHT TB PPDU format.

[0093] The L-STF, L-LTF, L-SIG, RL-SIG, U-SIG (Universal SIGNAL), and EHT-SIG fields may be encoded and modulated so that they can be attempted to be demodulated and decoded even by legacy STAs, and may be mapped based on a defined subcarrier frequency interval (e.g., 312.5 kHz). These may be referred to as pre-EHT modulated fields. Next, the EHT-STF, EHT-LTF, Data, and PE fields may be encoded and modulated so that they can be demodulated and decoded by STAs that have successfully decoded non-legacy SIGs (e.g., U-SIG and / or EHT-SIG) and obtained the information contained in those fields, and may be mapped based on a defined subcarrier frequency interval (e.g., 78.125 kHz). These may be referred to as EHT modulated fields.

[0094] Similarly, in the HE PPDU format, the L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, and HE-SIG-B fields can be referred to as pre-HE modulated fields, while the HE-STF, HE-LTF, Data, and PE fields can be referred to as HE modulated fields. Furthermore, in the VHT PPDU format, the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields can be referred to as pre-VHT modulated fields, while the VHT STF, VHT-LTF, VHT-SIG-B, and Data fields can be referred to as VHT modulated fields.

[0095] The U-SIG included in the EHT PPDU format in Figure 7 may be composed of, for example, two symbols (e.g., two consecutive OFDM symbols). Each symbol for the U-SIG (e.g., an OFDM symbol) may have a duration of 4us, and the U-SIG may have a total duration of 8us. Each symbol of the U-SIG may be used to transmit 26 bits of information. For example, each symbol of the U-SIG may be transmitted and received based on 52 data tones and 4 pilot tones.

[0096] U-SIGs may be configured in 20MHz units. For example, when an 80MHz PPDU is configured, identical U-SIGs may be duplicated in 20MHz units. That is, an 80MHz PPDU may contain four identical U-SIGs. When the bandwidth exceeds 80MHz, for example, for a 160MHz PPDU, the first 80MHz U-SIG and the second 80MHz U-SIG may be different from each other.

[0097] In a U-SIG, for example, A uncoded bits may be transmitted, and the first U-SIG symbol (e.g., U-SIG-1 symbol) may transmit the first X bits of the total A bits, while the second U-SIG symbol (e.g., U-SIG-2 symbol) may transmit the remaining Y bits of the total A bits. The A bits (e.g., 52 uncoded bits) may include a CRC field (e.g., a 4-bit field) and a tail field (e.g., a 6-bit field). The tail field may be used to terminate the trellis of the convolution decoder and may be set to 0, for example.

[0098] The A bit information transmitted by U-SIG can be distinguished into version-independent bits and version-dependent bits. For example, a new PPDU format not shown in Figure 7 (e.g., UHR PPDU format) may include U-SIG, and the format of the U-SIG field in the EHT PPDU format and the format of the U-SIG field in the UHR PPDU format may be the same, while the version-independent bits may differ in some or all respects.

[0099] For example, the size of the version-independent bits of a U-SIG may be fixed or variable. The version-independent bits may be assigned only to U-SIG-1 symbols, or to both U-SIG-1 and U-SIG-2 symbols. Version-independent and version-dependent bits may be referred to by various names, such as the first control bit and the second control bit.

[0100] For example, the version-independent bits of the U-SIG may include a 3-bit physical layer version identifier (PHY version identifier), which can indicate the PHY version of the transmitted and received PPDUs (e.g., EHT, UHR, etc.). The version-independent bits of the U-SIG may include a 1-bit UL / DL flag field. The first value of the 1-bit UL / DL flag field relates to UL communication, and the second value relates to DL communication. The version-independent bits of the U-SIG may also include information about the length of the TXOP (transmission opportunity) and information about the BSS color ID.

[0101] For example, the version-dependent bits of the U-SIG may include information that directly or indirectly indicates the type of PPDU (e.g., SU PPDU, MU PPDU, TB PPDU, etc.).

[0102] The U-SIG may include information necessary for transmitting and receiving PPDUs. For example, the U-SIG may further include information about bandwidth, information about the MCS technique applied to non-legacy SIGs (e.g., EHT-SIG or UHR-SIG), information indicating whether a dual carrier modulation (DCM) technique (e.g., a technique for reusing the same signal on two subcarriers to achieve an effect similar to frequency diversity) is applied to the non-legacy SIG, information about the number of symbols used for the non-legacy SIG, and information about whether the non-legacy SIG is generated across the entire bandwidth.

[0103] Some of the information necessary for sending and receiving PPDUs may be included in the U-SIG and / or non-legacy SIGs (e.g., EHT-SIG or UHR-SIG). For example, information regarding the type of non-legacy LTF / STF (e.g., EHT-LTF / EHT-STF or UHR-LTF / UHR-STF), information regarding the length and cyclic prefix (CP) length of non-legacy LTFs, information regarding the guard interval (GI) applicable to non-legacy LTFs, information regarding preamble puncturing applicable to PPDUs, and information regarding resource unit (RU) allocation may be included only in the U-SIG, only in the non-legacy SIG, or indicated by a combination of information included in the U-SIG and information included in the non-legacy SIG.

[0104] Preamble puncturing can mean the transmission of a PPDU in which one or more frequency units within the PPDU's bandwidth are not present. For example, the size of the frequency units (or the resolution of preamble puncturing) may be defined as 20 MHz, 40 MHz, etc. For example, preamble puncturing may be applied to PPDU bandwidths of a certain size or larger.

[0105] In the example shown in Figure 7, non-legacy SIGs such as HE-SIG-B and EHT-SIG may contain control information for the receiving STA. Non-legacy SIGs may be transmitted with at least one symbol, which may have a length of 4us. Information regarding the number of symbols used for the EHT-SIG may be included in a previous SIG (e.g., HE-SIG-A, U-SIG, etc.).

[0106] Non-legacy SIGs such as HE-SIG-B and EHT-SIG may include common fields and user-specific fields. Common fields and user-specific fields may be coded separately.

[0107] In some cases, the common field may be omitted. For example, in a compressed mode where non-OFDMA (orthogonal frequency multiple access) is applied, the common field may be omitted, and multiple STAs can receive the PPDU (e.g., the data field of the PPDU) in the same frequency band. In an uncompressed mode where OFDMA is applied, multiple users can receive the PPDU (e.g., the data field of the PPDU) in separate frequency bands.

[0108] The number of user-specific fields may be determined based on the number of users. A single user block field may contain a maximum of two user fields. Each user field may be associated with either MU-MIMO or non-MU-MIMO assignments.

[0109] The common field may include a CRC bit and a Tail bit, the length of the CRC bit may be determined to be 4 bits, and the length of the Tail bit may be determined to be 6 bits and set to 000000. The common field may include RU allocation information. The RU allocation information may include information about the location of RUs to which multiple users (i.e., multiple receiving STAs) are assigned.

[0110] A RU may contain multiple subcarriers (or tones). RUs may be used when transmitting signals to multiple STAs based on the OFDMA method. Alternatively, a RU may be defined when transmitting a signal to a single STA. Resources may be allocated on a RU basis for non-legacy STFs, non-legacy LTFs, and Data fields.

[0111] The applicable size of RUs may be defined by the PPDU bandwidth. RUs may be defined to be identical or different for the applicable PPDU format (e.g., HE PPDU, EHT PPDU, UHR PPDU, etc.). For example, for an 80MHz PPDU, the RU arrangement for HE PPDU and EHT PPDU may differ from each other. The applicable RU size, number of RUs, RU locations, DC (direct current) subcarrier locations and number, null subcarrier locations and number, guard subcarrier locations and number, etc., for each PPDU bandwidth can be called a tone plan. For example, a tone plan for a wide bandwidth may be defined as multiple iterations of a low-bandwidth tone plan.

[0112] RUs of various sizes may be defined as 26-tone RUs, 52-tone RUs, 106-tone RUs, 242-tone RUs, 484-tone RUs, 996-tone RUs, 2×996-tone RUs, 4×996-tone RUs, etc. An MRU (multiple RU) is distinct from multiple individual RUs and corresponds to a group of subcarriers composed of multiple RUs. For example, one MRU may be defined as 52+26 tones, 106+26 tones, 484+242 tones, 996+484 tones, 996+484+242 tones, 2×996+484 tones, 3×996 tones, or 3×996+484 tones. Furthermore, the multiple RUs that make up a single MRU may or may not be consecutive in the frequency domain.

[0113] The specific size of a RU may be reduced or expanded. Therefore, the specific size of each RU (i.e., the number of corresponding tones) in this disclosure is illustrative and not restrictive. Also, in this disclosure, the number of RUs within a given bandwidth (e.g., 20, 40, 80, 160, 320 MHz, ...) may vary depending on the size of the RU.

[0114] In the PPDU format shown in Figure 7, the names of the fields are illustrative and do not limit the scope of this disclosure. Furthermore, the examples in this disclosure may apply not only to the PPDU format illustrated in Figure 7, but also to new PPDU formats that are based on the PPDU format in Figure 7 but with some fields excluded and / or some fields added.

[0115] Target wake time (TWT)

[0116] TWT is a Power Saving (PS) technology that can improve the energy efficiency of non-AP STAs by defining a Service Period (SP) between APs and non-AP STAs, and by sharing information about the SPs with each other to reduce contention.

[0117] A TWT Setup Stage (TWT) STA that makes a request / suggestion / demand during the TWT setup phase can be called a TWT Requesting STA. Similarly, an AP (Application Partner) that responds to such a request (acceptance / rejection) can be called a TWT Responding STA.

[0118] The setup phase may include the process of determining / defining the TWT request from the STA to the AP, the type of TWT operation to be performed, and the type of frames to be sent and received. TWT operations can be distinguished into individual TWTs and broadcast TWTs.

[0119] Figure 8 illustrates an example of individual TWT operation to which this disclosure can be applied.

[0120] Individual TWT is a mechanism in which AP and non-AP STA negotiate the activation / doze status of the non-AP STA through the sending and receiving of TWT Request / Response frames, and then exchange data.

[0121] In the example shown in Figure 8, AP and STA1 can form a trigger-enabled TWT agreement through TWT request frames and TWT response frames.

[0122] In this case, the method used by STA1 is a solicited TWT method, in which STA1 sends a TWT request frame to the AP, and STA1 receives information for TWT operation from the AP through a TWT response frame.

[0123] On the other hand, STA2, which uses an unsolicited TWT scheme, can receive information from AP regarding the setting of a trigger-enabled TWT agreement through an unsolicited TWT response.

[0124] Specifically, STA2 can calculate the next TWT by adding a specific number to the current TWT value. During a trigger-enabled TWT SP, the AP can send a trigger frame to the STA. The trigger frame informs the STA that the AP has buffered data. In response, STA1 can inform the AP of its awake state by sending a PS-Poll frame. Similarly, STA2 can inform the AP of its awake state by sending a QoS Null frame. Here, the data frames sent by STA1 and STA2 may be in TB PPDU format. After confirming the status of STA1 and STA2, the AP can send a DL MU PPDU to the awake STA. When the TWT SP expires, STA1 and STA2 may switch to a doze state.

[0125] Figure 9 illustrates an example of a broadcast TWT operation to which this disclosure can be applied.

[0126] A broadcast TWT is a type of TWT in which a non-AP STA (or TWT scheduling STA) obtains information such as TBTT (target beacon transmission time) and listen interval by sending and receiving TWT request / response frames with an AP (or TWT scheduled STA). Negotiation operations regarding the TBTT may also be performed. Based on this, the AP can define a frame containing TWT scheduling information through a beacon frame.

[0127] In Figure 9, STA1 performs a requested TWT operation, and STA2 performs an unrequested TWT operation. The AP can send a DL MU PPDU after confirming the awake state of the STA through the trigger it sent. This may be the same as the process for individual TWTs. In a broadcast TWT, a trigger-enabled TWT SP containing a beacon frame may be repeated multiple times at regular intervals.

[0128] TWT information may be transmitted through TWT information frames and TWT information elements. TWT information frames are transmitted by STAs to request or transmit information about TWT agreements, and are transmitted by one of the STAs of existing TWT agreements. The action field of a TWT information frame contains a TWT information field.

[0129] The TWT information field may include a 3-bit TWT flow identifier subfield, a 1-bit response requested subfield, a 1-bit next TWT request subfield, a 2-bit next TWT subfield size subfield, a 1-bit all TWT subfield, and a 0 / 32 / 48 / 64-bit next TWT subfield.

[0130] Here, the TWT flow identifier subfield may be used to identify the flow for which TWT information is requested / provided.

[0131] The Request Response subfield can indicate whether the transmitter of a frame containing the TWT information field requests the transmission of a TWT information frame (which is sent as a response to the reception of the frame). The Request Response subfield value may be set to 0 to request the receiver not to send a TWT information frame as a response to the frame reception. The Request Response subfield value may be set to 1 to request the receiver to send a TWT information frame as a response to the frame reception.

[0132] The following TWT subfield value may be set to 1 to indicate that this is a request to send a TWT information frame containing the following TWT field (where the length of the TWT information frame is not 0). Otherwise, the following TWT subfield value may be set to 0.

[0133] The Next TWT Subfield Size subfield can indicate the size of the next TWT subfield. If the size of the next TWT subfield is 0 / 32 / 48 / 64 bits, the value of the Next TWT Subfield Size subfield may be set to 0 / 1 / 2 / 3.

[0134] All TWT subfield values ​​may be set to 1 by HE STA, which can mean that the TWT information frame has readjusted the entire TWT. Otherwise, all TWT subfield values ​​may be set to 0.

[0135] Figure 10 is a diagram illustrating an example of the TWT information element format.

[0136] A TWT element may be included in and transmitted / received in beacons, probe responses, (re)connection response frames, etc. A TWT element may include an element ID field, a length field, a control field, and a TWT parameter information field.

[0137] The control field of a TWT element has the same format regardless of whether it is an individual TWT or a broadcast TWT.

[0138] The NDP paging indication subfield may have a value of 1 if the NDP paging field exists, and a value of 0 if the NDP paging field does not exist.

[0139] The Responder PM mode subfield can indicate the Power Management (PM) mode.

[0140] The negotiation type subfield can indicate whether the information contained in the TWT element pertains to the negotiation of parameters for a broadcast TWT or individual TWT(s), or to the wake TBTT interval.

[0141] For example, if the value of the negotiation type subfield is 0, the TWT subfield is for a future individual TWT SP start time, and the TWT element contains one individual TWT parameter set. This may correspond to an individual TWT negotiation between a TWT requesting STA and a TWT responding STA, or to an individual TWT announcement by a TWT responder.

[0142] For example, if the value of the negotiation type subfield is 1, the TWT subfield is for the next TBTT time, and the TWT element contains one separate TWT parameter set. This may correspond to a wake TBTT and wake interval negotiation between a TWT-scheduled STA and a TWT-scheduling AP.

[0143] For example, if the value of the negotiation type subfield is 2, the TWT subfield is for a future broadcast TWT SP start time, and the TWT element contains one or more broadcast TWT parameter sets. This may constitute providing a broadcast TWT schedule to the TWT-scheduled STA by including the TWT element in the broadcast management frame sent by the TWT scheduling AP.

[0144] For example, if the value of the negotiation type subfield is 3, the TWT subfield is for a future broadcast TWT SP start time, and the TWT element contains one or more broadcast TWT parameter sets. This may constitute managing membership in a broadcast TWT schedule by including the TWT element in an individually addressed management frame sent by either the TWT-scheduled STA or the TWT-scheduling AP.

[0145] If the TWT information frame disabled subfield is set to 1, it indicates that the reception of TWT information frames by the STA is disabled; otherwise, it may be set to 0.

[0146] The Wake Duration Unit subfield indicates the unit of the Nominal Minimum TWT Wake Duration field. The Wake Duration Unit subfield may be set to 0 if the unit is 256us, and to 1 if the unit is TU. If it is not an HE / EHT STA, the Wake Duration Unit subfield may be set to 0.

[0147] The MSB (most significant bit) of the negotiation type field may correspond to the broadcast field. If the broadcast field is 1, the TWT element may contain one or more broadcast TWT parameter sets. If the broadcast field is 0, the TWT element may contain only one individual TWT parameter set. A TWT element in which the broadcast field is set to 1 can be called a broadcast TWT element.

[0148] Figure 10 shows a case where the reserved field consists of 2 bits, but this is just one example. For example, a TWT element may include a Link ID bitmap present field (e.g., 1 bit) and a reserved field (e.g., 1 bit).

[0149] For example, if the Link ID Bitmap Existence field is set to 1, the Individual TWT Parameter Set Field Format (described later) may be configured to include a Link ID Bitmap subfield, and if the Link ID Bitmap Existence field is set to 0, the Individual TWT Parameter Set Field Format may be configured not to include a Link ID Bitmap subfield.

[0150] Figure 11 is a diagram illustrating an example of an individual TWT parameter set field format. Figure 12 is a diagram illustrating an example of a broadcast TWT parameter set field format.

[0151] The TWT parameter information field included in the TWT element in Figure 10 may have a different configuration depending on whether it is an individual TWT or a broadcast TWT.

[0152] If it is an individual TWT, the TWT parameter information field within the TWT element contains a single individual TWT parameter set field.

[0153] If it is a broadcast TWT, the TWT parameter information field within the TWT element includes one or more broadcast TWT parameter set fields. Each broadcast TWT parameter set may contain specific information about a single broadcast TWT.

[0154] As shown in Figures 11 and 12, the individual TWT parameter set field and the broadcast TWT parameter set field include common subfields.

[0155] The request type subfield is the same size in both the individual TWT parameter set field and the broadcast TWT parameter set field, but its detailed configuration may differ from one another. This will be explained later.

[0156] The Target Wake Time subfield indicates the start time of upcoming individual / broadcast TWT SPs.

[0157] The Nominal Maximum TWT Wake Duration subfield indicates the minimum unit that a TWT requesting STA expects to wake up during the TWT wake interval duration to complete the TWT flow identifier and associated frame exchange. Here, the TWT wake interval can mean the average time between consecutive TWT SPs expected by the TWT requesting STA.

[0158] The TWT Wake Interval Mantissa subfield is a binary representation of the TWT wake interval value, displayed in microseconds.

[0159] Referring to Figure 11, the TWT group assignment subfield, TWT channel, and NDP paging subfield are included only in the individual TWT parameter set field.

[0160] The TWT group assignment subfield provides the TWT requesting STA with information about the TWT group to which the STA has been assigned. This information can be used to calculate the TWT values ​​within the TWT group. The STA's TWT value may be the same as the zero offset value and the value obtained by multiplying the TWT offset value by the TWT unit value.

[0161] Here, the TWT group information may include a TWT group ID subfield, a zero offset presence subfield, a zero offset subfield for the group, a TWT unit subfield, and a TWT offset subfield.

[0162] The TWT Group ID subfield indicates the identifier of the TWT group to which the requested STA is assigned, and the TWT group can mean an STA group having TWT values ​​within a specific interval of TSF values. If the TWT Group ID subfield value is set to 0, this can indicate a unique TWT group containing all STAs of the BSS.

[0163] The zero-offset existence subfield can indicate whether or not a zero-offset subfield exists for a group. For example, if the zero-offset existence subfield value is set to 1, this indicates that a zero-offset subfield exists for the group. If the zero-offset existence subfield value is set to 0, this indicates that a zero-offset subfield does not exist for the group.

[0164] The zero-offset subfield of a group is selective and can indicate the initial TWT value of the TWT group identified by the TWT group ID.

[0165] The TWT unit subfield can indicate the increment unit of the TWT value within the TWT group identified by the TWT group ID. For example, if the TWT unit time values ​​are 32 μs, 256 μs, 1024 μs, 8.192 ms, 32.768 ms, and 262.144 ms, the TWT unit subfield values ​​may be expressed as 0, 1, 2, 3, and 4, respectively.

[0166] The TWT offset subfield can display the position of the STA within a specified group that corresponds to the RA of the frame containing the TWT element.

[0167] The TWT Channel subfield represents a bitmap indicating the allowed channels. When transmitted by a TWT Requesting STA, the TWT Channel subfield may include a bitmap indicating the channels that the STA requests to be used as temporary basic channels during the TWT SP. When transmitted by a TWT Responseing STA, the TWT Channel subfield may include a bitmap indicating the channels that the TWT Requesting STA will allow.

[0168] The NDP paging subfield is optional and may include information such as the identifier of the STA being paged and the maximum number of TWT wake intervals between NDP paging frames.

[0169] Referring to Figure 12, the broadcast TWT info subfield is included only in the broadcast TWT parameter set field. The broadcast TWT info subfield may include a 3-bit reservation subfield, a 5-bit broadcast TWT identifier (ID) subfield, and an 8-bit broadcast TWT persistence subfield. The broadcast TWT identifier subfield indicates the broadcast ID of a particular broadcast TWT to which the STA requests participation or provides TWT parameters, based on the value of the TWT setup command subfield of the TWT element. The broadcast TWT persistence subfield indicates the number of TBTTs planned on the broadcast TWT schedule.

[0170] Next, we will explain the detailed structure of the request type subfield.

[0171] First, with reference to Figure 11, we will describe the format of the request type subfield of the individual TWT parameter set field.

[0172] The TWT request subfield can indicate whether it is a requesting STA or a response STA. A value of 1 indicates a TWT requesting STA or a scheduled STA, while a value of 0 indicates a TWT response STA or a scheduling AP.

[0173] The TWT setup command subfield can indicate commands such as Request, Suggest, Demand, Accept, Change, Order, and Reject.

[0174] The trigger subfield indicates whether or not to use a trigger frame in TWT SP. A value of 1 means the trigger is used, and a value of 0 means the trigger is not used.

[0175] An implicit subfield can indicate whether a TWT is implicit or explicit. A value of 1 indicates an implicit TWT, while a value of 0 indicates an explicit TWT.

[0176] The flow type subfield can indicate the type of interaction between a TWT requesting STA (or a TWT-scheduled STA) and a TWT response STA (or an AP that schedules a TWT). A value of 1 can indicate an announced TWT, where the STA sends a PS-Poll or APSD (automatic power save delivery) trigger frame to the AP to wake up before any non-trigger frames are sent from the AP to the STA. A value of 0 can indicate an unannounced TWT.

[0177] The TWT flow identifier subfield may contain a 3-bit value that uniquely identifies specific information about the TWT request from other requests made between the same TWT request STA and TWT response STA pair.

[0178] The TWT wake interval exponent subfield allows you to set the TWT wake interval value in binary microseconds. For individual TWTs, this can represent the interval between individual TWT SPs. The TWT wake interval for a requested STA may be defined as [TWT Wake Interval Mantissa*2*TWT Wake Interval Exponent].

[0179] The TWT protection subfield can indicate whether or not a TWT protection mechanism is used. If its value is 1, the TXOP in the TWT SP may be started by a NAV protection mechanism such as (MU)RTS / CTS or CTS-to-self frame; if it is 0, no NAV protection mechanism is required.

[0180] Referring to Figure 12, some of the subfields of the request type subfield of the broadcast TWT parameter set field are common with the subfields of the request type subfield of the individual TWT parameter set field, so a detailed explanation of these will be omitted. The subfields that are included only in the broadcast TWT parameter set are described below.

[0181] The Last Broadcast Parameter Set subfield indicates whether it is the last broadcast TWT parameter set. A value of 1 indicates that it is the last broadcast TWT parameter set, while a value of 0 indicates that the next broadcast TWT parameter set exists.

[0182] The Broadcast TWT Recommendation subfield can indicate a recommendation for the frame type sent by the AP during Broadcast TWTSP, with a value from 1 to 7.

[0183] For example, if the broadcast TWT recommendation subfield value is set to 4, the corresponding broadcast TWT SP can be referred to as an r-TWT SP. That is, a broadcast TWT parameter set with a broadcast TWT recommendation subfield value set to 4 can be referred to as a restricted TWT parameter set. In this case, within the r-TWT SP, the AP and member r-TWT scheduled STAs can specify the transmission priority of QoS data frames, which are delay-sensitive traffic. Furthermore, a broadcast TWT element containing only the r-TWT parameter set field can be considered a restricted TWT element.

[0184] The last bit of the request type subfield in the broadcast TWT parameter set field may be reserved.

[0185] As an example of this disclosure, the broadcast TWT parameter set field may include a restricted TWT traffic information (info) subfield. For example, the TWT traffic information subfield may follow the broadcast TWT information field of the broadcast TWT parameter set field shown in Figure 12.

[0186] As an example of this disclosure, as shown in Figure 13(a), the broadcast TWT information subfield may include a restricted TWT traffic information present subfield and a restricted TWT schedule full subfield.

[0187] The TWT traffic information presence subfield and the restricted TWT schedule overall subfield may be set to the first bit (B0) and the second bit (B1) of the broadcast TWT information field shown in Figure 12, respectively.

[0188] For example, if the restricted TWT traffic information field exists on the broadcast TWT parameter set field, the value of the restricted TWT traffic information existence subfield in the restricted TWT parameter set field may be set to 1. Otherwise, the value of the restricted TWT traffic information existence subfield may be set to 0. In the case of an STA that is not EHT, the restricted TWT traffic information existence subfield may be reserved.

[0189] If the Restricted TWT Schedule Overall subfield value is set to 1, this may indicate that the r-TWT scheduling AP is unlikely to accept a request from the BSS STA to set up a new membership in that schedule. Otherwise, the Restricted TWT Schedule Overall subfield value may be set to 0.

[0190] The restricted TWT schedule overall subfield may be valid when the restricted TWT parameter set field is transmitted to a TWT element where the negotiation type subfield is set to 2, and the TWT element is sent by the EHT AP.

[0191] If the value of the Restricted TWT Traffic Information Existence subfield in the Broadcast TWT Information subfield is set to 1, the Restricted TWT Traffic Information field may exist in the Restricted TWT Intermediate Variable Set field.

[0192] As shown in Figure 13(b), the restricted TWT traffic information field may include a traffic information control subfield, a restricted TWT DL TID bitmap subfield, and a restricted TWT UL TID bitmap subfield.

[0193] As shown in Figure 13(c), the traffic information control field may include a DL TID bitmap valid subfield and an UL TID bitmap valid subfield.

[0194] The DL TID bitmap enabled subfield may be set to 1 to indicate that the restricted TWT DL TID bitmap field is enabled. The DL TID bitmap enabled subfield may be set to 0 to indicate that DL traffic for all TIDs mapped to DL on a link where r-TWT membership is configured is identified as delay-sensitive traffic and the restricted TWT DL TID bitmap field is reserved.

[0195] The UL TID Bitmap Enabled subfield may be set to 1 to indicate that the restricted TWT UL TID bitmap field is enabled. The UL TID Bitmap Enabled subfield may be set to 0 to indicate that UL traffic for all TIDs mapped to UL on a link where r-TWT membership is configured is identified as delay-sensitive traffic and the restricted TWT UL TID bitmap field is reserved.

[0196] The restricted TWT DL TID bitmap and restricted TWT UL TID bitmap subfields can specify TIDs that are identified as delay-sensitive traffic streams in the DL and UL directions, respectively, by the r-TWT scheduling AP or R-TWT scheduling STA.

[0197] A value of 1 at bit position k in the bitmap indicates that TID k is classified as a delay-sensitive traffic stream. A value of 0 at bit position k in the bitmap indicates that TID k is not classified as a delay-sensitive traffic stream.

[0198] R-TWT Membership Setup and R-TWT SP Publicly Known

[0199] R-TWT membership may be configured using the same procedure as that used to configure broadcast TWT membership, except that the broadcast TWT element transmitted on the TWT setup frame contains one or more restricted TWT parameter set fields. An R-TWT scheduling AP may set the trigger field to 1 in the R-TWT parameter set field it transmits. When included in an individually addressed TWT setup frame transmitted by an R-TWT scheduling AP or R-TWT scheduling STA, the R-TWT traffic information present subfield of the broadcast TWT information field included in the R-TWT parameter set field may be set to 1.

[0200] R-TWT scheduling APs and R-TWT scheduling STAs can configure restricted TWT traffic information fields to identify TIDs that transmit latency-sensitive traffic in DL and UL for configured R-TWT memberships.

[0201] When R-TWT membership is configured, the EHT AP can make R-TWT schedule information public, including a TWT parameter set field limited to the broadcast TWT element included in the transmitted management frame. Membership may be configured on nontransmitting APs belonging to the same multiple BSSID set or co-hosting BSSID set as the linked EHT AP or transmitting AP. A BSSID transmitted in a multiple BSSID set may include all untransmitted BSSIDs in the same multiple BSSID set as all R-TWT schedules advertised for the transmitted BSSID.

[0202] An R-TWT scheduling AP that includes an R-TWT parameter set field in its broadcast TWT element can set the restricted TWT traffic information presence subfield of the restricted TWT parameter set field to 0 if the negotiation type subfield of the TWT element is 2. Non-AP STAs do not need to request membership settings in R-TWT schedules advertised by an R-TWT scheduling AP whose restricted TWT schedule subfield is set to 2. An R-TWT scheduling AP can determine the start times of R-TWT SPs that occur after the first R-TWT SP (the start time of the next R-TWT SP) in a periodic R-TWT schedule, based on the start time of the first R-TWT SP and the TWT wake interval of that R-TWT schedule.

[0203] TXOP and backoff procedure rules for R-TWT SP

[0204] A non-AP EHT STA (e.g., a TXOP holder) with "dot11RestrictedTWTOptionImplemented" set to true can ensure that the TXOP terminates before the start time of an active R-TWT SP advertised by an associated AP or an AP corresponding to a BSSID transmitted in the multiple BSSID set to which the associated AP belongs.

[0205] Here, TXOP means a time interval during which a particular STA may have the right to initiate a frame exchange sequence on a wireless medium (WM). TXOP may be defined by the starting time and maximum duration values ​​(for which such right may be exercised).

[0206] A TXOP holder is an STA that has been granted a TXOP by a hybrid coordinator (HC) or has successfully competed for a TXOP. In other words, a TXOP holder is an STA that has the authority to perform frame exchange sequences within a TXOP. A TXOP responder is an STA that sends a frame in response to a frame received from a TXOP holder during a frame exchange sequence, but does not acquire a TXOP in the process.

[0207] Furthermore, before initiating PPDU transmission, a non-AP EHT STA with "dot11RestrictedTWTOptionImplemented" set to true can verify if there is sufficient time to complete the frame exchange before the R-TWT SP begins. If there is insufficient time, the STA can now use CW (without proceeding to the next value in the sequence) and select a random backoff count to postpone transmission. An R-TWT schedule that is not publicly known in a beacon or probe response frame and is not in a transmitted BSSID profile may include schedules for both transmitted and untransmitted BSSIDs.

[0208] Unless the remainder of the TXOP belonging to the R-TWT SP is used for DL ​​frame transmission of the R-TWT DL TID or for requesting the UL frame of the R-TWT UL TID, an EHT AP (e.g., a TXOP holder) with "dot11RestrictedTWTOptionImplemented" set to true can ensure that the TXOP terminates before the start time of the self-advertised active R-TWT SP.

[0209] When an R-TWT SP begins, a member STA may temporarily suspend the backoff counter decrement for ACs that do not have a mapped R-TWT TID until all frames have been transmitted with the R-TWT TID. The member STA can then resume the decrement afterward or when the SP ends.

[0210] R-TWT SP and associated quiet interval

[0211] The R-TWT scheduling AP can schedule up to one silence interval that overlaps with the R-TWT SP. Here, the (overlapping) silence interval has a duration of 1 TU (time unit) and may be disclosed simultaneously with the R-TWT SP.

[0212] To schedule overlapping silence intervals for one or more R-TWT SPs belonging to one or more periodic or aperiodic R-TWT schedules, an EHT AP can do so by transmitting one or more quiet elements in beacon and probe response frames.

[0213] An EHT AP affiliated with an AP MLD does not need to include any silence elements in the transmitted beacon or probe response frame that correspond to overlapping silence intervals scheduled and advertised by other APs affiliated with the same AP MLD. A non-AP EHT STA can operate as if there were no overlapping silence intervals.

[0214] Multiple Access Point (MAP) Operation

[0215] The following describes examples of this disclosure relating to multiple access point (MAP) operation.

[0216] MAP operation can be a general term for methods by which multiple APs / STAs cooperate to send and receive data when communicating with other STAs. MAP operation may include a first method in which multiple APs simultaneously transmit data to an STA (i.e., a multiplexed APs / STAs co-transmission method), and a second method in which appropriate APs among multiple APs divide an appropriate domain (e.g., frequency / time / space domain) and then transmit data to a specific STA (i.e., an appropriate STA) (i.e., a multiplexed APs / STAs coordination method).

[0217] Specifically, the first method may include a method in which multiple APs / STAs communicate with each STA simultaneously during the same time period (for example, the C-SR (coordinated spatial reuse) method) and a method in which multiple APs / STAs perform joint transmission to the same STA (for example, the J-TX (joint transmission) method).

[0218] In the C-SR method, multiplexed APs / STAs share channel information (e.g., transmit power (Tx power), RSSI (Received Signal Strength Indicator)) with the STA, and can communicate with the STA(s) in the same time period based on the channel information. In the J-TX method, multiplexed APs / STAs share channels and data with the STA, and can communicate with the STA(s) in the same time period based on the shared channels and data.

[0219] As described above, the second method is a general term for methods in which APs / STAs divide into frequency, time, or spatial domains and communicate with other STAs in the divided domains. Frequency domain-based communication methods may include the C(coordinated)-OFDMA method, time domain-based communication methods may include AP selection, relay operation, C(coordinated)-TDMA (time division multiple access), V(virtual)-BSS method, etc., and spatial domain-based communication methods may include the C(coordinated)-BF(beamforming) method, etc.

[0220] For example, in a frequency domain-based communication scheme, multiplexed APs / STAs share channel information such as frequency bands with the STA, and can select an appropriate frequency band based on the shared channel information. The multiplexed APs / STAs can then communicate with the STA in the selected frequency band.

[0221] As another example, in time-domain-based communication schemes, a representative AP can be configured to take the lead in communication by selecting the appropriate AP / STA (which includes the representative AP) for the STA(s).

[0222] As another example, in spatial domain-based communication schemes, multiple APs / STAs can share channel information and other data with the STA, and calculate a BF matrix that is appropriate for each AP's communication or does not interfere with other APs. The multiple APs / STAs can then communicate with the STA based on the calculated BF matrix.

[0223] To support the MAP operation described above, the representative AP can select and instruct APs / STAs (hereinafter referred to as participating APs / STAs) for communication with the STA.

[0224] The representative AP (which can be rephrased as master AP, sharing AP, or primary AP) is responsible for initiating and controlling MAP operations for sending and receiving data between multiple APs. The representative AP groups participating APs and manages links with them to enable information sharing among them. The representative AP manages information about the BSS (Blockchain Service Server) that the participating APs make up, and information about the STAs (Standalone Services) that are associated with that BSS.

[0225] Participating APs (which may be referred to as slave APs, shared APs, or secondary APs) can connect with the main AP and share control information, management information, and data traffic with each other. Participating APs perform the same basic functions as APs that can establish a BSS in a wireless LAN.

[0226] In MAP operation, participating STAs can form a BSS by connecting with participating APs or representative APs.

[0227] In a MAP environment, the representative AP and participating APs can send and receive data directly from each other. The representative AP and STA may not send and receive data directly from each other. Participating APs (for example, participating APs that are connected to an STA) can send and receive data directly from an STA. Any one of the participating APs may be the representative AP.

[0228] How to protect OBSS R-TWT within a multi-BSS environment

[0229] In a multi-BSS environment, the range of overlapping BSS (hereinafter referred to as OBSS) is formed / configured based on the range in which an STA can receive frames transmitted from one or more APs (e.g., beacon frames).

[0230] For example, as shown in Figure 14, the signaling ranges of AP1 and AP2 may overlap, and an STA located within that range (e.g., STA1-2 and / or STA2-4) can receive not only beacon frames transmitted by AP1 in BSS1, to which it is associated, but also beacon frames from AP2 in BSS2, to which it is not associated.

[0231] Here, AP1 and AP2 may, but are not limited to, slave APs belonging to a multi-AP group having the same master AP. Either AP1 or AP2 may be the master AP.

[0232] The AP can transmit a beacon frame containing R-TWT scheduling information to the STA. At this time, the STA receiving the beacon frame may be located within the range of protecting the R-TWT SP. For example, the STA can protect the R-TWT SP based on the R-TWT scheduling information received from the AP using the method described above.

[0233] However, an STA located within the range corresponding to OBSS may receive beacon frames from neighboring APs (i.e., APs in BSS that the STA does not belong to (unassociated)) (e.g., AP2), and these beacon frames may contain R-TWT (hereinafter, OBSS R-TWT) scheduling information generated by the neighboring AP. Conventionally, there was a problem in that not only was there a method defined for the STA to protect the OBSS R-TWT SP, but there was also no defined method for sending and receiving low-latency traffic / data within the OBSS R-TWT SP.

[0234] The following describes the various operations performed by the STA and the BSS AP (e.g., AP1) that the STA is coupled with, based on the (OBSS) R-TWT scheduling information of the neighboring AP (e.g., OBSS R-TWT SP protection operation).

[0235] In describing this disclosure, STA may include non-AP STA and AP STA, and an R-TWT SP known by an AP of a BSS to which the STA is not coupled may be referred to as an OBSS R-TWT SP or an R-TWT SP scheduled by another AP. And an Associated AP may mean an AP of a BSS to which the STA is coupled (i.e., a BSS AP).

[0236] Figure 15 is a flowchart illustrating the operation of an STA according to one embodiment of the present disclosure. Here, the STA may be coupled to the BSS of the first AP. That is, from the perspective of the STA, the second AP may be an adjacent AP. The STA may, but is not limited to, the region where the BSS of the first AP and the BSS of the second AP overlap.

[0237] The STA can receive a first frame from the first access point (AP) that includes a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field (S1510). Here, the first frame may, but is not limited to, a management frame such as a beacon frame.

[0238] As an example of this disclosure, a first broadcast TWT parameter set field (i.e., a broadcast parameter set associated with a first R-TWT SP scheduled by a first AP) and a second broadcast TWT parameter set field (i.e., a broadcast parameter set associated with a second R-TWT SP scheduled by a second AP (i.e., an OBSS R-TWT SP)) may be included in a single TWT element (e.g., a first TWT element) included in the first frame. That is, the first TWT element may include multiple broadcast parameter sets, including the first broadcast parameter set and the second broadcast parameter set. In this case, the second broadcast parameter set may be, but is not limited to, the last broadcast parameter set among the multiple broadcast parameter sets included in the first TWT element of the first frame.

[0239] As yet another example of this disclosure, the first frame may include a second TWT element and a third TWT element, where the first broadcast parameter set is contained within the second TWT element and the second broadcast parameter set is contained within the third TWT element. That is, the first broadcast parameter set and the second broadcast parameter set may each be contained within a separate TWT element.

[0240] For example, the first information and the first broadcast TWT ID related to the first R-TWT SP scheduled by the first AP may be included in the first broadcast TWT parameter set, and the second information and the second broadcast TWT ID related to the second R-TWT SP scheduled by the second AP may be included in the second broadcast TWT parameter set. That is, the first broadcast TWT ID may correspond to the first information, and the second broadcast TWT ID may correspond to the second information. This allows the STA (e.g., a UHR STA supporting improved R-TWT) to distinguish between the first and second information.

[0241] For example, if the first TWT element contains a first broadcast TWT parameter set and a second broadcast TWT parameter set, the STA can identify the second broadcast parameter set containing information related to the second R-TWT SP by the second broadcast TWT ID. That is, the STA can identify the second broadcast parameter set contained in the third TWT element (i.e., the second broadcast parameter set containing the said second broadcast TWT ID) by the second broadcast TWT ID on the first TWT element. As yet another example, the STA can identify that the second broadcast parameter set on the first TWT element is related to the second R-TWT SP by the second broadcast TWT ID that corresponds to / maps / defines it to the second R-TWT SP.

[0242] As yet another example of this disclosure, a TWT recommendation field included in the first TWT element of the first frame may indicate that the first TWT element contains second information. For example, a reserved value (e.g., 5-7) in the TWT recommendation field may be mapped / corresponded to information indicating that the first TWT element contains second information. As yet another example, a TWT recommendation field included in the third TWT element may indicate that the third TWT element contains second information.

[0243] As yet another example of this disclosure, the inclusion of the second information in the WP1TWT element may be indicated by an NDP paging indicator subfield and a responder PM (power management) subfield included in the control field of the first TWT element. As yet another example, the inclusion of the second information in the third TWT element may be indicated by an NDP paging indicator subfield and a responder PM subfield included in the control field of the third TWT element.

[0244] The first STA can decode the first frame (S1520). Based on the information contained in the first frame, the first STA can perform actions to protect the second R-TWT SP.

[0245] For example, STA can terminate its TXOP (transmission opportunity) before the start of the second R-TWT SP.

[0246] As an example, the broadcast TWT information (info) subfield of the second broadcast TWT parameter set may include an R-TWT schedule information subfield, which may include information indicating that a membership request by the STA associated with the second R-TWT SP is not permitted. This prevents the STA from making a membership request based on the second broadcast TWT ID associated with the second R-TWT SP.

[0247] As yet another example, the R-TWT information subfield included in the broadcast TWT information subfield of the second broadcast TWT parameter set may include information indicating that the second information is associated with a second R-TWT SP scheduled by a second AP corresponding to a nontransmitted BSSID.

[0248] As another example, the value of the broadcast TWT persistence subfield included in the second broadcast parameter set field may be set to a predefined minimum value (e.g., 1).

[0249] The method performed by the STA as illustrated in Figure 15 may be performed by the first device 100 in Figure 1. For example, one or more processors 102 of the first device 100 in Figure 1 can receive a first frame containing a first broadcast TWT parameter set field and a second broadcast TWT parameter set field from a first access point (AP) via one or more transceivers 106. One or more processors 102 can decode the first frame.

[0250] When executed by one or more processors 102, the memory 104 can store instructions for performing the method described in the example in Figure 15.

[0251] Figure 16 is a diagram illustrating the operation of the first AP according to one embodiment of the present disclosure.

[0252] The first AP can receive second information related to the second restricted target wake time (R-TWT) service period (SP) from the second AP (S1610).

[0253] The fact that the first AP receives the second information from the second AP may include the operation of the first AP receiving the second information via another individual.

[0254] The first AP can transmit a first beacon frame containing first and second information related to the first R-TWT SP to the first STA (S1620).

[0255] The configuration of the first beacon frame that the first AP transmits to the first STA to protect / process the second R-TWT SP is explained with reference to Figure 15, and a redundant explanation is omitted here.

[0256] The method performed by the second STA, as illustrated in Figure 16, may also be performed by the second device 200 in Figure 1. For example, one or more processors 202 of the second device 200 in Figure 10 can receive second information related to the second R-TWT SP from the second AP via one or more transceivers 206. One or more processors 202 can transmit a first beacon frame containing first and second information related to the first R-TWT SP to the first STA via one or more transceivers 206.

[0257] Furthermore, one or more memories 204 of the second device 200 can store instructions for performing the method illustrated in the example of Figure 16, when executed by one or more processors 202.

[0258] The following section will specifically describe the method by which the STA and the 1st AP process OBSS R-TWT scheduling information, as explained with reference to Figures 15 and 16.

[0259] Example 1

[0260] Example 1 relates to a method by which an Associated AP acquires OBSS R-TWT scheduling information. In this example, the Associated AP can acquire OBSS R-TWT scheduling information using at least one of the following methods.

[0261] Method 1: When direct wired / wireless data transmission is possible between APs (i.e., Associated AP and neighboring APs), the Associated AP can transmit its R-TWT scheduling information to the neighboring AP, or receive OBSS R-TWT scheduling information from the neighboring AP.

[0262] Method 2: When direct wired / wireless data transmission between APs is not possible, APs can share R-TWT scheduling information via a third management entity. That is, APs can share R-TWT scheduling information using the third management entity as a relay entity.

[0263] For example, APs may be located within the same ESS. In the same ESS where multiple BSSs are connected to a single DS, a third management entity can provide the same service (e.g., a centralized service). This allows a third management entity that relays APs located within the same ESS to assume a role similar to a master AP or network controller.

[0264] As yet another example, an AP may be a slave (i.e., a Shared AP or / and a Scheduled AP) with the same AP as the Master AP (i.e., a Sharing AP or / and a Scheduled AP). In this case, the third managing entity may be the Master AP.

[0265] Method 3: The STA can overhear beacon frames made known by neighboring APs and decode the overheared beacon frames. The STA can then transmit information related to the OBSS R-TWT SP contained in the decoded beacon frame to the Associated AP.

[0266] Example 2

[0267] Example 2 relates to a method for protecting OBSS R-TWT according to STA types classified by the presence or absence of R-TWT support.

[0268] Depending on whether or not they support R-TWT, STA types can be classified as follows.

[0269] - Pre-EHT STA that does not support R-TWT: This refers to an STA that has Pre-EHT capability and may qualify as a legacy STA.

[0270] - EHT STA that does not support R-TWT: This is an STA that has EHT capacity and may be classified as an STA that does not support R-TWT.

[0271] - EHT STA supporting R-TWT: This is an STA with EHT capability and may qualify as an STA supporting R-TWT. In this case, the EHT STA supporting R-TWT may be defined / configured so as not to consider protective operation for OBSS R-TWT SP.

[0272] Additionally, UHR STAs (or STAs on wireless LAN systems based on or after IEEE 802.11be) may be classified based on whether or not they support R-TWT and / or OBSS R-TWT. For example, a UHR STA may transmit capability information to other STAs (e.g., APs) indicating whether or not it supports R-TWT and / or OBSS R-TWT, and the type of UHR STA may be classified based on this capability information.

[0273] - UHR STA that does not support R-TWT: This is an STA that has UHR capability and may be classified as an STA that does not support R-TWT.

[0274] - UHR STA supporting only R-TWT: This may be an STA that has UHR capability but supports only R-TWT (i.e., R-TWT and related operations and parameters shown in Figures 8-13). A UHR STA supporting only R-TWT cannot, but is not limited to, information related to OBSS R-TWT (e.g., information related to enhanced R-TWT). A UHR STA supporting only R-TWT can also decode information related to OBSS R-TWT.

[0275] - UHR STA for assisting improved R-TWT: This may correspond to a STA that supports UHR capabilities and supports improved R-TWT operation. The improved R-TWT operation may include protection operations for OBSS R-TWT SP, etc.

[0276] Example 2-1

[0277] Example 2-1 relates to the method by which the STA classified in Example 2 protects the OBSS R-TWT SP. The method of protecting the OBSS R-TWT SP may be defined / applied by extending the above-described methods (e.g., overlapping quiet intervals and / or TXOP of R-TWT SP and backoff procedure rules, etc.) for the STA to report the R-TWT SP.

[0278] Here, the TXOP and backoff procedure rules of the R-TWT may include rules for the STA (i.e., TXOP holder) that transmits and receives data in a TXOP that started before the R-TWT start time to stop the TXOP. The TXOP and backoff procedure rules of the R-TWT may also be equally applicable to the OBSS R-TWT SP. That is, rules for the STA (i.e., TXOP holder) that transmits and receives data in a TXOP that started before the OBSS R-TWT start time to stop the TXOP may be defined.

[0279] Also, the overlapping quiet interval can mean a quiet interval assigned to overlap at the same time as the R-TWT SP. The BSS AP can set the quiet interval to overlap with the OBSS R-TWT SP obtained by the method of obtaining the OBSS R-TWT scheduling information disclosed in Example 1. For example, the R-TWT scheduling AP (e.g., BSS AP) can set at least one (or at most one) overlapping interval that overlaps with the R-TWT SP and / or the OBSS R-TWT SP.

[0280] The following describes the method of protecting OBSS R-TWT SP for each STA type classified in Example 2.

[0281] - Pre-EHT STA that does not support R-TWT: This STA can protect OBSS R-TWT SP using overlapping silent intervals. For example, a Pre-EHT STA that does not support R-TWT can protect OBSS R-TWT SP (using the overlapping silent intervals set by the BSS AP to include OBSS R-TWT SP).

[0282] - EHT STA that does not support R-TWT: This STA can protect OBSS R-TWT SP using overlapping silent intervals. For example, an EHT STA that does not support R-TWT can protect OBSS R-TWT SP (using the overlapping silent intervals set by the BSS AP to include OBSS R-TWT SP).

[0283] - EHT STA that supports R-TWT: The operation of an EHT STA that supports R-TWT may be determined by whether the BSS AP makes the information on OBSS R-TWT SP (i.e., the R-TWT SP scheduled / assigned by the neighboring AP) known to the STA together with the information on the R-TWT SP assigned by itself. Option 1 below relates to the case where the BSS AP makes the information on OBSS R-TWT SP known to the STA (i.e., the EHT STA that supports R-TWT) together with the information on the R-TWT SP assigned by itself, and Option 2 relates to the case where the BSS AP does not make the information on OBSS R-TWT SP known to the STA.

[0284] - Option 1: If a BSS AP makes the OBSS R-TWT SP known to the STA along with information on the R-TWT SP it has assigned, the STA can protect the OBSS R-TWT SP by stopping any TXOPs that were in progress prior to the OBSS R-TWT SP, based on the TXOP and backoff procedure rules for the R-TWT SP.

[0285] A BSS AP can configure OBSS R-TWT SP information in the same way as R-TWT SP information, which may cause the STA to be unable to distinguish between OBSS R-TWT SP and R-TWT SP. However, a BSS AP can be configured so that OBSS R-TWT SP information corresponds to a specific broadcast TWT ID value. In this case, the broadcast TWT ID corresponding to the OBSS R-TWT SP information does not need to overlap with the broadcast TWT ID corresponding to the R-TWT SP information assigned / scheduled by the BSS AP (i.e., R-TWT SP information assigned by the BSS AP within its own BSS).

[0286] For example, a non-AP EHT STA (i.e., a TXOP holder) with "dot11RestrictedTWTOptionImplemented" set to true can ensure that the TXOP terminates before the start time of an active R-TWT SP, and such active R-TWT SP may include R-TWT SPs scheduled / advertised by an associated AP or an AP corresponding to a BSSID transmitted in a multi-BSSID set to which the associated AP belongs, and / or R-TWT SPs scheduled / advertised by (other) APs included in a multi-AP set.

[0287] In this case, a broadcast TWT element containing OBSS R-TWT SP information includes a broadcast TWT information (Info) subfield, and the broadcast TWT information subfield may include a restricted TWT schedule information subfield. The BSS AP can set the value of the restricted TWT schedule information subfield to a value indicating a full R-TWT schedule. In this case, the full R-TWT schedule indicated by the restricted TWT schedule information subfield may mean an R-TWT schedule that cannot accept a new membership request from the STA. This can prevent the STA from requesting membership based on a broadcast TWT ID containing OBSS R-TWT SP information.

[0288] As an addition or alternative, a BSS AP may set the value of the restricted TWT schedule information subfield to a value (e.g., 3) that indicates that the corresponding R-TWT SP is an R-TWT SP scheduled by an AP corresponding to a nontransmitted BSSID. This allows an STA connected to an AP corresponding to a transmitted BSSID to recognize that the R-TWT SP (i.e., the OBSS R-TWT SP) is not an R-TWT SP scheduled by an AP of the BSS to which it belongs.

[0289] Through the method described above, an STA whose R-TWT SP is coupled to a publicly known BSS can recognize the OBSS R-TWT SP information as information about an SP assigned by another R-TWT member (for example, an AP of a BSS to which the STA itself does not belong).

[0290] - Option 2: If a BSS AP does not disclose to the STA the OBSS R-TWT SP (i.e., an OBSS R-TWT SP scheduled by a neighboring AP) along with the information of the R-TWT SP it has assigned, the EHT STA supporting the R-TWT can protect the OBSS R-TWT SP using overlapping silence intervals set by the BSS AP to include the OBSS R-TWT SP.

[0291] - UHR STA that does not support R-TWT: The STA can protect the OBSS R-TWT SP using overlapping silence intervals configured by the BSS AP to include the OBSS R-TWT SP.

[0292] - UHR STA supporting only R-TWT: The behavior of a UHR STA supporting only R-TWT may be determined by whether or not the BSS AP has made public information about the OBSS R-TWT SP (i.e., the R-TWT SP scheduled / assigned by a neighboring AP) along with information about the R-TWT SP that it has assigned.

[0293] As an example of this disclosure, if a BSS AP makes an OBSS R-TWT SP public to a STA along with information on an R-TWT SP that it has assigned, the STA can protect the OBSS R-TWT SP by stopping any TXOPs that were in progress prior to the OBSS R-TWT SP, based on the TXOP and backoff procedure rules for the R-TWT SP.

[0294] A BSS AP can configure OBSS R-TWT SP information in the same way as R-TWT SP information, which may cause the STA to be unable to distinguish between OBSS R-TWT SP and R-TWT SP. However, a BSS AP can configure OBSS R-TWT SP information to correspond to the value of a specific broadcast TWT ID. In this case, the broadcast TWT ID corresponding to the OBSS R-TWT SP information does not need to overlap with the broadcast TWT ID corresponding to the R-TWT SP information assigned / scheduled by the BSS AP (i.e., the R-TWT SP information assigned by the BSS AP within its own BSS).

[0295] In this case, a broadcast TWT element containing OBSS R-TWT SP information includes a broadcast TWT information subfield, and the broadcast TWT information subfield may include a restricted TWT schedule information subfield. The BSS AP can set the value of the restricted TWT schedule information subfield to a value indicating the full R-TWT schedule. In this case, the full R-TWT schedule indicated by the restricted TWT schedule information subfield may mean an R-TWT schedule that cannot accept a new membership request from the STA. This can prevent the STA from requesting membership based on a broadcast TWT ID containing OBSS R-TWT SP information.

[0296] As yet another example of this disclosure, if a BSS AP does not make known to its STA information about R-TWT SPs assigned by neighboring APs (i.e., OBSS R-TWT SPs) along with information about R-TWT SPs assigned by itself, the STA can protect the OBSS R-TWT SPs using overlapping silence intervals set by the BSS AP to include the OBSS R-TWT SPs.

[0297] As an addition or alternative, a BSS AP may set the value of the restricted TWT schedule information subfield to a value (e.g., 3) that indicates that the corresponding R-TWT SP is an R-TWT SP scheduled by an AP corresponding to a nontransmitted BSSID. This allows an STA connected to an AP corresponding to a transmitted BSSID to recognize that the R-TWT SP (i.e., the OBSS R-TWT SP) is not an R-TWT SP scheduled by an AP of the BSS to which it belongs.

[0298] As yet another example of this disclosure, if a BSS AP does not make known to the STA information about R-TWT SPs assigned by neighboring APs (i.e., OBSS R-TWT SPs) along with information about R-TWT SPs assigned by itself, the STA can protect the OBSS R-TWT SPs using overlapping silence intervals set by the BSS AP to include the OBSS R-TWT SPs.

[0299] Using the method described above, an STA that has an R-TWT SP connected to a known BSS can recognize the OBSS R-TWT SP information as information about an SP assigned by another R-TWT member (for example, an AP of a BSS to which the STA itself does not belong).

[0300] As an example of this disclosure, let us assume that the STA requests membership based on the broadcast TWT ID corresponding to the OBSS R-TWT SP information. In this case, the AP can reject the membership request based on the broadcast ID corresponding to the OBSS R-TWT SP.

[0301] - UHR STA supporting improved R-TWT: This STA can protect the OBSS R-TWT SP based on the TXOP and backoff procedure rules of the R-TWT SP.

[0302] For example, a Non-AP EHT STA (e.g., a TXOP holder) with "dot11RestrictedTWTOptionImplemented" set to true can be guaranteed to end its TXOP before the start time of the active R-TWT SP advertised by the associated AP, the AP corresponding to the BSSID transmitted in the multi-BSSID set to which the associated AP belongs, or the AP included in the same multi-AP set (or, an unassociated AP / neighbor AP).

[0303] As an example, as shown in FIG. 17, a UHR STA (e.g., STA1) that supports improved R-TWT can end its own TXOP before the start time of an OBSS R-TWT SP (i.e., an R-TWT SP scheduled by a neighbor AP (e.g., AP2)) known by the AP (i.e., the associated AP) of the BSS to which the STA is associated (e.g., AP1) in order to protect the OBSS R-TWT SP.

[0304] As an example of the present disclosure, a UHR STA that supports improved R-TWT can protect an OBSS R-TWT SP using overlapping silent intervals.

[0305] As an example, when a UHR STA that supports improved R-TWT cannot receive a beacon frame and does not know that a specific silent interval overlaps with an OBSS R-TWT SP, the UHR STA that supports improved R-TWT can protect the OBSS R-TWT SP by operating according to the silent interval assigned by the AP (e.g., the BSS AP). At this time, information related to the silent interval assigned by the AP can be transmitted to the STA in a frame separate from the beacon frame.

[0306] As described above, by an AP (e.g., a BSS AP) making public an R-TWT SP that includes information about the OBSS R-TWT SP, an EHT STA supporting an R-TWT and / or a UHR STA supporting only an R-TWT can recognize that the OBSS R-TWT SP is also an SP of a separate R-TWT member assigned by the AP.

[0307] In this case, the STA can request membership through an R-TWT member corresponding to the OBSS R-TWT SP. Since the SP and / or the STA are inter-BSS, the STA does not need to belong to / correspond to the broadcast TWT ID corresponding to the OBSS R-TWT SP. In this case, the AP (e.g., BSS AP) can operate in one or more of the following ways.

[0308] - If the STA requests membership based on a broadcast TWT ID corresponding to the OBSS R-TWT SP, the AP may reject the membership request.

[0309] - The AP may transmit information about the R-TWT SP to the STA in a beacon frame. In this case, the restricted TWT element containing the OBSS R-TWT SP may include a broadcast TWT information subfield, and the value of the broadcast TWT persistence subfield of the broadcast TWT information subfield may be set to a minimum value (e.g., 1). Setting the broadcast TWT persistence subfield value to a minimum value means that the validity period of the R-TWT SP can only exist until the next beacon interval. This can prevent the STA from making a membership request based on the broadcast TWT ID corresponding to the R-TWT SP.

[0310] Here, the minimum value that the AP sets in the broadcast TWT persistence subfield within a restricted TWT element containing an OBSS R-TWT SP does not need to be related to the actual possible existence time of the OBSS R-TWT SP. This can prevent the AP from being overloaded by membership requests from multiple STAs for broadcast TWT IDs corresponding to the OBSS R-TWT SP.

[0311] Example 3

[0312] As an implementation of this disclosure, an AP may make information about R-TWT SPs it has scheduled / assigned and information about OBSS R-TWT SPs available to an STA. In this case, if the STA is an STA supporting an improved R-TWT (e.g., a UHR STA supporting an improved R-TWT), the STA may distinguish between OBSS R-TWT SPs and R-TWT SPs assigned by the AP. An AP (e.g., a BSS AP) may instruct an STA (an STA coupled to the BSS) that a particular R-TWT SP is an OBSS R-TWT SP by any one of the methods described later in the embodiments (Embodiments 3-1, 3-2, and 3-3).

[0313] Example 3-1

[0314] Method 1: As an example of this disclosure, the broadcast TWT information subfield may include a restricted TWT traffic information presence subfield. Since the restricted TWT traffic information subfield is not included in the beacon frame, the restricted TWT traffic information presence subfield value of the broadcast TWT information subfield included in the beacon frame may always be set to 0. As yet another example, if the restricted TWT traffic information presence subfield value included in the beacon frame is set to 1, this can mean that the broadcast TWT element included in the beacon frame contains information related to an R-TWT SP (i.e., OBSS R-TWT SP) scheduled by a neighboring AP. That is, a restricted TWT traffic information presence subfield set to 1 included in the beacon frame does not mean that the broadcast TWT element has a restricted TWT traffic information subfield, but rather that the broadcast TWT element is related to an R-TWT SP scheduled by a neighboring AP.

[0315] Method 2: As an additional or alternative, and as an example of the present disclosure, OBSS R-TWT SP information may be configured to correspond to a specific broadcast TWT ID value, so that an STA (e.g., a UHR STA supporting improved R-TWT) can identify that the OBSS R-TWT SP information relates to an R-TWT SP scheduled by a neighboring AP. APs within a BSS can configure the broadcast TWT IDs corresponding to each R-TWT SP information they have assigned within their BSS so that they do not overlap with the broadcast TWT IDs corresponding to OBSS R-TWT SP information (scheduled by neighboring APs).

[0316] As an addition or alternative, the presence or absence of duplicate broadcast TWT IDs in the broadcast TWT parameter set field containing one or more OBSS R-TWT schedule information is not limited. That is, there may be multiple broadcast TWT IDs corresponding to multiple OBSS R-TWT schedules. As another example, there may be one specific broadcast TWT ID corresponding to multiple OBSS R-TWT schedules.

[0317] As an addition or alternative, i) a specific broadcast TWT ID indicating that it is an OBSS R-TWT SP, and ii) the NDP paging indicator subfield and responder PM mode subfield values ​​of the control field within the TWT element may be used. That is, the broad TWT ID value in the broadcast TWT parameter set field may be set to a broadcast TWT ID indicating that it is an OBSS R-TWT SP, and the combination of the NDP paging indicator subfield and responder PM mode subfield values ​​on the control field of the TWT element containing the broadcast TWT parameter set field may indicate the presence of a broadcast TWT parameter set field containing an OBSS R-TWT schedule within that TWT element. For example, the combination of the NDP paging indicator subfield and responder PM mode subfield values ​​may be (1,0) or (0,0).

[0318] Method 3: As an addition or alternative, in one implementation of the present disclosure, a reserved value (e.g., 5-7) in the Broadcast TWT recommendation field within the Broadcast TWT element may indicate that the schedule information contained within the Broadcast TWT element is related to an R-TWT SP (e.g., OBSS R-TWT SP) scheduled by a neighboring AP.

[0319] For example, if the OBSS R-TWT SP is indicated by the value of the broadcast TWT recommendation field within the broadcast TWT element, the (sub)fields within the broadcast TWT parameter set field may be parsed / defined as follows.

[0320] - As an example, (sub)fields within a broadcast TWT parameter set field (e.g., TWT request subfields, TWT setup command subfields, trigger subfields, flow type subfields, and / or aligned subfields included within a request type field) may be replaced with subfields associated with OBSS R-TWT schedules included within the broadcast TWT parameter set field (e.g., subfields containing information for OBSS R-TWT schedules or / or information indicating that OBSS R-TWT schedule information exists). As another example, reserved subfields within a broadcast TWT parameter set field may be replaced with subfields associated with OBSS R-TWT schedules.

[0321] - Information for an OBSS R-TWT schedule may include information related to the BSS color of the OBSS AP that scheduled the OBSS R-TWT SP / schedule, information related to the bandwidth on which the OBSS R-TWT SP / schedule operates, and / or information related to the channel on which the OBSS R-TWT schedule operates.

[0322] Specifically, the overprotection problem for the OBSS R-TWT SP can be resolved by using information related to the BSS color of the OBSS AP that scheduled the OBSS R-TWT SP / schedule. For example, if a BSS STA (i.e., an STA coupled to a BSS) has never received a PPDU with a specific BSS color A, the BSS STA does not necessarily have to stop its TXOP before the start of the OBSS R-TWT SP corresponding to BSS color A. In other words, the fact that a BSS STA has never received a PPDU with a specific BSS color A means that the BSS STA is in a position where it is not affected by the OBSS R-TWT schedule.

[0323] Information related to the bandwidth in which the OBSS R-TWT schedule operates can represent the bandwidth operated by BSS APs that are affected by the bandwidth in which the OBSS AP operates. In other words, information related to the bandwidth in which the OBSS R-TWT schedule operates can indicate the bandwidth information of BSS APs that overlap with the bandwidth in which the OBSS AP operates. For example, the information related to the bandwidth in which the OBSS R-TWT schedule operates and the associated subfield values ​​can indicate 20MHz, 40MHz, 80MHz, 160MHz, 320MHz, or 640MHz.

[0324] For example, if the bandwidth operated by the OBSS AP is 80 MHz and the bandwidth operated by the BSS AP is 160 MHz, the overlapping bandwidth region between the bandwidths operated by the BSS AP and the OBSS AP may be indicated by the TWT bandwidth subfield. In the example above, if the overlapping bandwidth between the bandwidth operated by the BSS AP and the OBSS AP is 80 MHz (or 40 MHz or 20 MHz), the TWT bandwidth subfield may be set to a value indicating 80 MHz (or 40 MHz or / and 20 MHz).

[0325] Alternatively, for example, if the bandwidth operated by the OBSS AP is 320 MHz and the bandwidth operated by the BSS AP is 320 MHz, but the secondary channels have other bandwidths (e.g., 160-1 MHz or 160-2 MHz in the 320 MHz band within 6 GHz, or another 20 MHz secondary in the 40 MHz band within 2.4 GHz), the TWT bandwidth subfield can only indicate common bandwidths other than those that do not overlap.

[0326] Information related to the channel on which the OBSS R-TWT schedule is operated may be in a bitmap format where one bit indicates 20 MHz based on the bandwidth indicated by the TWT bandwidth. That is, the length of the TWT channel field may vary depending on the value of the TWT bandwidth subfield. For example, if the TWT channel field has a length of one octet and the value of the TWT bandwidth subfield is set to a value indicating 40 MHz, the TWT channel field may contain two bits of information about the channel on which the R-TWT schedule is operated (e.g., 00, 01, 10, 11), with the remaining bits reserved.

[0327] As an addition or alternative, if an OBSS R-TWT SP is indicated in the Broadcast TWT Recommendation field within the Broadcast TWT element, the Broadcast TWT element may include a specific element which may include information / subfields related to the OBSS R-TWT schedule made public by the AP to the STA (e.g., a subfield containing information for the OBSS R-TWT schedule and / or information indicating that OBSS R-TWT schedule information exists).

[0328] Example 3-2

[0329] Method 4: When the value of the restricted TWT traffic information presence subfield in the broadcast TWT Info subfield included in the beacon frame is set to 1 by Method 1 of Example 3-1, or when the value of the TWT recommendation field in the broadcast TWT element indicates that the scheduling information of the TWT element is an OBSS R-TWT SP by Method 2 of Example 3-1, the AP may transmit / disclose information about the OBSS R-TWT SP in the manner described below.

[0330] As an example, as shown in Figure 18(a), the information regarding the OBSS R-TWT SP may include the BSS color of the neighboring AP to which the OBSS R-TWT SP was assigned, as well as the actual TWT persistence, TWT bandwidth, and TWT channel information of the OBSS R-TWT SP. In other words, the information regarding the OBSS R-TWT SP shown in Figure 18(a) may be included in the TWT element, and the AP can transmit the TWT element to the STA.

[0331] For example, if the value of the Restricted TWT Traffic Information Presence subfield within a broadcast TWT element included in a beacon frame is set to 1, the Broadcast TWT ID subfield can indicate that the information regarding the R-TWT SP is OBSS R-TWT SP information. The BSS Color subfield can indicate the BSS color of the neighboring AP that assigned the OBSS R-TWT SP. The Restricted TWT Persistence subfield can indicate information related to the actual persistence of the OBSS R-TWT SP. The TWT Bandwidth subfield can indicate information related to the bandwidth on which the OBSS R-TWT schedule / SP operates. The TWT Channel subfield can indicate information related to the channel on which the OBSS R-TWT schedule / SP operates.

[0332] Method 5: The method by which the AP transmits / discloses the OBSS R-TWT SP, as described in Method 4, may be as described in the methods below (Methods 5-1 and 5-2).

[0333] Method 5-1: When the value of the last broadcast parameter set subfield included in the request type field within the broadcast TWT parameter set is set to 1, one OBSS TWT parameter set may be added after the last broadcast TWT parameter set. The added OBSS TWT parameter set may be no more than 10 octets, which is the length of the existing broadcast TWT parameter set.

[0334] For example, if one or more broadcast TWT IDs correspond to OBSS R-TWT SPs, information regarding the OBSS R-TWT SPs corresponding to each broadcast TWT ID may be listed. As an example, as shown in Figure 18(b), an OBSS TWT parameter set may be constructed by listing information regarding OBSS R-TWT SPs corresponding to one or more broadcast TWT IDs. However, this is only one embodiment, and a single OBSS TWT parameter set may be constructed with the broadcast TWT ID as the boundary.

[0335] Method 5-2: The OBSS R-TWT and its associated OBSS TWT element may be placed / positioned after the TWT element within the beacon frame. The OBSS TWT element may, but is not limited to, the configuration shown in Figure 18(c).

[0336] As an example, an OBSS TWT element may include a control field and an OBSS R-TWT SP information field. The control field may include an OBSS R-TWT SP subfield and a broadcast TWT ID subfield. The OBSS R-TWT SP subfield can indicate the total number of OBSS R-TWT SPs indicated by the TWT element. The broadcast TWT ID subfield can indicate the total number of broadcast TWT IDs included in the TWT element that indicates the OBSS R-TWT SP. The total number of broadcast TWT IDs can indicate the number of times the broadcast TWT ID in the OBSS R-TWT SP information field is repeated. As an example, the OBSS R-TWT SP information field may include additional information for the OBSS R-TWT SP shown in Figure 18(a). As yet another example, if one or more broadcast TWT IDs correspond to OBSS R-TWT SPs, the OBSS R-TWT SP information field may be configured as shown in Figure 18(b).

[0337] Example 3-3

[0338] If the AP has configured information regarding R-TWT SP and OBSS R-TWT SP in the beacon frame, the AP can add OBSS R-TWT SP information to the beacon frame using the method described later.

[0339] Method 6: If the last broadcast parameter set subfield value included in a specific broadcast TWT parameter set is 1, the AP may add one OBSS TWT parameter set field after that last broadcast TWT parameter set. The additional OBSS TWT parameter set may have a length not exceeding 10 octets, which is the length of the existing broadcast TWT parameter set.

[0340] For example, if one or more broadcast TWT IDs correspond to OBSS R-TWT SPs, the information for each OBSS R-TWT SP corresponding to each broadcast TWT ID may be listed / arranged. The consecutive configuration shown in Figure 18(a) may be configured as shown in Figure 18(b). In such a case, a single parameter set may be configured with the broadcast TWT ID as the boundary.

[0341] Method 7: The OBSS TWT element described with reference to Method 5-2 may be positioned / placed after the TWT element of the beacon frame. The OBSS TWT element may be configured as shown in Figure 18(c).

[0342] The following examples illustrate the operation of OBSS R-TWT SP and related AP / STA.

[0343] Figure 19 illustrates the operation of an AP for making known an OBSS R-TWT SP according to one embodiment of the present disclosure, and may be applicable when supporting an improved R-TWT. Specifically, the operation in Figure 19 is when an STA (e.g., STA1-2 and STA2-4 in Figure 14) is located in an overlapping position between the BSS of an AP (i.e., the AP of the BSS to which the STA is coupled) and the BSS of an adjacent AP. Figure 14 illustrates, but is not limited to, APs not located in the BSS region between them.

[0344] APs can obtain information about OBSS R-TWT SPs directly or indirectly from neighboring APs (S1910). APs can determine whether or not information about OBSS R-TWT SPs is contained within a TWT element (S1920). If information about OBSS R-TWT SPs is contained within a TWT element, APs can perform actions related to the information contained within the TWT element. APs may be configured so that the broadcast TWT ID set to correspond to an OBSS R-TWT SP does not overlap with the broadcast TWT ID set to correspond to an R-TWT SP scheduled by that AP.

[0345] For example, if the broadcast TWT ID set to correspond to the OBSS R-TWT SP and the broadcast TWT ID set to correspond to the R-TWT SP scheduled by the AP overlap, the AP may change the broadcast TWT ID corresponding to the OBSS R-TWT SP to a different value (S1940-1).

[0346] As yet another example, if the broadcast TWT ID set to correspond to the OBSS R-TWT SP and the broadcast TWT ID set to correspond to the R-TWT SP scheduled by the AP do not overlap, the AP can add additional information to the OBSS R-TWT SP (on the TWT element) according to the embodiment described above (S1940-2). The AP can then make the additional information to the OBSS R-TWT SP public (S1950). Furthermore, the embodiment described above may prevent the STA from requesting membership for the OBSS R-TWT SP.

[0347] Figure 20 illustrates an operation in which an AP knows the overlapping silence interval for an OBSS R-TWT SP, according to one embodiment of the present disclosure, and may be applicable when supporting an improved R-TWT. Specifically, the operation in Figure 20 is when an STA (e.g., STA1-2 and STA2-4 in Figure 14) is located in an overlapping position between the BSS of an AP (i.e., the AP of the BSS to which the STA is coupled) and the BSS of an adjacent AP. Figure 14 illustrates that APs are not located in the BSS region between them, but is not limited to this.

[0348] In other words, Figure 20 illustrates a method for making the assignment information of silent intervals known to the STA connected to the BSS of the AP by assigning silent intervals that are duplicated in the OBSS R-TWT SP.

[0349] The AP can obtain information regarding the OBSS R-TWT SP (S2010). The AP can decide whether or not to set / assign a silence interval that overlaps with the OBSS R-TWT SP (S2020). If the AP sets / assigns a silence interval that overlaps with the OBSS R-TWT SP, it can include information related to that silence interval in the silence element and make that silence element public to the STA connected to the BSS (S2030).

[0350] As another example, if no silent interval is assigned that overlaps with the OBSS R-TWT SP, it can be said that the AP will not protect the OBSS R-TWT SP using the silent interval. In this case, only the STA supporting the R-TWT and / or the STA supporting the improved R-TWT SP may be supported for protection of the R-TWT SP.

[0351] Figure 21 is a flowchart illustrating the operation of the AP with respect to the R-TWT known by STA type according to one embodiment of the present disclosure. Specifically, Figure 21 relates to a method in which the AP protects the OBSS R-TWT SP with the capacity supported by the STA based on the R-TWT SP information known by the AP.

[0352] STA may disclose information regarding R-TWT SP from the AP of the coupled BSS (S2110).

[0353] As an example of this disclosure, if the STA is a UHR STA that supports an improved R-TWT (S2120-1), the STA can protect the OBSS R-TWT SP by suspending its TXOP before the start of the OBSS R-TWT SP (S2130-1). In this case, the STA can distinguish between the R-TWT SP and the OBSS R-TWT SP scheduled by the AP according to the embodiments described above.

[0354] As yet another example of this disclosure, if the STA is an EHT / UHR STA that supports R-TWT (i.e., does not support improved R-TWT) (S2120-2), the STA cannot distinguish between R-TWT SPs and OBSS R-TWT SPs. Therefore, the STA can perform protective actions for all R-TWT SPs included in the scheme known from the AP (S2130-2).

[0355] As yet another example of this disclosure, if the STA is an EHT / Pre-EHT STA that does not support R-TWT (S2130-3), the STA may not be aware of the publicly known information of the AP's R-TWT SP. Therefore, the STA can protect the OBSS R-TWT SP using a silence interval that overlaps with the OBSS R-TWT SP (S2130-3).

[0356] Figure 22 is a diagram illustrating a PPDU transmission and reception procedure between a transmitting STA and a receiving STA according to one embodiment of the present disclosure. Some steps shown in Figure 22 may be omitted depending on the circumstances and / or settings. The transmitting device and receiving STA may be AP and / or non-AP STA.

[0357] The transmitting STA can acquire control information related to the tone plan (or RU) described above (S105). The control information related to the tone plan may include the size and location of the RU, control information related to the RU, information about the frequency band in which the RU is contained, and information about the STA receiving the RU.

[0358] The transmitting STA can configure / generate a PPDU based on the acquired control information (S110). Configuring / generating a PPDU means configuring / generating each field of the PPDU. That is, the step of configuring / generating a PPDU may include the step of configuring the EHT-SIG-A / B / C fields, which contain control information related to the tone plan.

[0359] In other words, the steps of configuring / generating the PPDU may include configuring a field containing control information (e.g., an N-bitmap) that indicates the size / location of the RU and / or configuring a field containing an identifier (e.g., AID) of the STA that receives the RU.

[0360] Furthermore, the step of configuring / generating the PPDU may include a step of generating the STF / LTF sequence to be transmitted by a specific RU. The STF / LTF sequence may be generated based on a pre-configured STF generation sequence / LTF generation sequence.

[0361] Furthermore, the step of configuring / generating the PPDU may include the step of generating the data fields (i.e., MPDU) to be transmitted in a specific RU.

[0362] The transmitting STA can send the configured / generated PPDU to the receiving STA (S115).

[0363] Specifically, the transmitting STA can perform at least one of the following: CSD (cyclic shift diversity), spatial mapping, IDFT (inverse discrete fourier transform) / IFFT (inverse fast fourier transform) operation, and GI (guard interval) insertion operation.

[0364] The receiving STA can decode the PPDU and obtain control information related to the tone plan (or RU) (S120).

[0365] Specifically, the receiving STA can decode the L-SIG and EHT-SIG of the PPDU based on the L-STF / LTF and obtain the information contained in the L-SIG and EHT-SIG fields. Information regarding the various tone plans (i.e., RUs) of this disclosure may be contained in the EHT-SIG (EHT-SIG-A / B / C, etc.), and the receiving STA can obtain information regarding the tone plans (i.e., RUs) by the EHT-SIG.

[0366] The receiving STA can decode the rest of the PPDU based on the information about the acquired tone plan (i.e., RU) (S125). For example, the receiving STA can decode the STF / LTF fields of the PPDU based on the information about the tone plan (i.e., RU). The receiving STA can also decode the data fields of the PPDU based on the information about the tone plan (i.e., RU) and obtain the MPDU contained in the data fields.

[0367] Furthermore, the receiving STA can perform processing operations to transmit the decoded data to a higher layer (e.g., the MAC layer). Also, if the higher layer instructs the PHY layer to generate a signal in response to the data transmitted to the higher layer, the receiving STA can perform subsequent operations.

[0368] Through the operations described above, the receiving STA can obtain not only R-TWT scheduling information, but also, in some cases, information about R-TWTs scheduled by neighboring APs, based on the data. This allows the receiving STA to perform protective actions against R-TWT SPs.

[0369] The embodiments described above are combinations of the components and features of the present disclosure in a predetermined form. Each component or feature should be considered optional unless otherwise explicitly mentioned. Each component or feature may be implemented in a form that does not combine with other components or features. It is also possible to combine some components and / or features to constitute embodiments of the present disclosure. The order of operations described in embodiments of the present disclosure may be changed. Some components or features of one embodiment may be included in other embodiments, or replaced by corresponding components or features of other embodiments. It is clear that claims that do not have an explicit reference relationship in the claims may be combined to constitute embodiments, or may be included as new claims by amendment after filing.

[0370] It will be obvious to those skilled in the art that this disclosure can be embodied in other specific forms, provided that the essential features of this disclosure are not deviated from. Therefore, the above-mentioned detailed description should not be constrained in any way and should be considered illustrative. The scope of this disclosure should be determined by a reasonable interpretation of the attached claims, and any modifications within the equivalent scope of this disclosure are included within the scope of this disclosure.

[0371] The scope of this disclosure includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) that cause an apparatus or computer to perform operations according to the methods of various embodiments, and non-transitory computer-readable medium on which such software or instructions are stored and executable on the apparatus or computer. Instructions available for programming a processing system that performs the features described in this disclosure may be stored on / in a storage medium or computer-readable storage medium, and the features described in this disclosure may be embodied using a computer program product including such storage medium. The storage medium may include, but is not limited to, high-speed random-access memory such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices, and may include non-volatile memory such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory optionally includes one or more storage devices located remotely from the processor. Memory, or alternatively, non-volatile memory devices within memory, includes non-transitory computer-readable storage medium. The features described in this disclosure may be stored on any one of the machine-readable media and integrated into software and / or firmware that can control the hardware of the processing system and cause the processing system to interact with other mechanisms that utilize the results relating to the embodiments of this disclosure. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems and execution environments / containers.

[0372] [Industrial applicability] Although the method proposed in this disclosure has been primarily described in terms of its application to IEEE 802.11-based systems, it can be applied to a variety of other wireless LAN or wireless communication systems.

[0373] [Claims when filing an international application] [Claim 1] A method performed by a station (STA) in a wireless LAN system, The process includes receiving a first frame from a first access point (AP) that includes a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field, The process includes the step of decoding the first frame, The first information and the first broadcast TWT identifier (ID) related to the first restricted TWT (R-TWT) service period (SP) scheduled by the first AP are included in the first broadcast TWT parameter set. The second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set, in this method. [Claim 2] The method according to claim 1, wherein the transmission opportunity (TXOP) of the STA is terminated by the STA before the start of the second R-TWT SP. [Claim 3] The broadcast TWT information (info) subfield of the second broadcast TWT parameter set includes the R-TWT schedule information subfield, The method according to claim 1, wherein the R-TWT schedule information subfield includes information indicating that a membership request by the STA related to the second R-TWT SP is not permitted. [Claim 4] The broadcast TWT information subfield of the second broadcast TWT parameter set includes the R-TWT schedule information subfield, The method according to claim 1, wherein the R-TWT schedule information subfield includes information indicating that the second R-TWT SP is associated with the second AP scheduled by the second AP corresponding to a nontransmitted BSSID (basic service set identifier). [Claim 5] The method according to claim 1, wherein the value of the broadcast TWT persistence subfield included in the second broadcast parameter set field is set to a predefined minimum value. [Claim 6] The first frame includes a first TWT element, The method according to claim 1, wherein the first TWT element is indicated to contain the second information by a null data physical protocol data unit (NDP) paging indicator subfield and a responder PM (power management) subfield included in the control field of the first TWT element. [Claim 7] The method according to claim 1, wherein a TWT recommendation field included in the first TWT element of the first frame indicates that the first TWT element contains the second information. [Claim 8] The first TWT element includes a plurality of parameter sets, including the first broadcast parameter set and the second broadcast parameter set. The method according to claim 1, wherein the second broadcast parameter set is the last of the plurality of broadcast parameter sets. [Claim 9] The method according to claim 1, wherein the second broadcast parameter set includes at least one of the BSS color of the second AP or the channel or bandwidth in which the second R-TWT SP is used. [Claim 10] The first frame includes a second TWT element and a third TWT element, The first broadcast parameter set is included in the second TWT element, The method according to claim 1, wherein the second broadcast parameter set is included in the third TWT element. [Claim 11] The method according to claim 1, wherein the second R-TWT SP is protected by an overlapping quiet interval set by the first AP. [Claim 12] The method according to claim 1, wherein the first frame includes a beacon frame. [Claim 13] The method according to claim 1, wherein the STA is associated with the BSS of the first AP. [Claim 14] A station (STA) that operates in a wireless LAN system, One or more transceivers, The system comprises one or more processors connected to one or more of the aforementioned transceivers, The one or more processors described above are: A first frame is received from the first access point (AP) via one or more transceivers, including a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field; The first frame is configured to decode; The first information and the first broadcast TWT identifier (ID) related to the first restricted TWT (R-TWT) service period (SP) scheduled by the first AP are included in the first broadcast TWT parameter set. The second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set, STA. [Claim 15] A method performed by a first access point (AP) in a wireless LAN system, The second AP receives second information related to the second restricted target wake time (R-TWT) service period (SP), The process includes the step of transmitting a first beacon frame containing first information and second information related to the first R-TWT SP to the first station (STA), The first beacon frame includes a first broadcast TWT parameter set field and a second broadcast TWT parameter set field, The first broadcast TWT parameter set field includes the first information and the first broadcast TWT ID, The method wherein the second broadcast TWT parameter set field includes the second information and the second broadcast TWT ID. [Claim 16] A first access point (AP) operating in a wireless LAN system, One or more transceivers, The system comprises one or more processors connected to one or more of the aforementioned transceivers, The one or more processors described above are: The second AP receives second information related to the second restricted target wake time (R-TWT) service period (SP) via one or more transceivers; The system is configured to transmit a first beacon frame containing first information and second information related to the first R-TWT SP to the first station (station:STA) via one or more of the aforementioned transceivers; The first beacon frame includes a first broadcast TWT parameter set field and a second broadcast TWT parameter set field, The first broadcast TWT parameter set field includes the first information and the first broadcast TWT ID, The second broadcast TWT parameter set field includes the second information and the second broadcast TWT ID, and is part of the first AP. [Claim 17] A processing device configured to control a first station (STA) operating in a wireless LAN system, One or more processors, The system comprises one or more computer memories that are operably connected to one or more processors and store instructions for performing operations based on execution by the one or more processors, The aforementioned operation is, The operation of receiving a first frame from the first access point (AP) that includes the first broadcast target wake time (TWT) parameter set field and the second broadcast TWT parameter set field, The operation includes decoding the first frame, The first information and the first broadcast TWT identifier (ID) related to the first restricted TWT (R-TWT) service period (SP) scheduled by the first AP are included in the first broadcast TWT parameter set. Processing device, in which the second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set. [Claim 18] One or more non-transitory computer-readable media for storing one or more instructions, The aforementioned one or more instructions are executed by one or more processors, and the device operating in the wireless LAN system is, The first access point (AP) receives a first frame containing the first broadcast target wake time (TWT) parameter set field and the second broadcast TWT parameter set field; Controlled to decode the first frame; The first information and the first broadcast TWT identifier (ID) related to the first restricted TWT (R-TWT) service period (SP) scheduled by the first AP are included in the first broadcast TWT parameter set. The second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set in a computer-readable medium.

Claims

1. A method performed by a station (STA) in a wireless LAN system, The process includes receiving a first frame from a first access point (AP) that includes a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field, The process includes the step of decoding the first frame, The first broadcast TWT parameter set includes first information and a first broadcast TWT identifier (ID) related to a first restricted TWT (R-TWT) service period (SP) scheduled by the first AP, The second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set, in this method.

2. The method according to claim 1, wherein the TXOP (transmission opportunity) of the STA is terminated by the STA before the start of the second R-TWT SP.

3. The broadcast TWT information (info) subfield of the second broadcast TWT parameter set includes the R-TWT schedule information subfield, The method according to claim 1, wherein the R-TWT schedule information subfield includes information indicating that a membership request by the STA related to the second R-TWT SP is not permitted.

4. The broadcast TWT information subfield of the second broadcast TWT parameter set includes the R-TWT schedule information subfield, The method according to claim 1, wherein the R-TWT schedule information subfield includes information indicating that it is associated with the second R-TWT SP scheduled by the second AP corresponding to a nontransmitted BSSID (basic service set identifyr).

5. The method according to claim 1, wherein the value of the broadcast TWT persistence subfield included in the second broadcast parameter set field is set to a predefined minimum value.

6. The first frame includes a first TWT element, The method according to claim 1, wherein the first TWT element is indicated to contain the second information by a null data physical protocol data unit (NDP) paging indicator subfield and a responder PM (power management) subfield included in the control field of the first TWT element.

7. The method according to claim 1, wherein a TWT recommendation field included in the first TWT element of the first frame indicates that the first TWT element contains the second information.

8. The first TWT element includes a plurality of parameter sets, including the first broadcast parameter set and the second broadcast parameter set. The method according to claim 1, wherein the second broadcast parameter set is the last of the plurality of broadcast parameter sets.

9. The method according to claim 1, wherein the second broadcast parameter set includes at least one of the BSS color of the second AP or the channel or bandwidth in which the second R-TWT SP is used.

10. The first frame includes a second TWT element and a third TWT element, The first broadcast parameter set is included in the second TWT element, The method according to claim 1, wherein the second broadcast parameter set is included in the third TWT element.

11. The method according to claim 1, wherein the second R-TWT SP is protected by an overlapping quiet interval set by the first AP.

12. The method according to claim 1, wherein the first frame includes a beacon frame.

13. The method according to claim 1, wherein the STA is associated with the BSS of the first AP.

14. A station (STA) operating in a wireless LAN system, One or more transceivers, The system comprises one or more processors connected to one or more of the aforementioned transceivers, The one or more processors described above are: A first frame is received from a first access point (AP) via one or more transceivers, including a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field; The first frame is configured to decode; The first broadcast TWT parameter set includes first information and a first broadcast TWT identifier (ID) related to a first restricted TWT (R-TWT) service period (SP) scheduled by the first AP, The second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set, STA.

15. A method performed by a first access point (AP) in a wireless LAN system, The second AP receives second information related to the second restricted target wake time (R-TWT) service period (SP), The process includes the step of transmitting a first beacon frame containing first information and second information related to the first R-TWT SP to the first station (STA), The first beacon frame includes a first broadcast TWT parameter set field and a second broadcast TWT parameter set field, The first broadcast TWT parameter set field includes the first information and the first broadcast TWT ID, The method wherein the second broadcast TWT parameter set field includes the second information and the second broadcast TWT ID.

16. A first access point (AP) operating in a wireless LAN system, One or more transceivers, The system comprises one or more processors connected to one or more of the aforementioned transceivers, The one or more processors described above are: The second AP receives, via one or more transceivers, second information relating to a second restricted target wake time (R-TWT) service period (SP); The system is configured to transmit a first beacon frame containing first information and second information related to the first R-TWT SP to the first station (STA) via one or more transceivers. The first beacon frame includes a first broadcast TWT parameter set field and a second broadcast TWT parameter set field, The first broadcast TWT parameter set field includes the first information and the first broadcast TWT ID, The second broadcast TWT parameter set field includes the second information and the second broadcast TWT ID, and is part of the first AP.

17. A processing device configured to control a first station (STA) operating in a wireless LAN system, One or more processors, The system comprises one or more computer memories that are operably connected to one or more processors and store instructions for performing operations based on execution by the one or more processors, The aforementioned operation is, The operation of receiving a first frame from a first access point (AP) that includes a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field, The operation includes decoding the first frame, The first broadcast TWT parameter set includes first information and a first broadcast TWT identifier (ID) related to a first restricted TWT (R-TWT) service period (SP) scheduled by the first AP, A processing device in which the second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set.

18. One or more non-transitory computer-readable media for storing one or more instructions, The aforementioned one or more instructions are executed by one or more processors, and the device operating in the wireless LAN system is, The first access point (AP) receives a first frame containing a first broadcast target wake time (TWT) parameter set field and a second broadcast TWT parameter set field; The first frame is controlled to decode; The first broadcast TWT parameter set includes first information and a first broadcast TWT identifier (ID) related to a first restricted TWT (R-TWT) service period (SP) scheduled by the first AP, The second information and second TWT ID related to the second R-TWT SP scheduled by the second AP are included in the second broadcast TWT parameter set in a computer-readable medium.

Images