Method and apparatus for agreement between multiple access point in wi-fi communication

Abstract

The present disclosure relates to a method and apparatus for agreement between multiple access points in Wi-Fi communication, wherein a method by a first access point performing Wi-Fi communication comprises: transmitting a first frame containing information regarding the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement to a second access point; and receiving a second action frame from the second access point in response to the first action frame.

Description

Technology Field

[0001] The present disclosure relates to Wi-Fi communication between electronic devices, and more specifically, to a method and apparatus for agreement between multiple access points in Wi-Fi communication. Background Technology

[0002] Recently, due to the development of wireless technology, wired networks used by many people are being replaced by wireless networks. In other words, as wireless technology can solve the mobility limitations of wired networks, many technologies utilizing wireless networks are being actively researched.

[0003] A Wireless Local Area Network (WLAN), also known as Wi-Fi (Wireless Fidelity), allows users to access the internet via mobile devices or laptops within a certain distance from an Access Point (AP). The Wi-Fi Alliance defines Wi-Fi as a Wireless Local Area Network (WLAN) product based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Wi-Fi communication primarily uses the 2.4 GHz and 5 GHz wireless bands. In particular, with the popularization of mobile devices, wireless LANs, which possess potential as open wireless networks, are expanding rapidly, and Wi-Fi is being used to provide high-speed data services throughout cities, including in schools, airports, hotels, and offices.

[0004] The Internet is evolving from a human-centered network where humans generate and consume information into an IoT (Internet of Things) network where distributed components, such as objects, exchange and process information. IoE (Internet of Everything) technology, which combines IoT with big data processing technologies through connections with cloud servers, is also emerging. Implementing IoT requires technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology. Recently, technologies such as sensor networks, Machine-to-Machine (M2M) communication, and Machine-Type Communication (MTC) are being researched for connecting objects.

[0005] In an IoT environment, intelligent IT (Internet Technology) services that create new value for human life by collecting and analyzing data generated from connected objects can be provided. Through the convergence and integration of existing IT (Information Technology) with various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services.

[0006] Meanwhile, an efficient cooperation mechanism among access points (APs) is essential to maximize network performance in a multi-AP environment. In conventional wireless LAN systems, each AP performs scheduling independently, which can lead to increased interference and inefficient distribution of transmission opportunities in a multi-AP setting. In particular, collisions between APs sharing the same frequency band can result in data transmission delays and reduced throughput. Therefore, methods and devices are required to minimize interference and efficiently coordinate transmission opportunities through consensus among multiple APs. The problem to be solved

[0007] The present disclosure aims to provide a method and apparatus for agreement between multiple access points during Wi-Fi communication.

[0008] The present disclosure aims to provide a method and apparatus for agreeing on or negotiating conditions for the validity or maintenance of a MAPC agreement between access points performing multi-AP coordination (MAPC) during Wi-Fi communication.

[0009] The technical problems to be solved by the present disclosure are not limited to those mentioned above, and other unmentioned technical problems may be considered by those skilled in the art from the various embodiments of the present disclosure described below. means of solving the problem

[0010] A method by a first access point performing Wi-Fi communication according to one embodiment of the present disclosure comprises: transmitting a first frame containing information on the condition of keeping alive a multiple-access point (AP) coordination (MAPC) agreement to a second access point; and receiving a second frame from the second access point in response to the first frame.

[0011] A method by a second access point performing Wi-Fi communication according to one embodiment of the present disclosure comprises: receiving a first frame from a first access point containing information on the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement; and transmitting a second frame to the first access point in response to the first frame.

[0012] According to one embodiment of the present disclosure, a first access point performing Wi-Fi communication comprises: a transceiver; and at least one processor; wherein the at least one processor is configured to transmit a first frame containing information regarding the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement to a second access point, and to receive a second frame from the second access point in response to the first frame.

[0013] According to one embodiment of the present disclosure, a second access point performing Wi-Fi communication comprises: a transceiver; and at least one processor; wherein the at least one processor receives a first frame from a first access point containing information regarding the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement, and is configured to transmit a second frame to the first access point in response to the first frame.

[0014] The various embodiments of the present disclosure described above are merely some of the preferred embodiments of the present disclosure, and various embodiments reflecting the technical features of the various embodiments of the present disclosure can be derived and understood by those skilled in the art based on the detailed description to be described below. Effects of the invention

[0015] According to one embodiment of the present disclosure, by proposing a method for agreeing on or negotiating conditions for the validity or maintenance of an agreement between multiple access points, effects such as saving network resources, reducing interference and latency, and flexible configuration management are achieved.

[0016] The effects obtainable from the various embodiments of the present disclosure are not limited to those mentioned above, and other unmentioned effects can be clearly derived and understood by those skilled in the art based on the following detailed description. Brief explanation of the drawing

[0017] FIG. 1 is a drawing for illustrating an example of a short-range communication connection type between an electronic device and an access point according to one embodiment of the present disclosure. FIG. 2 is a diagram illustrating the operation of an access point (AP) and a station (STA) for establishing a wireless LAN connection according to one embodiment of the present disclosure. FIG. 3 is a drawing for illustrating an example of a short-range communication connection type of an electronic device according to one embodiment of the present disclosure. FIG. 4 is a drawing illustrating an example of a frame structure used in an IEEE 802.11 system according to one embodiment of the present disclosure. FIG. 5 is a diagram illustrating an example of a network allocation vector (NAV) setting according to one embodiment of the present disclosure. FIG. 6 is a drawing illustrating an example of a TXOP (transmission opportunity) according to one embodiment of the present disclosure. FIG. 7 is a drawing illustrating a wireless communication system including multiple access points and stations according to one embodiment of the present disclosure. FIG. 8 is a diagram illustrating an example of the configuration of a Multi-AP (access point) Coordination (MAPC) framework of a wireless LAN system according to one embodiment of the present disclosure. FIG. 9 is a diagram illustrating an exemplary operation of Co-TDMA of a wireless LAN system according to one embodiment of the present disclosure. FIG. 10 is a diagram illustrating an example of a Co-TDMA or TXS (triggered TXOP sharing) operation according to one embodiment of the present disclosure. FIGS. 11a, FIGS. 11b, and FIGS. 11c illustrate an example of a case where the MAPC agreement is terminated after Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure. FIG. 12 is a diagram illustrating an example of the configuration of a framework for Multi-AP Coordination (MAPC) including an agreement operation for a MAPC keep-alive condition of a wireless LAN system according to one embodiment of the present disclosure. FIG. 13 is a diagram illustrating an example of Multi-AP Coordination (MAPC) agreement operation according to one embodiment of the present disclosure. FIG. 14 is a diagram illustrating a keep-alive condition for a Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure. FIG. 15 is a diagram illustrating an example of an operation for transmitting a keep-alive Action frame for Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure. FIG. 16 is a diagram illustrating an example of an operation for transmitting a teardown action frame for Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure. FIG. 17 is a diagram illustrating an example of an operation for transmitting a teardown action frame for Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure. FIGS. 18a, FIGS. 18b and FIGS. 18c are drawings for illustrating an action frame for MAPC agreement according to one embodiment of the present disclosure. FIGS. 19a, FIGS. 19b, and FIGS. 19c illustrate an example of an Action field format of an Action Frame for MAPC agreement according to one embodiment of the present disclosure. FIGS. 20a, FIGS. 20b, FIGS. 20c and FIGS. 20d are drawings illustrating an example of a MAPC element format that may include MAPC-related information according to an embodiment of the present disclosure. FIG. 21 is a drawing illustrating an example of a MAPC agreement request / response element format that may include information related to MAPC keep-alive conditions according to one embodiment of the present disclosure. FIG. 22 is a drawing illustrating an example of a MAPC Keep-alive element field format according to one embodiment of the present disclosure. FIGS. 23a and FIGS. 23b are drawings illustrating an example of a MAPC teardown element format according to one embodiment of the present disclosure. FIG. 24 is a drawing illustrating an example of an operation related to MAPC discovery and consensus according to one embodiment of the present disclosure. FIG. 25 is a flowchart illustrating the operation of a first access point according to one embodiment of the present disclosure. FIG. 26 is a flowchart illustrating the operation of a second access point according to one embodiment of the present disclosure. The drawings are included as reference examples to aid in understanding the present disclosure and are not limited to specific embodiments of the invention. Specific details depicted in the drawings are included to supplement the overall technical background and context of the present disclosure and may provide technical information useful to the present disclosure even if not directly specified in the claims. Specific details for implementing the invention

[0018] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0019] In describing the embodiments, technical details that are well known in the technical field to which this disclosure belongs and are not directly related to this disclosure are omitted. This is intended to convey the essence of this disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0020] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the size of each component does not entirely reflect its actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference number.

[0021] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. The embodiments of the present disclosure are provided merely to make the present disclosure complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, like reference numerals refer to like components.

[0022] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing means of instruction to perform the function described in the flow diagram block(s).

[0023] Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that execute a computer or other programmable data processing equipment by performing a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer may also provide steps for executing the functions described in the flowchart block(s).

[0024] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). Also, it should be noted that in some alternative practices, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0025] In this embodiment, the term "part" used refers to a software or hardware component such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or may be configured to run one or more processors. Accordingly, according to some embodiments, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and 'parts' may be implemented to utilize one or more CPUs within the device or secure multimedia card. Furthermore, according to some embodiments, the 'parts' may include one or more processors.

[0026] In the present disclosure, each of the phrases such as “A or B,” “at least one of A and B,” “at least one of A or B,” “A, B or C,” “at least one of A, B and C,” and “at least one of A, B, or C” may include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as “first,” “second,” or “first” or “second” may be used simply to distinguish a corresponding component from another corresponding component and do not limit the components in any other aspect (e.g., importance or order).

[0027] Unless specifically stated otherwise, in the description of an embodiment of the present disclosure, "greater than" may be replaced with "greater than," and "greater than" may be replaced with "greater than." Unless specifically stated otherwise, in the description of an embodiment of the present disclosure, "less than" may be replaced with "less than," and "less than" may be replaced with "less than."

[0028] The terms 'station', 'terminal', or 'device' as used herein may be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit, subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile, or other terms. Various embodiments of a terminal may include a cellular telephone, a smartphone with wireless communication capabilities, a personal digital assistant (PDA) with wireless communication capabilities, a wireless modem, a portable computer with wireless communication capabilities, a photographic device such as a digital camera with wireless communication capabilities, a gaming device with wireless communication capabilities, a music storage and playback appliance with wireless communication capabilities, an internet appliance capable of wireless internet access and browsing, as well as portable units or terminals integrating combinations of such capabilities. Additionally, the terminal may include, but is not limited to, M2M (Machine to Machine) terminals and MTC (Machine Type Communication) terminals / devices. In this specification, the terminal may be referred to as an electronic device or simply a device.

[0029] Exemplary embodiments are described below in relation to Wireless Local Area Network (WLAN) systems solely for the sake of simplicity. It should be understood that the exemplary embodiments are equally applicable to systems using signals of one or more wired standards or protocols (e.g., Ethernet and / or HomePlug / PLC standards), as well as other wireless networks (e.g., cellular networks, pico networks, femto networks, satellite networks). As used herein, the terms “WLAN” and “Wi-Fi®” may include communications controlled by the IEEE 802.11 family of standards, BLUETOOTH®, HiperLAN (a set of wireless standards comparable to IEEE 802.11 standards, mainly used in Europe), and other technologies having a relatively short wireless range. Accordingly, the terms “WLAN” and “Wi-Fi” may be used interchangeably herein. Additionally, although the following describes an infrastructure WLAN system comprising one or more access points (APs) and multiple wireless stations (STAs), exemplary embodiments are equally applicable to other WLAN systems, such as multiple WLANs, peer-to-peer (or independent basic service set) systems, Wi-Fi Direct systems and / or hotspots.

[0030] Additionally, while this specification describes the exchange of data frames between wireless devices, exemplary embodiments may be applied to the exchange of any data unit, packet, and / or frame between wireless devices. Accordingly, the term “frame” may include any frame, packet, or data unit such as, for example, protocol data units (PDUs), MAC (media access control) protocol data units (MPDUs), and PLCP (physical layer convergence procedure) protocol data units (PPDUs). The term “A-MPDU” may mean aggregated MPDUs.

[0031] In the following description, many specific details, such as examples of specific components, circuits, and processes, are presented to provide a thorough understanding of the present disclosure. As used herein, the term “connected” means being directly connected or being connected through one or more intervening components or circuits. The term “connected access point” means an access point to which a given station is currently associated and / or connected (e.g., there exists a communication channel or link established between the access point and the given station). Additionally, in the following description and for illustrative purposes, specific nomenclature is presented to provide a thorough understanding of exemplary embodiments. However, it will be apparent to those skilled in the art that these specific details may not be necessary to carry out the exemplary embodiments. In other cases, to avoid obscuring the present disclosure, well-known circuits and devices are illustrated in block diagram form.

[0032] Specific terms used in the following description are provided to aid in understanding the present disclosure, and the use of such specific terms may be modified in other forms without departing from the technical spirit of the present disclosure.

[0033] The operating principles of the present disclosure will be described in detail below with reference to the attached drawings. In describing the present disclosure below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Furthermore, the terms described below are defined in consideration of their functions in the present disclosure, and these may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0034] FIG. 1 is a diagram illustrating a short-range communication connection type of an electronic device and an access point that can be applied to the present disclosure.

[0035] According to various embodiments, with reference to FIG. 1, an electronic device (100) may be connected to an access point (AP) (140) based on a plurality of communication methods based on Wi-Fi. According to various embodiments, the electronic device (100) may include a processor (120) and a communication module (130).

[0036] According to various embodiments, the communication module (130) can receive a communication signal from the outside or transmit a communication signal to the outside based on a Wi-Fi communication method (e.g., IEEE 802.11be). For example, the communication module (130) can operate based on at least one of the Wi-Fi communication methods IEEE 802.11ac, 802.11ax, 802.11be, or 802.11bn, and in particular, IEEE 802.11be or 802.11bn supports a wider bandwidth, higher data throughput, and shorter latency compared to IEEE 802.11ax, thereby improving performance.

[0037] According to various embodiments, the communication module (130) may include a transceiver (131) for transmitting and receiving data with an external device and a communication processor (133) (e.g., a communication processor (not shown), or a short-range wireless communication module (e.g., a Wi-Fi chipset)). According to various embodiments, the communication module (130) may further include memory.

[0038] According to various embodiments, the transceiver (131) can convert a baseband transmission signal into a wireless signal or convert a received wireless signal into a baseband reception signal.

[0039] According to various embodiments, the communication module (130) may further include, in addition to the transceiver (131) and the communication processor (133), components for orthogonal frequency division multiplexing (OFDM) or orthogonal frequency division multiple access (OFDMA), e.g., a modulator, a digital-analog converter, a frequency converter, an A / D converter, an amplifier, and / or a demodulator.

[0040] Although not illustrated, according to various embodiments, the electronic device (100) may be electrically connected to a communication module of an access point (140) and may include at least one antenna module that supports a communication protocol and / or frequency band supported by the communication module of the access point (140).

[0041] According to various embodiments, the communication processor (133) can control the transceiver (131) to form a communication connection with the access point (140). For example, the communication connection may include a Wi-Fi network. For example, the communication processor (133) can control the transceiver (131) to form a wireless connection with the access point (140) using a wireless local area network (WLAN) standard in the 2.4 GHz, 5 GHz, or 6 GHz band, such as an IEEE 802.11ac, 802.11ax, 802.11be, or 802.11bn system. Alternatively, the communication processor (133) can control the transceiver (131) to form a wireless connection with the access point (140) using a WLAN standard in the 60 GHz band, such as an IEEE 802.11ad or 802.11ay.

[0042] According to various embodiments, a method of communicating between an electronic device (100) and an access point (140) using a wireless local area network (WLAN) standard may be referred to as a communication method based on STA mode.

[0043] According to various embodiments, the processor (120) may include an application processor. The processor (120) may perform a specified operation of the electronic device (100) or control other hardware (e.g., a communication module (130)) to perform a specified operation.

[0044] According to various embodiments, the access point (140) may support the operation of transmitting data to an external network and / or the operation of the multiple electronic devices (e.g., electronic device (100)) receiving data from an external network based on the connection between the multiple electronic devices (e.g., electronic device (100)) and an external network (e.g., Internet, external LAN, or cellular network).

[0045] According to various embodiments, the access point (140) may be a wireless router. The access point (140) may be a dedicated wireless router or a general-purpose device that supports a mobile hotspot function, and there are no limitations on its implementation. For example, the access point (140) may include the same components (e.g., a processor and / or a communication module) as the electronic device (100).

[0046] According to various embodiments, the access point (140) may transmit and receive data with an external device, such as a server or an electronic device (100). For example, the access point (140) may transmit at least some of the data received from the server to the electronic device (100). According to various embodiments, the access point (140) and the electronic device (100) may transmit and receive UL (uplink) / DL (downlink) data during an operation period. For example, the access point (140) may transmit traffic to the electronic device (100) only during an operation period set based on schedule information received from the electronic device (100).

[0047] FIG. 2 is a diagram illustrating the operation of an access point and a station for establishing a wireless LAN connection according to one embodiment of the present disclosure.

[0048] As illustrated in FIG. 1, the access point can communicate with the station based on Wi-Fi. The station can be implemented as the electronic device (100) of FIG. 1. The station may be a terminal that supports Wi-Fi communication according to the IEEE 802.11 standard (or a terminal having a Wi-Fi interface).

[0049] A station may transmit (or broadcast) a probe request frame to an access point. According to one embodiment, the probe request message may be a frame for the station to search for nearby access points. According to one embodiment, the probe request frame may include information regarding at least one communication capability supported by the station. According to one embodiment, the station may receive a beacon frame from an access point and transmit a probe request frame to the access point based on the information contained in the beacon frame. The beacon frame is one of the management frames in IEEE 802.11 and may be transmitted periodically to announce the presence of a wireless network and to allow a scanning STA to find the wireless network and join the wireless network. The access point may transmit a probe response frame in response to the probe request frame.

[0050] Upon receiving the probe response frame, the station may transmit an authentication request frame to the access point. The access point transmits an authentication response frame to the station in response to the authentication request frame, and the authentication procedure between the access point and the station may be completed. According to one embodiment, the authentication procedure for transmitting and receiving the authentication request frame and the authentication response frame may be a process of authenticating by selecting the channel with the strongest reception strength among the frames received during the channel search process. According to one embodiment, the station and the access point may negotiate the encryption method of the authentication procedure through the authentication procedure.

[0051] Once the authentication process is complete, the station may send an association request frame to the access point to perform an association setup for the access point. According to one embodiment, the association request frame may include information regarding at least one capability to be used for data communication between the station and the access point (e.g., according to the IEEE 802.11 standard). The access point may generate an association ID (AID) for the station and send an association response frame to the station.

[0052] FIG. 3 is a drawing for illustrating an example of a short-range communication connection type of an electronic device according to one embodiment of the present disclosure.

[0053] Referring to FIG. 3, the wireless communication system (300) may include an access point (310), client electronic devices (330, 332, 334, 336) corresponding to the station, and a wireless local area network (WLAN) (305).

[0054] A wireless communication system (300) may be formed by an access point (310) that provides a wireless communication channel or link to one or more stations (STA) (330, 332, 334, 336).

[0055] An access point (310) is assigned a unique media access control (MAC) address. The WLAN (305), depicted as a circular shape in FIG. 3, is depicted as a basic service set (BSS), which is a basic building block of an IEEE 802.11 system; however, in other exemplary embodiments, the WLAN (305) may be an independent basic service set (IBSS) network or a peer-to-peer (P2P) network (e.g., operating according to Wi-Fi Direct protocols). The circular shape of the WLAN (305) depicted in FIG. 3 may also be understood as representing a coverage area where stations included in the BSS maintain communication. This area may be referred to as a Basic Service Area (BSA). When stations (330, 332, 334, 336) move out of the BSA, they are unable to communicate directly with access points or other stations within the BSA. The access point (310) may be a dedicated wireless router or a station that supports a mobile hotspot function, in which case the access point (310) may be referred to as an AP STA.

[0056] The stations (330, 332, 334, 336) are devices that operate according to the Medium Access Control (MAC) / PHY specifications of IEEE 802.11. Unless the function of the station is individually distinguished from the access point, the station may include AP STAs and non-AP STAs. However, when communication is performed between the STA and the AP, the STA may be understood as a non-AP STA. If the station supports a mobile hotspot function and operates like an access point (310), the station may be understood as an AP STA.

[0057] The stations (330, 332, 334, 336) may be any suitable Wi-Fi-enabled wireless device or electronic device, including, for example, a cell phone, a personal digital assistant (PDA), a tablet device, a laptop computer, etc. The stations (330, 332, 334, 336) may also be referred to as user equipment (UE), subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, electronic device, or any other suitable technical term.

[0058] A "point coordination function (PCF) transmission method" and a "distributed coordination function (DCF) transmission method" can be used as a method to perform data transmission of a plurality of wireless stations (330, 332, 334, 336) corresponding to UL clients connected to the access point (310) shown in FIG. 3.

[0059] "PCF (point coordination function) method transmission" refers to a transmission method in which the access point directly asks multiple wireless stations and waits for data transmission.

[0060] "Distributed coordination function (DCF) transmission" refers to a transmission method in which a wireless station detects and waits in advance to avoid collisions before transmitting data in an environment where multiple wireless stations compete to transmit data.

[0061] The above DCF transmission method is a concept for providing services during contention periods, and to request channel usage, traffic priorities can be divided into IFS (inter-frame space) to handle waiting times. That is, priority can be determined by the size of the waiting time, and the shorter the time, the waiting time may be for a packet with higher priority. The above IFS may include SIFS (short IFS), PIFS (PCF IFS), and DIFS (DCF IFS).

[0062] The above SIFS has the shortest period and high priority, and can be used primarily as a waiting time for control information. The above PIFS has a medium-length period and can have a medium level of priority. The above DIFS has the longest time interval compared to SIFS and PIFS, has low priority, and is mainly used as a waiting time for channel checking. That is, during the DIFS period, the channel is listened to (or waited for). If the channel is busy during the DIFS period, transmission may be delayed.

[0063] However, since this DCF method does not consider the priority between STAs, it has the problem of being difficult to support various forms of data transmission and QoS (Quality of Service); therefore, HCF (hybrid coordination function) was introduced. HCF is based on the aforementioned DCF and PCF (point coordination function). PCF refers to a polling-based synchronous access method that periodically polls all receiving APs and / or STAs so that they can receive data frames. HCF includes EDCA (enhanced distributed channel access), a contention-based channel access method, and HCCA (HCF controlled channel access), a contention-based method utilizing a polling mechanism. Furthermore, HCF includes a media access mechanism to enhance the QoS of the WLAN and can transmit QoS data during both the contention period (CP) and the contention-free period (CFP).

[0064] FIG. 4 is a drawing illustrating an example of a frame structure used in an IEEE 802.11 system according to one embodiment of the present disclosure.

[0065] The PPDU (physical layer protocol data unit) format may be configured to include at least one of the STF (short training field), LTF (long training field), SIG (signal) field, and data field. The most basic (e.g., non-HT (high throughput)) PPDU frame format may consist only of L-STF (legacy-STF), L-LTF (legacy-LTF), SIG field, and data field.

[0066] STF can be used for frame timing acquisition, automatic gain control (AGC), diversity detection, and coarse frequency / time synchronization. LTF can be used for fine frequency / time synchronization and channel estimation. STF and LTF together can be referred to as the PLCP preamble, and the PLCP preamble can be described as a signal for synchronization and channel estimation in the OFDM physical layer.

[0067] The SIG field can be used to transmit control information for demodulation and decoding of the data field. The SIG field may include information regarding the data rate and data length. Additionally, the SIG field may include a parity bit, a SIG TAIL bit, etc.

[0068] The data field may include a SERVICE field, a PSDU (physical layer service data unit), and PPDU TAIL bits, and may also include padding bits if necessary. Some bits of the SERVICE field may be used for the descrambler at the receiver. The PSDU corresponds to the MPDU (mac protocol data unit) defined at the MAC layer and may contain data generated or used by the upper layer. The PPDU TAIL bits may be used to return the encoder to a state of 0. Padding bits may be used to adjust the length of the data field to a predetermined unit.

[0069] MPDUs 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). A MAC frame is composed of an MPDU and can be transmitted or received through the PSDU of the data portion in the PPDU format.

[0070] The MAC header is defined as an area including a frame control field, a duration / ID field, an address 1 field, an address 2 field, an address 3 field, a sequence control field, an address 4 field, a QoS control field, and an HT control field.

[0071] The frame control field contains information about the characteristics of the corresponding MAC frame. The interval / identifier field can be implemented to have different values ​​depending on the type and subtype of the corresponding MAC frame.

[0072] The address 1 to address 4 fields are used to indicate the BSSID, source address (SA), destination address (DA), transmitting address (TA) representing the transmitting STA address, and receiving address (RA) representing the receiving STA address.

[0073] The sequence control field is configured to include a sequence number and a fragment number. The sequence number may indicate the sequence number assigned to the corresponding MAC frame. The fragment number may indicate the number of each fragment of the corresponding MAC frame.

[0074] The QoS control field contains information related to QoS. The QoS control field may be included if the Subtype subfield indicates a QoS data frame. The HT control field contains control information related to HT and / or VHT transmission and reception techniques.

[0075] The frame body is defined as the MAC payload, contains the data to be transmitted from the upper layer, and has a variable size. For example, the maximum MPDU size can be 11,454 octets, and the maximum PPDU size can be 5.484 ms.

[0076] FCS is defined as the MAC footer and is used for error detection in MAC frames.

[0077] The first three fields (frame control field, interval / identifier field, and address 1 field) and the very last field (FCS field) constitute the minimum frame format and are present in all frames. Other fields may exist only in specific frame types.

[0078] The following describes the network allocation vector (NAV) used in wireless LAN networks.

[0079] The CSMA / CA mechanism includes virtual carrier sensing in addition to physical carrier sensing, where APs and / or STAs directly sense the medium. Virtual carrier sensing is intended to compensate for problems that may occur in medium access, such as hidden node issues. For virtual carrier sensing, the MAC of a wireless LAN system may utilize NAV. NAV is a value that indicates to other APs and / or STAs the time remaining until the medium becomes available, provided that the AP and / or STA currently using or authorized to use the medium is using it. Therefore, the value set as NAV corresponds to the period during which the medium is scheduled to be used by the AP and / or STA transmitting the frame, and the STA receiving the NAV value is prohibited from accessing the medium during that period. NAV can be set, for example, based on the value of the duration field in the frame's MAC header.

[0080] FIG. 5 is a diagram illustrating an example of a network allocation vector (NAV) setting according to one embodiment of the present disclosure.

[0081] Referring to FIG. 5, the source STA (source STA, 500) transmits an RTS frame after DIFS, and the destination STA (destination STA, 510) transmits a CTS frame after SIFS. The destination STA (510), designated as the recipient via the RTS frame, does not set the NAV. Some of the remaining STAs (620) receive the RTS frame and set the NAV (530), while others receive the CTS frame and set the NAV (540).

[0082] If a CTS frame (e.g., PHY-RXSTART.indication primitive) is not received within a certain period from the time when an RTS frame is received (e.g., when a MAC receives the PHY-RXEND.indication primitive corresponding to the RTS frame), STAs that set or updated the NAV through the RTS frame may reset the NAV (e.g., 0). The certain period may be (2*aSIFSTime + CTS_Time + aRxPHYStartDelay + 2*aSlotTime). CTS_Time may be calculated based on the length and data rate of the CTS frame indicated by the RTS frame. The above certain period may be the NAVTimeout period.

[0083] In FIG. 5, for convenience, NAV setting or updating is exemplified through an RTS frame or a CTS frame, but NAV setting / resetting / updating may also be performed based on the interval field of various other frames, such as non-HT PPDU, HT PPDU, VHT PPDU, or HE PPDU (for example, the interval field within the MAC header of a MAC frame).

[0084] In addition, 802.11ax introduced basic NAV and intra-BSS NAV. Basic NAV is always set (mandatory) to NAV based on frames transmitted by APs or STAs other than itself, while intra-BSS NAV is optionally set to NAV based on frames transmitted by the BSS to which it belongs. An AP or STA can access the medium when both NAV timers have expired (or after the NAV time interval has elapsed).

[0085] The following describes TXOP. TXOP (transmission opportunity) was newly introduced in 802.11e MACs to guarantee QoS and increase channel utilization. To guarantee QoS, TXOP can be used to allocate an opportunity for priority transmission when two or more packets belong to the same AC (access category).

[0086] FIG. 6 is a drawing illustrating an example of a TXOP (transmission opportunity) according to one embodiment of the present disclosure.

[0087] STAs participating in QoS transmission can obtain a TXOP that allows them to transmit traffic for a certain period by using two channel access methods: EDCA (enhanced distributed channel access) and HCCA (HCF controlled channel access). Obtaining a TXOP is possible by succeeding in an EDCA competition or by receiving a QoS CF-Poll (Contention-Free Poll) frame from an AP; the former is referred to as an EDCA TXOP, and the latter as a Polled TXOP. In this way, the concept of a TXOP can be used to grant a specific amount of time for any STA to transmit a frame, or to forcibly limit the transmission time.

[0088] The transmission start time and maximum transmission time of a TXOP are determined by the AP, and this is notified to the STA by a beacon frame in the case of an EDCA TXOP, and by a QoS CF-Poll frame in the case of a Polled TXOP.

[0089] NAV can be understood as a type of timer designed to protect the TXOP of a transmitting STA (e.g., a TXOP holder). An STA can protect the TXOPs of other STAs by not performing channel access during the period when the NAV set for it is valid. In current wireless LAN systems, the TXOP duration is set via the duration field of the MAC header. That is, the TXOP holder and the TXOP responder (e.g., an Rx STA) transmit frames containing all the TXOP information necessary for the transmission and reception of the frames in the duration field of the frames being exchanged between them. Third-party STAs that are not the TXOP holder or TXOP responder (e.g., third-party STAs) check the duration field of the frames exchanged between the TXOP holder and the TXOP responder, and delay channel usage until the NAV period expires by setting or updating the NAV.

[0090] The 802.11be standard is described below. Also known as EHT (extremely high throughput), 802.11be operates across the 2.4, 5, and 6 GHz bands. It is being developed to provide low latency and high network throughput by introducing a 320 MHz wide bandwidth, 4096QAM, multiple resource units (RUs), and multi-link operation (MLO), offering speeds up to 46 Gbps—4.8 times faster than WiFi 6. Specifically, 802.11be provides a 320 MHz wide bandwidth in the 6 GHz band and can transmit data via MU-MIMO, which offers 16 spatial streams in both uplink and downlink; it also achieves high transmission efficiency by adopting 4096QAM. Furthermore, it features enhanced spectrum efficiency by flexibly performing spectrum resource scheduling through multiple RUs, and the ability to simultaneously transmit and receive data across various frequency bands and channels through multi-link operation.

[0091] The following describes Ultra High Reliability (UHR). UHR refers to a technical objective designed to provide ultra-high reliability within the IEEE 802.11 standard. UHR ensures stable wireless communication in latency-sensitive and reliability-critical applications such as industrial automation, telemedicine, and AR / VR. It addresses the issue where existing Wi-Fi technology, despite providing high bandwidth, failed to adequately meet the requirements for reliability and low latency. To achieve this, it utilizes technologies such as Multi-Link Operation (MLO) and Dynamic Subchannel Operation (DSO) to minimize interference and maximize reliability. Additionally, it includes efficient retransmission mechanisms and QoS management functions to reduce data transmission failures. It is characterized by maintaining stable performance even in high-density network environments and expanding the use of Wi-Fi in applications requiring ultra-low latency and ultra-high reliability.

[0092] Below, we describe OBSS (overlapping basic service set) or inter-BSS (basic service set). As the number of users increases, the performance of existing wireless LAN networks, such as transmission rates, decreases significantly. This is because wireless LAN systems fundamentally utilize the CSMA / CA method, which corresponds to time division access control; therefore, when an adjacent network is detected, the frequency resources of the same band are shared for the duration of the adjacent network's activity.

[0093] Currently, it is common for multiple APs to operate in specific areas, and in such cases, the performance of wireless LAN networks degrades due to coverage overlap between APs. This is because the APs of each BSS and the STAs connected to them are affected by signals from adjacent BSSs, resulting in interference and a reduction in transmission rates caused by collisions between signals transmitted simultaneously. BSSs that can affect signal transmission in this way (or have overlapping coverage) can be referred to as overlapping BSSs (OBSS) or inter-BSS (basic service set). The content described below regarding OBSSs can be equally applied even if the term inter-BSS is used.

[0094] FIG. 7 illustrates a wireless communication system including multiple access points and stations according to one embodiment of the present disclosure.

[0095] Referring to FIG. 7, the wireless communication system (700) includes a first AP (700), a second AP (710), and a third AP (720), and may include STA 1-1 (705) and STA 1-2 (707) connected to the first AP (700), STA 2-1 (715) and STA 2-2 (717) connected to the second AP (710), and STA 3 (725) connected to the third AP (720). In FIG. 7, the first AP (700), the second AP (710), and the third AP (720) may each form a wireless local area network (WLAN) (703, 713, 723). The circular shape of the WLAN (703, 713, 723) shown in Fig. 7 can also be understood as representing the coverage area where STAs included in the corresponding infrastructure basic service set (BSS) of each AP maintain communication.

[0096] The first AP (700), the second AP (710), and the third AP (720) are assigned unique media access control (MAC) addresses. The WLAN (703, 713, 723), depicted as a circular shape in FIG. 7, is illustrated as an infrastructure BSS, which is a basic building block in an IEEE 802.11 system; however, in other exemplary embodiments, the WLAN (703, 713, 723) may include an independent basic service set (IBSS) network. This area may be referred to as the Basic Service Area (BSA). When a STA moves out of the BSA, it is no longer able to communicate directly with other STAs within that BSA.

[0097] STAs (705, 707, 715, 717, 725) are devices that operate in accordance with the Medium Access Control (MAC) / PHY specifications of IEEE 802.11. Unless the function of the STA is individually distinguished from that of the AP, the STA may include AP STAs and non-AP STAs. However, when communication is performed between the STA and the AP, the STA may be understood as a non-AP STA. The stations (705, 707, 715, 717, 725) may be any suitable Wi-Fi-enabled wireless device or electronic device, including, for example, a cell phone, a personal digital assistant (PDA), a tablet device, a laptop computer, etc. The stations (705, 707, 715, 717, 725) may also be referred to as user equipment (UE), subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, electronic device, or any other suitable technical term.

[0098] In FIG. 7, the second AP (710) and the third AP (720) may have an overlapping set of basic services (overlapping BSS, OBSS) that overlaps with the first AP (700), in which case the second AP (710) and the third AP (720) may be referred to as OBSS APs. In this case, the second AP (710) and the third AP (OBSS AP) (720) may overhear signals transmitted (e.g., broadcast) by the first AP (700).

[0099] In one embodiment, the first AP (700) may operate as a sharing AP that shares TXOPs with other APs or STAs, and the second AP (710) may operate as a shared AP that shares TXOPs from the first AP (700).

[0100] FIG. 8 is a diagram illustrating an example of the configuration of a Multi-AP (access point) Coordination (MAPC) framework of a wireless LAN system according to one embodiment of the present disclosure.

[0101] In this disclosure, methods for verifying whether an AP is capable of supporting Multi-AP operation and ensuring reliability are described prior to association or connection for performing Multi-AP operation among a plurality of APs.

[0102] More specifically, in order to perform coordination operations among APs according to a Multi-AP coordination scheme (hereinafter referred to as the MAPC scheme) (e.g., C-TDMA (coordinated time division multiple access), CR-TWT (coordinated restricted target awake time), C-SR (coordinated spatial reuse), or C-BF (coordinated beamforming)), capability information (e.g., Multi-AP capability) among APs needs to be shared. Additionally, authentication may be required to determine whether they can be combined into a single pair or group to perform Multi-AP operations by indicating whether security is required.

[0103] In this case, cooperative operation among APs may include functions such as Coordinated Operating mode negotiation and Coordinated Power saving scheduling, which involve APs cooperating to negotiate / agree on an operating mode or power saving mode scheduling.

[0104] In addition, as with the examples described above, cooperative operations between APs may be referred to as Multi-AP (M-AP or MAP, hereinafter referred to as M-AP), Coordinated-AP (C-AP), or Multi-AP Coordination (MAPC, or MAP-C), and for smooth M-AP operation, operations or processes for communication between APs may be referred to. Hereinafter, in the present disclosure, the cooperative operations between APs described above may be referred to as MAPC, but are not limited to this designation.

[0105] Additionally, the MAPC operation described in this disclosure may be performed in a single AP pair or an AP group comprising multiple APs. Accordingly, in the embodiments described below, at least these APs performing the MAPC operation may form a single AP pair or a single AP group. However, for convenience of explanation, this disclosure includes an example in which a single AP pair composed of two APs performs the MAPC procedure.

[0106] Referring to Fig. 8, in 802.11bn, the procedure for each AP to share or advertise (hereinafter referred to as advertisement) the MAPC capabilities they support and to negotiate or agree on which MAPC scheme to use can be defined as a general MAPC framework.

[0107] More specifically, in step 810, the advertisement of MAPC capability may broadcast or announce information regarding each AP's MAPC capability through a management frame (e.g., a beacon). Additionally, the management frame for the advertisement of MAPC capability may be referred to as a MAPC capability advertisement frame.

[0108] Accordingly, MAPC capabilities can be shared or exchanged between at least two APs (hereinafter referred to as AP1 and AP2) in an unencrypted state. Additionally, a broadcasted MAPC capability of a specific AP can be discovered by at least one other AP. For example, at least one neighboring AP can overhear information from an AP broadcasting MAPC capabilities, which may be referred to as MAPC discovery passive scanning. Thus, information related to MAPC between APs can be identified by the advertisement of MAPC capabilities. For example, an AP can identify information regarding whether at least one other AP supports MAPC or the status of its MAPC operation. In one embodiment, an AP can identify at least one other AP capable of participating in or supporting MAPC operations. In one embodiment, APs participating in MAPC operations may identify which MAPC operation (e.g., MAPC scheme) to perform based on the information regarding the discovered MAPC capabilities. Of course, the MAPC scheme may also be determined in a step after step 810 (e.g., the ICF (initial control frame) / ICR (initial control response) exchange operation at the TXOP (transmission opportunity) level).

[0109] In step 820, based on the MAPC capabilities exchanged between APs, the APs can perform authentication. The authentication operation in step 820 may include an authentication procedure to determine whether MAPC operations between APs are possible. The authentication operation in step 820 may be one of the IEEE 802.11 authentication methods (e.g., Fast BSS Transition (FT) authentication, Simultaneous Authentication of Equals (SAE), FILS authentication, Pre-association Security Negotiation (PASN) authentication, or Wi-Fi Protected Access 3 (WP3)-based authentication). If the authentication operation in step 820 is one of the FT authentication, SAE, FILS authentication, PASN authentication, or WP3-based authentication exemplified above, an authentication procedure to determine whether MAPC operations between APs are possible may be performed by including it in part of the detailed message of the aforementioned authentication operation.

[0110] An AP can enhance security through an authentication operation to perform MAPC operations with an authenticated OBSS (or inter-BSS) AP (e.g., an AP of another BSS that overlaps with its own BSS (basic service set). However, Step 820 may not be a mandatory step and may be performed optionally depending on security requirements. For example, if authentication between APs is completed prior to the operation of the present disclosure, Step 820 may be omitted. As another example, Step 820 may be performed as a separate step prior to Step 850 below, or it may be performed together with Step 850.

[0111] In step 830, based on steps 810 and 820, a combination or connection between APs (hereinafter referred to as MAPC combination) may be performed. For example, APs that detect MAPC capabilities through step 810 and mutually discover each other may be assigned a MAPC AID (e.g., referred to as an AID between APs or an AP ID) for combination. Meanwhile, the MAPC AID assigned for mutual identification between APs may be referred to as an AID or an AP ID, but it should be noted that it may refer to a different meaning from the AID assigned between an AP and a non-AP STA as described above. Additionally, the assigned AIDs are exchanged between APs so that the APs can identify each other's AIDs. In one embodiment, an AID may be assigned to each AP. In another embodiment, in addition to the MAPC AID, an ID to designate an AP pair or AP group may be additionally assigned, which may be referred to as a MAPC Group ID (or MAPC GID).

[0112] In step 840, APs can generate and negotiate security keys to support trigger frames based on WPS, etc. or MAC header protection. At this time, signaling may be possible by adopting security procedures defined in IEEE 802.11 (e.g., Wi-Fi Protection Setup between APs or RSNA (robust security network association)).

[0113] In step 850, APs may perform negotiation and agreement on MAPC features or features. Even when referred to as a negotiation procedure or an agreement procedure in this disclosure, it may mean a procedure that includes both negotiation and agreement operations of step 850. Additionally, MAPC features may refer to features or functions that are distinguished according to the MAPC scheme, or, even if they relate to the same MAPC scheme, are distinguished according to the logical session (hereinafter referred to as a session) created when different sessions are created through negotiation / agreement between APs.

[0114] In step 860, APs can perform actions corresponding to the MAPC scheme(s) agreed upon between APs through the aforementioned steps 810 or 850.

[0115] The names of each step in FIG. 8 described above are merely examples to explain the operation of the corresponding step and are not limited to the examples provided. Accordingly, each step may be replaced with an appropriate term to explain the corresponding operation. For example, the MAPC combination in step 830 described above may be referred to as MAPC link establishment, MAPC pre-negotiation, MAPC pre-configuration, or MAPC ID allocation.

[0116] In addition, although the description in Fig. 8 describes MAPC operations performed between two APs, it can be similarly applied to cases where operations are performed between three or more APs (e.g., a group of APs).

[0117] FIG. 9 is a diagram illustrating an example of Co-TDMA operation of a wireless LAN system according to one embodiment of the present disclosure.

[0118] As discussions on the 802.11bn standard progress, various proposals to improve Co-TDMA are being discussed. Co-TDMA refers to a procedure for a specific AP to share the time resources of a TXOP it has acquired with a set of other APs, and it may also be called TXS (TXOP sharing) in that it is a procedure for a specific AP to share a TXOP with another AP.

[0119] An AP that shares (or transfers) the TXOP it has acquired to another AP in Co-TDMA or TXS may be referred to as a sharing AP. The sharing AP announces its intention to share at least a portion of the time resources of the TXOP it has acquired, and this process can be accomplished by transmitting an initial control frame (ICF) at the beginning of the TXOP (905).

[0120] The ICF transmitted by the sharing AP may be a frame for the sharing AP to poll the interest of the target APs to share the TXOP, and an AP that receives (or receives) a portion of the TXOP acquired by the sharing AP in this way may be referred to as a shared AP or a polled AP. The names Sharing AP, shared AP, and polled AP are merely exemplary names for APs participating in Co-TDMA and TXS, and may be referred to by other names instead of the ones mentioned.

[0121] The ICF (905) transmitted by the sharing AP may include a duration field, and the duration field of the ICF (905) may be set to a value representing the time length of the time plus SIFS for transmitting the ICR (initial control response) which is a response to the ICF (905).

[0122] The ICF (905) transmitted by the Sharing AP can be delivered to STA1, which is the associated STA of the Sharing AP, and to the shared AP adjacent to the sharing AP. Upon receiving the ICF (905), STA1 can transmit an ICR (initial control response) to the sharing AP to respond to the ICF (910). The shared AP that receives the ICF (905) from the Sharing AP can also transmit an ICR (915) to the sharing AP to respond to the ICF (905).

[0123] The sharing AP sends a DL PPDU or a DL MU (multi-user) PPDU to STA1 within its TXOP (955) (920), and STA1 can send a BA (block ack) to the sharing AP in response to the reception of the DL PPDU (925).

[0124] Meanwhile, as the sharing AP decides to share at least some of its TXOPs with the shared AP, the sharing AP may transmit a MU-RTS TXS TF (trigger frame) to the shared AP to indicate the start (or initiation) of these TXS (or C-TDMA) (930).

[0125] FIG. 9 illustrates an embodiment in which a sharing AP transmits a MU-RTS TXS TF to one shared AP, but the sharing AP may transmit the MU-RTS TXS TF to one or more shared APs (i.e., a set of APs).

[0126] A shared AP that receives a MU-RTS TXS TF can send a CTS frame to a sharing AP to indicate that it has confirmed the start (or initiation) of the TXS (or C-TDMA) (935), and can send a DL (MU) PPDU to a non-AP STA, STA2, which is coupled with itself, within the time resources (960) allocated to it (940).

[0127] Meanwhile, the time resource (960) allocated to the Shared AP may be indicated by the allocation duration field of the previously described MU-RTS TXS TF (930). STA2 may send a BA to the shared AP in response to the received DL (MU) PPDU (945). The Sharing AP may monitor the TXOP and, upon confirming that there is no data transmission or reception during the PIFS, reclaim the TXOP that was shared with the shared AP, and accordingly, perform a separate transmission and reception procedure by sending a basic TF within its own TXOP (960).

[0128] The TXS described in Fig. 9 can be distinguished from the existing procedure of sharing TXOPs between APs and non-AP STAs in that it shares TXOPs between APs.

[0130] FIG. 10 is a diagram illustrating an example of a Co-TDMA or TXS (triggered TXOP sharing) operation according to one embodiment of the present disclosure.

[0131] FIG. 10 shows that a sharing AP (associated with BSS1) transmits an ICF for polling Co-TDMA (or TXS) to a non-AP STA (associated with BSS1) and a shared AP (associated with BSS2) combined with it (1005), and this ICF may be intended to announce the intention of the sharing AP to share some of its TXOP time resources with the shared AP and / or STA, and the ICF may include a BSRP (buffer status report poll) trigger frame.

[0132] Subsequently, the non-AP STA and shared AP that received the ICF can send an ICR to the sharing AP (1010, 1015) to indicate whether the non-AP STA and shared AP will each participate in Co-TDMA (or TXS), and the ICR may include a multi-STA block ACK frame.

[0133] Meanwhile, the time interval indicated by the duration field of the ICF transmitted by the sharing AP may be equal to the sum of the lengths of the frame for SIFS and ICR transmission. In this case, after the ICF / ICR exchange, the sharing AP may receive the ICR (1015) to occupy a time interval including a time interval for frame exchange (1035) to communicate with the STA in its BSS (BSS1) and a time interval to transfer to the shared AP, and transmit a MU-RTS (1020) frame after the SIFS time.

[0134] The Sharing AP can send a MU-RTS (1020) and the STA in BSS1 can send a CTS (1025) to indicate that a frame exchange (1035) in BSS1 follows, and optionally the Shared AP can send a CTS (1030) to additionally set up NAV for the STAs in BSS2 of the Shared AP to protect the Sharing AP's frame exchange (1035).

[0135] After the frame exchange (1035) within its BSS is terminated, the sharing AP transmits a MU-RTS TXS TF (1040) to the shared AP to indicate the start (or initiation) of the TXS (or C-TDMA) within the TXOP, and the shared AP may transmit a CTS frame (1045) to the sharing AP in response.

[0136] Through the above MU-RTS TXS TF (1040), the sharing AP can specify the time interval in which TXS (or C-TDMA) is to be performed within the TXOP, and subsequently, the shared AP can perform frame exchange according to TXS (or C-TDMA) (1050).

[0137] According to the above-described embodiment, the sharing AP may separately transmit a frame (i.e., a MU-RTS trigger frame) for transmitting scheduling information for a TXOP to be performed on a TXS (or C-TDMA) and a frame (MU-RTS TXS TF) for indicating that the TXS (or C-TDMA) has actually started (or started). According to the proposed embodiment, by the sharing AP transmitting a MU-RTS trigger frame and the shared AP receiving it transmitting a CTS frame for a response, the sharing AP can not only transmit TXOP scheduling information for the TXS (or C-TDMA) but also resolve the hidden node problem located between the sharing AP and the shared AP.

[0138] Meanwhile, according to another embodiment, in order to resolve the over-protection problem, a shared AP that receives a MU-RTS trigger frame from a sharing AP may not transmit a response frame such as a CTS.

[0139] In FIG. 10, the time interval for sending the ICF (1005) and ICR (1010), and the MU-RTS (1020), CTS (1025), frame exchange (1035), MU-RTS TXS TF (1040), CTS (1045), and frame exchange (1050) can be composed of a single TXOP. In this case, the interval indicated by the duration field in the ICF (1005) may be the sum of the frame lengths for SIFS and ICF transmission, but the TXOP length may be extended according to the duration field of the frame transmitted in the subsequent MU-RTS (1020) and Frame exchange (1035).

[0142] FIGS. 11a, FIGS. 11b, and FIGS. 11c illustrate an example of a case where the MAPC agreement is terminated after Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure.

[0143] FIGS. 11a, FIGS. 11b, and FIGS. 11c illustrate an example of a case where MAPC agreement is terminated after MAPC agreement between access points through the operation of FIG. 8 described above.

[0144] Referring to FIG. 11a, after AP1 and AP2 complete the MAPC agreement through the operation of FIG. 8, if AP2 is unavailable for a certain period of time, AP1 may terminate the MAPC agreement. In this case, an agreement between AP1 and AP2 regarding termination or an agreement related to a keep-alive condition that the MAPC agreement is valid may be required.

[0145] Alternatively, if AP1 or AP2 wishes to terminate the said MAPC agreement, AP1 or AP2 may require an agreement between AP1 and AP2 that enables the termination of the said MAPC agreement, or an agreement regarding the keep-alive conditions for which the said MAPC is valid.

[0146] Referring to FIGS. 11b and 11C, after the AP and mobile-AP (or AP STA) complete the MAPC agreement through the operation of FIG. 8, if the mobile-AP moves out of the coverage of the AP or if the mobile-AP's operation is terminated by a user, an agreement regarding termination between the AP and mobile-AP, or an agreement related to a keep-alive condition where the MAPC agreement is valid, may be required.

[0148] FIG. 12 is a diagram illustrating an example of a framework for Multi-AP Coordination (MAPC) including an agreement operation for a MAPC keep-alive condition of a wireless LAN system according to one embodiment of the present disclosure.

[0149] FIG. 12 describes a method for performing agreement on MAPC agreement keep-alive conditions in particular within a general framework for cooperative operation between APs illustrated in FIG. 8. Accordingly, FIG. 12 omits descriptions of configurations that overlap with those described in FIG. 8, and FIG. 8 may be referenced for the omitted descriptions.

[0150] Referring to Fig. 12, in step 1210, APs can perform a beacon-based MAPC discovery procedure. APs can discover neighboring APs along with information about each AP's MAPC capability broadcast through beacons or MAPC advertisement frames. That is, through the MAPC Discovery passive scanning process, APs can mutually discover that they are APs that support MAPC operation or have MAPC functions enabled within each other's coverage.

[0151] The above MAPC Discovery passive scanning process may be a process in which an AP includes information about the MAPC scheme it supports within a beacon message or MAPC Advertisement frame that it periodically broadcasts, thereby enabling an adjacent AP that receives the beacon to know the MAPC scheme supported or activated by the AP sending the beacon or MAPC Advertisement frame. Step 1210 may refer to the framework described in Step 810 of FIG. 8. The above MAPC Advertisement frame may be a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame, in which the Action Details field value in FIG. 18c, to be described later, signifies a MAPC Advertisement.

[0152] In step 1220, APs can perform a unicast-based MAPC discovery procedure along with an authentication procedure based on step 1210. Through the unicast-based MAPC discovery procedure, namely the MAPC Discovery active scanning process, APs can mutually discover that they are APs that support MAPC operation within each other's coverage.

[0153] The above MAPC Discovery active scanning may be a process in which two adjacent APs exchange mutually supported MAPC schemes and related information through a procedure in which an adjacent AP transmits a MAPC discovery request requesting information regarding whether MAPC operation is supported, whether it is enabled, whether authentication is required, or whether a secure channel needs to be formed by transmitting a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame, etc., by designating the adjacent AP as the destination address of the frame, and the AP that receives it responds as a response. Step 1220 may refer to the framework described in Step 820 of FIG. 8.

[0154] In step 1230, APs may perform a combination or association among APs (hereinafter referred to as MAPC association) based on steps 1210 and 1220, and may perform a common negotiation or agreement on the MAPC. In one embodiment, APs may perform an agreement or negotiation on a keep-alive condition of the MAPC agreement among APs in step 1230.

[0155] In step 1240, APs may perform negotiations and agreements specific to the MAPC scheme. In one embodiment, APs may set initial configurations and operation parameters used for the MAPC scheme. In one embodiment, the MAPC association may be performed in step 1240. In one embodiment, agreement or negotiation regarding the MAPC keep-alive condition may be performed in step 1240. For a description of steps 1230 and 1240, refer to the framework described in steps 830 through 850 of FIG. 8.

[0156] Afterwards, APs can perform MAPC scheme operations agreed upon among APs through the aforementioned steps 1210 to 1240.

[0157] The frame used for each operation between APs in FIG. 12 may be one of the Public Action frame, Protected dual of Public Action frame, UHR Action frame, and Protected UHR Action frame described in FIG. 18a, FIG. 18b, and FIG. 18c.

[0159] FIG. 13 is a diagram illustrating an example of Multi-AP Coordination (MAPC) agreement operation according to one embodiment of the present disclosure.

[0160] FIG. 13 is an example of signaling for a common MAPC negotiation (consultation) between a first AP (MAPC agreement requesting AP) and a second AP (MAPC agreement responding AP). In one embodiment, FIG. 13 may correspond to the frame exchange operation of step 1230 of FIG. 12.

[0161] In step 1310, one of the two APs (the first AP) that mutually recognizes itself as supporting MAPC through the MAPC Discovery passive scanning process or the MAPC Discovery active scanning process can transmit a MAPC agreement request frame to the second AP.

[0162] The above MAPC agreement request frame may include at least one of the following information / fields.

[0163] - AP ID: The AID used by the first AP to refer to the second AP. It is the value assigned by the first AP to the second AP.

[0164] - MAPC Scheme Name: The name of the MAPC scheme to be negotiated through the request

[0165] - MAPC Agreement ID (MID): An ID used to collectively refer to the MAPC scheme negotiated through the negotiation / agreement process and its corresponding operational parameters, for future status management or operational parameter updates.

[0166] - MAPC keep-alive condition: Information regarding the keep-alive (valid or maintained) condition of the MAPC agreement reached through the relevant negotiation / agreement process (MAPC keep-alive condition).

[0167] Detailed information regarding the keep-alive (valid or maintained) condition of the above MAPC agreement (MAPC keep-alive condition) can be referenced in Fig. 21, which will be described later.

[0168] In step 1320, the second AP that received the MAPC agreement request frame in step 1310 can transmit a MAPC agreement response frame to the first AP in response thereto.

[0169] The above MAPC agreement response frame may include at least one of the following information / fields.

[0170] - AP ID: The AID used by the second AP to refer to the first AP. It is the value assigned by the second AP to the first AP.

[0171] - MAPC Scheme Name: May be included to verify that the value is identical to the MAPC scheme name received in the above MAPC agreement request frame.

[0172] - MAPC agreement ID (MID): May include a value identical to the value received in the above MAPC agreement request frame, or may be omitted.

[0173] - MAPC keep-alive condition: Information regarding the keep-alive condition of the MAPC agreement reached through the relevant negotiation / agreement process (MAPC keep-alive condition)

[0174] In one embodiment, the MAPC agreement request frame and the MAPC agreement response frame may include a MAPC association request / response element comprising at least one of the AP ID and the MAPC agreement ID (MID).

[0175] In one embodiment, the frame used for each operation between APs in FIG. 13 may be one of the Public Action frame, Protected dual of Public Action frame, UHR Action frame, and Protected UHR Action frame described in FIG. 18a, FIG. 18b, and FIG. 18c.

[0176] In this disclosure, the terms "negotiation" and "agreement" may be used interchangeably, and both refer to the act of forming an agreement on specific parameters or functions between two or more devices or network entities. Accordingly, even if the terms "negotiation" or "agreement" are described alone in this specification, they may be understood to include the content described by the relative terms.

[0177] FIG. 14 is a diagram illustrating a keep-alive condition for a Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure.

[0178] In the present disclosure, a keep-alive condition for a MAPC agreement (MAPC keep-alive condition) may refer to a condition for determining to automatically terminate the MAPC agreement (MAPC Agreement teardown) after a certain period of time has elapsed without a MAPC operation or keep-alive operation (keep-alive timeout) following the time when the MAPC agreement between APs is completed or the last operation performed after completion (e.g., a TXOP / SP-based MAPC operation).

[0179] In one embodiment, terminating MAPC consensus among APs may include flushing MAPC consensus-related operation parameters and retrieving the AP ID, MAPC agreement ID (or management ID), etc.

[0180] In one embodiment, the last operation between APs for determining the keep-alive timeout may include at least one of a MAPC operation, MAPC management (management operations such as MAPC operating parameter updates, status updates, etc. within a MAPC TWT SP or TXOP), or an operation of transmitting and receiving a MACP keep-alive frame. In one embodiment, the MACP keep-alive frame may refer to a frame transmitted at regular intervals to prevent the connection from being disconnected, as described in detail in FIG. 15.

[0181] In one embodiment, a certain period after the last operation for defining the keep-alive timeout may be agreed upon based on at least one of absolute time (e.g., seconds or minutes, etc.) or the transmission period (interval) of the keep-alive frame * the number of keep-alive frames. In one embodiment, if a beacon is not received for a time equal to TBTT (target beacon transmission time) * n after the last beacon reception, it may be agreed that the keep-alive timeout has occurred.

[0182] Referring to Fig. 14, as an example of the MAPC keep-alive condition described above, after MAPC agreement between APs is completed, and after a MAPC operation or MAPC TWT SP is performed, if four (keep-alive count) MAPC keep-alive intervals (MAPC keep-alive timeout) have elapsed without any MAPC operation or keep-alive operation, the MAPC agreement may be terminated (MAPC Agreement teardown).

[0183] FIG. 15 is a diagram illustrating an example of an operation for transmitting a keep-alive Action frame for Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure.

[0184] In the present disclosure, a MAPC keep-alive action frame may refer to an action frame transmitted by an AP that does not intend to terminate the MAPC even if there is no MAPC operation or MAPC management, such as MAPC operating parameter updates or status updates, for a certain period of time. That is, a MAPC keep-alive action frame may refer to a frame transmitted at regular intervals to maintain MAPC consensus and prevent the MAPC consensus from terminating even in a state of inactivity.

[0185] In one embodiment, the MAPC keep-alive action frame may include information about an identifier (at least one of an AP ID or a MAPC management ID (or a MAPC agreement ID)) that designates the MAPC agreement to which keep-alive is to be applied, and details may be referred to in FIG. 22, which will be described later.

[0186] In one embodiment, an AP that receives a MAPC keep-alive action frame can transmit an Ack frame. In one embodiment, APs that transmit and receive a MAPC keep-alive action frame can update the MAPC keep-alive timer.

[0187] Referring to FIG. 15, after MAPC agreement between APs is completed, MAPC operations are performed. If one AP transmits a MAPC keep-alive action frame before the MAPC keep-alive timeout, the MAPC keep-alive timer for determining the MAPC keep-alive timeout may be updated. Accordingly, if a certain period elapses (MAPC keep-alive timeout) without any MAPC operations, MAPC operating parameter updates, or status updates after the MAPC keep-alive action frame is transmitted, the MAPC agreement may be terminated (MAPC Agreement teardown).

[0188] In one embodiment, the MAPC keep-alive action frame in FIG. 15 may be one of the Public Action frame, Protected dual of Public Action frame, UHR Action frame, and Protected UHR Action frame described in FIG. 18a, FIG. 18b, and FIG. 18c.

[0189] The MAPC teardown action frame defined in the present disclosure is described below. In the present disclosure, the MAPC teardown action frame may refer to an action frame used to explicitly terminate the MAPC consensus. In one embodiment, the MAPC teardown action frame may be used to notify other APs of termination by explicitly transmitting it when a MACP keep-alive timeout or termination condition between APs is satisfied. As a result, problems caused by channel condition asymmetry between APs can be resolved, and in the case of Co-RTWT, it is possible to prevent unnecessary operations to protect OBSS RTWT, or in the case of Co-TDMA, unnecessary operations to perform Co-TDMA polling.

[0190] In one embodiment, the AP can transmit a MAPC teardown action frame at any time when it wants to terminate the MAPC consensus, regardless of the MACP keep-alive timeout or satisfaction of the termination condition.

[0191] In one embodiment, the MAPC teardown action frame may include information for explicitly terminating the MAPC consensus by defining it as a MAPC teardown element or in the corresponding field within the frame. In one embodiment, the information for explicitly terminating the MAPC consensus may include at least one piece of information among the AP ID and MAPC MID associated with the MAPC consensus to be terminated. In one embodiment, the information for explicitly terminating the MAPC consensus may include information regarding a grace period from the transmission of the MAPC teardown action frame (or MAPC teardown element) until the teardown is performed. For details regarding the information for explicitly terminating the MAPC consensus, refer to FIGS. 23a and 23b.

[0192] In one embodiment, information for explicitly terminating the MAPC consensus (e.g., a MAPC teardown element) may be included and transmitted within the beacon.

[0193] FIG. 16 is a diagram illustrating an example of an operation for transmitting a teardown action frame for Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure.

[0194] Referring to FIG. 16, after MAPC agreement between APs is completed, MAPC operations are performed. If a certain period of time elapses without MAPC operations, MAPC management operations such as MAPC operating parameter updates or status updates (MAPC keep-alive timeout), the MAPC agreement may be terminated (MAPC Agreement teardown). In this case, the AP may explicitly notify that the MAPC agreement has been terminated by transmitting a MAPC teardown action frame. The MAPC teardown action frame may be transmitted for the purpose of notification, and the AP receiving it may not necessarily be required to send an ack frame in response.

[0195] FIG. 17 is a diagram illustrating an example of an operation for transmitting a teardown action frame for Multi-AP Coordination (MAPC) agreement according to one embodiment of the present disclosure.

[0196] Referring to FIG. 17, after MAPC consensus among APs is completed, MAPC operations are performed. Even before a certain period of time elapses (MAPC keep-alive timeout) without MAPC operations, MAPC operating parameter updates, status updates, etc., an AP that wishes to terminate MAPC consensus can terminate MAPC consensus by transmitting a MAPC teardown action frame. In this case, the AP that wishes to terminate MAPC consensus may additionally include information regarding the time when the MACP will be terminated (information regarding the grace period from the transmission of the frame until the teardown is performed) within the MAPC teardown action frame (see FIG. 23a and 23b for details).

[0197] In one embodiment, the MAPC teardown action frame in FIGS. 16 and 17 may be one of the Public Action frame, Protected dual of Public Action frame, UHR Action frame, and Protected UHR Action frame described in FIGS. 18a, 18b, and 18c.

[0198] FIGS. 18a, FIGS. 18b and FIGS. 18c are drawings for illustrating an action frame for MAPC agreement according to one embodiment of the present disclosure.

[0199] FIG. 18a illustrates an example of an Action field format included in an action frame as defined in the IEEE 802.11 standard.

[0200] The Action field shown in FIG. 18a may be included in the frame body of the action frame indicated through the type field and subtype field of the MAC frame in the MAC Header of the MAC frame format within the frame shown in FIG. 4.

[0201] Referring to FIG. 18a, the Action field may include a Category field and an Action Details field.

[0202] The Category field is a field that indicates the category of an action frame and can be set to one of the values ​​defined for the categories of action frames in the IEEE 802.11 standard, and examples of category names and corresponding values ​​are shown in FIG. 18b. An action frame of a specific category may be referred to as the "Category Name" action frame.

[0203] For example, if the value of the Category field is set to a value that designates a UHR category (e.g., xx), the frame may be indicated as a "UHR Action frame." The above UHR Action frame may refer to one of the Action frames for operating an action related to a UHR characteristic.

[0204] For example, the Category field may be set to a value designating a category of Protected UHR to indicate that the frame is a Protected UHR Action frame. In one embodiment, a Protected UHR Action frame is one of the Action frames for operating an action related to UHR characteristics, and in particular, it may refer to an Action frame transmitted between an AP and a STA (or between STAs) after authentication and connection have been completed.

[0205] The Action Details field may include details of the action frame referred to in the Category field. The Action Details field may include different details for each action frame referred to in the Category field.

[0206] The Action Details field may include a field representing a detailed category, and examples of the values ​​of the field representing the detailed category (Action Details field values) are shown in FIG. 18c.

[0207] FIG. 18c illustrates examples of values ​​that can be set, for example, in the Public Action field of a Public Action frame or a Protected dual of a Public Action frame, the UHR Action field of a UHR Action frame, and the Protected UHR Action field of a Protected UHR Action frame.

[0208] Referring to FIG. 18c, the specific name or use of the corresponding action frame can be indicated according to the values ​​of the Public Action field, UHR Action field, and Protected UHR Action field.

[0209] Referring to FIG. 18c, depending on the values ​​of the UHR Action field, Protected UHR Action field, and Public Action field, the corresponding action frame may be indicated as a MAPC Agreement request frame, MAPC Agreement response frame, MAPC Agreement Keep-alive frame, or MAPC Agreement Teardown frame.

[0210] In one embodiment, the Action field value shown in FIG. 18c may not be set in the Public Action field of the Action frame or the Protected dual of the Public Action frame, the UHR Action field of the UHR Action frame, or the Protected UHR Action field of the Protected UHR Action frame. In this case, as described in FIG. 20d, the MAPC Management Type field that may be included in the Action frame may indicate the type of management that the frame intends to perform for the MAPC operation.

[0211] In one embodiment, if the Action Details field value is MAPC Advertisement, it may be an action frame for unidirectional transmission. The MAPC Advertisement Action frame may include information about the MAPC consensus currently being performed, along with MAPC capability, support, and activation status in the MAPC discovery process.

[0212] The MAPC Advertisement Action frame may include a MAPC teardown element that is included in the MAPC teardown action frame (see details in Fig. 22) and may be used to convey information about the MAPC consensus to be terminated.

[0213] The MAPC Advertisement Action frame may include a MAPC keep-alive element included in the MAPC keep-alive action frame (details in FIG. 23a and FIG. 23b) and may be used to convey information about the MAPC consensus to be terminated.

[0214] FIGS. 19a, FIGS. 19b and FIGS. 19c are drawings illustrating an example of an Action field format of an action frame according to one embodiment of the present disclosure.

[0215] FIG. 19a illustrates the Action field format of a UHR Action frame according to one embodiment of the present disclosure. The UHR Action frame may include fields representing the corresponding information in the order shown in FIG. 19a.

[0216] Referring to FIG. 19a, the Action field format of the UHR Action frame may include at least one of a Category field, a UHR Action field, a Dialog Token field, and a field format that depends on the UHR Action field value (UHR Action field value-dependent field format).

[0217] As previously explained, the above Category field may include a value representing the category of the UHR Action frame.

[0218] The above UHR Action field may include a value representing the detailed category of the corresponding action frame, and examples of values ​​that may be included can be seen in FIG. 18c.

[0219] The above Dialog Token field may include a non-zero random value to identify the association (or transaction) between the request and response messages, and may be omitted depending on the UHR Action.

[0220] The field format that varies according to the above UHR Action field value (UHR Action field value-dependent field format) may include specific fields or be defined by corresponding elements (e.g., MAPC elements) depending on the UHR Action field value. An example of this is explained in FIG. 20a.

[0221] FIG. 19b illustrates the Action field format of a Protected UHR Action frame according to one embodiment of the present disclosure. The Protected UHR Action frame may include fields representing the corresponding information in the order shown in FIG. 19b.

[0222] Referring to FIG. 19b, the Action field format of the Protected UHR Action frame may include at least one of a Category field, a Protected UHR Action field, a Dialog Token field, and a field format that depends on the Protected UHR Action field value (Protected UHR Action field value-dependent field format).

[0223] As previously explained, the above Category field may include a value representing the category of the Protected UHR Action frame.

[0224] The above UHR Action field may include a value representing the detailed category of the corresponding action frame, and examples of values ​​that may be included can be seen in FIG. 15c.

[0225] The above Dialog Token field may include a non-zero random value to identify the association (or transaction) between the request and response messages, and may be omitted according to the Protected UHR Action.

[0226] The field format that varies according to the Protected UHR Action field value (Protected UHR Action field value-dependent field format) may include a specific field format or be defined by a corresponding element (e.g., MAPC element) depending on the Protected UHR Action field value. An example of this is explained in FIG. 20a.

[0227] FIG. 19c illustrates the Action field format of a Public Action frame or a Protected dual of a Public Action frame according to one embodiment of the present disclosure. The Public UHR Action frame or the Protected dual of a Public Action frame may include fields representing the corresponding information in the order shown in FIG. 19c.

[0228] Referring to FIG. 19c, the Action field format of a Public Action frame or a Protected dual of a Public Action frame may include at least one of a Category field, a Public Action field, and a field format that depends on the Public Action field value (Public Action field value-dependent field format).

[0229] As previously explained, the above Category field may include a value representing the category of the Public Action frame (or, Protected dual of Public Action frame).

[0230] The above Public Action field may include a value representing the detailed category of the corresponding action frame, and examples of values ​​that may be included can be seen in FIG. 15c.

[0231] The field format that varies according to the Public Action field value (Public Action field value-dependent field format) may include a specific field format or be defined by a corresponding element (e.g., a MAPC element) depending on the Public Action field value. An example of this is explained in FIG. 20a.

[0232] FIGS. 20a, FIGS. 20b, FIGS. 20c and FIGS. 20d are drawings illustrating an example of a MAPC element format that may include MAPC-related information according to an embodiment of the present disclosure.

[0233] FIG. 20a is a drawing illustrating an example of a MAPC element format that may include information related to Co-TDMA operation according to one embodiment of the present disclosure.

[0234] In one embodiment, the MAPC element format may include some or all of the information included in the MAPC agreement request frame and MAPC agreement response frame described in FIG. 13.

[0235] The MAPC element format can be included in one of the Public Action frame, Protected dual of Public Action frame, UHR Action frame, and Protected UHR Action frame described in FIG. 12, and can be transmitted between the MAPC agreement requesting AP and the MAPC agreement responding AP in the AP-to-AP MAPC negotiation / agreement operation steps (steps 1310 and 1320) shown in FIG. 13.

[0236] In one embodiment, the Action field value-dependent field of each Action field format illustrated in FIG. 19a, 19b, and 19c may be defined as a MAPC element of the structure illustrated in FIG. 20a, or may include at least one field of the structure illustrated in FIG. 20a.

[0237] Referring to FIG. 20a, the MAPC element format may include at least one of an Element ID field, a Length field, an Element ID Extension field, a Control field, an Extended Control field, a MAPC Control field, a MAPC Capability field, a MAPC Status field, or a MAPC Operation Parameters field.

[0238] The Element ID field and the element ID extension field can indicate that the element is a MAPC element.

[0239] The Length field may contain a value for the length of the information transmitted through the MAPC element.

[0240] The Control field may contain information related to the control of the MAPC. In this case, the configuration of the sub-fields constituting the Control field is explained in detail below in FIG. 20b.

[0241] The Extended Control field can represent extended information of the Control field and may be optionally included.

[0242] The MAPC Control field may include information related to the control of MAPC operations and may be included optionally.

[0243] The MAPC Capability field may contain information related to the capability to perform MAPC operations.

[0244] The MAPC Status field may indicate status information regarding the MAPC operation of the AP transmitting the frame containing the element. The MAPC status field may include subfields indicating information regarding the MAPC status formed by the AP transmitting the frame. For example, the MAPC status field may include a Num of MAPC agreements field and a MAPC agreement info field.

[0245] In one embodiment, the MAPC status field may indicate whether each MAPC scheme is enabled. Such activation includes information different from the capability to perform MAPC operations included in the MAPC Capability field; while the capability to perform MAPC operations indicates whether the AP has implemented the corresponding MAPC scheme, the MAPC activation status may indicate that the AP is currently in a state where it can operate by activating the implemented MAPC scheme. That is, even if there is the capability to perform MAPC operations for a specific MAPC scheme, if it is disabled, it may not be able to reach consensus and perform operations regarding that MAPC scheme with neighboring APs.

[0246] The Num of MAPC agreements field contains one octet and can indicate the number of MAPC agreements that an AP has made.

[0247] The MAPC agreement info field may contain at least 8 octets and may include an information set consisting of {MAPC scheme, AP MAC address, Type}. In this case, the MAPC scheme contains 1 octet and may be represented in a bitmap format (e.g., bit 0: C-TDMA, bit 1: C-SR, bit 2: C-BF, ...). The AP MAC address contains 6 octets and may represent the MAC address of the counterpart AP that formed the MAPC scheme. The Type contains 1 octet and may include other information regarding the MAPC agreement (e.g., Protected: whether a Protected MAPC scheme is used).

[0248] The MAPC Operations Parameters field is a field containing configuration parameters used for MAPC operations, and FIG. 20c illustrates an example of the MAPC Operation Parameters field format.

[0249] FIG. 20b illustrates an example of the Control field format of the Control field described in FIG. 20a.

[0250] Referring to FIG. 20b, the Control field format may include a Present subfield indicating whether there is a field corresponding to the MAPC element format, such as a Type subfield, an Extended Control Present subfield, a MAPC Control Present subfield, a MAPC Capability Present subfield, a MAPC Status Present subfield, and a MAPC Operation Parameters Present subfield.

[0251] The Type subfield may indicate type information regarding the MAPC operation of the AP transmitting the frame containing the element. The Type subfield may contain 2 bits, 4 bits, or 8 bits and may include other information regarding MAPC consensus (e.g., Protected: whether a Protected MAPC scheme is used).

[0252] FIG. 20c is a diagram illustrating an example of the field format of the MAPC Operation Parameters field described in FIG. 20a.

[0253] Referring to FIG. 20c, the MAPC Operation Parameters field format may include at least one of the MAPC Management Type field, MAPC scheme field, MAPC MID field, and Type-dependent Information field.

[0254] The MAPC Management Type field may indicate one of the following management types that the frame intends to perform for the MAPC operation.

[0255] - Establishment of a new MAPC scheme agreement: For example, the parameter or element included in the Type-dependent Information field of the MAPC Operation Parameters field may indicate whether it is for a MAPC agreement request, response, confirmation, or acknowledgment.

[0256] - Parameter update for an MAPC scheme agreement: For example, a parameter or element included in the Type-dependent Information field of the MAPC Operation Parameters field may indicate whether it is for a MAPC parameter update request, response, or confirmation.

[0257] - Status change of an MAPC agreement: For example, the parameters or MAPC included in the Type-dependent Information field of the MAPC Operation Parameters field may indicate whether the MAPC is for MAPC suspend, resume, teardown, or keep-alive.

[0258] In one embodiment, the MAPC Management Type field may indicate one of the management types that the frame intends to perform for MAPC operations using a pre-configured table, and an example thereof is illustrated in FIG. 20d.

[0259] Referring to FIG. 20d, if the MAPC Management Type field contains, for example, a value of b0000, it may indicate that the parameter included in the Type-dependent Information field is a parameter for the MAPC agreement request.

[0260] In one embodiment, the MAPC Management Type field may be set to a value such as that shown in FIG. 20d only when the Action Details field value described in 18c in the Action Details field of the corresponding Action frame is not set, thereby indicating the management type of the corresponding Action frame.

[0261] Referring again to FIG. 20c, the MAPC scheme field can refer to the MAPC scheme to be formed through the corresponding frame (e.g., Co-TDMA).

[0262] The MAPC MID (MAPC agreement ID) field may be an indicator that collectively refers to the MAPC agreement negotiated through the frame and the associated operation parameters. In one embodiment, the MAPC MID field may be included in a frame that updates the status (suspend, resume, termination, etc.) or operation parameters of the MAPC agreement, and may be used to update the status or operation parameters of the MAPC agreement by referring to the operation parameters associated with the MAPC agreement corresponding to the MAPC MID field value. In one embodiment, the MAPC MID field may be included conditionally.

[0263] The Type-dependent Information field may include a parameter or element corresponding to the value included in the MAPC Management Type field or the Action Details field value described in 18c. For a detailed description of the parameter or element that may be included in the Type-dependent Information field, refer to FIGS. 21, 22, 23a, and 23b.

[0264] FIG. 21 is a drawing illustrating an example of a MAPC agreement request / response element format that may include information related to MAPC keep-alive conditions according to one embodiment of the present disclosure.

[0265] FIG. 21 illustrates an example of the format of a MAPC agreement request / response element that can be included in the Type-dependent Information field of the MAPC Operation Parameters field described in FIG. 20c.

[0266] Referring to FIG. 21, if the MAPC Management Type field of the Action frame contains a value indicating a MAPC agreement request or a MAPC agreement response as described in FIG. 20d above, or if the Action Details field contains a value indicating a MAPC agreement request or a MAPC agreement response as described in FIG. 18c above, the Type-dependent information field can be defined as the MAPC agreement request element or MAPC agreement request element illustrated in FIG. 21.

[0267] Referring to FIG. 21, the MAPC agreement request element format or the MAPC agreement request element format may include a field defined as a Control field and a MACP keep-alive condition element.

[0268] The MACP keep-alive condition element may include at least one of the Max MAPC idle period field, MAPC keep-alive required field, MAPC keep-alive interval field, and MAPC keep-alive count field.

[0269] The Max MAPC Idle Period field may contain information regarding the maximum MAPC idle period during which the MAPC agreement is maintained even without MAPC operations, management operations within the MAPC TWT SP, or the sending and receiving of keep-alive messages. For example, the information regarding the maximum MAPC idle period included in the Max MAPC Idle Period field may be expressed in units of 1000 TU. For example, the information regarding the maximum MAPC idle period included in the Max MAPC Idle Period field may include absolute time (e.g., seconds or minutes).

[0270] The MAPC keep-alive required field may indicate whether periodic keep-alive frames must be sent separately from MAPC operations to maintain MAPC negotiation. For example, if the MAPC keep-alive required field contains 0, it may indicate that MAPC negotiation can be maintained even without keep-alive frames if MAPC operations or management operations within the MAPC TWT SP are performed. For example, if the MAPC keep-alive required field contains 1, it may indicate that MAPC keep-alive frames must be transmitted and received separately to maintain MAPC negotiation.

[0271] The MAPC keep-alive interval field can indicate the transmission period of a frame when periodic keep-alive frames must be sent to maintain MAPC negotiation.

[0272] The MAPC keep-alive count represents the count value for maintaining the corresponding MAPC agreement even if the periodic keep-alive frames required to maintain the MAPC agreement are not received consecutively for that number of times.

[0273] FIG. 22 is a drawing illustrating an example of a MAPC Keep-alive element field format according to one embodiment of the present disclosure.

[0274] FIG. 22 illustrates an example of the format of a MAPC keep alive element that can be included in the Type-dependent Information field of the MAPC Operation Parameters field described in FIG. 20c.

[0275] FIG. 22 illustrates an example of the format of a MAPC keep-alive element that can be included in the MAPC keep-alive action frame described in FIG. 15.

[0276] Referring to FIG. 22, if the MAPC Management Type field of the corresponding Action frame contains a value indicating MAPC keep-alive as described in FIG. 20d above, or if the Action Details field contains a value indicating MAPC agreement keep-alive as described in FIG. 18c above, the Type-dependent information field can be defined as the MAPC keep-alive element illustrated in FIG. 22.

[0277] Referring to FIG. 22, the MAPC keep-alive element format may include at least one of the Control field, the Sender AP ID field, and the AP ID element.

[0278] The control field may include a presence field indicating the existence of fields within the MAPC keep-alive element, and information indicating the number of elements included in a field composed of a list.

[0279] Referring to FIG. 22, the Control field may include at least one of the Sender AP ID present subfield, Num of AP ID elements (for keep-alive) subfield, or Keep-alive all agreements subfield.

[0280] The Sender AP ID present subfield can indicate whether the Sender AP ID field exists within the element.

[0281] The Num of AP ID elements (for keep-alive) subfield may include a value indicating the number of elements (AP ID elements) containing the AP ID to which keep-alive is to be applied and the list of MIDs to which keep-alive is to be applied among the MAPC agreements made with the AP referred to by that AP ID.

[0282] The Keep-alive all agreements subfield may include a value indicating whether the AP that received the MAPC Keep-alive element retains all MAPC agreements performed with the AP that transmitted the MAPC Keep-alive element. In one embodiment, if the receiver address (RA) is individually addressed, the retention of all MAPC agreements may apply to the AP corresponding to the RA (receiver address). In one embodiment, if the RA is a broadcast address, the retention of all MAPC agreements indicated by the Keep-alive all agreements subfield may apply to all APs that received the MAPC Keep-alive element.

[0283] The Sender AP ID field may include the AP ID of the sender AP requesting Keep-alive.

[0284] The AP ID element may include an AP ID field, a Num of MIDs field, and at least one MID field.

[0285] The AP ID field may include the AP ID (receiver AP) to which Keep-alive will be applied.

[0286] The Num of MIDs field may include information indicating the number of MAPC agreements to be kept-alive through this MAPC keep-alive element among the MAPC agreements established with the receiver AP referred to by the AP ID included within the same AP ID element.

[0287] The MID field may include the MID of the MAPC agreement to which keep-alive is to be applied among the MAPC agreements established between the sender AP and the receiver AP, and there may be as many MID fields as there are MIDs. In one embodiment, each MID field may be composed of 4 bits.

[0288] FIGS. 23a and FIGS. 23b are drawings illustrating an example of a MAPC teardown element format according to one embodiment of the present disclosure.

[0289] FIGS. 23a and 23b illustrate an example of the format of a MAPC teardown element that can be included in the Type-dependent Information field of the MAPC Operation Parameters field described in FIG. 20c.

[0290] FIGS. 23a and FIGS. 23b illustrate an example of the format of a MAPC teardown element that can be included in the MAPC teardown action frame described in FIG. 17.

[0291] Referring to FIGS. 23a and 23b, if the MAPC Management Type field of the corresponding Action frame contains a value indicating MAPC teardown as described in FIG. 20d above, or if the Action Details field contains a value indicating MAPC agreement teardown as described in FIG. 18c above, the Type-dependent information field can be defined as the MAPC teardown element illustrated in FIGS. 23a and 23b.

[0292] Referring to FIG. 23a, the MAPC teardown element format may include at least one of the Control field, Sender AP ID field, Teardown time field, and AP ID element.

[0293] The control field may include a presence field indicating the existence of fields within the MAPC teardown element, and information indicating the number of elements included in the field composed of a list.

[0294] Referring to FIG. 23a, the Control field may include at least one of the following: Sender AP ID present subfield, Num of AP ID elements (for teardown) subfield, Teardown all agreements subfield, and Teardown time present subfield.

[0295] The Sender AP ID present subfield can indicate whether the Sender AP ID field exists within the element.

[0296] The Num of AP ID elements (for teardown) subfield may contain a value indicating the number of elements (AP ID elements) that include the AP ID to which teardown is to be applied and a list of MIDs to which teardown is to be applied among the MAPC agreements made with the AP referred to by that AP ID.

[0297] The Teardown all agreements subfield may include a value indicating whether the AP that received the MAPC Teardown element terminates all MAPC agreements performed with the AP that transmitted the MAPC Teardown element. In one embodiment, if the receiver address (RA) is individually addressed, the determination to terminate all MAPC agreements may apply to the AP corresponding to the RA (receiver address). In one embodiment, if the RA is a broadcast address, the determination to terminate all MAPC agreements indicated by the Teardown all agreements subfield may apply to all APs that received the MAPC Teardown element.

[0298] The Sender AP ID field may include the AP ID of the sender AP requesting Teardown.

[0299] The AP ID element may include an AP ID field, a Num of MIDs field, and at least one MID field.

[0300] The AP ID field may include the AP ID (recipient AP) to which Teardown will be applied.

[0301] The Num of MIDs field may include information indicating the number of MAPC agreements to be torn down through this MAPC teardown element among the MAPC agreements established with the receiver AP referred to by the AP ID included within the same AP ID element.

[0302] The MID field may include the MID of the MAPC agreement to which teardown is to be applied among the MAPC agreements established between the sender AP and the receiver AP, and there may be as many MID fields as there are MIDs. In one embodiment, each MID field may be composed of 4 bits.

[0303] Referring to FIG. 23b, the Teardown time field may include a Teardown time type subfield and a Type-dependent value.

[0304] The Teardown time type field can represent a value that selects one of several options for the grace period from the transmission of the corresponding teardown element until the time when the teardown is actually applied. For example, the Teardown time type field can include the following values.

[0305] - b00: Exit immediately

[0306] - b01: Terminate the MAPC agreement after a time that is a multiple of TBTT

[0307] -b10: MAPC agreement terminates after a time equal to a multiple of the MAPC TWT SP interval.

[0308] - b11: MAPC agreement terminates after the time equal to the Teardown timer value.

[0309] The Type-dependent value field may represent a time value according to the method of indicating the grace period from the transmission of the corresponding teardown element indicated in the above Teardown time type field until the time when teardown is actually applied.

[0310] For example, if the Teardown time type field represents b01, the Type-dependent value field may contain a constant value (Num of TBTTs) corresponding to a multiple of TBTT, and the MAPC agreement may be terminated after a time equal to a multiple of TBTT.

[0311] For example, if the Teardown time type field represents b02, the Type-dependent value field may contain a constant value (Num of MAPC TWT SPs) corresponding to a multiple of the MAPC TWT SP interval, and the MAPC agreement may be terminated after a time equal to a multiple of the MAPC TWT SP.

[0312] For example, if the Teardown time type field represents b11, the Type-dependent value field may contain a Teardown timer value, and the MAPC agreement may be terminated after that time.

[0313] FIG. 24 is a drawing illustrating an example of an operation related to MAPC discovery and consensus according to one embodiment of the present disclosure.

[0314] Figure 24 is an example of signaling for MAPC discovery and agreement between a first AP (MAPC agreement requesting AP) and a second AP (MAPC agreement responding AP).

[0315] FIG. 24 is a diagram illustrating the framework of Multi-AP Coordination (MAPC) of FIG. 12, and each step can be described by referring to the description of the corresponding configuration in FIG. 12.

[0316] Referring to FIG. 24, in step 2410, the first AP and the second AP can perform a procedure for beacon-based MAPC discovery. The APs can discover neighboring APs by broadcasting a beacon containing the MAPC capability parameter of each AP. In one embodiment, the beacon may include a UHR Operation element or the MAPC element described in FIG. 20a.

[0317] Subsequently, the 1st AP and 2nd AP can perform the MAPC discovery procedure based on the above 2410 steps.

[0318] In step 2420, the first AP may transmit a MAPC discovery request frame to the second AP. The MAPC discovery request frame may include at least one MAPC capability parameter and MAPC authentication information by transmitting it with an adjacent AP designated as the destination address of the frame. In one embodiment, the MAPC discovery request frame may be one of the Public Action frame, Protected dual of Public Action frame, UHR action frame, or Protected UHR Action frame described in FIGS. 18a, 18b, and 18c.

[0319] In step 2425, the second AP that receives the MAPC discovery request frame can determine whether the first AP is a trusted AP based on the MAPC authentication information.

[0320] In step 2430, if the second AP confirms that the first AP is a trusted AP, it may transmit a MAPC discovery response frame to the first AP. The MAPC discovery response frame may include at least one of the MAPC capability parameter and MAPC authentication information received from the MAPC discovery request frame.

[0321] Afterwards, the 1st AP and the 2nd AP can perform the MAPC agreement procedure based on the above 2420 steps.

[0322] In step 2435, the first AP can determine whether the first AP is a trusted AP based on the MAPC authentication information.

[0323] In step 2440, the first AP may transmit a MAPC negotiation request frame (or, MAPC agreement request frame) to the second AP. The MAPC negotiation request frame (or, MAPC agreement request frame) may include at least one of MAPC association information (e.g., AP ID allocation), MAPC scheme-specific information (e.g., Co-TDMA information, Co-BF information, etc.), and MAPC keep-alive condition information. For the MAPC keep-alive condition information, refer to the description of the MAPC keep-alive condition element illustrated in FIG. 21.

[0324] In step 2450, the second AP that receives the MAPC negotiation request frame (or MAPC agreement request frame) can transmit the MAPC negotiation response frame (or MAPC agreement response frame) to the first AP. The MAPC negotiation response frame (or MAPC agreement response frame) may include at least one of the MAPC association information (e.g., AP ID allocation), MAPC scheme-specific information (e.g., Co-TDMA information, Co-BF information, etc.), and MAPC keep-alive condition information received from the MAPC negotiation request frame (or MAPC agreement request frame).

[0325] The MAPC negotiation request frame (or MAPC agreement request frame) and MAPC negotiation response frame (or MAPC agreement response frame) in steps 2440 and 2450 may refer to the MAPC agreement request frame and MAPC agreement response frame described in FIGS. 13 and FIGS. 18a through 21. That is, the MAPC negotiation request frame and MAPC negotiation response frame in steps 2440 and 2450 may be one of the Public Action frame, Protected dual of Public Action frame, UHR action frame, or Protected UHR Action frame described in FIGS. 18a, 18b, and 18c.

[0326] The size (e.g., byte / bit size), name, and / or location of each of the fields included in the frame formats or element formats described in this disclosure are merely examples for convenience of explanation, and the size, name, and / or location of each of the fields may be implemented with various values ​​or names according to design specifications.

[0327] FIG. 25 is a flowchart illustrating the operation of a first access point according to one embodiment of the present disclosure.

[0328] Referring to FIG. 25, in step 2510, the first access point may transmit a first frame containing information on the condition of keeping alive a multiple-access point (AP) coordination (MAPC) agreement to the second access point.

[0329] In step 2520, the first access point can receive a second frame from the second access point in response to the first frame.

[0330] In one embodiment, information regarding the validity or maintenance conditions of the MAPC agreement may include information regarding the maximum idle period for maintaining the MAPC agreement.

[0331] In one embodiment, after the first access point performs a MAPC operation based on the MAPC agreement, it may transmit a third frame to the second access point to validate or maintain the MAPC agreement.

[0332] In one embodiment, information regarding the validity or maintenance conditions of the MAPC agreement may include at least one of information indicating whether it is necessary to transmit the third frame to maintain the MAPC agreement, the transmission period of the third frame, and the number of transmission periods of the third frame included in the maximum idle period for maintaining the MAPC agreement.

[0333] In one embodiment, the third frame may include an identifier (ID) for a first access point requesting the validity or maintenance of the MAPC agreement, at least one recipient ID for at least one access point to which the validity or maintenance is requested, and at least one ID for the MAPC agreement to which the validity or maintenance is requested.

[0334] In one embodiment, the third frame may include information regarding the number of at least one receiver ID included in the third frame and information indicating whether the MAPC consensus to be requested for validity or maintenance includes all MAPC consensuses for the receiver ID.

[0335] In one embodiment, after the first access point performs a MAPC operation based on the MAPC agreement, it may transmit a fourth frame to the second access point for termination of the MAPC agreement.

[0336] In one embodiment, the fourth frame may include information regarding the period from when the fourth frame is transmitted until the time when the MAPC agreement is terminated.

[0337] In one embodiment, information regarding the period from when the fourth frame is transmitted until the time to terminate the MAPC consensus may include one of information indicating immediate termination, information regarding the period based on TBTT (target beacon transmission time), information regarding the period based on the MAPC TWT (target awake time) SP (service period) interval, and information regarding a predefined period.

[0338] In one embodiment, the fourth frame may include an identifier (ID) for a first access point requesting termination of the MAPC agreement, at least one receiver ID for at least one access point to which termination is requested, and at least one ID for the MAPC agreement to which termination is requested.

[0339] In one embodiment, the first frame and the second frame include an action frame, and the action frame may be one of a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame.

[0340] In one embodiment, the fourth frame includes a beacon or an action frame, and the action frame may be one of a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame.

[0341] In one embodiment, information regarding the validity or maintenance conditions of the at least one MAPC agreement may be included in the MAPC element.

[0342] FIG. 26 is a flowchart illustrating the operation of a second access point according to one embodiment of the present disclosure.

[0343] Referring to FIG. 26, in step 2610, the second access point may receive a first frame from the first access point containing information about the validity or keep-alive condition of the multiple-access point (AP) coordination (MAPC) agreement.

[0344] In step 2620, the second access point can transmit a second frame to the first access point in response to the first frame.

[0345] In one embodiment, information regarding the validity or maintenance conditions of the MAPC agreement may include information regarding the maximum idle period for maintaining the MAPC agreement.

[0346] In one embodiment, after the second access point performs a MAPC operation based on the MAPC agreement, it may transmit a third frame to the first access point to validate or maintain the MAPC agreement.

[0347] In one embodiment, information regarding the validity or maintenance conditions of the MAPC agreement may include at least one of information indicating whether it is necessary to transmit the third frame to maintain the MAPC agreement, the transmission period of the third frame, and the number of transmission periods of the third frame included in the maximum idle period for maintaining the MAPC agreement.

[0348] In one embodiment, the third frame may include an identifier (ID) for a first access point requesting the validity or maintenance of the MAPC agreement, at least one recipient ID for at least one access point to which the validity or maintenance is requested, and at least one ID for the MAPC agreement to which the validity or maintenance is requested.

[0349] In one embodiment, the third frame may include information regarding the number of at least one receiver ID included in the third frame and information indicating whether the MAPC consensus to be requested for validity or maintenance includes all MAPC consensuses for the receiver ID.

[0350] In one embodiment, the second access point may transmit a fourth frame to the first access point for termination of the MAPC agreement after performing a MAPC operation based on the MAPC agreement.

[0351] In one embodiment, the fourth frame may include information regarding the period from when the fourth frame is transmitted until the time when the MAPC agreement is terminated.

[0352] In one embodiment, information regarding the period from when the fourth frame is transmitted until the time to terminate the MAPC consensus may include one of information indicating immediate termination, information regarding the period based on TBTT (target beacon transmission time), information regarding the period based on the MAPC TWT (target awake time) SP (service period) interval, and information regarding a predefined period.

[0353] In one embodiment, the fourth frame may include an identifier (ID) for a first access point requesting termination of the MAPC agreement, at least one receiver ID for at least one access point to which termination is requested, and at least one ID for the MAPC agreement to which termination is requested.

[0354] In one embodiment, the first frame and the second frame include an action frame, and the action frame may be one of a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame.

[0355] In one embodiment, the fourth frame includes a beacon or an action frame, and the action frame may be one of a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame.

[0356] In one embodiment, information regarding the validity or maintenance conditions of the at least one MAPC agreement may be included in the MAPC element.

[0357] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0358] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

Claim 1 A method by a first access point performing Wi-Fi communication, comprising: transmitting a first frame containing information on the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement to a second access point; and receiving a second frame from the second access point in response to the first frame. Claim 2 A method according to claim 1, wherein the information regarding the validity or maintenance conditions of the MAPC agreement includes information regarding the maximum idle period for maintaining the MAPC agreement. Claim 3 A method characterized by further including the step of, in claim 1, transmitting a third frame to the second access point to validate or maintain the MAPC agreement after performing a MAPC operation based on the MAPC agreement. Claim 4 A method according to claim 3, wherein information regarding the validity or maintenance conditions of the MAPC agreement comprises at least one of information indicating whether it is necessary to transmit the third frame to maintain the MAPC agreement, the transmission period of the third frame, and the number of transmission periods of the third frame included in the maximum idle period for maintaining the MAPC agreement. Claim 5 A method according to paragraph 3, wherein the third frame comprises an identifier (ID) for a first access point requesting the validity or maintenance of the MAPC agreement, at least one recipient ID for at least one access point to which the validity or maintenance is requested, and at least one ID for the MAPC agreement to which the validity or maintenance is requested. Claim 6 A method according to claim 5, wherein the third frame comprises information regarding the number of at least one recipient ID included in the third frame and information indicating whether the MAPC agreement to be requested for validity or maintenance includes all MAPC agreements for the recipient ID. Claim 7 A method characterized by further including the step of, in claim 1, transmitting a fourth frame for termination of the MAPC agreement to the second access point after performing a MAPC operation by the MAPC agreement. Claim 8 A method according to claim 7, wherein the fourth frame includes information regarding the period from when the fourth frame is transmitted until the time when the MAPC agreement is terminated. Claim 9 A method according to claim 8, wherein the information regarding the period from when the fourth frame is transmitted until the time to terminate the MAPC consensus includes one of the following: information indicating immediate termination, information regarding the period based on TBTT (target beacon transmission time), information regarding the period based on the MAPC TWT (target awake time) SP (service period) interval, and information regarding a predefined period. Claim 10 A method according to claim 7, wherein the fourth frame comprises an identifier (ID) for a first access point requesting termination of the MAPC agreement, at least one recipient ID for at least one access point to which termination is requested, and at least one ID for the MAPC agreement to which termination is requested. Claim 11 A method according to claim 1, wherein the first frame and the second frame include an action frame, and the action frame is one of a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame. Claim 12 A method according to claim 7, wherein the fourth frame comprises a beacon or an action frame, and the action frame is one of a Public Action frame, a Protected dual of a Public Action frame, a UHR action frame, or a Protected UHR Action frame. Claim 13 A method according to claim 1, characterized in that information regarding the validity or maintenance conditions of the MAPC agreement is included in the MAPC element. Claim 14 A method by a second access point performing Wi-Fi communication, comprising: receiving a first frame from a first access point containing information regarding the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement; and transmitting a second frame to the first access point in response to the first frame. Claim 15 A method according to claim 14, wherein information regarding the validity or maintenance conditions of the MAPC agreement includes information regarding the maximum idle period for maintaining the MAPC agreement. Claim 16 A method characterized by further including, in claim 14, the step of transmitting a third frame to the first access point to validate or maintain the MAPC agreement after performing a MAPC operation by the MAPC agreement. Claim 17 A method according to claim 16, wherein information regarding the validity or maintenance conditions of the MAPC agreement comprises at least one of information indicating whether it is necessary to transmit the third frame to maintain the MAPC agreement, the transmission period of the third frame, and the number of transmission periods of the third frame included in the maximum idle period for maintaining the MAPC agreement. Claim 18 A method characterized by further including, in paragraph 14, the step of transmitting a fourth frame for termination of the MAPC agreement to the first access point after performing a MAPC operation by the MAPC agreement. Claim 19 A first access point performing Wi-Fi communication comprises: a transceiver; and at least one processor; wherein the at least one processor is configured to transmit a first frame containing information regarding the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement to a second access point, and to receive a second frame from the second access point in response to the first frame. Claim 20 A second access point performing Wi-Fi communication comprises: a transceiver; and at least one processor; wherein the at least one processor is configured to receive a first frame from a first access point containing information regarding the validity or keep-alive condition of a multiple-access point (AP) coordination (MAPC) agreement, and to transmit a second frame to the first access point in response to the first frame.

Images