Method and apparatus for performing R-TWT related negotiation in multi-BSS environment in wireless LAN system

Abstract

Disclosed are a method and an apparatus for performing R-TWT related negotiation in a multi-BSS environment in a wireless LAN system. A method performed by a first access point (AP) in a wireless LAN system according to an embodiment of the present disclosure may comprise the steps of: performing a negotiation for coordination of a restricted TWT service period (R-TWT SP) between the first AP of a first BSS and a second AP of a second BSS, the negotiation is performed based on an exchange of a first frame for the coordination request and a second frame for the coordination response; and notifying one or more associated STAs of information about the coordination-based R-TWT SP on the basis of completion of the negotiation. Here, on the basis that the AP transmitting the first frame acquires the TSF information of the AP receiving the first frame, the SP information on R-TWT may be configured on the basis of the TSF within the first frame.

Description

Technical Field

[0001] This disclosure relates to a method and apparatus for performing negotiation related to Restricted Target Wake-up Time (R-TWT) in a multi-basic service set (multi-BSS) environment of a wireless local area network (WLAN) system. Background Technology

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

[0003] To provide a more robust wireless communication environment, enhancement technologies for EHT (Extreme High Throughput) are being discussed. For example, technologies for supporting multi-access point (AP) coordination and multiple-input multiple-output (MIMO) to increase bandwidth, effectively utilize multiple bands, and increase spatial flow are being investigated. In particular, various technologies are being explored to support low-latency or real-time services. Furthermore, new technologies to support Ultra-High Reliability (UHR) through improvements or extensions to EHT technologies 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 performing negotiation related to Restricted Target Wake-up Time (R-TWT) in a multi-BSS (Basic Service Set) environment of a wireless local area network (WLAN) system.

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

[0007] Technical solution

[0008] A method performed by a first access point (AP) in a wireless local area network (WLAN) system according to one aspect of this disclosure may include: negotiating a restricted target wake-up time (restricted TWT, R-TWT) service period (SP) between the first AP in a first basic service set (BSS) and a second AP in a second BSS; wherein the negotiation is performed based on the exchange of a first frame for a coordination request and a second frame for a coordination response; and, based on the completion of the negotiation, notifying one or more associated STAs of information for the coordinated R-TWT SP. Here, based on information obtained by the AP that sends the first frame from the timing synchronization function (TSF) of the AP that receives the first frame, the information for the R-TWT SP can be configured in the first frame based on the TSF.

[0009] A method performed by a station (STA) in a wireless local area network (WLAN) system according to an additional aspect of this disclosure may include: receiving a notification from a first AP associated with the STA, the notification including information regarding a restricted target wake-up time (restricted TWT, R-TWT) service period (SP) for coordination between the first AP based on a first basic service set (BSS) and a second AP based on a second BSS; and performing relevant operations for the R-TWT SP based on the notification. Here, coordination may be based on negotiation performed by exchanging a first frame for a coordination request and a second frame for a coordination response between the first AP and the second AP. Based on information obtained by the AP that sends the first frame from the timing synchronization function (TSF) of the AP that receives the first frame, information for the R-TWT SP may be configured in the first frame based on the TSF.

[0010] Technical effect

[0011] According to this disclosure, a method and apparatus may be provided for performing negotiation related to Restricted Target Wake-up Time (R-TWT) in a multi-BSS (Basic Service Set) environment of 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, included as part of the detailed description for understanding this disclosure, provide embodiments of the disclosure and describe the technical features of the disclosure through detailed description.

[0014] Figure 1 The figure shows a block configuration diagram of a wireless communication device according to an embodiment of the present disclosure.

[0015] Figure 2This 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 describe the link setup process to which this disclosure can be applied.

[0017] Figure 4 It is a diagram used to describe the retreat process to which this disclosure can be applied.

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

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

[0020] Figure 7 This is a diagram illustrating an example of a PPDU that can be applied in the IEEE 802.11 standard of this disclosure.

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

[0022] Figure 9 This is a diagram used to illustrate an example of a single TWT operation to which this disclosure can be applied.

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

[0024] Figure 11 This diagram illustrates the AP and STA that can be applied in the OBSS disclosed herein.

[0025] Figure 12 The illustration shows an example of a configuration for coordinated R-TWT information according to this disclosure.

[0026] Figure 13 The illustration shows an example of overlapping R-TWT service periods (SPs) according to this disclosure.

[0027] Figure 14 The illustration shows another example of an overlapping R-TWT SP according to this disclosure.

[0028] Figure 15 The illustration shows yet another example of an overlapping R-TWT SP according to this disclosure.

[0029] Figure 16 The illustration shows yet another example of an overlapping R-TWT SP according to this disclosure.

[0030] Figure 17 The diagram illustrates configuring a coordination request during negotiation to coordinate the operation of R-TWT, according to this disclosure.

[0031] Figure 18 The diagram illustrates the configuration of a coordination response during negotiation, according to this disclosure, for coordinating the operation of R-TWT.

[0032] Figure 19 The diagram illustrates the operation of a first access point (AP) based on coordination negotiation with an R-TWT SP according to this disclosure.

[0033] Figure 20 The operation of a station (STA) based on coordination negotiation for R-TWT SP is shown according to this disclosure. Detailed Implementation

[0034] In the following, embodiments according to the present 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 the present disclosure and not to represent the only embodiments in which the present disclosure may be practiced. The following detailed description includes specific details to provide a complete understanding of the present disclosure. However, those skilled in the art will recognize that the present disclosure may be practiced without these specific details.

[0035] 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 of the concepts in this disclosure.

[0036] 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 where another element exists therebetween. 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.

[0037] In this invention, 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.

[0038] 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 the embodiments and the appended claims, the singular forms are intended to include the plural forms 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”.

[0039] 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 next-generation standards-based wireless LANs 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.

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

[0041] Figure 1 The figure shows a block diagram of a wireless communication device according to an embodiment of the present disclosure.

[0042] Figure 1 The first device 100 and the second device 200 illustrated in the diagram 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 simple user, etc. Furthermore, the first device 100 and the second device 200 can 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.

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

[0044] refer to 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.

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

[0046] 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 processor 102 may control the memory 104 and / or the transceiver 106 and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor 102 may transmit a wireless signal including the first information / signal via the transceiver 106 after generating first information / signal by processing information in the memory 104. Additionally, the processor 102 may receive a wireless signal including a second information / signal via the transceiver 106, and then store information obtained through signal processing of the second information / signal in the memory 104. The memory 104 may be connected to the processor 102 and may store various information relating to the operation of the processor 102. For example, the memory 104 may store software code including instructions for performing all or part of the processes controlled by the processor 102 or for performing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. Here, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement wireless LAN technologies (e.g., LTE 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, "device" may refer to a communication modem / circuit / chip.

[0047] 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 processor 202 may control the memory 204 and / or the transceiver 206 and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure. For example, the processor 202 may generate third information / signals by processing information in the memory 204, and then transmit a wireless signal including the third information / signals via the transceiver 206. Additionally, the processor 202 may receive wireless signals including fourth information / signals via the transceiver 206, and then store information obtained through signal processing of the fourth information / signals in the memory 204. The memory 204 may be connected to the processor 202 and may store various information related to the operation of the processor 202. For example, the memory 204 may store software code including instructions for performing all or part of the processes controlled by the processor 202 or for performing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure. Here, processor 202 and memory 204 may be part of a communication modem / circuit / chip designed to implement wireless LAN technologies (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, "device" may refer to a communication modem / circuit / chip.

[0048] The hardware components of devices 100 and 200 will be described in more detail below. However, they are not limited thereto, but 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, proposals, 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, proposals, 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, proposals, 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 descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure.

[0049] 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. In examples, 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, proposals, 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, proposals, 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, proposals, methods, and / or operation flowcharts included in this invention may be implemented by firmware or software in the form of code, commands, and / or command sets.

[0050] One or more memories 104, 204 may be connected to one or more processors 102, 202 and are capable of storing 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.

[0051] 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, proposals, 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. Furthermore, 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. Furthermore, one or more transceivers 106, 206 may be connected to one or more antennas 108, 208, and the 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, proposals, methods, and / or operation flowcharts included in this disclosure via one or more antennas 108, 208. In this invention, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). The one or more transceivers 106, 206 may process the received wireless signals / channels, etc., by converting them from RF band signals to baseband signals using one or more processors 102, 202. The one or more transceivers 106, 206 may convert the user data, control information, wireless signals / channels, etc., processed by using one or more processors 102, 202 from baseband signals to RF band signals. Therefore, the one or more transceivers 106, 206 may include (analog) oscillators and / or filters.

[0052] 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. 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). Furthermore, in this disclosure, the operations of generating transmit / receive signals or performing data processing or calculations on transmit / receive signals in advance by various STAs can be performed by… Figure 1 Processors 102 and 202 perform the following operations: For example, examples of generating transmit / receive signals or performing data processing or calculations on transmit / receive signals in advance may include 1) determining / acquiring / configuring / calculating / 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 resources 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; and 5) operations related to determining / acquiring / configuring / calculating / encoding the ACK signal. Additionally, in the following examples, various information used by various 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.

[0053] 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 PPDUs / 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 PPDUs / 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.

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

[0055] A wireless LAN system can be structured by multiple components. Wireless LANs that support STA mobility transparent to upper layers can be provided through the interaction of these components. The Basic Services 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 are included as members of each BSS (STA1 and STA2 are included in BSS1, and STA3 and STA4 are included in BSS2). Figure 2 The 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 out of the BSA, it cannot directly communicate with other STAs within the BSA.

[0056] If we do not consider Figure 2 The DS shown represents the most basic type of BSS in a wireless LAN, which is 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 when a LAN is needed, and this can be called a self-organizing network. Because 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.

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

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

[0059] DS refers to the interconnected structure of BSSs. 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 by the characteristics of the Distributed System Medium (DSM). In this respect, 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. Thus, the flexibility of wireless LAN architectures (DS architectures or other network architectures) can be interpreted as multiple media being logically different. That is, wireless LAN architectures can be implemented in various ways, and the corresponding wireless LAN architectures can be independently specified by the physical characteristics of each embodiment.

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

[0061] An AP enables access to a DS via WM for its associated non-AP STA, and this implies an entity that also functions as a STA. Data movement between the BSS and DS can be performed through the AP. For example, Figure 2 STA2 and STA3, as shown, possess 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 an AP for communication on the DSM. A BSS consisting of APs and one or more STAs can be referred to as an infrastructure BSS.

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

[0063] In addition to the DS structure described above, an Extended Service Set (ESS) can be configured to provide broad coverage.

[0064] 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 by being treated as an IBSS (Independent Service Set Service) within the Logical Link Control (LLC) layer. STAs included in an ESS can communicate with each other, and a mobile STA can move from one BSS to another BSS (within the same ESS), which is transparent to the LLC. APs included in an ESS can have the same Service Set Identity (SSID). The SSID is distinct from the BSSID, which is the identifier of the BSS.

[0065] Wireless LAN systems do not assume anything about the relative physical location of BSSs, and all of the following forms are possible. BSSs can partially overlap, which is a common form used to provide continuous coverage. Additionally, BSSs may not have physical connections, and logically, there is no limit to the distance between BSSs. Furthermore, BSSs may 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 be analogous to the form corresponding to 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.

[0066] Figure 3 This is a diagram used to explain the link setup process to which this disclosure can be applied.

[0067] For a STA to establish a link with the network and send / receive data, the network must first be discovered, authentication performed, and association established. A security authentication process is also required. This link establishment process can also be called the session initiation process or session setup process. Furthermore, the discovery, authentication, association, and security settings within the link establishment process can be collectively referred to as the association process.

[0068] 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 the network, it needs to find networks it can participate in. Before participating in a wireless network, the STA should identify compatible networks, and the process of identifying networks present in a specific area is called scanning.

[0069] Scanning schemes include active scanning and passive scanning. Figure 3An exemplary illustration depicts a network discovery operation including an active scanning process. In an active scan, the STA performing the scan sends probe request frames while moving channels to discover which APs are present in its vicinity and awaits a response. A responder sends a probe response frame to the STA that sent the probe request frame as a response to the probe request frame. Here, the responder could be the STA that last sent a beacon frame in the BSS of the scanned channel. In the BSS, the AP becomes the responder because it sends a beacon frame, and in the IBSS, STAs in the IBSS take turns sending 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 can store the BSS-related information included in the received probe response frame and can move to the next channel (e.g., channel 2) and perform a scan in the same manner (i.e., sending / receiving probe requests / responses on channel 2).

[0070] Although Figure 3 Although not shown, scanning operations can be performed passively. In passive scanning, the STA performing the scan waits for beacon frames while moving through channels. Beacon frames are one of the management frames defined in IEEE 802.11 and are periodically sent to notify of the existence of a wireless network and allow the STA performing the scan to find and participate in the network. In a BSS, the AP periodically sends beacon frames, and in an IBSS, STAs within the IBSS take turns sending beacon frames. When a 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 the scan in the next channel in the same manner. Comparing active and passive scanning, active scanning has the advantages of lower latency and lower power consumption.

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

[0072] The authentication process includes the STA sending an authentication request frame to the AP, and in response, the AP sending an authentication response frame to the STA. The authentication frame used for the authentication request / response corresponds to the management frame.

[0073] The authentication frame includes the authentication algorithm number, authentication transaction sequence number, status code, challenge text, robust security network (RSN), and finite cycle group, etc. This corresponds to some examples of information that can be included in the authentication request / response frame, and may be replaced with other information or may include further additional information.

[0074] A STA can send an authentication request frame to an AP. The AP can determine whether to allow the corresponding STA to authenticate based on the information included in the received authentication request frame. The AP can then provide the result of the authentication process to the STA via an authentication response frame.

[0075] After successful STA authentication, the association process can be performed in step S330. The association process includes the STA sending an association request frame to the AP, and in response, the AP sending an association response frame to the STA.

[0076] 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 map broadcast requests (TIM broadcast requests), and interoperability capabilities. 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, and quality of service (QoS) maps. These correspond to examples of information that can be included in association request / response frames and may be replaced with other information or further supplementary information.

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

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

[0079] Figure 4 This is a diagram used to explain the retreat process to which this disclosure can be applied.

[0080] In wireless LAN systems, the basic access mechanism for Media Access Control (MAC) is Carrier Sense 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-speak" access mechanism. Under this type of access mechanism, the AP and / or STA can perform a sensed free channel assessment (CCA) of the wireless channel or medium within a predetermined time interval (e.g., the DCF inter-frame interval (DIFS)) before initiating transmission. As a result of the sensing, if the medium is determined to be idle, frame transmission begins through the corresponding medium. Conversely, if the medium is detected to be occupied or busy, the corresponding AP and / or STA does not initiate its own transmission and can set a delay period for medium intervention (e.g., a random backoff period) and attempt frame transmission after waiting. By applying a random backoff period, collisions can be minimized because several STAs are expected to attempt frame transmission after waiting for different time periods.

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

[0082] refer to Figure 4This section describes the operation based on a random backoff period. When a occupied / busy medium becomes idle, several STAs may attempt to transmit data (or frames). As a method to minimize collisions, each STA can individually select a random backoff count and attempt transmission 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 be doubled if a transmission failure occurs (e.g., when an ACK for a transmitted frame is not received). When the CW parameter value reaches CWmax, data transmission can be attempted while maintaining the CWmax value until successful data transmission, and the CWmin value is reset when data transmission is successful. The values ​​of CW, CWmin, and CWmax are preferably set to 2n-1 (n = 0, 1, 2, ...).

[0083] When the random backoff process begins, the STA continuously monitors the medium while counting down the backoff time slot based on the determined backoff count value. When medium occupancy is detected, it stops counting down and waits, and resumes the remaining countdown when the medium becomes free.

[0084] exist Figure 4 In the example, when the packet to be sent arrives at STA3's MAC, STA3 can send the frame immediately after confirming that the medium is free for as long as DIFS. The remaining STAs monitor and wait for the medium to be occupied / busy. Meanwhile, data to be sent may also occur in each of STA1, STA2, and STA5, and when the medium is detected as free, each STA waits for as long as DIFS, and can then count down the backoff slots according to a random backoff count value selected by each STA. Assume that STA2 chooses the minimum backoff count value, and STA1 chooses the maximum backoff count value. That is, the case where STA5's remaining backoff time is less than STA1's remaining backoff time when STA2 completes its backoff count and begins frame transmission is illustrated. STA1 and STA5 temporarily stop the countdown and wait, while STA2 occupies the medium. When STA2 finishes occupying the medium and it becomes free again, STA1 and STA5 wait for DIFS and resume the stopped backoff count. That is, after counting down the remaining backoff slots for the remaining backoff time, frame transmission can begin. Because STA5's remaining backoff time is less than STA1's, STA5 begins frame transmission. While STA2 is occupying the medium, data to be transmitted may also appear in STA4. From STA4's perspective, when the medium becomes idle, STA4 can wait for DIFS, and 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 coincides exactly with the random backoff count of STA4. In this case, a collision may occur between STA4 and STA5. When a collision occurs, neither STA4 nor STA5 receives an ACK, thus data transmission fails. In this situation, STA4 and STA5 can double their CW value, choose a random backoff count, and begin a countdown. STA1 waits while the medium is occupied due to the transmissions of STA4 and STA5, waits for DIFS when the medium becomes idle, and then begins frame transmission after the remaining backoff time has elapsed.

[0085] like Figure 4 As shown in the example, data frames are frames used to transmit data forwarded to higher layers and can be sent after a backoff following the elapsed DIFS when the medium becomes idle. Management frames are frames used to exchange management information that is not forwarded to higher layers and are sent after a backoff following an IFS such as a DIFS or a 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 send (RTS), clear send (CTS), acknowledgment (ACK), power-saving polling (PS-Poll), block ACK (BlockAck), block ACK request (BlockACKReq), empty data packet advertisement (NDP advertisement), and triggers, etc. If a control frame is not a response frame to a previous frame, it is sent after a backoff following the elapsed DIFS; if it is a response frame to a previous frame, it is sent without a backoff following the elapsed 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.

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

[0087] Figure 5 This is a diagram used to explain the CSMA / CA-based frame transmission operation to which this disclosure can be applied.

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

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

[0090] To reduce the likelihood of transmission conflicts between multiple STAs in CSMA / CA-based frame transmission operations, a mechanism using RTS / CTS frames can be applied. Figure 5 In the example, while STA1 is transmitting, as a result of STA3's carrier sensing, it can be determined that the medium is in an idle state. That is, STA1 can correspond to a hidden node of STA3. Alternatively, in Figure 5 In the example, it can be determined that the carrier sensing result medium of STA3 is idle while the transmission of STA2 is being performed. That is, STA2 can correspond to a hidden node of STA3. By exchanging RTS / CTS frames before 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 for transmissions from STA1 or STA3, can not attempt to occupy the channel during data transmission and reception between STA1 and STA2.

[0091] Specifically, STA1 can determine whether a channel is in use through carrier sensing. Regarding physical carrier sensing, STA1 can determine the channel occupancy status based on the energy level or signal correlation detected in the channel. Furthermore, regarding virtual carrier sensing, STA1 can use a network allocation vector (NAV) timer to determine the channel occupancy status.

[0092] 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.

[0093] If STA3 cannot listen to CTS frames from STA2 but can listen to RTS frames from STA1, STA3 can use the duration information included in the RTS frame to set the NAV timer for subsequent consecutive frame transmission cycles (e.g., SIFS+CTS frame+SIFS+data frame+SIFS+ACK frame). Alternatively, if STA3 can listen to CTS frames from STA2, even if STA3 cannot listen to RTS frames from STA1, STA3 can use the duration information included in the CTS frame to set the NAV timer for subsequent consecutive frame transmission cycles (e.g., SIFS+data frame+SIFS+ACK frame). That is, if STA3 can listen to one or more RTS 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 before the NAV timer expires.

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

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

[0096] Using instructions or primitives (meaning a set of instructions or parameters) from the MAC layer, the PHY layer can prepare a MAC PDU (MPDU) to be sent. For example, when it receives a command from the MAC layer requesting the PHY layer to begin transmission, the PHY layer switches to transport mode and configures the information (e.g., data) provided from the MAC layer in the form of a frame and sends it. Additionally, when the PHY layer detects a valid preamble to 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.

[0097] 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) frame format is defined.

[0098] A basic PPDU frame 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 may consist only of legacy STF (L-STF), legacy LTF (L-LTF), legacy SIG (L-SIG) fields, and a data field. Additionally, depending on the PPDU format type (e.g., HT mixed format PPDU, HT-greenfield format PPDU, VHT (very high throughput) PPDU, etc.), additional (or different types of) RL-SIG, U-SIG, non-legacy SIG fields, non-legacy STF, non-legacy LTF (i.e., xx-SIG, xx-STF, xx-LTF (e.g., xx is HT, VHT, HE, EHT, etc.)) may be included between the L-SIG field and the data field.

[0099] 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.

[0100] 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 compilation 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 HE PPDUs, the value of the length field can be determined to be a multiple of 3 + 1 or 3 + 2.

[0101] 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 in predetermined units.

[0102] 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 are transmitted / received through the PSDU in the data portion of the PPDU frame format.

[0103] 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 for transmitting the corresponding frame. For detailed information on the sequence control, QoS control, and HT control subfields of the MAC header, please refer to the IEEE 802.11 standard document.

[0104] The NDP (Narrow Data PPDU) format refers to a PPDU format that does not include the data field. In other words, NDP refers to a frame format that includes the PPDU preamble (i.e., L-STF, L-LTF, L-SIG fields and additional non-legacy SIG, non-legacy STF, and non-legacy LTF (if present)) but does not include the remaining portion (i.e., the data field) in the general PPDU frame format.

[0105] Figure 7 This is a diagram illustrating an example of a PPDU as defined in the IEEE 802.11 standard that can be applied to this disclosure.

[0106] Various types of PPDUs are 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)).

[0107] In addition to the basic PPDU format, the HT PPDU format (IEEE 802.11n) also 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-mixed format. Alternatively, an HT-greenfield format PPDU can be defined, which corresponds to a format consisting of HT-GF-STF, HT-LTF1, HT-SIG, one or more HT-LTFs and a data field, excluding L-STF, L-LTF and L-SIG (not shown).

[0108] Examples of VHT PPDU format (IEEE 802.11ac) include, in addition to the basic PPDU format, VHT SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields (e.g., Figure 7 (as shown in (c)).

[0109] Examples of HE PPDU format (IEEE 802.11ax) include, in addition to the basic PPDU format, repeated L-SIG (RL-SIG), HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF(s), and packet extension (PE) fields (such as...). Figure 7 (as shown in (d)). Based on the detailed example of the HE PPDU format, some fields may be excluded or their lengths may vary. For example, the HE-SIG-B field is included in the HE PPDU format for multi-user (MU) applications, but not in the HE PPDU format for single-user (SU) applications. Additionally, the HE trigger (TB) based PPDU format does not include HE-SIG-B, and the length of the HE-STF field may vary 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 may vary to 16µs. For example, RL-SIG can be configured to be the same as L-SIG. The receiving STA can determine whether the received PPDU is an HE PPDU or an EHT PPDU based on the presence of RL-SIG, which will be described later.

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

[0111] Figure 7In (e), the EHT MU PPDU corresponds to a PPDU that carries 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 used for one or more receiving STAs.

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

[0113] 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 legacy 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 for demodulation and decoding by an STA that has successfully decoded a non-legacy SIG (e.g., U-SIG and / or EHT-SIG) and obtained the information contained in the fields, 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.

[0114] 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 free VHT modulation fields, and the VHT STF, VHT-LTF, VHT-SIG-B, and Data fields can be referred to as VHT modulation fields.

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

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

[0117] For example, A uncompiled 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 of information, and the second symbol of U-SIG (e.g., U-SIG-2 symbol) can send the remaining Y bits of the total A bits of information. The A bits of information (e.g., 52 uncompiled 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 grid of the convolutional decoder and can be set to 0.

[0118] The bit information sent by U-SIG can be divided into version-independent bits and version-dependent bits. For example, U-SIG can be included in... Figure 7 In the new PPDU format (e.g., UHR PPDU format) not shown in the figure, and 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 may be the same, and some or all of the version-related bits may be different.

[0119] 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 bits and version-dependent bits can be referred to by various names, such as first control bits and second control bits.

[0120] For example, the version-independent bits of U-SIG may include a 3-bit Physical Layer Version Identifier (PHY Version Identifier), and this information 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.

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

[0122] The information necessary for PPDU transmission and reception can be included in the U-SIG. For example, the U-SIG may further include information about the bandwidth, information about the MCS technique applied to the non-legacy SIG (e.g., EHT-SIG or UHR-SIG), an indication of whether DCM (dual-carrier modulation) technique (e.g., a technique that achieves a frequency diversity-like effect by repeating the same signal on two subcarriers) is applied to the non-legacy SIG, information about the number of symbols used for the non-legacy SIG, and the generation of the non-legacy SIG across the entire band.

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

[0124] A preamble can refer to the transmission of a PPDU in which 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) can be defined as 20MHz, 40MHz, etc. For example, a preamble can be applied to a PPDU of a predetermined size or larger bandwidth.

[0125] exist Figure 7In the examples, non-legacy SIGs such as HE-SIG-B and EHT-SIG can include control information for receiving STAs. Non-legacy 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.).

[0126] Non-legacy SIGs such as HE-SIG-B and EHT-SIG can include public fields and user-specific fields. Public fields and user-specific fields can be compiled separately.

[0127] In some cases, the common field can be omitted. For example, in compressed mode using non-OFDMA (Orthogonal Frequency 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.

[0128] 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.

[0129] The common fields may include CRC bits and tail bits, where the length of the CRC bits can be determined to be 4 bits, and the length of the tail bits 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).

[0130] 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-legacy STFs, non-legacy LTFs, and data fields.

[0131] The appropriate RU size can be defined based on the PPDU bandwidth. For the applied PPDU format (e.g., HE PPDU, EHT PPDU, UHR PPDU, etc.), the RUs can be defined the same or different. For example, in the case of an 80MHz PPDU, the RU placement for HEPPDU and EHT PPDU may differ. The applicable RU size, number and location, DC (direct current) subcarrier location and number, empty subcarrier location and number, guard subcarrier location and number, 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.

[0132] 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. An MRU (multiple RUs) is distinguished from multiple individual RUs and corresponds 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 continuous or non-contiguous in the frequency domain.

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

[0134] Figure 7 The names of each field in the PPDU format are exemplary, and the scope of this disclosure is not limited to the names. Furthermore, the examples in this disclosure can be applied to... Figure 7 The PPDU format illustrated in the figure, and its application in... Figure 7 The PPDU format excludes some fields and / or adds some fields to the new PPDU format.

[0135] Multiple Access Point (MAP) Operation

[0136] Examples of this disclosure for multi-access point (MAP) operation will be described below.

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

[0138] The master AP initiates and controls MAP operations to transmit or receive 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 with the slave APs and the STAs associated with those BSSs.

[0139] A slave AP can be associated with the master AP and share control information, management information, and data services. The slave AP performs the basic functions of the master AP and can establish a BSS in the same way within the wireless LAN.

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

[0141] 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. Slave APs (e.g., a slave AP associated with an STA) can perform direct transmission or reception with the STA. One of the slave APs can become the master AP.

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

[0143] Figure 8 It is a diagram used to describe various transmitting or receiving technologies that can be applied in a MAP environment according to this disclosure.

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

[0145] 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 8In the C-OFDMA method of (b), AP1 can perform transmission to STA1 in the first bandwidth, and AP2 can simultaneously perform transmission 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 of AP2 and / or STA2 when performing a transmission to STA1, and AP2 nulls the interference of AP1 and / or STA1 when performing a transmission to STA2. Figure 8 (d) illustrates the AP selection method, where the AP with good channel conditions among adjacent APs performs the transmission. For example... Figure 8 As in the example in (e), multiple APs can be applied to cooperate to perform joint transmission (JTX) or joint reception (JRX) simultaneously, and joint MU-MIMO can also be supported.

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

[0147] 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).

[0148] 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.

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

[0150] When the resources distributed among APs are frequency resources, it can correspond to the C-OFDMA method; when it is a time resource, it can correspond to the C-TDMA technique; and when it is a spatial resource (or beam), it can correspond to the CBF method. In the examples described below, the description is representatively based on the assumption of performing C-OFDMA (i.e., multi-AP operation with 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 with resources differentiated in another domain (e.g., the time domain and / or the spatial domain).

[0151] Target wake-up time (TWT)

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

[0153] TWT is a power saving (PS) technology 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. STAs that perform requests / suggestions / demands during the TWT setup process are called TWT requesting STAs. Similarly, APs that respond to requests such as accept / reject are called TWT responding STAs. The setup process may include the AP's TWT request to the STA, the type of TWT operation to be performed, and the procedure for determining / defining the type of frames to be sent or received. TWT operations can be categorized as single TWTs and broadcast TWTs.

[0154] Figure 9 This is a diagram used to illustrate an example of a single TWT operation to which this disclosure can be applied.

[0155] A single TWT is a mechanism by which the AP and non-AP STAs exchange data after negotiating the wake-up / sleep state of the non-AP STA by sending or receiving TWT request / response frames. Figure 9 In the example, AP and STA1 can form an enabled triggered TWT protocol using TWT request frames and TWT response frames. Here, the method used by STA1 is the solicited TWT method, which is a method where 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, which performs the unsolicited TWT method, can receive information about the enabled triggered TWT protocol configuration from AP via the unsolicited TWT response. Specifically, STA2 can calculate the next TWT by adding a specific number from the current TWT value. During the enabled 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-Poll frame. Furthermore, 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 frames in the form of TB PPDU. The AP that confirms the status of STA1 and STA can send a DL MU PPDU to wake up the STA. When the corresponding TWT SP expires, STA1 and STA2 can switch to sleep mode.

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

[0157] A broadcast TWT is a TWT that a non-AP STA (or a TWT-scheduled STA) obtains information such as the Target Beacon Transmission Time (TBTT) and listening interval by sending or receiving TWT request / response frames with the AP (or the TWT-scheduled STA). Here, negotiation operations for the TBTT can be performed. Based on this, the AP can define frames that will include the TWT scheduling information via beacon frames. Figure 10 In a broadcast TWT, STA1 performs the solicited TWT operation, while STA2 performs the unsolicited 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 may be the same process as for a single TWT. In a broadcast TWT, the trigger-enabled TWT SP, including the beacon frame, can be repeated several times at specific intervals.

[0158] TWT messages can be transmitted using TWT message frames and TWT message elements.

[0159] 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 with the proliferation of multimedia devices, the need to support this in wireless environments has increased. 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 within the Industrial Science and Medicine (ISM) band, making it relatively more difficult to support latency-sensitive services compared to cellular communication networks based on radio resource scheduling via a central base station. This disclosure describes a novel method for supporting latency-sensitive services in WLAN systems.

[0160] 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 until the transmission of the transmitting STA is successfully completed in the PHY layer after the frame enters the queue of the MAC layer to be sent to the transmitting STA, and the corresponding frame is removed from the queue of the transmitting STA's MAC layer after the transmitting STA receives the 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.

[0161] Because the AP configures a special broadcast TWT for low-latency STAs transmitting latency-sensitive data, a restricted TWT (restricted TWT, r-TWT) can prioritize data transmission for low-latency STAs over other STAs. STAs can establish membership for at least one r-TWT scheduler for the AP. Here, the r-TWT protocol can be established through the same process as the broadcast TWT protocol, 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 setting fields. In other words, the r-TWT parameter set field can correspond to a special case of the broadcast TWT parameter setting field. Furthermore, the AP can advertise r-TWT SPs.

[0162] 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 advertised 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.

[0163] In this disclosure, as described above, a low-latency STA associated with a specific r-TWT is referred to as a member r-TWT scheduling STA, and 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.

[0164] A STA (e.g., a low-latency STA) that supports restricted SP (or r-TWT SP) operation for broadcast TWT can notify the AP that it must send latency-sensitive data based on r-TWT operation. If the AP supports r-TWT operation / mode, 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 an r-TWT operation, 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 used for broadcast, advertising, and announcements).

[0165] Based on restricted TWT operations, a separate TXOP (i.e., restricting access to other STAs) can be ensured within an r-TWT SP by using NAVs, such as (MU)RTS / CTS or CTS-to-self, or silent intervals. Before a specific r-TWT SP starts, if a TXOP exists for another STA (i.e., a non-member STA) besides the one with membership for that specific r-TWT scheduling, it must be stopped. And after a specific r-TWT SP ends, an additional TXOP for another STA (i.e., a non-member STA) can be executed.

[0166] Negotiation process related to R-TWT coordination

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

[0168] Figure 11 This diagram illustrates the AP and STA that can be applied in the OBSS disclosed herein.

[0169] like Figure 11 As illustrated, the signaling-capable range of AP1 (e.g., corresponding to the range of BSS1) and the signaling-capable range of AP2 (e.g., corresponding to the range of BSS2) can overlap. In this way, when AP1 and AP2 are within range where they can receive from each other (i.e., listen to each other), AP1 and AP2 can perform negotiation via (wireless / wired) communication to coordinate the R-TWT service periods (SPs) scheduled by each of them. This differs from the case where AP1 and AP2 are hidden nodes relative to each other; this case corresponds to AP1 and AP2 being located in OBSSs with overlapping transmit / receive ranges.

[0170] In this respect, STAs located within the overlapping range can receive beacon frames not only from the APs associated with them, but also from APs not associated with them. For example, STAs 1-2 can receive beacon frames from AP1, which is associated with them, and can also receive (i.e., listen to) beacon frames from AP2, which is not associated with them. Similarly, STAs 2-3 can receive beacon frames from AP2, which is associated with them, and can also receive (i.e., listen to) beacon frames from AP1, which is not associated with them.

[0171] In this case, AP1 and AP2 can correspond to slave APs (or shared APs) belonging to the same MAP (either a primary AP or a shared AP). Furthermore, either AP1 or AP2 can be the primary AP (or a shared AP). Additionally, AP1 and AP2 belong to the same MAP.

[0172] Beacon frames may include restricted TWT (R-TWT) scheduling information assigned by an AP to its associated STAs, and the STAs receiving the R-TWT scheduling information are required to protect the R-TWT SP, where they are not members (e.g., as mentioned above, terminating a STA's TXOP when the corresponding TXOP occurs before the start time of the R-TWT SP). In other words, this may mean that the STA receiving the beacon frame including 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 when it receives R-TWT scheduler information advertised by an unrelated (or neighboring) AP, or whether low-latency services / data should be sent or received during the corresponding R-TWT SP, is undefined.

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

[0174] In this disclosure, the scenario in which a coordination request is sent by an associated AP and a coordination response to it is sent by a non-associated (or adjacent) AP is described primarily as a representative example. However, this is for clarity of description, and the method proposed in this disclosure can also be applied to the scenario in which a coordination request is sent by a non-associated (or adjacent) AP and a coordination response to it is sent by an associated AP.

[0175] Example 1

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

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

[0178] The negotiation process for coordination between associated APs (e.g., AP1) and non-associated (or adjacent) APs (e.g., AP2) can be performed in a bidirectional (2-way) manner.

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

[0180] - Step 2. The non-associated (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).

[0181] 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 negotiating party, can be considered the coordinating R-TWT SP among the participating APs.

[0182] Conversely, when the coordination response in step 2 includes a message indicating "rejection" (or "failure"), the associated AP may retransmit the coordination request to an unassociated (or neighboring) AP. In this case, the retransmitted coordination request may include the same R-TWT SP information as that included in the previously sent coordination request (e.g., the coordination request sent in step 1), or it may include information that has been partially or completely changed. When the last coordination response received from an unassociated (or neighboring) AP during the negotiation process includes a message indicating "rejection" (or "failure"), the coordination can be interpreted as rejected (or failed). In this case, the R-TWT SP that is a subject of the negotiation can be considered a non-coordinating R-TWT SP among the APs participating in the negotiation. In this respect, non-coordinating R-TWT SPs can collectively refer to R-TWT SPs whose coordination through the negotiation process within the AP has failed, and R-TWT SPs that are not subjects of the negotiation process used for coordination (i.e., not included in it).

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

[0184] 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 be used 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 the coordinating R-TWT SPs among the APs.

[0185] As another example, when an associated AP receives (i.e., listens to) a beacon frame sent by a non-associated (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 respect, 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. For example, the associated AP can assign R-TWT SPs to its associated STAs so as not to overlap with corresponding OBSS R-TWT SPs and announce these.

[0186] As yet another example, information about the OBSS R-TWT SP can be obtained when the STA receives (i.e., supervises) a beacon frame sent by an unassociated (or neighboring) AP.

[0187] In this scenario, the STA can advertise information about the corresponding OBSS R-TWT SP to its 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 assign R-TWT SPs to its associated STAs to avoid overlap with corresponding OBSS R-TWT SPs and advertise these.

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

[0189] Regarding the scheme based on the above TWT request, the STA can send a TWT request including a new field (e.g., SP) indicating non-overlapping time based on the information in the OBSS R-TWT SP (via TWT frame establishment). This field can be indicated by reserved bits within the TWT element.

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

[0191] As another example, it can be configured with the following: Figure 12 The diagram illustrates information related to the coordination of R-TWT.

[0192] Figure 12 The illustration shows an example of the configuration of information related to coordinating R-TWT according to this disclosure.

[0193] Reference 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.

[0194] 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.

[0195] The Coordinated R-TWT field indicates whether an R-TWT SP corresponds to an R-TWT SP that has successfully performed coordination negotiation with the AP that issued the announcement (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 to indicate a coordinated R-TWT SP, and a value of 0 can be defined to indicate a non-coordinated R-TWT SP. Furthermore, in this disclosure, considering the presence of a third entity managing the AP, this field can be extended and used to distinguish between the aforementioned coordinated and non-coordinated R-TWT SPs.

[0196] The BSS color field indicates 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.

[0197] 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.

[0198] 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 greater, this can indicate that the STA should conditionally comply with the protection rules for the corresponding R-TWT SP based on other information. This other information could be information from another layer of the corresponding STA (e.g., the PHY layer).

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

[0200] 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 the scheduling information for the corresponding R-TWT (i.e., the corresponding coordinating R-TWT).

[0201] Overlapping R-TWT fields can indicate whether an R-TWT service period (SP) corresponding to a broadcast TWT ID overlaps with another R-TWT SP, a time (SP) included in a TWT request, etc.

[0202] Based on the above-mentioned coordinated R-TWT related information, information about times (e.g., SPs) that do not overlap with the corresponding OBSS R-TWT SPs can be included / indicated 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.

[0203] 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 information about the requested time (e.g., SP) included in the TWT request of the STA. This also allows other STAs to participate as members in the corresponding R-TWT.

[0204] Example 2

[0205] This embodiment relates to a specific method for performing (wireless / wired-based) negotiation to coordinate R-TWT service periods (SPs) between associated APs and unassociated (or adjacent) APs. As a result of the negotiation, the APs can obtain scheduling information for coordinating the R-TWT SP (i.e., coordinating R-TWT).

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

[0207] In this regard, in the case of wireless negotiation, assuming that an AP is located in a topology where its corresponding BSS (e.g., the second BSS to which AP2 belongs) overlaps with its own BSS (e.g., the first BSS to which AP1 belongs) (i.e., the OBSS area), wireless-based negotiation is possible. If wireless-based communication between APs is not possible, negotiation can be performed via wireless communication (e.g., backhaul-based communication). Furthermore, when a master AP is present to manage APs, (wireless / wired) negotiation can be based on sending and receiving coordination requests and responses via the master AP.

[0208] Furthermore, this disclosure is described based on the assumption that, in a state where the associated APs know in advance about the R-TWT service periods (SPs) scheduled by the unassociated (or adjacent) APs, negotiations for coordination can be initiated. For example, in the case of direct negotiations between APs, the APs may be located in positions where they can send and receive beacon frames from each other, and may identify information about the R-TWT SPs in advance by receiving (i.e., listening to) beacon frames. However, the scope of this disclosure is not limited thereto, and this disclosure may be extended to apply even when the APs are unaware of the pre-scheduled R-TWT SPs (e.g., when the APs are not located in positions where they can send and receive beacon frames from each other).

[0209] Furthermore, this disclosure is based on the following assumptions: 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 by defining new fields based on the TWT elements in the TWT setup frame and the broadcast TWT parameter set field.

[0210] Furthermore, in this disclosure, it is assumed 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.

[0211] Example 2-1

[0212] In this embodiment, the elements constituting the coordination request described above are described in detail. At least one or more of the elements described below may be included in the coordination request.

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

[0214] The coordination request may include information for synchronizing the TSF of the AP that sends the coordination request (e.g., an associated AP) with the TSF of the AP that receives the coordination request (e.g., a non-associated (or adjacent) AP).

[0215] This information can be used to resolve issues related to different reference times in AP.

[0216] 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, scheduling information for R-TWT can be configured based on the TSF of the AP receiving the coordination request. Configuring the TWT element 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 a non-associated (or adjacent) AP.

[0217] As another example, when the AP sending the coordination request does not previously identify information related to the TSF of the AP receiving the coordination request, the AP sending the coordination request can include information related to its own TSF 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.

[0218] 2) Scheduling information for R-TWT SPs undergoing coordination and negotiation

[0219] The coordination request may include a TWT element consisting of broadcast TWT parameter set fields, which include information about the R-TWT SP to which coordination negotiation is to be performed.

[0220] Broadcast TWT parameter set fields may include restricted TWT service information fields. 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 fields.

[0221] In this regard, for the coordination and negotiation of R-TWT in the AP, unused fields in the broadcast TWT parameter set field and / or restricted TWT service information field included in the coordination request can be set to reserved values ​​and sent and received, 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 protection operations for the R-TWT SP may not need to be shared in the AP during the coordination and negotiation process.

[0222] 3) Information relating to the overlap between a coordinated R-TWT SP and another R-TWT SP.

[0223] When an R-TWT SP overlaps with an R-TWT SP scheduled by a non-associated (or adjacent) AP, the coordination request may include a field indicating that the R-TWT SP requesting coordination is an overlapping R-TWT SP.

[0224] 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 TWs are the same (e.g., whether they overlap). Conversely, in cases other than the AP sending the coordination request identifying 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), indicating whether to indicate an overlapping R-TWT SP can take the form of requesting the AP receiving the coordination request to schedule the overlapping R-TWT SP based on the TWT element information included in the coordination request.

[0225] For example, when the value of the TWT field in the broadcast TWT parameter set field of the TWT element containing R-TWT scheduling information (i.e., R-TWT SP information) indicated 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 of the AP scheduling that received 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.

[0226] Figure 13 The illustration shows an example of an overlapping R-TWT SP according to this disclosure.

[0227] refer to Figure 13When the duration of the overlapping R-TWT SPs of AP1 (e.g., associated AP) and AP2 (e.g., non-associated (or adjacent) AP) is the same, the corresponding overlapping R-TWT SPs can be considered as completely overlapping R-TWT SPs. Figure 13 In this context, assume that the AP sending the coordination request is AP1, and the AP receiving the coordination request is AP2.

[0228] In this respect, it is not restricted whether the TWT interval value is the same. That is, for R-TWT SPs and OBSSR-TWT SPs that overlap with each other, the TWT interval can be set to the same value or different values.

[0229] Figure 14 The illustration shows another example of an overlapping R-TWT SP according to this disclosure.

[0230] Reference Figure 14 When the durations of the overlapping R-TWT SPs of AP1 (e.g., associated AP) and AP2 (e.g., non-associated (or adjacent) AP) are not the same, the corresponding overlapping R-TWT SPs can be considered as partially overlapping R-TWT SPs. Figure 14 In this context, assume that the AP sending the coordination request is AP1, and the AP receiving the coordination request is AP2.

[0231] In this respect, it is not restricted whether the TWT interval value is the same. That is, for R-TWT SPs and OBSSR-TWT SPs that overlap with each other, the TWT interval can be set to the same value or different values.

[0232] 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 that includes the value of the TWT field in the broadcast TWT parameter set field of the TWT element based on the R-TWT scheduling information (i.e., the information of the R-TWT SP) indicated in the coordination request, the corresponding R-TWT SPs overlap with each other, that is, they correspond to overlapping R-TWT SPs.

[0233] Figure 15 The illustration shows yet another example of an overlapping R-TWT SP according to this disclosure.

[0234] refer to Figure 15 When an R-TWT SP scheduled by AP2 (e.g., a non-associated (or adjacent) AP) begins during an R-TWT SP scheduled by AP1 (e.g., an associated AP), the corresponding overlapping R-TWT SP can be considered a partially overlapping R-TWT SP. Figure 15In this context, assume that the AP sending the coordination request is AP1, and the AP receiving the coordination request is AP2.

[0235] As another example, when the value of the TWT field in the broadcast TWT parameter set field of the TWT element that constitutes the R-TWT scheduling information of the AP scheduling that receives the coordination request, and the value of the TWT field in the broadcast TWT parameter set field of the TWT element that includes the R-TWT scheduling information (i.e., the information of the R-TWTSP) indicated in the coordination request, are within the duration of the SP, the corresponding R-TWT SPs overlap with each other, that is, they correspond to overlapping R-TWT SPs.

[0236] Figure 16 The illustration shows yet another example of an overlapping R-TWT SP according to this disclosure.

[0237] refer to Figure 16 When an R-TWT SP scheduled by AP1 (e.g., an associated AP) begins during an R-TWT SP scheduled by AP2 (e.g., a non-associated (or adjacent) 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 AP1, and the AP receiving the coordination request is AP2.

[0238] The fields related to the above-mentioned overlapping R-TWT SPs can be defined by a two-level indication method that indicates overlapping or non-overlapping R-TWT SPs, or by a three-level indication method that indicates fully overlapping, partially overlapping, or non-overlapping R-TWT SPs.

[0239] In this regard, when the corresponding field indicates fully overlapping R-TWT SPs or partially overlapping R-TWT SPs, information about the duration of the corresponding R-TWT SPs can be additionally included in the coordination request.

[0240] 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 SPs.

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

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

[0243] 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 can operate during the corresponding R-TWT SP can be indicated. As an example, when defining the ID indicating the corresponding coordination scheme, the coordination schemes supported during the corresponding R-TWT SP can be indicated in the form of a list. As another example, the corresponding fields can be defined in the form of a bitmap. 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 can be used to indicate whether the corresponding coordination scheme is supported (i.e., 0 or 1).

[0244] In addition, the coordination request may include, after the information on the coordination schemes supported during the corresponding SP, additional information required to operate each coordination scheme.

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

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

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

[0248] The coordination request may include information relating 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.

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

[0250] For example, a coordination request may include information about low-latency service / data IDs commonly used in the AP to indicate the transmission and reception requirements of low-latency services.

[0251] 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 a specific threshold level.

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

[0253] The coordination request may include information indicating whether a request is made for low-latency services to be sent and received by the AP during the R-TWT SP, and related requirements are included in the coordination response.

[0254] Example 2-2

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

[0256] Status code information

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

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

[0259] 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, the coordination response may include information related to the TSF, information about whether the R-TWT SPs overlap, information about the coordination technique, information about the BSS color of the AP, and additional information for low-latency services transmitted and received during the corresponding SP, etc.

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

[0261] 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 can be utilized.

[0262] 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 coordination response may also include a TSF alignment field, the value of which may be set to the same value indicated in the coordination request.

[0263] For example, when information for its own TSF (i.e., the TSF of the AP sending 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 for the TSF of the AP sending the coordination response can be included in the coordination response in the same format as that included in the coordination request.

[0264] 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., as proposed in Example 2-1).

[0265] 3) Scheduling information for R-TWT SPs undergoing coordination and negotiation

[0266] The coordination response may include a TWT element consisting of one or more broadcast TWT parameter set fields, which include information to be used for its coordination negotiation R-TWT SP.

[0267] Broadcast TWT parameter set fields may include restricted TWT service information fields. In this case, the restricted TWT service information fields can be used to share information about the TIDs of low-latency services sent and received during the corresponding R-TWT SP.

[0268] If a coordination request indicates an overlapping R-TWT SP, 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 / mean that the R-TWT SP is overlapping. Conversely, if a coordination request indicates a non-overlapping R-TWT SP, 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 / mean that the R-TWT SP is non-overlapping.

[0269] In this regard, in the coordination response for R-TWT coordination negotiation in the AP, unused fields in the broadcast TWT parameter set field and / or restricted TWT service information field 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 protection operations for the R-TWT SP may not need to be shared in the AP during the coordination negotiation process.

[0270] 4) Overlapping information between coordinated R-TWT SPs and other R-TWT SPs

[0271] The coordination response may include a field indicating that the R-TWT SP requesting coordination is an overlapping R-TWT SP when the R-TWT SP overlaps with an R-TWT SP scheduled by an unassociated (or adjacent) AP.

[0272] 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.

[0273] For example, if the status code information is set to the value of a first rejection code or a third rejection code, the value of the corresponding field can be set based on the (fully / partially) overlapping R-TWT SP definition proposed in the coordination request of this disclosure (i.e., proposed in Embodiment 2-1) (see, for example, see...). Figures 13 to 16 ).

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

[0275] The coordination response may include information about an AP coordination scheme to be operated during the coordination R-TWT SP, which is supported by the AP that is delivered via the coordination request.

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

[0277] 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).

[0278] 6) Identification information related to the AP that sent the coordination response

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

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

[0281] The coordination response may include information about low-latency services to be sent and received by the AP during R-TWT SP, as well as information about the associated send and receive requests.

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

[0283] For example, a coordination response may include information for a common low-latency service / data ID used in the AP, which indicates transmission and reception requirements for low-latency services.

[0284] For example, a coordination 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 a specific threshold level.

[0285] Compared to 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 recommended / suggested R-TWT SP information is included in the coordination response, the AP receiving the coordination response can retransmit the coordination request with a new value based on the recommended / suggested R-TWT SP information.

[0286] Furthermore, after the coordination negotiation performed based on the method proposed in this disclosure—that is, the negotiation of coordinated R-TWT between associated APs and unassociated (or adjacent) APs—is completed, the APs can announce the scheduling information for coordinating R-TWT within their respective BSSs 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 the scheduling information 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 and 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.

[0287] Figure 17 The diagram illustrates the operation of configuring a coordination request in a negotiation for R-TWT coordination according to this disclosure.

[0288] Reference Figure 17This will describe the situation where coordination requests for coordinating R-TWT between APs (e.g., associated APs) and neighboring APs (e.g., non-associated APs) are configured and sent by the APs.

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

[0290] Upon receiving the information, the AP can determine whether there is any overlap between the R-TWT SP to be coordinated and the R-TWT SP 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 neighboring APs (S1730), or it can configure a coordination request for non-overlapping R-TWT SPs and send the coordination request to neighboring APs (S1740).

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

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

[0293] Figure 18 The diagram illustrates the operation of configuring a coordination response in a negotiation for R-TWT coordination according to this disclosure.

[0294] refer to Figure 18 This will describe the scenario where the coordination response is configured and sent by the AP based on the coordination request for coordination between the AP (e.g., non-associated AP) and neighboring APs (e.g., associated AP).

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

[0296] If the overlapping / non-overlapping R-TWT SPs included in the coordination request are approved, 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).

[0297] 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 recommendation" (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).

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

[0299] In the following text, reference will be made to Figure 19 and Figure 20 Describe the AP and STA operations considering the methods described above. Figure 19 and Figure 20 In this context, it is assumed that the first AP corresponds to an AP associated with the STA, and the second AP corresponds to an AP not associated with the STA (or an adjacent AP). At this point, it is assumed that the first AP and the second AP belong to different BSSs.

[0300] Figure 19 The diagram illustrates the operation of the first AP based on coordination negotiation for R-TWT SP according to this disclosure. Figure 19 The diagram illustrates the operation of the first AP based on coordination negotiation for R-TWT SP according to this disclosure.

[0301] Reference Figure 19 The first AP can perform negotiation (S1910) for coordinating R-TWT SPs between the first AP belonging to the first BSS and the second AP belonging to the second BSS.

[0302] Negotiation can be performed based on the exchange of a first frame of a coordination request (e.g., the coordination request described in Example 2-1) and a second frame of a coordination response (e.g., the coordination response described in Example 2-2). In this respect, the AP that sends the first frame and the AP that receives the second frame can be the same AP, and the AP that receives the first frame and the AP that sends the second frame can be the same AP.

[0303] In this scenario, when the Timing Synchronization Function (TSF) information of the AP receiving the first frame is obtained by the AP sending the first frame, the R-TWT SP information in the first frame can be configured based on the TSF. In this case, the first frame may include information (e.g., a TSF alignment field, etc.) indicating whether information for the R-TWT SP has been configured based on the TSF. Conversely, when the AP sending the first frame does not obtain the TSF information from the AP receiving the first frame, the first frame may include the TSF information of the AP sending the first frame (e.g., an 8-byte TSF field, a 2-byte TSF offset field, etc.).

[0304] Alternatively or additionally, the information for the R-TWT SP in the first frame can be configured using a parameter set field (e.g., the broadcast TWT parameter set field) related to the broadcast TWT in the TWT element. In this regard, among the multiple subfields included in the parameter set field, at least one subfield not used for the aforementioned coordination negotiation can be reserved. For example, the trigger subfield, flow type subfield, restricted TWT service information presence subfield, and restricted TWT scheduling information subfield can be reserved. Furthermore, some subfields in the parameter set field can be used for information replacement related to the aforementioned coordination. For example, the broadcast TWT ID subfield can be replaced with the coordination TWT ID subfield to indicate the scheduling information for the R-TWT used for coordination between APs.

[0305] Alternatively or additionally, the first frame may include information indicating whether there is overlap between the R-TWT SP scheduled by the AP receiving the first frame and the R-TWT SP requesting coordination. In this regard, overlap may be based on whether the value of the TWT field of the R-TWT SP scheduled by the AP receiving the first frame is the same as the value of the TWT field of the R-TWT SP requesting coordination. For example, this information may indicate one of overlapping or non-overlapping R-TWT SPs, or it may be defined as indicating one of fully overlapping, partially overlapping, or non-overlapping R-TWT SPs.

[0306] Alternatively or additionally, when an R-TWT SP scheduled by the AP receiving the first frame overlaps with a requested coordination R-TWT SP, the first frame may include information for a coordination scheme to operate during the overlapping R-TWT SPs (e.g., C-TDMA, C-OFDMA, C-SR, etc.). In this regard, the information for the coordination scheme may include information indicating at least one coordination scheme that can operate during the overlapping R-TWT SPs among the coordination schemes supported by the AP transmitting the first frame. Furthermore, the first frame may also include additional information for the operation of the coordination scheme during the overlapping R-TWT SPs.

[0307] Alternatively or additionally, the first frame may further include information about the BSS color of the AP transmitting the first frame, information about low-latency services to be transmitted and received during the requested coordinated R-TWT SP, and / or information about the requirements for transmitting and receiving low-latency services. Additionally, the first frame may include information about the requests for low-latency services to be transmitted and received during the requested coordinated R-TWT SP and / or information about the requirements for transmitting and receiving low-latency services that are included in the second frame.

[0308] Additionally, the second frame may include information indicating a status code for the aforementioned coordination request. Specifically, the information indicating the status code may be defined as one of an acceptance code, a first rejection code, a second rejection code including a reason for rejection, or a third rejection code including information about a recommended R-TWT SP. When the information indicating the status code is set to the third rejection code, the AP receiving the second frame may be configured to send a third frame (i.e., a retransmission of the frame for the coordination request) for the recommended R-TWT SP.

[0309] When the above negotiation is completed, the first AP may notify one or more associated STAs of information for the coordinated R-TWT SP (i.e., coordinated R-TWT SP) (S1920).

[0310] For example, information notification of a coordinated R-TWT SP can be performed by sending a beacon frame or probe response frame to one or more associated STAs immediately after the negotiation process for coordination is completed (i.e., immediately following the completion of the negotiation process).

[0311] Figure 19 The methods described in the examples can be derived from... Figure 1 The first device 100 executes. For example... Figure 1One or more processors 102 of the first device 100 may be configured to: perform negotiation, via one or more transceivers, between a first AP of a first BSS and a second AP of a second BSS regarding the coordination of the R-TWT SP, and, based on the completion of the negotiation, notify one or more associated STAs of information for the coordination-based R-TWT SP. Furthermore, one or more memories 104 of the first device 100 may store instructions that, when executed by one or more processors 102, cause one or more processors to perform... Figure 19 The example or the method described in the example below.

[0312] Figure 20 The diagram illustrates the operation of the STA based on the coordination negotiation for the R-TWT SP according to this disclosure.

[0313] Reference Figure 20 The STA associated with the first AP can receive a notification (S2010) from the first AP associated with the STA, including information for coordination between the first AP belonging to the first BSS and the second AP belonging to the second BSS.

[0314] In this regard, coordination can be based on negotiation performed by exchanging a first frame for the coordination request and a second frame for the coordination response between the first AP and the second AP.

[0315] Subsequently, the STA associated with the first AP can perform the relevant operations of the R-TWT SP (i.e., the coordinated R-TWT SP) based on the above announcement (S2020).

[0316] For example, related operations may include protection operations, such as terminating its own TXOP before the start time of the R-TWT SP, or data transmission and reception operations within the R-TWT SP.

[0317] exist Figure 20 In the example, the detailed description of specific information / components included in the first and / or second frames of the coordination request, as well as the timing of the information notification based on the coordination R-TWT SP, are... Figure 19 The examples are the same as those in the example, and therefore redundant descriptions are omitted.

[0318] Figure 20 The methods described in the examples can be derived from... Figure 1 The second device 200 performs the operation. For example... Figure 1One or more processors 202 of the second device 200 may be configured to: receive, via one or more transceivers, a notification from a first AP associated with the second device, including information for R-TWT SP coordination between the first AP and the second AP based on a first BSS, and to perform related operations for the R-TWT SP based on the notification. Furthermore, one or more memories 204 of the second device 200 may store instructions that, when executed by one or more processors 202, cause one or more processors to perform... Figure 20 The example or the method described in the example below.

[0319] Figure 19 and Figure 20 Instances may correspond to some of the various examples in this disclosure.

[0320] Unlike traditional WLAN systems that protect R-TWT SPs based on associated AP advertising of R-TWT related scheduling information, the method for protecting R-TWT SPs according to the examples of this disclosure can consider not only the associated AP R-TWT related scheduling information, but also the R-TWT related scheduling information of unassociated (or adjacent) APs, and can even protect R-TWT SPs scheduled by unassociated (or adjacent) APs, thereby achieving a new effect of minimizing the impact of conflicts and / or interference.

[0321] 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 can be implemented without combination with other elements or features. Furthermore, embodiments of this disclosure may include combinations of certain elements and / or features. The order of operations described in the 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. It is clear that embodiments may include combinations of claims where there is no explicit dependency in the claims, or may be included as new claims by amendment after the application.

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

[0323] 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, and non-transitory computer-readable media that store such software or commands and are executable in the 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 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. Alternatively, the non-volatile memory devices in the memory may 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 results from 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.

[0324] [Industrial Applicability]

[0325] The method proposed in this disclosure is mainly described based on examples applied to IEEE 802.11-based systems and 5G systems, but it can also be applied to various WLAN or wireless communication systems other than those based on IEEE 802.11.

Claims

1. A method performed by a first access point (AP) in a wireless local area network (WLAN) system, the method comprising: Negotiation for coordination of restricted target wake-up time (restricted TWT, R-TWT) service periods (SP) is performed between the first AP of the first basic service set (BSS) and the second AP of the second BSS; The negotiation is performed based on the exchange of a first frame for coordinating the request and a second frame for coordinating the response; Based on the completion of the negotiation, information for the coordinated R-TWT SP is notified to one or more associated STAs; and Specifically, based on the information obtained by the AP that sends the first frame regarding the timing synchronization function (TSF) of the AP that receives the first frame, information for the R-TWT SP is configured in the first frame based on the TSF.

2. The method according to claim 1, wherein: The first frame includes information indicating whether the information used for the R-TWT SP is configured based on the TSF.

3. The method according to claim 1, wherein: The first frame includes information about the TSF of the AP that sent the first frame, since the AP that sent the first frame did not obtain the TSF information for the AP that received the first frame.

4. The method according to claim 1, wherein: Use the parameter set fields within the TWT element related to the broadcast TWT to configure the information for the R-TWTSP in the first frame.

5. The method according to claim 4, wherein: Among the multiple subfields included in the parameter set field, at least one subfield that is not used for the negotiation of the coordination is set to be reserved.

6. The method according to claim 1, wherein: The first frame includes information indicating whether there is overlap between the R-TWT SP scheduled by the AP that receives the first frame and the R-TWT SP that requests the coordination.

7. The method according to claim 6, wherein: The overlap is based on whether the value of the TWT field of the R-TWT SP used for scheduling by the AP receiving the first frame is the same as the value of the TWT field of the R-TWT SP used to request the coordination.

8. The method according to claim 6, wherein: Based on the overlap between the R-TWT SP that indicates the AP receiving the first frame is scheduled by the AP and the R-TWT SP that requests the coordination, the first frame includes information on a coordination scheme for operation during the overlapping R-TWT SP.

9. The method according to claim 7, wherein: Information for the coordination scheme includes information indicating at least one coordination scheme that can operate during the overlapping R-TWT SP, among the coordination schemes that can be supported by the AP that sent the first frame.

10. The method according to claim 7, wherein: The first frame also includes additional information for the operation of the coordination scheme during the overlapping R-TWT SP.

11. The method according to claim 1, wherein: The first frame also includes at least one of the following: information on the BSS color of the AP that sends the first frame, information on low-latency services that are sent and received during the R-TWT SP that requests the coordination of the first frame, or information on the requirements for the transmission and reception of the low-latency services.

12. The method according to claim 1, wherein: The second frame includes information indicating the status code of the coordination request, and The information indicating the status code is defined as one of an acceptance code, a first rejection code, a second rejection code including a reason for rejection, or a third rejection code including information from the recommended R-TWT SP.

13. The method according to claim 12, wherein: Based on the information indicating that the status code is set to the third rejection code, the AP receiving the second frame is configured to send a third frame of coordination request for the recommended R-TWT SP.

14. The method according to claim 1, wherein: The announcement of information for the R-TWT SP based on the coordination is performed by first sending a beacon frame or probe response frame to one or more associated STAs after the negotiation is completed.

15. The method according to claim 1, wherein: The AP that sends the first frame and the AP that receives the second frame are the same AP, and The AP that receives the first frame and the AP that sends the second frame are the same AP.

16. A first access point (AP) device in a wireless local area network (WLAN) system, the device comprising: At least one transceiver; as well as At least one processor is connected to the at least one transceiver. Wherein, the at least one processor is configured to: Negotiation for coordinating restricted target wake-up time (restricted TWT, R-TWT) service periods (SP) is performed between the first AP of the first basic service set (BSS) and the second AP of the second BSS; Negotiation is performed based on the exchange of a first frame for coordinating the request and a second frame for coordinating the response. Based on the completion of the negotiation, information regarding the R-TWT SP based on the coordination is notified to one or more associated STAs; and Specifically, based on the information obtained by the AP that sends the first frame regarding the timing synchronization function (TSF) of the AP that receives the first frame, information for the R-TWT SP is configured in the first frame based on the TSF.

17. A method performed by a station (STA) in a wireless local area network (WLAN) system, the method comprising: Receive a notification from the first AP associated with the STA, the notification including information about a restricted target wake-up time (restricted TWT, R-TWT) service period (SP) for coordination between the first AP based on the first basic service set (BSS) and the second AP based on the second BSS; as well as Perform relevant operations on the R-TWT SP based on the announcement; The coordination is based on negotiation performed by exchanging a first frame for a coordination request and a second frame for a coordination response between the first AP and the second AP. Specifically, based on the information obtained by the AP that sends the first frame regarding the timing synchronization function (TSF) for the AP receiving the first frame, information for the R-TWT SP is configured in the first frame based on the TSF.

18. A station (STA) device in a wireless local area network (WLAN) system, the device comprising: At least one transceiver; as well as At least one processor is connected to the at least one transceiver. Wherein, the at least one processor is configured to: Receive a notification from a first AP associated with the STA, the notification including information about a restricted target wake-up time (restricted TWT, R-TWT) service period (SP) for coordination between the first AP and a second AP based on a first basic service set (BSS); and Perform relevant operations on the R-TWT SP based on the announcement; The coordination is based on negotiation performed by exchanging a first frame for a coordination request and a second frame for a coordination response between the first AP and the second AP. Specifically, based on the information obtained by the AP that sends the first frame regarding the timing synchronization function (TSF) of the AP that receives the first frame, information for the R-TWT SP is configured in the first frame based on the TSF.

19. A processing unit configured to control a first access point (AP) in a wireless local area network system, the processing unit comprising: One or more processors; as well as One or more computer memories, operatively connected to the one or more processors and storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-15.

20. One or more non-transitory computer-readable media storing one or more instructions, in, The one or more instructions are executed by one or more processors to control a first access point (AP) device in a wireless local area network (WLAN) system to perform the method according to any one of claims 1-15.

Images