Method and apparatus for transmitting or receiving channel access parameters for a coordinated service period between access points in a wireless LAN system

Abstract

A method and apparatus for channel access parameter negotiation for coordinated service period between access points in a wireless LAN system are disclosed. The method according to one embodiment of the disclosure can include the steps of, where a first access point (AP): transmits a first frame including a first set of channel access parameters to a second AP; and receives a second frame from the second AP in response to the first frame. Based on the second frame including information indicating that the first set of channel access parameters is accepted by the second AP, the first set of channel access parameters can be applied for channel access by the first and second APs during a particular service period (SP).

Description

Technical Field

[0001] This disclosure relates to methods and apparatus for transmitting or receiving channel access parameters for coordinating service periods between access points in a wireless local area network (WLAN) system. Background Technology

[0002] New technologies have been introduced for Wireless LANs (WLANs) to improve transmission rates, increase bandwidth, enhance reliability, reduce errors, and decrease latency. Within WLAN technology, the IEEE 802.11 series of standards can be referred to as Wi-Fi. For example, recent technologies introduced into WLAN include the Ultra High Throughput (VHT) enhancement of the 802.11 ac standard and the High Efficiency (HE) enhancement of the IEEE 802.11 ax standard.

[0003] To provide a more advanced wireless communication environment, improved techniques for Extremely High Throughput (EHT) are being discussed. For example, techniques for MIMO and multiple access point (AP) coordination that support increased bandwidth, efficient use of multiple frequency bands, and increased spatial flow are being investigated. Specifically, various techniques are being explored to support low-latency or real-time services. Furthermore, new technologies to support Ultra-High Reliability (UHR), including improvements or extensions to EHT techniques, are being discussed. Summary of the Invention

[0004] Technical issues

[0005] The technical objective of this disclosure is to provide a method and apparatus for transmitting or receiving channel access parameters for coordinating service periods between access points in a wireless local area network (WLAN) system.

[0006] The technical objectives to be achieved by this disclosure are not limited to those described above, and other technical objectives not described herein will be clearly understood by those skilled in the art through the following description.

[0007] Technical solution

[0008] A method according to one aspect of this disclosure may include: sending a first frame from a first access point (AP) to a second AP, the first frame including a first channel access parameter set; and receiving a second frame from the second AP in response to the first frame. Based on information included in the second frame indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set is applied to channel access by the first AP and the second AP during a specific service period (SP).

[0009] The method according to an additional aspect of this disclosure may include: receiving a first frame from a first AP by a second access point (AP), the first frame including a first channel access parameter set; and sending a second frame from the second AP to the first AP in response to the first frame. Based on information included in the second frame indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set is applied to channel access by the first AP and the second AP during a specific service period (SP).

[0010] Beneficial effects

[0011] According to this disclosure, a method and apparatus are provided for transmitting or receiving channel access parameters for coordinating service periods between access points in a wireless local area network (WLAN) system.

[0012] The effects achievable by this disclosure are not limited to those described above, and those skilled in the art can clearly understand other effects not described herein through the following description. Attached Figure Description

[0013] The accompanying drawings, which are included as part of the detailed description of this disclosure, provide embodiments of the disclosure and, together with the detailed description, describe the technical features of the disclosure.

[0014] Figure 1 A configuration block diagram of a wireless communication device according to an embodiment of the present disclosure is illustrated.

[0015] Figure 2 This is a diagram illustrating an exemplary structure of a WLAN system to which this disclosure can be applied.

[0016] Figure 3 This is a diagram used to illustrate the link establishment process that can be applied to this disclosure.

[0017] Figure 4 This is a diagram used to illustrate the backoff processing that can be applied to this disclosure.

[0018] Figure 5 This is a diagram illustrating the CSMA / CA-based frame transmission operation that can be applied to this disclosure.

[0019] Figure 6 This is a diagram illustrating an example of a frame structure that can be used in a WLAN system to which this disclosure may be applied.

[0020] Figure 7 This is a diagram illustrating an example of a PPDU as defined in the IEEE 802.11 standard of this disclosure.

[0021] Figure 8 This is a diagram illustrating various transmitting or receiving technologies that can be applied in a MAP environment according to this disclosure.

[0022] Figure 9 This is a diagram illustrating an example of individual TWT operations that can be applied to this disclosure.

[0023] Figure 10 This is a diagram illustrating an example of the broadcast TWT operation that can be applied to this disclosure.

[0024] Figure 11 This is a diagram illustrating the AP and STA in OBSS that can be applied to this disclosure.

[0025] Figure 12 An example of the configuration of information related to coordinating R-TWT according to this disclosure is shown.

[0026] Figure 13 An example of overlapping R-TWT service periods (SPs) according to this disclosure is illustrated.

[0027] Figure 14 Another example of an overlapping R-TWT SP according to this disclosure is illustrated.

[0028] Figure 15 Another example of overlapping R-TWT SPs according to this disclosure is illustrated.

[0029] Figure 16 Another example of an overlapping R-TWT SP according to this disclosure is illustrated.

[0030] Figure 17 The operation of a coordination request in the negotiation of R-TWT coordination is illustrated according to the configuration of this disclosure.

[0031] Figure 18 An example is illustrated of the operation of a coordination response in a negotiation for coordination of R-TWT according to the configuration of this disclosure.

[0032] Figure 19 This is a diagram illustrating an example of operation of the first AP according to this disclosure.

[0033] Figure 20 This is a diagram illustrating an example of the operation of the second AP according to this disclosure.

[0034] Figure 21 This is a diagram illustrating an example of an AP being executed for a (non)overlapping coordination R-TWT SP in accordance with this disclosure. Detailed Implementation

[0035] In the following, embodiments according to this disclosure will be described in detail with reference to the accompanying drawings. The detailed description disclosed with reference to the drawings is intended to describe exemplary embodiments of this disclosure and not to represent the only embodiments in which this disclosure can be implemented. The following detailed description includes specific details to provide a complete understanding of this disclosure. However, those skilled in the art will recognize that this disclosure can be implemented without these specific details.

[0036] In some cases, known structures and devices may be omitted, or they may be shown in block diagram form based on the core functions of each structure and device in order to prevent ambiguity in the concepts of this disclosure.

[0037] In this disclosure, when an element is referred to as “connected,” “combined,” or “linked” to another element, it can include both indirect and direct connections between the two elements. Furthermore, in this disclosure, the terms “comprising” or “having” specify the presence of the mentioned features, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, stages, operations, components, elements, and / or groups thereof.

[0038] In this disclosure, terms such as "first" and "second" are used only to distinguish one element from another and are not used to limit the elements. Unless otherwise stated, they do not limit the order or importance of the elements. Therefore, within the scope of this disclosure, a first element in one embodiment may be referred to as a second element in another embodiment, and similarly, a second element in one embodiment may be referred to as a first element in another embodiment.

[0039] The terminology used in this disclosure is for the purpose of describing particular embodiments and not for limiting the claims. As used in the description of embodiments and the appended claims, the singular form is intended to include the plural form unless the context clearly indicates otherwise. The term “and / or” as used in this disclosure may refer to one of the associated enumerations, or is intended to refer to and include any and all possible combinations of two or more of them. Furthermore, unless otherwise stated, the “ / ” between words in this disclosure has the same meaning as “and / or”.

[0040] The examples disclosed herein can be applied to various wireless communication systems. For example, the examples disclosed herein can be applied to wireless LAN systems. For example, the examples disclosed herein can be applied to wireless LANs based on the IEEE 802.11a / g / n / ac / ax standards. Furthermore, the examples disclosed herein can be applied to wireless LANs based on the newly proposed IEEE 802.11be (or EHT) standard. The examples disclosed herein can be applied to wireless LANs based on the IEEE 802.11be version 2 standard, corresponding to the additional enhancements of the IEEE 802.11be version 1 standard. Additionally, the examples disclosed herein can be applied to wireless LANs based on next-generation standards following IEEE 802.11be. Furthermore, the examples disclosed herein can be applied to cellular wireless communication systems. For example, it can be applied to cellular wireless communication systems based on 3GPP standards using Long Term Evolution (LTE) technology and 5G New Radio (NR) technology.

[0041] The technical features that can be applied to examples of this disclosure will be described below.

[0042] Figure 1 A block diagram illustrating a wireless communication device according to an embodiment of the present disclosure is shown.

[0043] Figure 1 The first device 100 and the second device 200 illustrated herein can be replaced by various terms such as terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), user terminal (UT), mobile subscriber station (MSS), mobile subscriber unit (MSU), subscriber station (SS), advanced mobile station (AMS), wireless terminal (WT), or simply user. Furthermore, the first device 100 and the second device 200 include access point (AP), base station (BS), fixed station, node B, base transceiver system (BTS), and network. It can be replaced by various terms such as artificial intelligence (AI) system, roadside unit (RSU), repeater, router, relay, and gateway.

[0044] Figure 1 The devices 100 and 200 illustrated herein may be referred to as stations (STAs). For example, Figure 1The devices 100 and 200 illustrated herein may be referred to by various terms such as transmitting device, receiving device, transmitting STA, and receiving STA. For example, STA 110 and 200 may perform an access point (AP) role or a non-AP role. That is, in this disclosure, STA 110 and 200 may perform AP and / or non-AP functions. When STA 110 and 200 perform AP functions, they may simply be referred to as APs, and when STA 110 and 200 perform non-AP functions, they may simply be referred to as STAs. Alternatively, in this disclosure, AP may also be referred to as AP STA.

[0045] Reference Figure 1 The first device 100 and the second device 200 can transmit and receive radio signals via various wireless LAN technologies (e.g., IEEE 802.11 series). The first device 100 and the second device 200 may include interfaces for the Media Access Control (MAC) layer and Physical Layer (PHY) conforming to the IEEE 802.11 standard.

[0046] In addition to wireless LAN technology, the first device 100 and the second device 200 can also support various communication standards (e.g., 3GPP LTE series, 5G NR series standards, etc.). Furthermore, the devices disclosed herein can be implemented in various devices such as mobile phones, vehicles, personal computers, augmented reality (AR) devices, and virtual reality (VR) devices. Additionally, 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 IoT (Internet of Things).

[0047] The first device 100 may include one or more processors 102 and one or more memories 104, and may additionally include one or more transceivers 106 and / or one or more antennas 108. The processors 102 may control the memories 104 and / or the transceivers 106, and may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure. For example, the processor 102 may transmit a wireless signal including the first information / signal via the transceivers 106 after generating first information / signal by processing information in the memories 104. Additionally, the processor 102 may receive a wireless signal including second information / signal via the transceivers 106, and then store information obtained through signal processing of the second information / signal in the memories 104. The memories 104 may be connected to the processor 102 and may store various information related to the operation of the processor 102. For example, the memories 104 may store software code including instructions for performing all or part of the processing controlled by the processor 102 or for performing the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure. Here, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement wireless LAN technology (e.g., IEEE 802.11 series). Transceiver 106 may be connected to processor 102 and may transmit and / or receive wireless signals via one or more antennas 108. Transceiver 106 may include a transmitter and / or a receiver. Transceiver 106 may be used with an RF (radio frequency) unit. In this disclosure, wireless device may refer to a communication modem / circuit / chip.

[0048] The second device 200 may include one or more processors 202 and one or more memories 204, and may additionally include one or more transceivers 206 and / or one or more antennas 208. The processors 202 may control the memories 204 and / or the transceivers 206, and may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure. For example, the processors 202 may generate third information / signals by processing information in the memories 204, and then transmit a wireless signal including the third information / signals via the transceivers 206. Additionally, the processors 202 may receive wireless signals including fourth information / signals via the transceivers 206, and then store information obtained through signal processing of the fourth information / signals in the memories 204. The memories 204 may be connected to the processors 202 and may store various information related to the operation of the processors 202. For example, the memories 204 may store software code including instructions for performing all or part of the processing controlled by the processors 202 or for performing the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure. Here, processor 202 and memory 204 may be part of a communication modem / circuit / chip designed to implement wireless LAN technology (e.g., IEEE 802.11 series). Transceiver 206 may be connected to processor 202 and may transmit and / or receive wireless signals via one or more antennas 208. Transceiver 206 may include a transmitter and / or a receiver. Transceiver 206 may be used with an RF unit. In this disclosure, apparatus may refer to a communication modem / circuit / chip.

[0049] The hardware elements of devices 100 and 200 will be described in more detail below. Not limited thereto, one or more protocol layers may be implemented by one or more processors 102 and 202. For example, one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as PHY and MAC). One or more processors 102 and 202 may generate one or more PDUs (Protocol Data Units) and / or one or more SDUs (Service Data Units) according to the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the functions, processes, suggestions, and / or methods disclosed in this disclosure to provide them to one or more transceivers 106 and 206. One or more processors 102, 202 may receive signals (e.g., baseband signals) from one or more transceivers 106, 206 and obtain PDUs, SDUs, messages, control information, data or information, in accordance with the description, functions, processes, suggestions, methods and / or operation flowcharts included in this disclosure.

[0050] One or more processors 102, 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102, 202 may be implemented 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, processes, suggestions, methods, and / or operation flowcharts included in this disclosure may be implemented using firmware or software, and the firmware or software may be implemented to include modules, processes, functions, etc. Firmware or software configured to execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure may be included in one or more processors 102, 202, or may be stored in one or more memories 104, 204 and driven by one or more processors 102, 202. The descriptions, functions, processes, suggestions, methods and / or operation flowcharts included in this disclosure may be implemented using firmware or software in the form of code, instructions and / or instruction sets.

[0051] One or more memories 104, 204 may be connected to one or more processors 102, 202 and may store data, signals, messages, information, programs, code, instructions, and / or commands in various forms. One or more memories 104, 204 may be configured with ROM, RAM, EPROM, flash memory, hard disk drive, registers, cache memory, computer-readable storage media, and / or combinations thereof. One or more memories 104, 204 may be located internally and / or externally to one or more processors 102, 202. Furthermore, one or more memories 104, 204 may be connected to one or more processors 102, 202 via various technologies such as wired or wireless connections.

[0052] One or more transceivers 106, 206 can transmit user data, control information, wireless signals / channels, etc., mentioned in the methods and / or operation flowcharts of this disclosure to one or more other devices. One or more transceivers 106, 206 can receive user data, control information, wireless signals / channels, etc., mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure from one or more other devices. For example, one or more transceivers 106, 206 can be connected to one or more processors 102, 202 and can transmit and receive wireless signals. For example, one or more processors 102, 202 can control one or more transceivers 106, 206 to transmit user data, control information, or wireless signals to one or more other devices. Additionally, one or more processors 102, 202 can control one or more transceivers 106, 206 to receive user data, control information, or wireless signals from one or more other devices. Additionally, 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, wireless signals / channels, etc., mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included 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 received wireless signals / channels, etc., from RF band signals into baseband signals for processing using one or more processors 102, 202. One or more transceivers 106, 206 may convert user data, control information, wireless signals / channels, etc., processed using one or more processors 102, 202, from baseband signals into RF band signals. Therefore, one or more transceivers 106, 206 may include (analog) oscillators and / or filters.

[0053] For example, one of STAs 100 and 200 can perform the expected operation of an AP, and the other of STAs 100 and 200 can perform the expected operation of a non-AP STA. For example, Figure 1 Transceivers 106 and 206 can perform transmission and reception operations of signals (e.g., packet or physical layer protocol data units (PPDUs) conforming to IEEE 802.11a / b / g / n / ac / ax / be / bn). Additionally, in this disclosure, the various STAs can generate transmit / receive signals or perform data processing or calculations on the transmit / receive signals in advance by [the relevant entity / component]. Figure 1Processors 102 and 202 perform the following operations: For example, examples of generating transmit / receive signals or performing data processing or computations on transmit / receive signals in advance may include: 1) determining / acquiring / configuring / computing / decoding / encoding bit information of fields (signals (SIG), short training field (STF), long training field (LTF), data, etc.) included in the PPDU; 2) determining / configuring / acquiring time or frequency resources (e.g., subcarrier resources) for the fields (SIG, STF, LTF, data, etc.) included in the PPDU; 3) determining / configuring / acquiring specific sequences (e.g., pilot sequences, STF / LTF sequences, additional sequences applied to SIG) for the fields (SIG, STF, LTF, data, etc.) included in the PPDU action; 4) power control operations and / or power saving operations applied to the STA; 5) operations related to determining / acquiring / configuring / computing / decoding / encoding of the ACK signal. Additionally, in the example below, various information used by different STAs to determine / acquire / configure / calculate / decode / encode transmitted and received signals (e.g., information related to fields / subfields / control fields / parameters / power, etc.) can be stored. Figure 1 In memory 104 and 204.

[0054] In the following text, downlink (DL) can refer to a link used for communication from an AP STA to a non-AP STA, and DL PPDU / packets / signals can be sent and received via DL. In DL communication, the transmitter can be part of an AP STA, and the receiver can be part of a non-AP STA. Uplink (UL) can refer to a link used for communication from a non-AP STA to an AP STA, and UL PPDU / packets / signals can be sent and received via UL. In UL communication, the transmitter can be part of a non-AP STA, and the receiver can be part of an AP STA.

[0055] Figure 2 This is a diagram illustrating an exemplary structure of a wireless LAN system to which this disclosure can be applied.

[0056] A wireless LAN system can be structured by multiple components. These components interact to provide STA mobility support that is transparent to upper layers. The Basic Service Set (BSS) corresponds to the basic building blocks of a wireless LAN. Figure 2 An example is shown where there are two BSSs (BSS1 and BSS2), and two STAs included as members of each BSS (STA1 and STA2 are included in BSS1, and STA3 and STA4 are included in BSS2). Figure 2The ellipse representing the BSS can also be interpreted as representing the coverage area within the corresponding BSS where STAs maintain communication. This area can be called the Basic Service Area (BSA). When a STA moves outside the BSA, it cannot communicate directly with other STAs within the BSA.

[0057] If we do not consider Figure 2 The DS shown in the diagram represents the most basic BSS type in a wireless LAN: the Independent BSS (IBSS). For example, an IBSS can have a minimal form containing only two STAs. For instance, assuming other components are omitted, BSS1 containing only STA1 and STA2, or BSS2 containing only STA3 and STA4, can respectively correspond to representative examples of IBSS. This configuration is possible when STAs can communicate directly without an AP. Furthermore, in this type of wireless LAN, it is not pre-configured but can be configured as needed, and this can be called an ad-hoc network. Since an IBSS does not include an AP, there is no centralized management entity. That is, in an IBSS, STAs are managed in a distributed manner. In an IBSS, all STAs can consist of mobile STAs and are not allowed to access the Distributed System (DS), thus forming a self-contained network.

[0058] Membership of an STA in a BSS can be dynamically changed by opening or closing an STA, or by entering or leaving a BSS zone. To become a member of a BSS, an STA can join the BSS using a synchronization process. To access all services of the BSS infrastructure, an STA must be associated with the BSS. This association can be dynamically established and may include the use of Distributed System Services (DSS).

[0059] Direct STA-to-STA distance in a wireless LAN may be limited by PHY performance. In some cases, this distance limitation may be sufficient, but in others, longer distances between STAs may be required for communication. Distributed systems (DS) can be configured to support extended coverage.

[0060] DS refers to the structure of BSS interconnection. Specifically, such as... Figure 2As shown, a BSS can exist as an extension of a network composed of multiple BSSs. A DS is a logical concept and can be specified through the characteristics of the Distributed System Medium (DSM). At this point, the Wireless Medium (WM) and the DSM can be logically separated. Each logical medium is used for a different purpose and by different components. These media are not limited to being the same, nor are they limited to being different. In this way, the flexibility of a wireless LAN architecture (DS architecture or other network architectures) can be interpreted as multiple media being logically different. That is, a wireless LAN architecture can be implemented in various ways, and the corresponding wireless LAN architecture can be independently specified by the physical characteristics of each implementation.

[0061] The DS can support mobile devices by providing seamless integration of multiple BSSs and offering the logical services necessary for addressing to the destination. Additionally, the DS may include a component called a portal, which acts as a bridge between the wireless LAN and other networks, such as IEEE 802.X.

[0062] AP enables access to DS via WM for associated non-AP STAs, and refers to entities that also have STA functionality. Data movement between BSS and DS can be performed through AP. For example, Figure 2 STA2 and STA3, shown in the diagram, have the functionality of STAs and provide the ability for associated non-AP STAs (STA1 and STA4) to access the DS. Furthermore, since all APs essentially correspond to STAs, all APs are addressable entities. The address used by an AP for communication on the WM is not necessarily the same as the address used by the AP for communication on the DSM. A BSS consisting of APs and one or more STAs can be referred to as an infrastructure BSS.

[0063] Data sent from one of the STAs associated with the AP to the corresponding STA address of the AP can always be received on an uncontrolled port and can be processed by the IEEE 802.1X port access entity. Alternatively, when the controlled port is authenticated, the transmitted data (or frames) can be delivered to the DS.

[0064] In addition to the DS structure described above, Extended Service Sets (ESS) can also be configured to provide wide coverage.

[0065] An ESS (Service Set Identity) refers to a network of arbitrary size and complexity consisting of DS (Service Controller) and BSS (Service Set Service). An ESS can correspond to a set of BSSs connected to a DS. However, an ESS does not include the DS. An ESS network is characterized as an IBSS (Integrated Service Set Service) within the Logical Link Control (LLC) layer. STAs included in an ESS can communicate with each other, and a moving STA can transparently move from one BSS to another (within the same ESS) to the LLC. APs included in an ESS can have the same Service Set Identity (SSID). The SSID is distinguished from the BSSID, which serves as the identifier for the BSS.

[0066] Wireless LAN systems make no assumptions about the relative physical locations of BSSs, and all of the following forms are possible. BSSs can partially overlap, a form commonly used to provide continuous coverage. Additionally, BSSs may not be physically connected, and logically, there is no limit to the distance between BSSs. Furthermore, BSSs can be physically located in the same location, which can be used to provide redundancy. Additionally, one (or more) IBSS or ESS networks can physically exist in the same space as one (or more) ESS networks. This can correspond to the form of ESS networks when an ad hoc network operates in a 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 in the same location, etc.

[0067] Figure 3 This is a diagram illustrating the link establishment process that can be applied to this disclosure.

[0068] In order for a STA to establish a link with the network and send / receive data, it first discovers the network, performs authentication, establishes an association, and performs authentication processing for security. The link establishment process can also be called session initiation processing or session establishment processing. Furthermore, the discovery, authentication, association, and security establishment processes of the link establishment process can be collectively referred to as association processing.

[0069] In step S310, the STA can perform a network discovery operation. The network discovery operation may include a scanning operation by the STA. That is, in order for the STA to access a network, it needs to find networks it can participate in. The STA should identify compatible networks before participating in a wireless network, and the process of identifying networks existing in a specific area is called scanning.

[0070] Scanning schemes include active scanning and passive scanning. Figure 3An exemplary network discovery operation including active scanning processing is illustrated. In active scanning, the STA performing the scan sends a probe request frame to discover which APs are present around it as the channel moves and awaits a response. The responder sends a probe response frame as a response to the probe request 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 the BSS, the AP becomes the responder because it sends a beacon frame, and in the IBSS, the STAs in the IBSS rotate to send beacon frames, so the responder is not constant. For example, an STA that sends a probe request frame on channel 1 and receives a probe response frame on channel 1 may store the BSS-related information included in the received probe response frame and may move to the next channel (e.g., channel 2) and perform a scan in the same manner (i.e., sending and receiving probe requests / responses on channel 2).

[0071] Although not in Figure 3 As shown, scanning can be performed passively. In passive scanning, the STA performing the scan waits for beacon frames while moving through the channel. Beacon frames are one of the management frames defined in IEEE 802.11 and are sent periodically to notify of the existence of a wireless network and allow the STA performing the scan to find and participate in the wireless network. In the BSS, the AP periodically sends beacon frames, and in the IBSS, the STA within the IBSS rotates to send beacon frames. When the STA performing the scan receives a beacon frame, it stores the BSS information included in the beacon frame and records the beacon frame information for each channel while moving to another channel. The STA receiving the beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning in the next channel in the same manner. Comparing active and passive scanning, active scanning has the advantages of less latency and less power consumption.

[0072] After the STA discovers the network, an authentication process can be performed in step S320. To clearly distinguish it from the security establishment operation in step S340, which will be described later, this authentication process can be referred to as the first authentication process.

[0073] The authentication process includes the following steps: the STA sends an authentication request frame to the AP, and in response, the AP sends an authentication response frame to the STA. The authentication frame used for the authentication request / response corresponds to the management frame.

[0074] An authentication frame includes the authentication algorithm number, authentication transaction sequence number, status code, challenge text, robust security network (RSN), and finite circular group. These correspond to some examples of information that can be included in the authentication request / response frame and can be replaced with other information, or additional information may be included.

[0075] A STA can send an authentication request frame to an AP. The AP can determine whether to allow the corresponding STA's authentication based on the information included in the received authentication request frame. The AP can then provide the STA with the authentication processing result via an authentication response frame.

[0076] After the STA is successfully authenticated, the association process can be performed in step S330. The association process includes the following steps: the STA sends an association request frame to the AP, and in response, the AP sends an association response frame to the STA.

[0077] For example, an association request frame may include information related to various capabilities, beacon listening intervals, service set identifiers (SSIDs), supported rates, supported channels, RSNs, mobile domains, supported operation classes, service indication mapping broadcast requests (TIM broadcast requests), interoperability capabilities, etc. Similarly, an association response frame may include information related to various capabilities, status codes, association IDs (AIDs), supported rates, enhanced distributed channel access (EDCA) parameter sets, received channel power indicators (RCPIs), received signal-to-noise ratio indicators (RSNIs), mobile domains, timeout intervals (e.g., association recovery time), overlapping BSS scan parameters, TIM broadcast responses, quality of service (QoS) mappings, etc. These correspond to some examples of information that can be included in association request / response frames and may be replaced with other information, or additional information may be included.

[0078] After the STA successfully associates with the network, a security establishment process can be performed in step S340. The security establishment process in step S340 can be referred to as the authentication process via a Robust Secure Network Association (RSNA) request / response, the authentication process in step S320 is referred to as the first authentication process, and the security establishment process in step S340 can also be simply referred to as the authentication process.

[0079] The secure establishment process in step S340 may include, for example, the process of establishing a private key using a four-way handshake via Extensible Authentication Protocol (EAPOL) frames over the LAN. Alternatively, the secure establishment process may be performed according to a security scheme not defined in the IEEE 802.11 standard.

[0080] Figure 4 This is a diagram illustrating the fallback process that can be applied to this disclosure.

[0081] In wireless LAN systems, the basic access mechanism for Media Access Control (MAC) is Carrier Sensing Multiple Access with Collision Avoidance (CSMA / CA). Also known as the Distributed Coordination Function (DCF) of IEEE 802.11 MAC, CSMA / CA essentially employs a "listen-before-talk" access mechanism. Under this type of access mechanism, before commencing transmission, the AP and / or STA can perform explicit channel assessment (CCA) of the sensing radio channel or medium during a predetermined time interval (e.g., the DCF inter-frame interval (DIFS)). As a result of the sensing, if it is determined that the medium is idle, frame transmission begins via the corresponding medium. Conversely, if the medium is detected to be occupied or busy, the corresponding AP and / or STA does not begin its own transmission and can set a delay period for medium access (e.g., a random backoff period) and attempt frame transmission after waiting. By applying a random backoff period, collisions can be minimized because multiple STAs are expected to attempt frame transmission after waiting for different time periods.

[0082] In addition, the IEEE 802.11 MAC protocol provides a Hybrid Coordination Function (HCF). HCF is based on DCF and Point Coordination Function (PCF). PCF is a polling-based synchronous access method, meaning that all receiving APs and / or STAs periodically poll to receive data frames. Furthermore, HCF includes Enhanced Distributed Channel Access (EDCA) and HCF Control Channel Access (HCCA). EDCA is a contention-based access method that provides data frames to multiple users, while HCCA uses a non-contention-based channel access method that utilizes a polling mechanism. Additionally, HCF includes a media access mechanism for improving the QoS (Quality of Service) of wireless LANs and can transmit QoS data during contention periods (CP) and contention-free periods (CFP).

[0083] Reference Figure 4This section describes the operation based on a random backoff period. When an occupied / busy medium becomes idle, multiple STAs can attempt to transmit data (or frames). As a method to minimize collisions, each STA can individually select a random backoff count and attempt to transmit after waiting for the corresponding time slot. The random backoff count has a pseudo-random integer value and can be determined as one of the values ​​ranging from 0 to CW. Here, CW is the contention window parameter value. The CW parameter is assigned an initial value of CWmin, but can take a value twice as large as in the event of transmission failure (e.g., when no ACK is received for the transmitted frame). When the CW parameter value reaches CWmax, data transmission can be attempted while maintaining the CWmax value until successful data transmission, and when successful, the CWmin value is reset. The values ​​of CW, CWmin, and CWmax are preferably set to 2n-1 (n=0, 1, 2, ...).

[0084] When random backoff processing begins, the STA continuously monitors the medium during the backoff time slot countdown based on the determined backoff count value. When monitoring the medium for occupancy, it stops the countdown and waits, and restarts the remainder of the countdown when the medium becomes idle.

[0085] exist Figure 4 In the example, when the packet to be sent arrives at STA 3's MAC, STA 3 can send the frame immediately after confirming that the medium has been idle for up to DIFS. The remaining STAs monitor and wait for the medium to be occupied / busy. Meanwhile, the data to be sent can also occur in each of STA 1, STA 2, and STA 5, and when the medium is detected as idle, each STA waits for up to DIFS, and then performs a countdown for the backoff slot based on a random backoff count value chosen by each STA. Assume STA 2 chooses the minimum backoff count value, and STA 1 chooses the maximum backoff count value. That is, the example illustrates the case where STA 5's remaining backoff time is shorter than STA 1's remaining backoff time when STA 2 completes its backoff count and begins frame transmission. STA 1 and STA 5 temporarily stop the countdown and wait while STA 2 occupies the medium. When STA 2's occupancy ends and the medium becomes idle again, STA 1 and STA 5 wait for DIFS and restart the stopped backoff count. In other words, frame transmission can begin after a countdown for the remaining backoff slot based on the remaining backoff time. Since STA5 has a shorter remaining backoff time than STA1, STA5 begins frame transmission. Data to be transmitted can also occur in STA4 while STA2 is occupying the medium. From STA4's perspective, when the medium becomes idle, STA4 can wait for DIFS, then execute a countdown based on a random backoff count value selected by STA4, and begin transmitting frames. Figure 4The example illustrates a scenario where the remaining backoff time of STA5 accidentally conflicts with the random backoff count value of STA4. In this case, a collision may occur between STA4 and STA5. When a collision occurs, neither STA4 nor STA5 receives an ACK, so data transmission fails. In this situation, STA4 and STA5 can double the CW value, select a random backoff count value, and begin a countdown. While the medium is occupied due to the transmissions of STA4 and STA5, STA1 waits; when the medium becomes idle, STA1 waits for DIFS, and then begins frame transmission after the remaining backoff time has elapsed.

[0086] As in Figure 4 In the example, data frames are frames used to send data forwarded to higher layers and can be sent after a backoff performed after DIFS, starting from when the medium becomes idle. Additionally, management frames are frames used to exchange management information that has not been forwarded to higher layers and are sent after a backoff performed after an IFS such as DIFS or Point Coordination Function IFS (PIFS). Subtypes of management frames include beacons, association requests / responses, reassociation requests / responses, probe requests / responses, authentication requests / responses, etc. Control frames are frames used to control access to the medium. Subtypes of control frames include request-to-transmit (RTS), clear-to-transmit (CTS), acknowledgment (ACK), power-saving polling (PS-Poll), block ACK (BlockAck), block ACK request (BlockACKReq), empty data packet announcement (NDP announcement), and triggering, etc. If a control frame is not a response frame to the previous frame, it is sent after a backoff performed after DIFS; if it is a response frame to the previous frame, it is sent without a backoff performed after short IFS (SIFS). The type and subtype of a frame can be identified by the type field and subtype field in the Frame Control (FC) field.

[0087] The Quality of Service (QoS) ST can perform a backoff following the Arbitration IFS (AIFS) for the Access Class (AC) to which the frame belongs (i.e., AIFS where i is a value determined by the AC) before the frame can be transmitted. Here, the frame that can use AIFS can be a data frame, management frame, or control frame, rather than a response frame.

[0088] Figure 5 This is a diagram illustrating the CSMA / CA-based frame transmission operation that can be applied to this disclosure.

[0089] As mentioned above, in addition to physical carrier sensing of the medium directly sensed by the STA, the CSMA / CA mechanism also includes virtual carrier sensing. Virtual carrier sensing aims to compensate for problems such as hidden node issues that may occur during medium access. For virtual carrier sensing, the STA's MAC can use the Network Allocation Vector (NAV). The NAV is a value that indicates to other STAs the remaining time until the medium is available for current use or for STAs authorized to use the medium. Therefore, a value set to NAV corresponds to the period during which the STA sending the frame plans to use the medium, and during the corresponding period, STAs receiving the NAV value are prohibited from accessing the medium. For example, the NAV can be configured based on the value of the "Duration" field in the frame's MAC header.

[0090] exist Figure 5 In the example, it is assumed that STA1 intends to send data to STA2, and STA3 is in a position that allows it to eavesdrop on some or all of the frames sent and received between STA1 and STA2.

[0091] To reduce the likelihood of transmission conflicts among multiple STAs in CSMA / CA-based frame transmission operations, a mechanism using RTS / CTS frames can be applied. Figure 5 In the example, when STA1 is transmitting, as a result of carrier sensing by STA3, it can be determined that the medium is in an idle state. That is, STA1 can correspond to a hidden node with respect to STA3. Alternatively, in Figure 5 In the example, it can be determined that while STA2 is transmitting, the carrier sensing result medium of STA3 is in an idle state. That is, STA2 can correspond to a hidden node with respect to STA3. By exchanging RTS / CTS frames before performing data transmission and reception between STA1 and STA2, STAs outside the transmission range of either STA1 or STA2, or STAs outside the carrier sensing range of transmissions from STA1 or STA3, can avoid attempting to occupy the channel during data transmission and reception between STA1 and STA2.

[0092] Specifically, STA1 can determine whether a channel is in use through carrier sensing. Regarding physical carrier sensing, STA1 can determine the channel occupancy / idle status based on the energy level or signal correlation detected in the channel. Alternatively, regarding virtual carrier sensing, STA1 can use a Network Allocation Vector (NAV) timer to determine the channel occupancy status.

[0093] When the channel is idle during DIFS, STA1 can send an RTS frame to STA2 after performing backoff. When STA2 receives the RTS frame, STA2 can send a CTS frame to STA1 after SIFS as a response to the RTS frame.

[0094] If STA3 cannot eavesdrop on CTS frames from STA2 but can eavesdrop on RTS frames from STA1, STA3 can use the duration information included in the RTS frame to set the NAV timer for the subsequent consecutive frame transmission period (e.g., SIFS+CTS frame+SIFS+data frame+SIFS+ACK frame). Alternatively, if STA3 can eavesdrop on CTS frames from STA2, STA3 can also use the duration information included in the CTS frame to set the NAV timer for the subsequent consecutive frame transmission period (e.g., SIFS+data frame+SIFS+ACK frame) even though STA3 cannot eavesdrop on RTS frames from STA1. That is, if STA3 can eavesdrop on one or more RTS frames or CTS frames from STA1 or STA2, STA3 can set the NAV accordingly. When STA3 receives a new frame before the NAV timer expires, STA3 can update the NAV timer using the duration information included in the new frame. STA3 does not attempt channel access until the NAV timer expires.

[0095] When STA1 receives a CTS frame from STA2, STA1 can send a data frame to STA2 after SIFS, starting from the time point when the CTS frame reception is complete. When STA2 successfully receives the data frame, STA2 can send an ACK frame to STA1 after SIFS as a response to the data frame. When the NAV timer expires, STA3 can determine whether the channel is in use through carrier sensing. If STA3 determines that the channel is not in use by other terminals during DIFS after the NAV timer expires, STA3 can attempt channel access after the contention window (CW) for random backoff has passed.

[0096] Figure 6 This is a diagram illustrating an example of a frame structure that can be used in a WLAN system to which this disclosure may be applied.

[0097] Using instructions or primitives (meaning a set of instructions or parameters) from the MAC layer, the PHY layer can prepare the MAC PDU (MPDU) to be transmitted. For example, when the PHY layer receives a command from the MAC layer requesting the start of transmission, it switches to transmit mode, configures the information (e.g., data) provided by the MAC layer in the form of a frame, and transmits it. Additionally, when the PHY layer detects a valid preamble in a received frame, it monitors the preamble header and sends a command to the MAC layer notifying the PHY layer of the start of reception.

[0098] In this way, information transmission / reception in a wireless LAN system is performed in the form of frames, and for this purpose, the PHY layer Protocol Data Unit (PPDU) format is defined.

[0099] A basic PPDU can include a Short Training Field (STF), a Long Training Field (LTF), a Signal (SIG) field, and a Data field. The most basic PPDU format (e.g., Figure 7 The non-HT (High Throughput) fields shown can consist solely of a Traditional-STF (L-STF), Traditional-LTF (L-LTF), Traditional-SIG (L-SIG) field, and a data field. Additionally, depending on the PPDU format type (e.g., HT mixed format PPDU, HT green format PPDU, VHT (Very High Throughput) PPDU, etc.), additional (or different types) RL-SIG, U-SIG, non-traditional SIG fields, non-traditional STF, non-traditional LTF (i.e., xx-SIG, xx-STF, xx-LTF (e.g., xx is HT, VHT, HE, EHT, etc.)) can be included between the L-SIG field and the data field.

[0100] STF is a signal used for signal detection, automatic gain control (AGC), diversity selection, precise time synchronization, etc., while LTF is a signal used for channel estimation and frequency error estimation. STF and LTF can be referred to as signals used for synchronization and channel estimation in the OFDM physical layer.

[0101] The SIG field can include various information related to PPDU transmission and reception. For example, the L-SIG field consists of 24 bits and can 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 can include information about the modulation and coding rate of the data. For example, the 12-bit length field can include information about the length or duration of the PPDU. For example, the value of the 12-bit length field can be determined based on the type of PPDU. For example, for non-HT, HT, VHT, or EHT PPDUs, the value of the length field can be determined to be a multiple of 3. For example, for HEPPDUs, the value of the length field can be determined to be a multiple of 3+1 or 3+2.

[0102] The data field may include a service field, a physical layer service data unit (PSDU), and a PPDU tail bit, and may also include padding bits if necessary. Some bits of the service field can be used for synchronization of the descrambler at the receiver. The PSDU corresponds to the MAC PDU defined in the MAC layer and may include data generated / used in the upper layer. The PPDU tail bit can be used to return the encoder to a 0 state. Padding bits can be used to adjust the length of the data field by predetermined units.

[0103] MAC PDUs are defined according to various MAC frame formats, and a basic MAC frame consists of a MAC header, a frame body, and a Frame Check Sequence (FCS). MAC frames can be composed of MAC PDUs and transmitted / received via PSDUs in the data portion of the PPDU format.

[0104] The MAC header includes a frame control field, a duration / ID field, and an address field. The frame control field can include control information required for frame transmission / reception. The duration / ID field can be set to the time used to transmit the corresponding frame, etc. For details on the sequence control, QoS control, and HT control subfields of the MAC header, refer to the IEEE 802.11 standard document.

[0105] The Narrow Data PPDU (NDP) format refers to a PPDU format that does not include the data field. In other words, NDP is a frame format that includes the PPDU preamble of the general PPDU format (i.e., the L-STF, L-LTF, L-SIG fields and other non-traditional SIG, non-traditional STF, and non-traditional LTF (if present)) and does not include the remaining part (i.e., the data field).

[0106] Figure 7 This is a diagram illustrating an example of a PPDU as defined in the IEEE 802.11 standard of this disclosure.

[0107] Various types of PPDUs have been used in standards such as IEEE 802.11a / g / n / ac / ax. The basic PPDU format (IEEE 802.11a / g) includes L-LTF, L-STF, L-SIG, and a data field. The basic PPDU format can also be referred to as a non-HT PPDU format (such as...). Figure 7 (as shown in (a)).

[0108] Compared to the basic PPDU format, the HT PPDU format (IEEE 802.11n) additionally includes the HT-SIG, HT-STF, and HT-LFT fields. Figure 7The HT PPDU format shown in (b) can be referred to as the HT hybrid format. Furthermore, an HT green format PPDU can be defined, and this corresponds to a format consisting of HT-GF-STF, HT-LTF1, HT-SIG, one or more HT-LTFs and data fields, excluding L-STF, L-LTF, and L-SIG (not shown).

[0109] Compared to the basic PPDU format, examples of the VHT PPDU format (IEEE 802.11ac) additionally include VHTSIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields (such as...). Figure 7 (as shown in (c)).

[0110] Compared to the basic PPDU format, examples of the HE PPDU format (IEEE 802.11ax) additionally include repeated L-SIG (RL-SIG), HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, and Packet Extension (PE) fields (such as...). Figure 7 (as shown in (d)). Some fields can be excluded, or their lengths can vary depending on the detailed examples of the HE PPDU format. For example, the HE-SIG-B field is included in the HE PPDU format for multi-user (MU), but not in the HE PPDU format for single-user (SU). Furthermore, the HE-Trigger-Based (TB) PPDU format does not include HE-SIG-B, and the length of the HE-STF field can vary up to 8 μs. The Extended Range (HE ER) SU PPDU format does not include the HE-SIG-B field, and the length of the HE-SIG-A field can vary up to 16 μs. For example, RL-SIG can be configured to be the same as L-SIG. Based on the presence of RL-SIG, the receiving STA can determine whether the received PPDU is an HE PPDU or an EHT PPDU, which will be described later.

[0111] EHT PPDU format can include Figure 7 EHT MU (Multi-user) in (e) and Figure 7 The EHT TB (trigger-based) PPDU in (f). The EHT PPDU format is similar to the HE PPDU format in that it includes RL-SIG following L-SIG, but it can include U (generic)-SIG, EHT-SIG, EHT-STF and EHT-LTF following RL-SIG.

[0112] Figure 7In (e), the EHT MU PPDU corresponds to a PPDU carrying one or more data (or PSDU) for one or more users. That is, the EHT MU PPDU can be used for both SU and MU transmissions. For example, the EHT MU PPDU can correspond to a PPDU for one or more receiving STAs.

[0113] Compared to EHT MU PPDU, Figure 7 In (f), the EHT-SIG is omitted from the EHT TB PPDU. The STA that receives the trigger for UL MU transmission (e.g., trigger frame or trigger response schedule (TRS)) can perform UL transmission based on the EHT TB PPDU format.

[0114] The L-STF, L-LTF, L-SIG, RL-SIG, U-SIG (general signal), and EHT-SIG fields can be encoded and modulated so that even conventional STAs can attempt demodulation and decoding, and can be mapped based on a determined subcarrier frequency interval (e.g., 312.5 kHz). These can be referred to as pre-EHT modulated fields. Next, the EHT-STF, EHT-LTF, data, and PE fields can be encoded and modulated to be demodulated and decoded by an STA that has successfully decoded a non-conventional SIG (e.g., U-SIG and / or EHT-SIG) and obtained the information contained in that field, and can be mapped based on a determined subcarrier frequency interval (e.g., 78.125 kHz). These can be referred to as EHT modulated fields.

[0115] 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 modulation fields, and the HE-STF, HE-LTF, data, and PE fields can be referred to as HE modulation fields. Additionally, in the VHT PPDU format, the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields can be referred to as non-VHT modulation fields, and the VHT STF, VHT-LTF, VHT-SIG-B, and data fields can be referred to as VHT modulation fields.

[0116] Included Figure 7In the EHT PPDU format, U-SIG can be configured based on, for example, two symbols (e.g., two consecutive OFDM symbols). Each symbol used for U-SIG (e.g., an OFDM symbol) can have a duration of 4 μs, and U-SIG can have a total duration of 8 μs. Each symbol of U-SIG can be used to transmit 26 bits of information. For example, each symbol of U-SIG can be transmitted and received based on 52 data tones and 4 pilot tones.

[0117] U-SIGs can be constructed in 20 MHz units. For example, if an 80 MHz PPDU is constructed, U-SIGs can be replicated. That is, the same four U-SIGs can be included in an 80 MHz PPDU. PPDUs with bandwidths exceeding 80 MHz can include different U-SIGs.

[0118] For example, A uncoded bits can be sent via U-SIG. The first symbol of U-SIG (e.g., U-SIG-1 symbol) can send the first X bits of the total A bits, and the second symbol of U-SIG (e.g., U-SIG-2 symbol) can send the remaining Y bits of the total A bits. The A bits (e.g., 52 uncoded bits) can include a CRC field (e.g., a 4-bit field) and a tail field (e.g., a 6-bit field). For example, the tail field can be used to terminate the lattice structure of the convolutional decoder and can be set to 0.

[0119] Bit information sent via U-SIG can be divided into version-independent bits and version-dependent bits. For example, U-SIG can be included in... Figure 7 The new PPDU format (e.g., UHR PPDU format) not shown in the figure, and can be included in the format of the U-SIG field included in the EHT PPDU format and the format of the U-SIG field included in the UHR PPDU format, the version-independent bits can be the same, and some or all of the version-related bits can be different.

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

[0121] For example, the version-independent bits of U-SIG may include a 3-bit Physical Layer Version Identifier (PHY Version Identifier), which can indicate the PHY version (e.g., EHT, UHR, etc.) of the transmitted / received PPDU. The version-independent bits of U-SIG may include a 1-bit UL / DL Flag field. The first value of the 1-bit UL / DL Flag field is related to UL communication, and the second value is related to DL communication. The version-independent bits of U-SIG may include information about the length of the Transmission Opportunity (TXOP) and information about the BSS color ID.

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

[0123] Information required for PPDU transmission and reception can be included in the U-SIG. For example, the U-SIG may also include information about bandwidth, information about the MCS technique applied to non-traditional SIGs (e.g., EHT-SIG or UHR-SIG), information indicating whether DCM (dual-carrier modulation) techniques (e.g., techniques used to achieve effects similar to frequency diversity by reusing the same signal on two subcarriers) are applied to non-traditional SIGs, information about the number of symbols used for non-traditional SIGs, and information about whether non-traditional SIGs are generated across the entire frequency band.

[0124] Some of the information required for PPDU transmission and reception may be included in U-SIG and / or non-traditional SIG (e.g., EHT-SIG or UHR-SIG). For example, information about the type of non-traditional LTF / STF (e.g., EHT-LTF / EHT-STF or UHR-LTF / UHR-STF), the length of the non-traditional LTF and the CP (cyclic prefix) length, the GI (guard interval) applicable to the non-traditional LTF, the preamble punching information applicable to the PPDU, and the resource unit (RU) allocation may be included only in U-SIG, only in non-traditional SIG, or may be indicated by a combination of information included in U-SIG and information included in non-traditional SIG.

[0125] Preamble puncturing can represent the transmission of a PPDU where no signal is present in one or more frequency units within the bandwidth of the PPDU. For example, the size of the frequency unit (or the resolution of the preamble puncturing) can be defined as 20 MHz, 40 MHz, etc. For example, preamble puncturing can be applied to PPDU bandwidths of a predetermined size or larger.

[0126] exist Figure 7In the examples, non-traditional SIGs such as HE-SIG-B and EHT-SIG can include control information for receiving STAs. Non-traditional SIGs can be transmitted on at least one symbol, and a symbol can have a length of 4 μs. Information regarding the number of symbols used for EHT-SIGs can be included in previous SIGs (e.g., HE-SIG-A, U-SIG, etc.).

[0127] Non-traditional SIGs such as HE-SIG-B and EHT-SIG can include both public and user-specific fields. These public and user-specific fields can be encoded separately.

[0128] In some cases, the common field can be omitted. For example, in compressed mode using non-OFDMA (Orthogonal Frequency Division Multiple Access), the common field can be omitted, and multiple STAs can receive PPDUs (e.g., the data field of the PPDU) through the same frequency band. In uncompressed mode using OFDMA, multiple users can receive PPDUs (e.g., the data field of the PPDU) through different frequency bands.

[0129] The number of user-specific fields can be determined based on the number of users. A user block field can include up to two user fields. Each user field can be associated with either a MU-MIMO allocation or a non-MU-MIMO allocation.

[0130] The common fields may include CRC bits and a tail bit, where the length of the CRC bits can be determined to be 4 bits, and the length of the tail bit can be determined to be 6 bits and set to 000000. The common fields may include RU allocation information. RU allocation information may include information about the locations of RUs assigned to multiple users (i.e., multiple receiving STAs).

[0131] An RU can include multiple subcarriers (or tones). RUs can be used when transmitting signals to multiple STAs based on OFDMA technology. Additionally, RUs can be defined even when transmitting signals to a single STA. Resources can be allocated in units of RUs for non-traditional STFs, non-traditional LTFs, and data fields.

[0132] The appropriate RU size can be defined based on the PPDU bandwidth. RUs can be defined the same or different for the applied PPDU format (e.g., HEPPDU, EHT PPDU, UHR PPDU, etc.). For example, in the case of an 80 MHz PPDU, the RU layout for HEPPDU and EHT PPDU can be different. The appropriate RU size, number and location of RUs, DC (direct current) subcarrier locations and numbers, empty subcarrier locations and numbers, guard subcarrier locations and numbers, etc., for each PPDU bandwidth can be referred to as the tone scheme. For example, a tone scheme for high bandwidth can be defined as multiple iterations of a low-bandwidth tone scheme.

[0133] RUs of various sizes can 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, 3×996-tone RUs, etc. MRUs (Multiple RUs) differ from multiple individual RUs and correspond to a group of subcarriers composed of multiple RUs. For example, an MRU can 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 constituting an MRU can be consecutive or non-consecutive in the frequency domain.

[0134] The specific size of the RU can be reduced or expanded. Therefore, the specific size of each RU in this disclosure (i.e., the number of corresponding tones) is not limiting but illustrative. In addition, in this disclosure, the number of RUs can vary depending on the RU size within a predetermined bandwidth (e.g., 20 MHz, 40 MHz, 80 MHz, 160 MHz, 320 MHz...).

[0135] Figure 7 The names of each field in the PPDU format are exemplary, and the scope of this disclosure is not limited to these names. Furthermore, the examples in this disclosure can be applied to… Figure 7 The PPDU format shown and based on Figure 7 A new PPDU format that excludes some fields and / or adds some fields, based on the PPDU format.

[0136] Multiple Access Point (MAP) Operation

[0137] The following will describe an example of this disclosure for multi-access point (MAP) operation.

[0138] MAP operations can be defined as operations between a primary AP (or sharing AP) and a secondary AP (or shared AP).

[0139] The master AP initiates and controls MAP operations for sending or receiving data among multiple APs. The master AP groups slave APs and manages links with them to share information. The master AP manages information about the BSSs configured for the slave APs and the STAs associated with those BSSs.

[0140] Slave APs can be associated with master APs and share control information, management information, and data services. Slave APs perform the basic functions of APs that can establish a BSS in a wireless LAN in the same way.

[0141] In MAP operations, a STA can be associated with a slave AP or a master AP to configure a BSS.

[0142] In a MAP environment, the master AP and slave APs can perform direct transmission or reception with each other. The master AP and STA may not be able to perform direct transmission or reception with each other. A slave AP (e.g., a slave AP associated with a STA) can perform direct transmission or reception with the STA. One of the slave APs can become the master AP.

[0143] MAP operation is a technique in which at least one AP sends and receives information to at least one STA. For example, Coordinated Time Division Multiple Access (C-TDMA) techniques that divide the allocation between APs along the time axis, Coordinated Orthogonal Frequency Division Multiple Access (C-OFDMA) techniques that divide the allocation between APs along the frequency axis, and Coordinated Spatial Reuse (C-SR) techniques that utilize spatial reuse can be applied to MAP operation. Alternatively, Coordinated Beamforming (C-BF) or Joint Beamforming techniques that cooperate to perform simultaneous transmission or reception can also be applied to MAP operation.

[0144] Figure 8 This is a diagram illustrating various transmitting or receiving technologies that can be applied in a MAP environment according to this disclosure.

[0145] When a BSS AP performs a transmission to a BSS STA using existing methods, it can be referred to as Single Transmission (STX). In STX, there is a problem of degraded transmission or reception performance for users / STAs located at the cell edge due to interference with neighboring APs. For example, as... Figure 15 In (a), when AP1 and AP2 transmit to STA1 and STA2 simultaneously in the same frequency bandwidth, a wireless medium collision may occur.

[0146] In MAP technology, performance can be improved by reducing inter-symbol interference (ISI) through cooperation or joint transmission between adjacent APs. For example, in Figure 8 In the C-OFDMA method of (b), AP1 can transmit to STA1 in the first bandwidth, and AP2 can simultaneously transmit to STA2 in the second bandwidth to avoid interference. Figure 8 The example in (c) illustrates a cooperative beamforming or nulling technique in which AP1 nulls the interference to AP2 and / or STA2 when performing a transmission to STA1, and AP2 nulls the interference to AP1 and / or STA1 when performing a transmission to STA2. Figure 8 (d) illustrates an AP selection method that enables an AP with good channel conditions among neighboring APs to perform transmission. For example, in Figure 8 In example (e), multiple APs can be applied to cooperate to perform joint transmission (JTX) or joint reception (JRX) simultaneously, and further, joint MU-MIMO can be supported.

[0147] In the examples disclosed herein, it is assumed that a multi-AP operation is performed as follows.

[0148] Step 1: Allocate resource areas to each AP via trigger frames from the master AP (i.e., AP-to-AP trigger frames or master trigger frames).

[0149] Step 2: Each AP performs DL (i.e., from AP to STA) data transmission in its assigned resource area, or sends a trigger frame (i.e., AP to STA trigger frame) for UL (i.e., from STA to AP) data transmission in its assigned resource area.

[0150] Step 3: The STA sends a response to the DL data, or sends it via UL data (e.g., TB PPDU).

[0151] When the resources allocated between APs are frequency resources, it can correspond to the C-OFDMA method; when the resources allocated between APs are time resources, it can correspond to the C-TDMA technology; and when the resources allocated between APs are spatial resources (or beams), it can correspond to the CBF method. In the examples described below, the C-OFDMA technology is assumed to be performed, i.e., it is representatively described through multi-AP operation using resources differentiated in the frequency domain. However, the scope of this disclosure is not limited thereto and may additionally or alternatively include multi-AP operation using resources differentiated in another domain (e.g., the time domain and / or the spatial domain).

[0152] Target wake-up time (TWT)

[0153] The target wake-up time (TWT) is described below.

[0154] TWT (Time-of-Service) is a power-saving (PS) technique that improves the energy efficiency of non-AP STAs by defining service periods (SPs) between APs and non-AP STAs and sharing information about these SPs to reduce media contention. STAs that perform requests / suggestions / requests during the TWT setup process can be called TWT-requesting STAs. APs that respond to the corresponding requests, such as accepting / rejecting, can be called TWT-responding STAs. The setup process can include the STA's TWT request to the AP, the type of TWT operation performed, and the process of determining / defining the type of frames to be sent or received. TWT operations can be divided into individual TWTs and broadcast TWTs.

[0155] Figure 9 This is a diagram illustrating an example of individual TWT operations that can be applied to this disclosure.

[0156] Individual TWT is a mechanism by which an AP and a non-AP STA exchange data after negotiating the wake-up / sleep state of a non-AP STA by sending or receiving TWT request / response frames. Figure 9 In the example, AP and STA1 can form a triggered TWT agreement using TWT request frames and TWT response frames. Here, STA1 uses the request TWT method, which is the method by which STA1 receives information for TWT operation from AP via a TWT response frame when STA1 sends a TWT request frame to AP. On the other hand, STA2, performing the non-request TWT method, can receive information about the triggered TWT agreement configuration from AP via a non-request TWT response. Specifically, STA2 can calculate the next TWT by adding a specific amount from the current TWT value. During the triggered TWT SP, AP can send a trigger frame to STA. The trigger frame can notify STA that AP has buffered data. In response, STA1 can notify AP of its wake-up status by sending a PS polling frame. Additionally, STA2 can notify AP of its wake-up status by sending a QoS empty frame. Here, the data frames sent by STA1 and STA2 can be in the form of TB PPDU frames. AP, confirming the status of STA1 and STA2, can send a DL MU PPDU to wake up STA. When the corresponding TWT SP expires, STA1 and STA2 can switch to hibernation mode.

[0157] Figure 10 This is a diagram illustrating an example of the broadcast TWT operation that can be applied to this disclosure.

[0158] A broadcast TWT is a TWT sent by a non-AP STA (or a TWT scheduling STA) to the AP (or a TWT-scheduled STA) to obtain information such as the Target Beacon Transmission Time (TBTT) and listening intervals by sending or receiving TWT request / response frames. Negotiation of the TBTT can be performed here. Based on this, the AP can define the frames that will include the TWT scheduling information via beacon frames. Figure 10 In this process, STA1 performs a request TWT operation, while STA2 performs a non-request TWT operation. The AP can send a DL MU PPDU after confirming the wake-up status of the STA via a trigger sent by the AP. This can be the same process as for individual TWTs. In broadcast TWTs, the TWT SP, including the enable trigger of the beacon frame, can be repeated several times at regular intervals.

[0159] TWT messages can be delivered using TWT message frames and TWT message elements.

[0160] With the recent surge in wired and wireless services, latency-sensitive services have also increased significantly. Latency-sensitive services include real-time audio / video transmission, and the need to support such services in wireless environments is increasing with the proliferation of multimedia devices. However, supporting latency-sensitive services in wireless environments presents many challenges compared to wired environments. This is because transmission speeds in wireless environments are lower than in wired environments, and interference from the surrounding environment must also be considered. Specifically, in WLAN systems, multiple STAs must compete equally for media occupancy in the Industrial, Scientific, and Medical (ISM) band, making it relatively more difficult to support latency-sensitive services compared to cellular communication networks based on radio resource scheduling by a central base station. This disclosure describes a novel method for supporting latency-sensitive services in WLAN systems.

[0161] In this disclosure, latency can refer to the latency defined in the IEEE 802.11 series of standards. For example, it can refer to the time from when a frame to be transmitted enters the MAC layer queue of the transmitting STA until the transmitting STA successfully completes transmission in the PHY layer and removes the corresponding frame from the MAC layer queue of the transmitting STA after receiving an ACK / block ACK from the receiving STA. Furthermore, in this disclosure, a non-AP STA that supports the transmission of latency-sensitive data can be referred to as a low-latency STA. And, data other than latency-sensitive data can be referred to as regular data.

[0162] Because the AP configures a special broadcast TWT for low-latency STAs transmitting time-sensitive data, a restricted TWT (r-TWT) can ensure that the data transmission probability of low-latency STAs is prioritized over other STAs. STAs can establish membership for the AP for at least one r-TWT scheduling. Here, the r-TWT agreement can be established through the same process as the broadcast TWT agreement, and the broadcast TWT element used here can be defined to include an r-TWT parameter set field. For example, the r-TWT parameter set can refer to a specific broadcast TWT parameter set field that differs from other broadcast TWT parameter set fields. In other words, the r-TWT parameter set field can correspond to a special case of the broadcast TWT parameter set field. Furthermore, the AP can advertise r-TWT SPs.

[0163] Basically, if another STA supporting r-TWT operation is a TXOP holder, the TXOP must end before the start time of the r-TWT SP announced in the associated AP. Therefore, the STA associated with the corresponding r-TWT (i.e., the low-latency STA) can take precedence over other STAs within the r-TWT SP in performing service transmission or reception.

[0164] In this disclosure, as described above, the low-latency STA associated with a specific r-TWT is referred to as the STA scheduled as a member of the r-TWT, and the other STAs are referred to as non-member STAs. A non-member STA has the capability to support r-TWT operations, but it may not be a member of any r-TWT, or it may support r-TWT operations and be a member of another r-TWT, or it may be an STA that does not have the capability to support r-TWT operations.

[0165] A STA (e.g., a low-latency STA) that supports restricted SP (or r-TWT SP) operations for broadcast TWT can notify the AP that it must send latency-sensitive data based on r-TWT operations. If the AP supports r-TWT operations / modes, the AP can send frames to the low-latency STA and other STAs that include scheduling information for the TWT requested by each STA. For example, to perform operations for r-TWT, a non-AP STA can obtain r-TWT related information from the AP via beacon frames, probe response frames, (re)association response frames, or other undefined format frames (e.g., frames for broadcast, announcement, and notification).

[0166] According to restricted TWT operations, a separate TXOP (i.e., access to other STAs is restricted) can be ensured within an r-TWT SP by using NAVs such as (MU)RTS / CTS or CTS to itself, or by silent intervals. Before a specific r-TWT SP begins, if there is a TXOP for another STA (i.e., a non-member STA) besides the one with membership for that specific r-TWT scheduling, the specific r-TWT SP must be stopped. Furthermore, another TXOP for a non-member STA can be executed after the specific r-TWT SP ends.

[0167] Negotiation process related to R-TWT coordination

[0168] In a multi-BSS environment, when APs are located within range where they can receive beacon frames from each other, an overlapping BSS (OBSS) range can be formed. This OBSS range is the range where the AP's transmit and receive ranges (i.e., BSSs) overlap.

[0169] Figure 11 This is a diagram illustrating the AP and STA in OBSS that can be applied to this disclosure.

[0170] like Figure 11 As illustrated, the signaling capability range of AP 1 (e.g., the range corresponding to BSS 1) and the signaling capability range of AP 2 (e.g., the range corresponding to BSS 2) can overlap. In this way, when AP 1 and AP 2 are within range where they can receive from each other (i.e., listen to each other), AP 1 and AP 2 can perform coordinated negotiation for their respective scheduled R-TWT service periods (SPs) via (wireless / wired) communication. This situation corresponds to AP 1 and AP 2 being located in OBSSs with overlapping transmit / receive ranges, which differs from the case where AP 1 and AP 2 are hidden nodes relative to each other.

[0171] In this respect, STAs located within the overlapping range can receive beacon frames not only from the AP associated with them, but also from APs not associated with them. For example, STAs 1-2 can receive beacon frames from their associated AP 1, and can also receive (i.e., listen to) beacon frames from their unassociated AP 2. For example, STAs 2-3 can receive beacon frames from their associated AP 2, and can also receive (i.e., listen to) beacon frames from their unassociated AP 1.

[0172] At this point, AP 1 and AP 2 can correspond to subordinate APs (or shared APs) belonging to a MAP that has the same primary AP (or shared AP). Furthermore, either AP 1 or AP 2 can be the primary AP (or shared AP). Additionally, AP 1 and AP 2 belong to the same MAP.

[0173] The beacon frame may include restricted TWT (R-TWT) scheduling information assigned by the AP to its associated STAs, and the STAs receiving the R-TWT scheduling information are required to protect R-TWT SPs for which they are not members (e.g., as mentioned above, terminating the STA's TXOP before the start time of the R-TWT SP while the corresponding TXOP is in progress). In other words, this can mean that the STA receiving the beacon frame including the R-TWT scheduling information is present at the location protecting the corresponding R-TWT SP. Meanwhile, whether a STA must protect the corresponding R-TWT SP or transmit or receive low-latency services / data during the corresponding R-TWT SP is undefined when it receives R-TWT scheduling information advertised by an unassociated (or neighboring) AP.

[0174] This disclosure describes a method for negotiating R-TWT coordination based on scheduling information of R-TWTs scheduled by an associated AP (e.g., AP 1) and / or by scheduling information of R-TWTs scheduled by an unassociated (or neighboring) AP (e.g., AP 2). In the following description, to distinguish R-TWT service periods (SPs) scheduled by an associated AP, an R-TWT SP scheduled by another AP (e.g., an unassociated AP or a neighboring AP) is referred to as an OBSS R-TWT SP. The scope of this disclosure is not limited to the name OBSS R-TWT.

[0175] In this disclosure, the case in which the coordination request is sent by the associated AP and the coordination response to the coordination request is sent by the unassociated (or neighboring) AP is described as a representative example. However, this is for clarity of description, and the method proposed in this disclosure can also be applied to the case in which the coordination request is sent by the unassociated (or neighboring) AP and the coordination response to it is sent by the associated AP.

[0176] Implementation Method 1

[0177] This embodiment relates to a method for distinguishing between coordinated R-TWT and non-coordinated R-TWT.

[0178] First, coordinated R-TWTs and uncoordinated R-TWTs can be distinguished based on the negotiation results of (wireless / wired) coordination between associated APs and unassociated (or neighboring) APs for R-TWT SPs.

[0179] The negotiation process for coordination between associated APs (e.g., AP 1) and unassociated (or neighboring) APs (e.g., AP 2) can be carried out in a two-way manner.

[0180] - Step 1. Associated APs can send coordination requests to unassociated (or neighboring) APs.

[0181] - Step 2. The unassociated (or neighboring) AP that receives the coordination request can send a coordination response to the AP that sent the coordination request (i.e., the associated AP).

[0182] In the aforementioned negotiation process, when the coordination response in step 2 includes a message indicating "acceptance" (or "success"), coordination can be interpreted as successfully established. In this case, the R-TWT SP, as the subject of the negotiation, can be considered as a coordinated R-TWT SP between the participating APs.

[0183] Conversely, when the coordination response in step 2 includes a message indicating "rejection" (or "failure"), the associated AP may retransmit the coordination request to the unassociated (or neighboring) AP. In this case, the retransmitted coordination request may include the same R-TWT SP-related information as that included in the previously sent coordination request (e.g., the coordination request sent in step 1), or may include information that has been partially or entirely changed. Coordination can be interpreted as rejected (or failed) when the last coordination response received during the negotiation process from an unassociated (or neighboring) AP includes a message indicating "rejection" (or "failure"). In this case, the R-TWT SP that is the subject of the negotiation can be considered a non-coordinated R-TWT SP between the participating APs. In this respect, non-coordinated R-TWT SPs can be collectively referred to as R-TWT SPs that failed to coordinate through the negotiation process between APs, as well as R-TWT SPs that are not the subject of the coordination negotiation process (i.e., not included in the coordination negotiation process).

[0184] Secondly, in addition to the above-mentioned negotiation process, coordinated R-TWT and non-coordinated R-TWT can be distinguished based on one or more of the following additional methods.

[0185] For example, when a third management entity (e.g., a central entity) exists, the third management entity can manage / allocate the scheduling of APs and can share AP scheduling information with the APs. As an example, the primary AP can act as the third management entity. In this case, when the third management entity allocates R-TWT SPs to each AP and shares the corresponding R-TWT-related scheduling information with other APs, the corresponding R-TWT SPs can be considered as coordinating R-TWT SPs between APs.

[0186] As another example, when an associated AP receives (i.e., listens to) a beacon frame sent by an unassociated (or neighboring) AP and obtains information about an OBSS R-TWT SP, the corresponding OBSS R-TWT SP can be considered a non-coordinated R-TWT SP. In this regard, the associated AP can schedule R-TWT SPs based on the OBSS R-TWT SPs obtained through the beacon frames received (i.e., listened to) by the associated AP. As an example, the associated AP can allocate R-TWT SPs to its associated STAs such that they do not overlap with the corresponding OBSS R-TWT SPs, and advertise the R-TWT SPs.

[0187] As yet another example, when a STA receives (i.e., listens to) a beacon frame sent by an unassociated (or neighboring) AP, it can obtain information about the OBSS R-TWT SP.

[0188] In this scenario, the STA can advertise the information of the corresponding OBSS R-TWT SP to the associated AP. At this point, the corresponding OBSS R-TWT SP can be considered a non-coordinated R-TWT SP. In this respect, the associated AP can schedule / allocate R-TWT SPs based on the OBSS R-TWT SPs shared / advertised by the STA. As an example, the associated AP can allocate R-TWT SPs to its associated STAs such that they do not overlap with the corresponding OBSS R-TWT SPs, and then advertise those R-TWT SPs.

[0189] Additionally or alternatively, in this case, based on the obtained information about the OBSS R-TWT SP, the STA can send a TWT request to the associated AP, the TWT request including information on times (e.g., SPs) that do not overlap with the corresponding OBSS R-TWT SP. This scheme has the effect of reducing the overhead that could occur by sending (a large number) of OBSS R-TWT SP information to the associated AP. This scheme may be efficient in situations where direct data transmission / reception between APs is impossible, where direct data transmission / reception between APs is possible but coordination cannot be performed, or where direct coordination between APs cannot be performed.

[0190] Regarding the scheme based on the aforementioned TWT request, the STA can send a TWT request (via TWT frame establishment), which includes a new field indicating the non-overlapping time (e.g., SP) based on information used for OBSS R-TWT SP. This field can be indicated by using reserved bits within the TWT element.

[0191] As an example, a new field with a length of 1 bit (e.g., the OBSS non-overlapping SP field) can be defined by using reserved bits in the control fields included in the TWT element. The value of this field can indicate whether the request time (e.g., SP) included in the TWT request overlaps with the OBSS R-TWT SP (all).

[0192] As another example, it can be additionally configured with the following Figure 12 The illustrated information is related to the coordination of R-TWT.

[0193] Figure 12 A configuration example of coordinating R-TWT related information according to this disclosure is shown.

[0194] refer to Figure 12 The coordinated R-TWT related information can be configured to include the coordinated R-TWT field, BSS color field, protection recommendation field, broadcast TWT ID field and / or overlapping R-TWT field.

[0195] Fields included in the coordination R-TWT related information can be defined as new fields within the broadcast / new TWT parameter set fields of a TWT element, or as fields defined in a new element. As an example, coordination R-TWT related information can be included / positioned after the TWT element within the TWT setup frame.

[0196] The Coordinated R-TWT field can indicate whether an R-TWT SP corresponds to an R-TWT SP that was successfully coordinated with the AP that issued the notification (i.e., the associated AP). For example, this field can have a length of 1 bit, and in this case, a value of 1 can be defined as indicating a coordinated R-TWT SP, and a value of 0 can be defined as indicating a non-coordinated R-TWT SP. Additionally, in this disclosure considering the presence of a third entity managing the AP, this field can also be extended and used to distinguish between the aforementioned coordinated and non-coordinated R-TWT SPs.

[0197] The BSS color field can indicate the BSS color of the AP that is scheduled for the corresponding R-TWT SP. As an example, this field can be 6 bits long and can be set to indicate the BSS color value.

[0198] The Protection Recommendation field indicates whether the associated STA should perform protection operations for the corresponding R-TWT SP. The Protection Recommendation field may have an indication value that indicates whether the STA should follow the protection rules for the corresponding R-TWT SP in a mandatory or conditionally mandatory (or optional) manner.

[0199] For example, when the corresponding value is 0, the STA will / should stop its TXOP before the start time of the corresponding R-TWT SP. Conversely, when the corresponding value is 1 or a value greater than 1, this can instruct the STA to conditionally comply with the protection rules for the corresponding R-TWT SP based on other information. This other information could be information about another layer (e.g., the PHY layer) for the corresponding STA.

[0200] As a specific example, this information may include the BSS color value of the U-SIG field used to determine if the PPDU originates from an AP other than the associated AP (i.e., an unassociated, neighboring, or OBSS AP), a threshold level value for the received signal strength of data received from an unassociated (or neighboring) AP, and values ​​related to space reuse. For example, the threshold level value may be a PD level of -82dBm, an ED level of -62dBm, or a threshold level value within a specific range defined in the system, and may be advertised via beacons, etc. Additionally, as an example, the value related to space reuse may be the value of the UL space reuse subfield indicated in the public information field of the trigger frame.

[0201] The broadcast TWT ID can refer to the broadcast TWT ID within the TWT element corresponding to the corresponding R-TWT SP. This value allows the STA to identify scheduling information for the corresponding R-TWT (i.e., the corresponding coordinating R-TWT).

[0202] The Overlapping R-TWT field can indicate whether the R-TWT service period (SP) corresponding to the broadcast TWT ID overlaps with another R-TWT SP (the time (SP) included in the TWT request).

[0203] Based on the aforementioned coordinated R-TWT related information, by indicating that the R-TWT SP corresponding to the broadcast TWT ID is a non-coordinated R-TWT SP and a non-overlapping R-TWT SP, information that does not overlap with the corresponding OBSS R-TWT SP (e.g., SP) can be included / indicated.

[0204] In this regard, the associated AP can identify, through the values ​​of the aforementioned new fields (e.g., the OBSS non-overlapping R-TWT SP field and the overlapping R-TWT SP field), that the requested time (e.g., SP) does not overlap with the OBSS R-TWT SP. Based on this, the associated AP can allocate and announce (R-)TWT SPs to its associated STAs based on the information of the requested time (e.g., SP) included in the STA's TWT request. In this way, other STAs can also be allowed to participate as members in the corresponding R-TWT.

[0205] Implementation Method 2

[0206] This implementation relates to a specific method for performing (wireless / wired) negotiation between an associated AP and an unassociated (or neighboring) AP for coordinating R-TWT service periods (SPs). As a result of the negotiation, the AP can obtain scheduling information for coordinating the R-TWT SP (i.e., coordinating the R-TWT).

[0207] The following will describe the specific information included in the messages / frames used for negotiation, namely the coordination request and the coordination response.

[0208] In this regard, in the case of wireless negotiation, it is assumed that wireless negotiation is possible in a topology where the AP is located in the area where the other AP's BSS (e.g., the second BSS to which AP 2 belongs) overlaps with its own BSS (e.g., the first BSS to which AP 1 belongs) (i.e., the OBSS area). If wireless-based communication between APs is not possible, negotiation can be performed through wired communication (e.g., backhaul-based communication). Additionally, when a master AP is present to manage APs, (wireless / wired) negotiation can be based on coordination requests and responses sent and received via the master AP.

[0209] Furthermore, this disclosure is described under the assumption that the associated APs know in advance about the R-TWT service periods (SPs) scheduled by the unassociated (or neighboring) APs and can initiate coordination negotiations. For example, in the case of direct negotiation between APs, the APs may be located in a position where they can send and receive beacon frames from each other, and can identify the R-TWT SP information in advance by receiving (i.e., listening to) beacon frames, etc. However, the scope of this disclosure is not limited to this, and this disclosure can be extended even if the APs do not know in advance about the R-TWT SPs scheduled by each other (e.g., the APs are not located in a position where they can send and receive beacon frames from each other, etc.).

[0210] Furthermore, this disclosure is based on the assumption that the coordination requests and responses described herein can be defined as new frames or as new elements to be sent along with other requests. For example, coordination requests and responses for R-TWT SP coordination can be configured by modifying some fields or defining new fields based on TWT elements and the broadcast TWT parameter set field in the TWT setup frame.

[0211] Furthermore, in this disclosure, the description assumes that the AP sending the coordination request and the AP receiving the coordination response correspond to the same AP, and that the AP receiving the coordination request and the AP sending the coordination response correspond to the same AP; however, the scope of this disclosure is not limited thereto.

[0212] Implementation Method 2-1

[0213] In this embodiment, the elements constituting the coordination request described above are described in detail. The coordination request may include at least one or more elements described below.

[0214] 1) Information related to the Timed Synchronization Function (TSF)

[0215] The coordination request may include information for synchronizing the TSF of the AP sending the coordination request (e.g., an associated AP) with the TSF of the AP receiving the coordination request (e.g., an unassociated (or neighboring) AP).

[0216] This information can be used to resolve the issue of different reference times between access points (APs).

[0217] For example, when the AP sending the coordination request has previously identified information related to the TSF of the AP receiving the coordination request, the AP sending the coordination request can configure the TWT element based on the TSF of the AP receiving the coordination request. That is, the scheduling information for R-TWT can be configured based on the TSF of the AP receiving the coordination request. This situation, where the TWT element is configured based on the TSF of the AP receiving the coordination request, can be indicated by using the value of a specific field within the coordination request (e.g., the TSF alignment field). As an example, when the value of the corresponding field is set to 1, it can indicate that the coordination request includes scheduling information aligned with the TSF of an unassociated (or neighboring) AP.

[0218] As another example, when the AP sending the coordination request has not previously identified information related to the TSF of the AP receiving the coordination request, the AP sending the coordination request may include its own TSF-related information in the coordination request. For example, this could include the value of an 8-byte TSF field, or it could include the value of a 2-byte TSF offset field.

[0219] 2) Scheduling information of R-TWT SP as a coordination and negotiation topic

[0220] The coordination request may include a TWT element consisting of a broadcast TWT parameter set field, which includes information for the R-TWT SP to be performed for coordination negotiation.

[0221] The broadcast TWT parameter set fields may include a restricted TWT service information field. In this case, information about the TID of low-latency services transmitted and received during the corresponding R-TWT SP can be shared through the restricted TWT service information field.

[0222] In this regard, for the coordination and negotiation of R-TWT between APs, unused fields in the broadcast TWT parameter set field and / or restricted TWT service information field in the coordination request can be set as reserved values ​​and sent and received, or new elements corresponding to the fields can be configured to be removed. This is because fields in the broadcast TWT parameter set field and / or restricted TWT service information field that are not related to the protection operation of the R-TWT SP may not need to be shared between APs during the coordination and negotiation process.

[0223] 3) Information related to the overlap between one R-TWT SP and another R-TWT SP as a coordinating topic.

[0224] When a requested R-TWT SP overlaps with an R-TWT SP scheduled by an unassociated (or neighboring) AP, the coordination request may include a field indicating that the R-TWT SP is an overlapping R-TWT SP.

[0225] Because each AP has a different TSF value, when the AP sending the coordination request identifies the TSF of the AP receiving the coordination request, the AP sending the coordination request can determine whether the two TWTs are the same (e.g., whether they overlap). Conversely, in other cases besides when the AP sending the coordination request identifies the TSF of the AP receiving the coordination request (e.g., when the AP sending the coordination request does not identify the TSF of the AP receiving the coordination request), whether to indicate overlapping R-TWT SPs can take the form of requesting the AP receiving the coordination request to schedule overlapping R-TWT SPs based on the TWT element information included in the coordination request.

[0226] For example, when the value of the TWT field in the broadcast TWT parameter set field of the TWT element indicating R-TWT scheduling information (i.e., information for the R-TWT SP) in the coordination request is the same as the value of the TWT field in the broadcast TWT parameter set field of the TWT element constituting the R-TWT scheduling information scheduled by the AP receiving the coordination request, the corresponding R-TWT SPs overlap, i.e., they correspond to overlapping R-TWT SPs. In other words, when the start time of an R-TWT SP is the same as the start time of an OBSS R-TWT SP, the corresponding R-TWT SP can correspond to an overlapping R-TWT SP. As an example, this can correspond to the minimum condition for satisfying overlapping R-TWT SPs.

[0227] Figure 13 An example of an overlapping R-TWT SP according to this disclosure is illustrated.

[0228] refer to Figure 13When the duration of the overlapping R-TWTSP of AP 1 (e.g., associated AP) and AP 2 (e.g., unassociated (or neighboring) AP) is the same, the corresponding overlapping R-TWTSP can be considered as a fully overlapping R-TWTSP. Figure 13 In this example, we assume that the AP sending the coordination request is AP 1, and the AP receiving the coordination request is AP 2.

[0229] In this respect, it is not restricted whether the TWT interval value is the same. That is, for overlapping R-TWT SPs and OBSSR-TWT SPs, the TWT interval can be set to the same value or different values.

[0230] Figure 14 Another example of an overlapping R-TWT SP according to this disclosure is illustrated.

[0231] refer to Figure 14 When the durations of the overlapping R-TWTSPs of AP 1 (e.g., associated AP) and AP 2 (e.g., unassociated (or neighboring) AP) are not the same, the corresponding overlapping R-TWTSPs can be considered as partially overlapping R-TWTSPs. Figure 14 In this example, we assume that the AP sending the coordination request is AP 1, and the AP receiving the coordination request is AP 2.

[0232] In this respect, it is not restricted whether the TWT interval value is the same. That is, for overlapping R-TWT SPs and OBSSR-TWT SPs, the TWT interval can be set to the same value or different values.

[0233] As another example, when the value of the TWT field in the broadcast TWT parameter set field of the TWT element constituting the R-TWT scheduling information scheduled by the AP receiving the coordination request is within the duration of the SP based on the value of the TWT field in the broadcast TWT parameter set field of the TWT element indicating in the coordination request that includes the R-TWT scheduling information (i.e., information for the R-TWT SP), the corresponding R-TWT SPs overlap with each other, i.e., they correspond to overlapping R-TWT SPs.

[0234] Figure 15 Another example of overlapping R-TWT SPs according to this disclosure is illustrated.

[0235] refer to Figure 15 When an R-TWT SP scheduled by AP 2 (e.g., an unassociated (or neighboring) AP) begins during an R-TWT SP scheduled by AP 1 (e.g., an associated AP), the corresponding overlapping R-TWT SP can be considered a partially overlapping R-TWT SP. Figure 15In this example, we assume that the AP sending the coordination request is AP 1, and the AP receiving the coordination request is AP 2.

[0236] As another example, when the value of the TWT field in the broadcast TWT parameter set field of the TWT element indicating R-TWT scheduling information (i.e., information for R-TWT SP) in the coordination request is within the duration of the SP based on the value of the TWT field in the broadcast TWT parameter set field of the TWT element constituting the R-TWT scheduling information scheduled by the AP receiving the coordination request, the corresponding R-TWT SPs overlap with each other, i.e., they correspond to overlapping R-TWT SPs.

[0237] Figure 16 Another example of an overlapping R-TWT SP according to this disclosure is illustrated.

[0238] refer to Figure 16 When an R-TWT SP scheduled by AP 1 (e.g., an associated AP) begins during an R-TWT SP scheduled by AP 2 (e.g., an unassociated (or neighboring) AP), the corresponding overlapping R-TWT SP can be considered a partially overlapping R-TWT SP. Figure 16 In this context, assume that the AP sending the coordination request is AP 1, and the AP receiving the coordination request is AP 2.

[0239] Fields that indicate information related to the aforementioned overlapping R-TWT SPs can be defined in a two-level indication manner, indicating overlapping or non-overlapping R-TWT SPs, or in a three-level indication manner, indicating fully overlapping, partially overlapping, or non-overlapping R-TWT SPs.

[0240] In this regard, when the corresponding field indicates a complete overlap or a partial overlap of R-TWT SPs, information about the duration of the corresponding R-TWT SP can be additionally included in the coordination request.

[0241] As an example, in the case of fully overlapping R-TWT SPs, the corresponding duration can have the same value as the duration of the R-TWT SP scheduled by the AP sending the coordination request. As another example, in the case of partially overlapping R-TWT SPs, the value obtained by subtracting the corresponding R-TWT SP overlap duration from the value obtained by adding the duration of the R-TWT SP scheduled by the AP sending the coordination request and the duration of the R-TWT SP scheduled by the AP receiving the coordination request can correspond to the entire duration of the partially overlapping R-TWT SP.

[0242] 4) Information on the coordination scheme used by AP during (non-)overlapping R-TWT SP operations.

[0243] When the information related to overlapping R-TWT SPs indicates that an R-TWT SP is (fully or partially) overlapping, it may be mandatory to include information about the coordination scheme of the APs to be operated during the corresponding SP. However, when performing coordination negotiations for non-overlapping R-TWT SPs, the inclusion of corresponding information is not restricted. For example, AP coordination schemes may include C-TDMA, C-OFDMA, C-SR, etc.

[0244] In this regard, the information regarding the coordination scheme to be operated by the AP included in the coordination request can be defined as indicating one or more technologies. In this case, among the coordination schemes supported by the AP sending the coordination request, only the coordination schemes that may operate during the corresponding R-TWT SP can be indicated. As an example, when IDs indicating each coordination scheme are defined, the coordination schemes that can be supported during the corresponding R-TWT SP can be indicated in list form. As another example, the corresponding field can be defined in bitmap form. In this case, each bit of the bitmap can be defined to correspond to C-TDMA, C-OFDMA, C-SR, etc., and the value of each bit (i.e., 0 or 1) can be used to indicate whether the corresponding coordination scheme is supported.

[0245] Additionally, within the coordination request, after the information on the coordination schemes supported during the corresponding SP period, information required to operate each coordination scheme may be included as an additional component.

[0246] 5) Identification information associated with the AP that sent the coordination request

[0247] The coordination request may include information indicating the BSS to which the AP sending the coordination request belongs (e.g., BSS color value).

[0248] 6) Information related to low-latency services

[0249] The coordination request may include information related to low-latency services transmitted and received during the R-TWT SP included in the coordination request. This information may correspond to information not included in beacon frames, etc. Furthermore, this information may correspond to the aforementioned restricted TWT service information field.

[0250] For example, a coordination request may include information from QoS characteristic elements included in a Flow Classification Service (SCS) request / response frame.

[0251] For example, a coordination request may include information about low-latency service / data IDs commonly used between APs to indicate transmission and reception requirements for low-latency services.

[0252] For example, a coordination request may include information related to the minimum propagation power required to transmit and receive low-latency services during the corresponding R-TWT SP, spatial reuse values, and values ​​indicating specific threshold levels.

[0253] 7) Requests related to information and requirements regarding low-latency services.

[0254] The coordination request may include information indicating whether to request that information and related requirements regarding low-latency services to be sent and received by the AP during R-TWT SP be included in the coordination response.

[0255] Implementation Method 2-2

[0256] In this embodiment, the elements constituting the above-described coordinated response will be described in detail. At least one or more elements described below may be included in the coordinated response.

[0257] 1) Information used for status codes

[0258] The coordination response may include status code information indicating acceptance (or success) or rejection (or failure) of the requested coordination.

[0259] In this regard, the status code indicating rejection may include a first rejection code that simply indicates rejection (e.g., REJECT), a second rejection code that includes the reason for rejection, and / or a third rejection code that includes recommendations / suggestions (e.g., information about the SP that is recommended / suggested) (e.g., REJECTED_WITH_SUGGESTED_CHANGES).

[0260] If the status code information is set to the value of the first rejection code or the third rejection code, the information for the newly negotiated R-TWT SP can be included in the coordination response. In this case, for the corresponding R-TWT SP, the coordination response may include information related to TSF, information on whether the R-TWT SPs overlap, information related to the coordination technique, information on the BSS color for the AP, and additional information for low-latency services transmitted and received during the corresponding SP, etc.

[0261] 2) Information related to TSF (Timed Synchronization Function)

[0262] The coordination response may include information for aligning the TSF of the AP that sent the coordination request with the TSF of the AP that sent the coordination response. In this regard, at least one of the following example methods may be utilized.

[0263] For example, when the TSF alignment field included in the coordination request indicates that the TWT element in the coordination request is based on the TSF configuration of the AP receiving the coordination request, the TSF alignment field can also be included in the coordination response, and the value of the field can be set to the same value indicated in the coordination request.

[0264] For example, when information about its own TSF (i.e., the TSF of the AP that sent the coordination request) (e.g., the value of the 8-byte TSF field, the value of the 2-byte TSF offset field, etc.) is included in the coordination request, information about the TSF of the AP that sent the coordination response can be included in the coordination response in the same format as that included in the coordination request.

[0265] For example, if the status code information is set to the value of the first rejection code or the value of the third rejection code, the value of the corresponding field can be set / configured based on a scheme that includes information for aligning the TSF of the AP sending the coordination request and the TSF of the AP receiving the coordination request (i.e., the scheme proposed in Implementation 2-1).

[0266] 3) Scheduling information of R-TWT SP as a coordination and negotiation topic

[0267] A coordination response may include a TWT element consisting of one or more broadcast TWT parameter set fields that include information for performing coordination negotiation R-TWT SP.

[0268] The broadcast TWT parameter set fields may include a restricted TWT service information field. In this case, information about the TID of low-latency services transmitted and received during the corresponding R-TWT SP can be shared through the restricted TWT service information field.

[0269] If an overlapping R-TWT SP is indicated by the coordination request, the coordination response may include an SP value that is the same as or similar to the SP value in the TWT element of the coordination request, i.e., the same or similar scheduling information. This can indicate / imply overlapping coordinated R-TWT SPs. Conversely, if a non-overlapping R-TWT SP is indicated by the coordination request, the coordination response may include an SP value that is different from the SP value in the TWT element of the coordination request, i.e., different scheduling information. This can indicate / imply non-overlapping coordinated R-TWT SPs.

[0270] In this regard, in the coordination negotiation between APs for R-TWT, including the broadcast TWT parameter set field and / or restricted TWT service information field in the coordination response, unused fields can be sent and received by being set to reserved values, or new elements corresponding to those fields can be configured to be removed. This is because fields in the broadcast TWT parameter set field and / or restricted TWT service information field that are not related to the protection operation of the R-TWT SP may not need to be shared between APs during the coordination negotiation process.

[0271] 4) Overlapping information between R-TWT SPs as coordinating themes and other R-TWT SPs

[0272] When a requested R-TWT SP overlaps with an R-TWT SP scheduled by an unassociated (or neighboring) AP, the coordination response may include a field indicating that the R-TWT SP is an overlapping R-TWT SP.

[0273] For example, if the status code indicates acceptance or success, the value of the corresponding field in the coordination response can be set to the same value indicated in the coordination request.

[0274] For example, if the status code information is set to the value of a first rejection code or a third rejection code, then the (full / partial) overlapping R-TWT SP definition proposed in the coordination request of this disclosure (i.e., proposed in implementation 2-1) can be used (see, for example, see...). Figures 13 to 16 Use this to set the value of the corresponding field.

[0275] 5) Information on the coordination scheme used by AP during (non-)overlapping R-TWT SP operations.

[0276] The coordination response may include information about an AP coordination scheme to be operated during the coordination R-TWT SP among the AP coordination schemes supported by the AP delivered through the coordination request.

[0277] For example, when the list of supported coordination schemes in the coordination request includes C-TDMA, C-OFDMA, and C-SR, the coordination response may include information indicating only one of these three coordination schemes (e.g., C-TDMA). Based on this, during (non-)overlapping coordination R-TWT SP, associated APs and unassociated (or neighboring) APs can use the same AP coordination scheme.

[0278] In this regard, the coordination response may additionally include information required for the operation of the corresponding AP coordination scheme (e.g., PHY-related information).

[0279] 6) Identification information associated with the AP that sent the coordination response

[0280] The coordination response may include information indicating the BSS to which the AP sending the coordination response belongs (e.g., BSS color value).

[0281] 7) Information related to low-latency services and information related to transmission / reception requirements

[0282] The coordination response may include information about the low-latency services that the AP needs to send and receive during the R-TWT SP, as well as information about the associated send and receive requirements.

[0283] For example, a coordination response may include information from QoS characteristic elements included in a Flow Classification Service (SCS) request / response frame.

[0284] For example, a coordination response may include information indicating a common low-latency service / data ID between APs that indicate the transmission and reception requirements for low-latency services.

[0285] For example, a coordinated response may include information related to the minimum propagation power required to transmit and receive low-latency services during the corresponding R-TWT SP, spatial reuse values, and values ​​indicating specific threshold levels.

[0286] Regarding the method proposed in this disclosure, when the status code value in the coordination response is set to a first rejection code or a third rejection code and the coordination response includes information for a recommended / suggested R-TWT SP, the AP receiving the coordination response can retransmit the coordination request with a new value based on the recommended / suggested R-TWT SP information.

[0287] Furthermore, after completing the coordination negotiation performed based on the method proposed in this disclosure (i.e., the negotiation of coordinated R-TWT between the associated AP and the unassociated (or neighboring) APs), the AP can advertise scheduling information for coordinating R-TWT within its respective BSS via beacon frames and / or probe response frames, etc. As an example, after sending or receiving a coordination response, the AP can send the scheduling information for coordinating R-TWT by including it in the first beacon frame and / or the first probe response frame sent to the (associated) STA. In this case, the AP can use channel bitmap information along with the scheduling information for coordinating R-TWT in the beacon frame and / or probe response frame, and based on this, can instruct the STA on information regarding the channel for transmitting and receiving low-latency services during the corresponding R-TWT SP.

[0288] Figure 17 The configuration operation of the coordination request in the negotiation for coordination of R-TWT according to this disclosure is illustrated.

[0289] refer to Figure 17This describes the configuration of an AP (e.g., an associated AP) and the sending of a coordination request for coordination of R-TWT to neighboring APs (e.g., unassociated APs).

[0290] The AP can obtain the scheduling information of the neighboring AP's R-TWT (i.e., information for the R-TWT SP) (S1710). In this case, this information can be obtained by receiving (i.e., listening to) beacon frames from the neighboring AP or by direct announcement from the neighboring AP.

[0291] Upon receiving this information, the AP can determine whether there is any overlap between the R-TWT SP to be coordinated and the R-TWT SPs scheduled within its own BSS (S1720). Based on this, the AP can configure a coordination request for overlapping R-TWT SPs and send the coordination request to a neighboring AP (S1730), or it can configure a coordination request for non-overlapping R-TWT SPs and send the coordination request to a neighboring AP (S1740).

[0292] In this regard, in the case of overlapping R-TWT SPs, the AP can configure the coordination request by including information related to the AP coordination scheme that will operate at the same time as the neighboring AP. Conversely, in the case of non-overlapping R-TWT SPs, the AP can configure the coordination request by including information related to the AP coordination scheme that will operate at the same time as the neighboring AP, if necessary.

[0293] In addition, the coordination request in the above operation can be configured to additionally include one or more components described in this disclosure (e.g., one or more components described in Embodiments 2-1).

[0294] Figure 18 The configuration operation of the coordination response in the negotiation for coordination of R-TWT according to this disclosure is illustrated.

[0295] refer to Figure 18 This will describe the scenario where an AP (e.g., an unassociated AP) configures and sends a coordination response based on a coordination request from a neighboring AP (e.g., an associated AP) for coordination in R-TWT.

[0296] When an AP receives a coordination request from a neighboring AP (S1810), the AP can determine whether to approve the coordination request (S1820).

[0297] If the overlapping / non-overlapping R-TWT SPs included in the coordination request are approved as is, the AP can set the status code in the coordination response to a value corresponding to "accepted (or successful)" (S1830). In this case, when the coordination request contains information from the receiving AP request (e.g., information related to the AP coordination technique in the case of overlapping R-TWT SPs), the AP can configure the coordination response by additionally including the related information and send the configured coordination response to the AP that sent the coordination request (S1870).

[0298] Conversely, when rejecting overlapping / non-overlapping R-TWT SPs included in the coordination request, the AP can determine whether to include information related to the recommended / suggested coordination SP along with the rejection (S1840). If it is determined that the information is not included, the AP can set the status code in the coordination response to a value corresponding to "rejection (or failure)" (S1850). On the other hand, if it is determined that the information is included, the AP can set the status code in the coordination response to a value corresponding to "rejection including recommended SP" (S1860). In this case, the AP can configure the coordination response by including information related to the recommended R-TWT SP and send the configured coordination response to the AP that sent the coordination request (S1870).

[0299] In addition, the coordination response in the above operation can be configured to additionally include one or more components described in this disclosure (e.g., the components described in embodiments 2-2).

[0300] Implementation Method 3

[0301] This disclosure relates to the transmission or reception of channel access parameters used between access points for coordinating service periods.

[0302] In existing WLAN systems, channel access parameters for non-AP STAs associated with an AP can be provided or updated by the AP. For example, channel access parameters may include an EDCA parameter set or a multi-user (MU) EDCA parameter set. Such EDCA parameter set elements and / or MU EDCA parameter set elements can be provided to the STA from the AP via beacon frames, probe response frames, (re)association response frames, etc. Therefore, non-AP STAs can perform channel access based on the channel access parameters configured / updated by the AP.

[0303] In existing WLAN systems, an AP can perform channel access based on its own channel access parameters without sharing these parameters with other APs and / or non-AP STAs. Alternatively, in existing WLAN systems, an AP does not need to share its own channel access parameters or the channel access parameters applied to its associated STAs with other APs.

[0304] In coordinated service periods (e.g., coordinated R-TWT SPs) between the same APs as described in the above embodiments, fairness of channel access opportunities may not be guaranteed when different APs perform channel access based on their own (independent) channel access parameters. Therefore, this disclosure describes a novel scheme for sharing or negotiating channel access parameters among APs (which are not shared with other APs / STAs).

[0305] For example, in the exchange of coordination requests and responses between APs in the above embodiments, information on channel access parameters can be shared or negotiated. For instance, channel access parameters may include the channel access parameters of the AP and / or the channel access parameters of the STA associated with the AP.

[0306] Figure 19 This is a diagram illustrating an operational example of the first AP according to this disclosure.

[0307] In step S1910, the first AP may send a first frame including the first channel access parameter set to the second AP.

[0308] The first channel access parameter set may include at least one channel access parameter that the first AP intends to use or requests to use during a specific service period (SP). For example, the channel access parameter set may include an EDCA parameter set. For example, a specific SP may correspond to the overlapping time period of an R-TWT SP for the first AP and an R-TWT SP for the second AP, and may be included in or may include the overlapping time period.

[0309] In step S1920, the first AP can receive a second frame in response to the first frame from the second AP.

[0310] When the second frame includes information indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set can be used by the first AP for channel access during a specific SP. Additionally, the first channel access parameter set can be used by the second AP for channel access during a specific SP.

[0311] Alternatively, when the second frame includes information indicating that a second channel access parameter set different from the first channel access parameter set is suggested or recommended by the second AP (or information indicating that the second channel access parameter set is suggested / recommended while rejecting the first channel access parameter set), the second channel access parameter set can be used by the first AP for channel access during a specific SP. Additionally, the second channel access parameter set can be used by the second AP for channel access during a specific SP. After the first AP provides an additional frame to the second AP in response to the second frame, including information confirming the use of the second channel access parameters, the first AP and / or the second AP can apply the second channel access parameter set.

[0312] Alternatively, when the second frame includes information indicating that the first channel access parameter set is rejected by the second AP, the first AP may send a third frame including a third channel access parameter set to the second AP. A fourth frame in response to the third frame may include information indicating that the third channel access parameter set is accepted or rejected by the second AP, or information suggesting / recommending a fourth channel access parameter set (and a fourth channel access parameter set). Accordingly, based on the third or fourth channel access parameter set, the first AP and the second AP may perform channel access in a specific SP.

[0313] That is, based on the same set of channel access parameters, the first AP and the second AP can perform channel access during a specific SP. In this way, the set of channel access parameters applied during a specific SP can be referred to as the coordinated channel access parameter set. The coordinated channel access parameter set may include a set of channel access parameters for APs (e.g., the first AP and / or the second AP) and / or a set of channel parameters for STAs (e.g., the first STA associated with the first AP and / or the second STA associated with the second AP).

[0314] The channel access parameter set for the STA, included in the coordinated channel access parameter set, can be delivered / announced from the first AP to the first STA associated with the first AP, and / or can be delivered / announced from the second AP to the second STA associated with the second AP. Accordingly, based on the delivered channel access parameter set for the STA, the first STA and / or the second STA can perform channel access during a specific SP.

[0315] Additionally or alternatively, the coordinated channel access parameter set may include a channel access parameter set for the AP, but may not include a channel access parameter set for the STA. In this case, a specific SP may be configured as a trigger-enabled SP for the first STA and / or the second STA. For example, the first STA associated with the first AP and / or the second STA associated with the second AP may not arbitrarily perform channel access in a specific SP configured as a trigger-enabled SP, and may perform channel access only based on a trigger from the first AP or the second AP.

[0316] Additionally or alternatively, the value of the Transmission Opportunity Limit (TXOP Limit) field can be set identically in both the channel access parameter set for the AP and the channel access parameter set for the STA, which are included in the coordinated channel access parameter set.

[0317] The set of coordinated channel access parameters applied to the first AP, second AP, first STA, and / or second STA during a specific SP may include at least one channel access parameter that is different from (or independent of) the set of channel access parameters applied to the first AP, second AP, first STA, and / or second STA during a period excluding the specific SP. That is, some / all parameters may be the same or different in the set of coordinated channel access parameters applied to the specific SP and in the (general) set of channel access parameters applied at other times.

[0318] The first or third frame described above may be related to the coordination request described in other embodiments. The second or fourth frame may be related to the coordination response described in other embodiments.

[0319] Figure 19 The methods described in the examples can be derived from... Figure 1 The first device (100) is executed. For example, Figure 1 At least one processor (102) of the first device (100) can be configured to transmit a first frame including a first channel access parameter set from the first device (100) to another device (e.g., a second device (200) on the second AP side) via at least one transceiver (106), and to receive a second frame in response to the first frame from the other device (e.g., a second device (200) on the second AP side) via at least one transceiver. Furthermore, at least one memory (104) of the first device (100) can store data executed when performed by at least one processor (102). Figure 19 The methods described in the examples or the instructions in the examples described below.

[0320] Figure 20 This is a diagram illustrating an operational example of the second AP according to this disclosure.

[0321] In step S2010, the second AP can receive a first frame including a first channel access parameter set from the first AP.

[0322] In step S2020, the second AP may send a second frame in response to the first frame to the first AP.

[0323] Therefore, through the exchange of first and second frames between the first and second APs (and additionally, a third frame received from the first AP when the second AP sends a second frame including information indicating rejection of the first channel access parameter set), information can be shared / negotiated such as... Figure 19 The example describes a coordinated channel access parameter set (e.g., a first channel access parameter set, a second channel access parameter set, or a third channel access parameter set). Therefore, a first AP, a first STA associated with the first AP, a second AP, and / or a second STA associated with the second AP can perform channel access during a specific SP.

[0324] in addition, Figure 20 The example provides a detailed description of the characteristics of a specific SP's (coordinated) channel access parameter set. Figure 19 The same as in the example, so repeated descriptions are omitted.

[0325] Figure 20 The methods described in the examples can be derived from... Figure 1 The second device (200) performs the operation. For example, Figure 1 At least one processor (202) of the second device (200) can be configured to receive a first frame including a first channel access parameter set from another device (e.g., the device (100) on the first AP side) via at least one transceiver (206); and to send a second frame in response to the first frame to the other device (e.g., the device (100) on the first AP side) via at least one transceiver (206). Furthermore, at least one memory (204) of the second device (200) can store data executed when performed by at least one processor (202). Figure 20 The methods described in the examples or the instructions in the examples described below.

[0326] exist Figure 19 and Figure 20 In the example, from the perspective of the first STA associated with the first AP, the second AP corresponds to a neighboring AP or overlapping BSS that the first STA is not associated with. Similarly, from the perspective of the second STA associated with the second AP, the first AP corresponds to a neighboring AP or overlapping BSS that the second STA is not associated with. Furthermore, it is assumed that the first AP and the second AP belong to different BSSs.

[0327] Figure 19 and Figure 20 Examples may correspond to some of the various examples in this disclosure. The following will describe, in more detail, examples including... Figure 19 and Figure 20 Examples of various examples disclosed herein.

[0328] In the embodiments described below, examples of this disclosure are described by assuming that two APs are neighbors or have (partially) overlapping BSSs, but the scope of this disclosure is not limited thereto, and examples of this disclosure can be equivalently applied to the set of channel access parameters applied in a coordinated service period among three or more APs / BSSs.

[0329] Figure 21 This is a diagram illustrating an example of an AP (Advanced Programming Notice) issued for (non-)overlapping coordination R-TWT SPs in accordance with this disclosure.

[0330] In this disclosure, when a second AP can receive beacon frames sent by a first AP, and / or when a first AP can receive beacon frames sent by a second AP, the first AP and the second AP correspond to each other as neighboring APs. An AP can perform a process with its neighboring APs to obtain a coordinated R-TWT SP.

[0331] exist Figure 21 In the example, the AP can send a coordination request to its neighboring AP, including information related to the R-TWT SP to be agreed upon / negotiated. The neighboring AP can then send a coordination response based on the received coordination request, including information such as a status code. The value of the status code included in the coordination response determines whether the coordinated R-TWT SP has been obtained. When the status code included in the coordination request sent by the neighboring AP has a value corresponding to success / acceptance, both the AP and the neighboring AP can obtain the coordinated R-TWT SP. Alternatively, the neighboring AP can send a coordination response including new / modified information regarding the R-TWT SP, with a status code indicating the new / modified information. Therefore, the information related to the R-TWT SP can be determined based on the negotiation / agreement between the AP and the neighboring AP, and the coordinated R-TWT SP can be obtained.

[0332] The information obtained as described above regarding the coordinated R-TWT SP can be announced by the AP to the STA associated with that AP, and can also be announced by the neighboring AP to the STA associated with that neighboring AP.

[0333] Implementation Method 3-1

[0334] This implementation relates to the EDCA parameter set of a coordinated AP included in the coordinated channel access parameter set.

[0335] During the process of obtaining the coordinated R-TWT SP described above, the AP and / or neighboring APs may include information about the EDCA parameter set of the AP to be agreed upon / negotiated in the coordination request and / or coordination response. Compared to the EDCA parameter set of STAs configured and advertised by the AP in existing WLAN systems, the AP's EDCA parameter set is configured and applied by the AP itself, and therefore does not need to be shared with another AP / STA. During the process of configuring the coordinated R-TWT SP among APs applying this disclosure, in order to ensure uniform and fair channel access among APs in overlapping coordinated R-TWT SPs, the EDCA parameter set can be shared among APs. For example, an AP may share information about its own configured AP EDCA parameter set with neighboring APs during the configuration of the coordinated R-TWT SP. Subsequently, to balance channel access among APs, the EDCA parameter set can be negotiated among APs.

[0336] When a neighboring AP agrees to the AP's EDCA parameter set included in the coordination request, the status code included in the coordination response can be set to a value indicating success / acceptance. In this document, the information regarding the agreed-upon AP's EDCA parameter set can be referred to as the coordinating AP's EDCA parameter set. Alternatively, when a neighboring AP disagrees with the AP's EDCA parameter set included in the coordination request, the status code included in the coordination response can be set to a value indicating rejection (e.g., when rejecting the coordination request itself), can be set to a value indicating rejection of the AP's EDCA parameter set, or can be set to a value indicating that a recommendation / recommendation exists alongside the rejection.

[0337] When an AP and a neighboring AP obtain the coordinated R-TWT SP and the EDCA parameter set of the coordinating AP, the AP and the neighboring AP can perform channel access (e.g., obtain TXOP by random backoff attempt) based on the information of the EDCA parameter set of the coordinating AP during at least one time period in the coordinated R-TWT SP.

[0338] When APs attempt channel access based on different EDCA parameters in a coordinated R-TWT SP, one AP (e.g., an AP with favorable parameter values, such as those associated with shorter backoff counts) may monopolize the TXOP. According to this disclosure, when the same EDCA parameters configured through agreement / negotiation between APs are applied to APs for channel access in a coordinated R-TWT SP, it is possible to prevent one AP from monopolizing the TXOP when APs perform channel access in overlapping coordinated R-TWT SPs.

[0339] Implementation Method 3-2

[0340] This implementation relates to a parameter set of a coordinated STA, which is included in the coordinated channel access parameter set.

[0341] During the process of obtaining the coordinated R-TWT SP, the AP and / or neighboring APs may include information about the EDCA parameter set of the STA to be agreed upon / negotiated in the coordination request and / or coordination response.

[0342] When a neighboring AP agrees to the STA's EDCA parameter set included in the coordination request, the status code included in the coordination response can be set to a value indicating success / acceptance. In this document, the information regarding the agreed-upon STA's EDCA parameter set can be referred to as the Coordinating STA's EDCA Parameter Set. Alternatively, when a neighboring AP disagrees with the STA's EDCA parameter set included in the coordination request, the status code included in the coordination response can be set to a value indicating rejection (e.g., when rejecting the coordination request itself), can be set to a value indicating rejection of the STA's EDCA parameter set, or can be set to a value indicating that a recommendation / recommendation exists alongside the rejection.

[0343] When an AP and its neighboring APs obtain the EDCA parameter sets for the coordinated R-TWT SP and the coordinated STA, they can advertise the coordinated STA's EDCA parameter sets to their respective associated STAs. During at least one time period in the coordinated R-TWT SP, a STA can perform channel access (e.g., obtain a TXOP through a random backoff attempt) based on the information in the coordinated STA's EDCA parameter set. That is, the coordinated STA's EDCA parameter set can be applied only within the coordinated R-TWT SP.

[0344] Therefore, an AP can notify its associated STAs, either separately or in a distinct manner, of the existing (general) EDCA parameter set of the STA to be used outside the Harmonized R-TWT SP and the EDCA parameter set of the Harmonized STA to be used in the Harmonized R-TWT SP. For example, the values ​​of some or all parameters in the (general) EDCA parameter set of the STA and the EDCA parameter set of the Harmonized STA may be the same or may be different.

[0345] The AP may include information about the set of EDCA parameters of the coordinating STA to be used in the coordinating R-TWT SP in its response to a request (e.g., a TWT request frame) sent by an associated STA requesting to join the coordinating R-TWT SP.

[0346] When STAs attempt channel access in a coordinated R-TWT SP based on different EDCA parameters, some STAs (e.g., those with favorable parameter values, such as those associated with shorter backoff counts) may monopolize the TXOP. According to this disclosure, when the same EDCA parameters, configured through agreement / negotiation between APs, are applied to STAs for channel access in a coordinated R-TWT SP, this situation of some STAs monopolizing the TXOP when STAs perform channel access in overlapping coordinated R-TWT SPs can be prevented.

[0347] Implementation Method 3-3

[0348] This implementation relates to a situation where the coordinated channel access parameter set includes the EDCA parameter set of the coordinated AP but excludes the parameter set of the coordinated STA.

[0349] For example, in the process of obtaining the coordinated R-TWT SP described above, the AP and / or neighboring AP may include information about the EDCA parameter set of the AP to be agreed upon / negotiated in the coordination request, but may not include information about the EDCA parameter set of the STA in the coordination request and / or coordination response.

[0350] Channel access based on the EDCA parameter set of a coordinated AP and channel access based on the EDCA parameter set of a non-coordinated STA (i.e., the EDCA parameter set of a general STA) may be disadvantageous for the AP compared to the STA in coordinated R-TWT SP.

[0351] With this in mind, in a coordinated R-TWT SP, a STA can perform channel access based on a trigger from an AP (i.e., without backing up arbitrary channel access attempts). For this purpose, a coordinated R-TWT SP can be configured / agreed between APs to enable triggered R-TWT SPs.

[0352] That is, by setting the trigger field in the broadcast TWT parameter set field, which includes information about the R-TWT SP in the coordination request, to a specific value (e.g., 1), one or more trigger frames can be instructed to be sent in the corresponding R-TWT SP. Therefore, a STA that is a member of a coordinated R-TWT SP configured / agreed to enable triggering cannot arbitrarily attempt channel access. In other words, if the EDCA parameter set of the coordinating STA is not agreed upon / negotiated during the acquisition of the coordinated R-TWT SP, the AP can agree / negotiate the corresponding coordinated R-TWT SP as an R-TWT with triggering enabled, and when the corresponding coordinated R-TWT SP begins, the STA can wait for the AP's triggering and perform trigger-based channel access.

[0353] Implementation methods 3-4

[0354] This implementation relates to the TXOP restriction field in the coordinated channel access parameter set. The TXOP restriction field can be included in the EDCA parameter set of the coordinated AP and the EDCA parameter set of the coordinated STA.

[0355] During the process of obtaining a coordinated R-TWT SP, the AP and the neighboring AP may set the value of the TXOP limit field in the AP's EDCA parameter set (hereinafter, the coordinated AP's TXOP limit field) to the same value as the value of the TXOP limit field in the STA's EDCA parameter set (hereinafter, the coordinated STA's TXOP limit field), which is agreed upon / negotiated by including it in the coordination request and / or coordination response.

[0356] When the values ​​of the TXOP limit field of the coordinating AP and the coordinating STA are not agreed upon / negotiated in the same way, a particular AP or STA may obtain a relatively long TXOP in an overlapping coordinated R-TWT SP. Therefore, another AP and / or STA may be at a disadvantage when performing channel access or obtaining TXOP in an overlapping coordinated R-TWT SP.

[0357] When the value of the TXOP limit field of the coordinating AP is agreed upon / negotiated in the same way as the value of the TXOP limit field of the coordinating STA, it can prevent a particular AP or a particular STA from getting an excessively long TXOP in an overlapping coordinating R-TWT SP.

[0358] Implementation methods 3-5

[0359] This implementation relates to specific examples of parameters included in the EDCA parameter set of the coordinating AP and / or the EDCA parameter set of the coordinating STA. Such parameters may be included in the coordination request and / or coordination response.

[0360] For example, the EDCA parameter set of a coordinating AP can be configured based on the EDCA parameter set elements of the AP that sends the coordination request or the AP that sends the coordination response.

[0361] For example, the EDCA parameter set of a coordinating STA can be configured based on the EDCA parameter set elements of the STA associated with the AP that sends the coordination request or the EDCA parameter set elements of the STA associated with the AP that sends the coordination response.

[0362] Table 1 exemplarily illustrates parameters that may be included in the EDCA parameter set of the coordinated AP and / or the EDCA parameter set of the coordinated STA. At least one parameter described in Table 1 may be included in the EDCA parameter set of the coordinated AP and / or the EDCA parameter set of the coordinated STA. The scope of this disclosure does not preclude the inclusion of additional parameters not described in Table 1 in the EDCA parameter set of the coordinated AP and / or the EDCA parameter set of the coordinated STA.

[0363] [Table 1]

[0364] In existing WLAN systems, where AP channel access parameters are not shared or negotiated with other APs / STAs, this disclosure provides a novel scheme for sharing or negotiating AP channel access parameters and / or STA channel access parameters applied during coordinated service periods between APs and / or STAs. For example, by having the AP and / or the STA associated with the AP operate according to the same channel access parameters during coordinated service periods, a new effect of implementing fair channel access for the AP can be achieved.

[0365] The above embodiments combine the elements and features of this disclosure in a predetermined form. Unless otherwise expressly stated, each element or feature should be considered optional. Each element or feature may be implemented without being combined with other elements or features. Furthermore, embodiments of this disclosure may include combinations of some elements and / or features. The order of operations described in embodiments of this disclosure may be changed. Some elements or features of one embodiment may be included in other embodiments, or may be replaced by corresponding elements or features of other embodiments. Obviously, embodiments may include claims that are not explicitly referenced in the claims, or may be included as new claims after the application has been amended.

[0366] It will be apparent to those skilled in the art that this disclosure may be implemented in other specific forms without departing from its essential characteristics. Therefore, the above detailed description should not be construed as restrictive in every respect, but rather as illustrative. The scope of this disclosure should be determined by a reasonable interpretation of the appended claims, and all variations within the equivalent scope of this disclosure are included within its scope.

[0367] The scope of this disclosure includes software or machine-executable commands (e.g., operating systems, applications, firmware, programs, etc.) that operate in a device or computer according to methods of various embodiments, as well as non-transitory computer-readable media that cause software or commands to be stored and executable in a device or computer. Commands that can be used to program a processing system to perform the features described in this disclosure can be stored in a storage medium or a computer-readable storage medium, and the features described in this disclosure can be implemented by using a computer program product including such a 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 storage devices, and may include non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory may optionally include one or more storage devices located remotely from the processor. The memory, or alternatively, the non-volatile memory devices in the memory include non-transitory computer-readable storage media. The features described in this disclosure can be stored in any machine-readable medium to control the hardware of a processing system and can be integrated into software and / or firmware that allows the processing system to interact with other mechanisms using the results of 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.

[0368] Industrial applicability

[0369] The method presented in this disclosure is primarily described based on examples applied to IEEE 802.11-based systems (5G systems), but can be applied to various WLAN or wireless communication systems other than IEEE 802.11-based systems.

Claims

1. A method, the method comprising: A first frame is sent from the first access point (AP) to the second AP. The first frame includes a first channel access parameter set. as well as The first AP receives a second frame in response to the first frame from the second AP. Wherein, based on the information in the second frame indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set is applied to the channel access of the first AP and the second AP during a specific service period SP.

2. The method according to claim 1, in, Based on the information included in the second frame indicating that the second channel access parameter set is suggested or recommended, the second channel access parameter set is included in the second frame, and During the specific SP, the second channel access parameter set is applied to the channel access of the first AP and the second AP.

3. The method according to claim 2, in, The first channel access parameter set or the second channel access parameter set includes at least one of the following: a channel access parameter set for an AP, or a channel parameter set for a station STA.

4. The method according to claim 3, in, The channel access parameters for the STA are delivered by the first AP to at least one STA associated with the first AP, and by the second AP to at least one STA associated with the second AP.

5. The method according to claim 2, in, Based on the first channel access parameter set or the second channel access parameter set including a channel access parameter set for the AP but excluding a channel parameter set for the STA: Configure the specific SP as a trigger-enabled SP.

6. The method according to claim 5, in, At least one of the at least one STA associated with the first AP or at least one STA associated with the second AP performs channel access in the specific SP based on a trigger from the first AP or the second AP.

7. The method according to claim 3, in, The value of the Transmission Opportunity Limit (TXOP) field, included in the channel access parameter set for the AP, is set identically to the value of the Transmission Opportunity Limit field, included in the channel parameter set for the STA.

8. The method according to claim 1, in, The specific SP corresponds to the overlapping time period between the restricted target wake-up time R-TWTSP used for the first AP and the R-TWT SP used for the second AP.

9. The method according to claim 1, in, The first frame is related to the coordination request, and The second frame is related to the coordination response.

10. The method according to claim 1, in, Based on the information in the second frame indicating that the first channel access parameter set is rejected, a third frame including a third channel access parameter set is sent from the first STA to the second STA.

11. The method according to claim 10, in, Based on information in a fourth frame responding to the third frame indicating that the third channel access parameter set is accepted by the second AP, the third channel access parameter set is applied to the channel access of the first AP and the second AP during the specific SP.

12. The method according to claim 11, in, The third frame is related to the coordination request, and The fourth frame is related to the coordination response.

13. The method according to claim 1, in, The first channel access parameter set includes the Enhanced Distributed Channel Access (EDCA) parameter set.

14. The method according to claim 1, in, The first channel access parameter set includes at least one channel access parameter that is distinct from the following: The set of channel access parameters applied to the first AP at the time when the specific SP is excluded; The set of channel access parameters applied to the second AP at the time when the specific SP is excluded; The set of channel access parameters applied to the channel access of at least one STA associated with the first AP at the time when the specific SP is excluded; or The set of channel access parameters applied to the channel access of at least one STA associated with the second AP at the time when the specific SP is excluded.

15. An apparatus comprising: At least one transceiver; as well as At least one processor, said at least one processor being connected to said at least one transceiver, Wherein, the at least one processor is configured to: A first frame, comprising a first channel access parameter set, is transmitted from a first access point (AP) to a second AP via the at least one transceiver; and The at least one transceiver receives a second frame in response to the first frame from the second AP. Wherein, based on the information in the second frame indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set is applied to the channel access of the first AP and the second AP during a specific service period SP.

16. A method, the method comprising: The second access point (AP) receives a first frame from the first AP, and the first frame includes a first channel access parameter set. as well as The second AP sends a second frame in response to the first AP, which is a response to the first frame. Wherein, based on the information in the second frame indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set is applied to the channel access of the first AP and the second AP during a specific service period SP.

17. An apparatus comprising: At least one transceiver; as well as At least one processor, said at least one processor being connected to said at least one transceiver, Wherein, the at least one processor is configured to: A first frame is received from a first access point (AP) via the at least one transceiver, the first frame including a first channel access parameter set; and The second AP sends a second frame in response to the first AP via the at least one transceiver. Wherein, based on the information in the second frame indicating that the first channel access parameter set is accepted by the second AP, the first channel access parameter set is applied to the channel access of the first AP and the second AP during a specific service period SP.

18. A processing apparatus, the processing apparatus comprising: At least one processor; as well as At least one computer memory, operatively connected to the at least one processor, and storing instructions for performing the method according to any one of claims 1 to 13 based on execution by the at least one processor.

19. At least one non-transitory computer-readable medium storing at least one instruction, said at least one instruction being executed by at least one processor to control the execution of the method according to any one of claims 1 to 13.

Images