Method and device for negotiating TWT overlapping obss AP in wireless LAN system

Abstract

The present disclosure relates to a wireless LAN system, and an embodiment of the present disclosure provides a method and device for performing coordination on coordinated target wake time (C-TWT) between APs in order to effectively operate a TWT.

Description

Method and device for performing TWT negotiation overlapping with OBSS AP in a wireless LAN system

[0001] The present disclosure relates to a method and apparatus for transmitting a signal in a wireless LAN network system, and more specifically, to a method and apparatus for negotiating a target wake time that overlaps with an adjacent access point.

[0002] A Wireless Local Area Network (WLAN), also known as Wi-Fi, is a network that enables internet access via mobile devices or laptops within a certain distance from an access point (AP). WLAN technology continues to evolve in line with the rise of the internet and the expansion of the smartphone market, and is being utilized to provide high-speed data services throughout the city, including in schools, airports, hotels, and offices.

[0003] The WiFi Alliance defines WiFi as a Wireless Local Area Network (WLAN) product based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. IEEE 802.11a and b, published in 1997 and 1999 respectively, are standards utilizing unlicensed bands at 2.4 GHz or 5 GHz; IEEE 802.11b provides a transmission speed of 11 Mbps, while IEEE 802.11a provides a transmission speed of 54 Mbps. IEEE 802.11g provides a transmission speed of 54 Mbps by applying Orthogonal Frequency-Division Multiplexing (OFDM) at 2.4 GHz. IEEE 802.11n applies multiple input multiple output OFDM (MIMO-OFDM) to provide a transmission speed of 300 Mbps using four spatial streams. IEEE 802.11n supports a channel bandwidth of up to 40 MHz, in which case it provides a transmission speed of 600 Mbps.

[0004] Subsequently, the IEEE 802.11ac standard was introduced, which uses a maximum bandwidth of 160 MHz and supports eight spatial streams to support speeds up to 1 Gbit / s, and the IEEE 802.11ax standard was introduced, which provides multi-user MIMO (MU-MIMO) in the uplink and downlink and supports spatial frequency reuse and dynamic fragmentation. Since then, research is underway on 802.11be, which aims to achieve theoretical speeds of 46 Gbps by supporting up to 320 ultra-wide channels, multi-link operation, and 4kQAM.

[0005] In 802.11, the target wake time (TWT) was defined to reduce power consumption and increase spectrum efficiency. In this case, if the TWT schedule overlaps with an overlapping BSS (OBSS), it is necessary to negotiate the TWT schedule with the OBSS's AP to secure TWT transmission.

[0006] The present invention for solving the above-mentioned problems comprises a method performed by an electronic device of a wireless LAN network, the method comprising: receiving a message containing information about a target wake time (TWT) schedule set in an overlapping basic service set (OBSS) AP (access point) from an overlapping basic service set (OBSS) AP; receiving a first TWT frame requesting a TWT setting from a station (STA); transmitting a second TWT frame in response to the first TWT frame indicating that pending or coordination is required when the TWT requested from the STA overlaps with the TWT schedule set in the OBSS AP and the TWT schedule for which the setting was requested; and transmitting a message requesting TWT coordination to the OBSS AP.

[0007] Additionally, a method performed by an electronic device of a wireless LAN network comprises the steps of: transmitting a first TWT frame requesting a TWT (target wake time) setting to an access point (AP); and receiving a second TWT frame from the AP in response to the first TWT frame, which indicates that the TWT requested to the STA is pending or requires coordination, wherein a TWT setup command field included in the second TWT frame indicates that the requested TWT is pending or requires coordination, or an indicator included in the second TWT frame indicates that the requested TWT is pending or requires coordination.

[0008] In addition, a method performed by an electronic device of a wireless LAN network comprises the steps of: receiving a message requesting TWT (target wake time) coordination from an OBSS (overlapping basic service set) AP (access point); and transmitting a response message to the OBSS AP regarding the message requesting TWT coordination, wherein the message requesting TWT coordination includes at least one of information regarding the requested TWT, information regarding the TWT of the overlapping OBSS AP, information indicating a coordination method that the electronic device can support, and information indicating a coordination method preferred by the electronic device.

[0009] In addition, an electronic device of a wireless LAN network comprises: a transceiver; and a control unit configured to receive a message containing information about a target wake time (TWT) schedule set in the OBSS AP from an overlapping basic service set (OBSS) AP (access point), receive a first TWT frame requesting a TWT setting from a station (STA), and in response to the first TWT frame, transmit a second TWT frame indicating that pending or coordination is required when the TWT requested from the STA overlaps with the TWT schedule set in the OBSS AP and the TWT schedule for which a setting was requested, and transmit a message requesting TWT coordination to the OBSS AP.

[0010] Additionally, in an electronic device of a wireless LAN network, the device is further configured to have a transceiver; and a control unit that transmits a first TWT frame requesting a TWT (target wake time) setting to an access point (AP), and receives a second TWT frame from the AP in response to the first TWT frame indicating that the TWT requested to the STA is pending or requires coordination, wherein a TWT setup command field included in the second TWT frame indicates that the requested TWT is pending or requires coordination, or an indicator included in the second TWT frame indicates that the requested TWT is pending or requires coordination.

[0011] Additionally, an electronic device of a wireless LAN network comprises: a transceiver; and a control unit configured to receive a message requesting TWT (target wake time) coordination from an OBSS (overlapping basic service set) AP (access point) and to transmit a response message to the message requesting TWT coordination to the OBSS AP, wherein the message requesting TWT coordination includes at least one of information regarding the requested TWT, information regarding the TWT of the overlapping OBSS AP, information indicating a coordination method that the electronic device can support, and information indicating a coordination method preferred by the electronic device.

[0012] According to a method according to at least one embodiment of the present disclosure, by setting up a STA and resources capable of performing NPCA, the carrier can be used efficiently and throughput can be increased.

[0013] Figure 1 is a diagram illustrating an example of a wireless communication network.

[0014] Figure 2 is a diagram illustrating an example of the structure of an electronic device that performs WLAN connection.

[0015] Figure 3 is a diagram illustrating an example of the link setup process of a typical wireless LAN.

[0016] Figure 4 is a diagram illustrating an example of a hidden node and an exposed node, and an example of an RTS and CTS for solving the problem of a hidden node and an exposed node.

[0017] Figure 5 is a diagram illustrating an example of a frame structure used in an IEEE 802.11 system.

[0018] Figure 6 is a diagram illustrating an example of a NAV setting.

[0019] Figure 7 is a diagram illustrating an example of TXOP.

[0020] Figure 8 is a drawing illustrating an example of TWT.

[0021] FIG. 9 is a drawing illustrating an example of the operation of the OBSS AP and AP according to the present disclosure.

[0022] Figure 10 is a diagram illustrating an example of a TWT setup frame format.

[0023] Figure 11 is a diagram illustrating an example of the format of a TWT parameter when the negotiation type is a TWT parameter of an individual TWT.

[0024] Figure 12 illustrates an example of the format of a TWT parameter when the negotiation type is a TWT parameter that is a broadcast TWT parameter.

[0025] FIG. 13 is a diagram illustrating an example of a C-TWT negotiation element that can be included in a MAP negotiation request and response frame.

[0026] Figure 14 is a diagram illustrating an example of a TWT information format.

[0027] FIG. 15 is a diagram illustrating an example of a requested / suggested MAP coordination information format.

[0028] Figure 16 is a diagram illustrating an example of the requiredCoordinationMethod subfield format.

[0029] FIG. 17 is a diagram illustrating an example in which a C-TWT negotiation element is included in a multi-STA blockAck frame.

[0030] FIG. 18 is a diagram illustrating an example in which a C-TWT negotiation element is included in a (protected) UHR action frame.

[0031] FIG. 19 is a diagram illustrating an example in which a C-TWT negotiation element is included in a management frame.

[0032] FIG. 20 is a drawing illustrating another example of the operation of the OBSS AP and the AP according to the present disclosure.

[0033] FIG. 21 is a diagram illustrating an example of the operation of an AP performing TWT scheduling according to the present disclosure.

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

[0035] In describing the embodiments, technical details that are well known in the art 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.

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

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

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

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

[0040] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For instance, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order depending on the corresponding function.

[0041] In this embodiment, the term "part" as used refers to a software or hardware component such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), 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. Also, according to some embodiments, the 'parts' may include one or more processors.

[0042] Exemplary embodiments are described below in relation to wireless LAN 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 propagation range. Accordingly, the terms WLAN and Wi-Fi may be used interchangeably herein. Additionally, although the following describes an infrastructure WLAN system including one or more APs and multiple wireless stations (STAs), exemplary embodiments are equally applicable to other WLAN systems including, for example, multiple WLANs, peer-to-peer (or independent basic service set) systems, Wi-Fi Direct systems and / or hotspots.

[0043] 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), media access control (MAC) protocol data units (MPDUs), and physical layer (PHY) protocol data units (PPDUs). The term A-MPDU may mean aggregated MPDUs. In the following, a wireless LAN, or WLAN network, may be a network implementing at least one of the IEEE 802.11 wireless communication protocol standard family, such as as defined by the IEEE 802.11-2016 standard or its amendments (including, but not limited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be).

[0044] 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 AP” means an access point to which a given wireless station is currently associated and / or connected (e.g., there exists a communication channel or link established between the access point and the given wireless 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, well-known circuits and devices are depicted in block diagram form to avoid obscuring the present disclosure. Also, the description of A / B means A or / and B, or at least one of A or B.

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

[0046] FIG. 1 is a diagram illustrating an example of a wireless communication network. The wireless communication network (100) may be an example of a wireless LAN, such as a Wi-Fi network. The wireless communication network (100) may include a number of wireless communication devices, such as an access point (AP, t102) and a number of stations (STA, 104). Although only one AP (102) is illustrated, the wireless communication network (100) may also include a number of APs (102).

[0047] A STA is a logical entity that includes a physical layer interface for a MAC and a wireless medium, and includes APs and non-AP STAs (Non-AP stations). Among the STAs, a portable terminal operated by a user is a Non-AP STA, and when simply referred to as STA, it may also refer to a Non-AP STA. Hereinafter, STA may refer to a non-AP STA. Each of the STAs (104) may be referred to as a terminal or a device. The terms 'terminal' or 'device' used in this specification 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 the terminal may include cellular telephones, smartphones with wireless communication capabilities, personal handheld terminals (PDAs) with wireless communication capabilities, wireless modems, portable computers with wireless communication capabilities, imaging devices such as digital cameras with wireless communication capabilities, gaming devices with wireless communication capabilities, music storage and playback appliances with wireless communication capabilities, internet appliances capable of wireless internet access and browsing, as well as portable units or terminals integrating combinations of such functions. Additionally, the terminal may include machine-to-machine (M2M) terminals and machine-type communication (MTC) terminals / devices, but is not limited thereto. In this specification, the terminal may be referred to as an electronic device or simply a device.

[0048] An AP (102) is an entity that provides access to a distribution system (DS) via a wireless medium to an Associated Station (STA) connected to it. An AP may also be called a central controller, base station (BS), Node-B, base transceiver system (BTS), or site controller.

[0049] An exemplary coverage area (106) of an AP (102) capable of representing the basic service area (BSA) of a wireless communication network (100) is illustrated. The AP (102) periodically broadcasts beacon frames (beacon frames may be interchangeable with beacons) containing a basic service set identifier (BSSID) to enable any STA (104) within the wireless range of the AP (102) to be associated with or re-associated with the AP (102) to establish or maintain individual communication links (108) (or may be referred to as Wi-Fi links) with the AP (102). The AP (102) can provide access to external networks for various STAs (104) within the WLAN through individual communication links (108).

[0050] A single AP (102) and an associated set of STAs (104) may be referred to as a basic service set (BSS) managed by the individual AP (102). The BSS may be identified to users by a service set identifier (SSID), as well as to other devices by a BSSID, which may be the MAC address of the AP (102).

[0051] BSS can be classified into infrastructure BSS and independent BSS (IBSS). The BSS shown in Fig. 1 is an IBSS, and it is also possible to establish an infrastructure BSS (not shown). An infrastructure BSS includes one or more STAs and APs, and in principle, communication between non-AP STAs in an infrastructure BSS is carried out via an AP, but if a direct link is established between non-AP STAs, direct communication between non-AP STAs is also possible.

[0052] Multiple infrastructure BSSs can be interconnected via DS. Multiple BSSs connected via DS are called an extended service set (ESS). STAs included in an ESS can communicate with each other, and within the same ESS, STAs can move from one BSS to another while communicating seamlessly.

[0053] A DS is a mechanism that connects multiple APs; it does not necessarily have to be a network, and there are no restrictions on its form as long as it can provide a specified distribution service. For example, a DS can be a wireless network such as a mesh network, or it can be a physical structure that connects APs to each other.

[0054] Additionally, AP (102) and STA (104) may be referred to as AP-MLD (access point multi-link device) and STA-MDL, respectively. This may mean that AP and STA can support multi-link operation.

[0055] Below, an example of a hierarchical structure according to the 802.11 standard is described.

[0056] The 802.11 standard document develops MAC and PHY protocols corresponding to Wi-Fi wireless access technology. The Data Link Layer (DLL) includes the MAC sublayer, which is responsible for media access control. It receives packets from the upper layer, 802.1X Port Filtering, via the MAC_SAP interface, constructs them into IEEE 802.11 MAC frames, and transmits them to the physical layer. The physical layer includes the PLCP (Physical Layer Convergence Procedure) sublayer and the PDM (Physical Medium Dependent) sublayer. The PLCP sublayer is responsible for converting the IEEE 802.11 MAC frames constructed by the MAC sublayer into PLCP frames. The PLCP frames are then transmitted to the target terminal through the PMD sublayer.

[0057] Various management frames that manage Wi-Fi wireless access are not transmitted at the upper layers of 802.1X. Instead, these management frames are transmitted as requests and responses between Station Management Entities (SMEs) located within each terminal. An SME is a layer-independent entity that may exist within a separate management plane or appear to be off-the-side. For example, if an AP wants to configure a BSS, it instructs the transmission of beacons via the MLME_SAP interface, specifically the MLME-START.request and MLME-START.confirm primitives. If an STA wants to establish an association with the corresponding AP, it instructs the transmission of association Request / Response frames via the MLME-ASSOCIATE.request, MLME-ASSOCIATE.response, MLME-ASSOCIATE.confirm, and MLME-ASSOCIATE.indication primitives. Meanwhile, if you wish to set operational parameter values ​​related to the physical layer, the SME can set various physical layer parameter values ​​through the PLCP_SAP interface.

[0058] FIG. 2 is a diagram illustrating an example of the structure of an electronic device performing a WLAN connection. Referring to FIG. 2, the electronic device (200) may be connected to an AP (210), and the electronic device (200) may include a processor (230) and a communication module (220). The electronic device (200) may be the STA (104) of FIG. 1, in which case the electronic device (200) may be connected to the AP (210) as illustrated. Alternatively, the electronic device (200) may be the AP (102) of FIG. 1, in which case the electronic device may be connected to the STA (104) and / or another AP as illustrated in FIG. 1.

[0059] The communication module (220) 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 Std 802.11™). For example, the communication module (220) can operate based on Wi-Fi communication methods such as 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.

[0060] The communication module (220) may include a transceiver (224) for transmitting and receiving data with an external device and a communication processor (222) (e.g., a communication processor (not shown), or a short-range wireless communication module (e.g., a Wi-Fi chipset)). Depending on various embodiments, the communication module (220) may further include memory.

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

[0062] According to various embodiments, the communication module (220) may further include, in addition to the transceiver (224) and the communication processor (222), components for OFDM or OFDMA (orthogonal frequency division multiple access), such as a modulator, a digital-analog converter, a frequency converter, an A / D converter, an amplifier, and / or a demodulator.

[0063] According to various embodiments not shown, the electronic device (200) may be electrically connected to a communication module of the AP (210) and may include at least one antenna module that supports a communication protocol and / or frequency band supported by the communication module of the AP (210).

[0064] The communication processor (222) can control the transceiver (224) to form a communication connection with the AP (210). For example, the communication connection may include a Wi-Fi network. For example, the communication processor (222) can control the transceiver (224) to form a wireless connection with the AP (200) using a WLAN standard in the 2.4 GHz, 5 GHz, or 6 GHz band such as IEEE 802.11ac, 802.11ax, 802.11be, or 802.11bn. Alternatively, the communication processor (222) can control the transceiver (191) to form a wireless connection with the AP (210) using a WLAN standard in the 60 GHz band such as IEEE 802.11ad or 802.11ay. In addition, the method of communicating between the electronic device (200) and the AP (210) using a WLAN standard can be referred to as a communication method based on STA mode.

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

[0066] According to various embodiments, the AP (210) may support the operation of transmitting packets to an external network and / or the operation of receiving packets from an external network based on a connection between a plurality of electronic devices (e.g., electronic device (200)) and an external network (e.g., the Internet, an external LAN, or a cellular network).

[0067] For example, the AP (210) may be a wireless router. The AP (210) may be a dedicated wireless router or a general-purpose device that supports mobile hotspot functions, and there are no limitations on its implementation. For example, the AP (210) may include the same components (e.g., a processor and / or a communication module) as the electronic device (200). Additionally, the AP (210) may transmit and receive data with an external device, such as a server. For example, the AP (210) may transmit at least some of the data received from the server to the electronic device (200).

[0068] If the electronic device (200) of FIG. 2 corresponds to the AP (102), the electronic device (200) may include a separate communication module for connection with an external network, although not shown. This communication module may be controlled by a processor (230) or by a separate processor. The separate communication module may include a transceiver and a processor, and may also include memory. Additionally, the electronic device (200) may include a separate antenna module or a wired connection device for connection with an external network.

[0069] Figure 3 is a diagram illustrating an example of the link setup process of a typical wireless LAN.

[0070] In order for an STA to set up a link and transmit and receive data on a network, it must first discover the network, perform authentication, establish an association, and go through authentication procedures for security. The link setup process can also be referred to as the session initiation process or the session setup process. Additionally, the discovery, authentication, association, and security setup processes of the link setup process can be collectively referred to as the association process.

[0071] Referring to FIG. 3, the STA (300) can perform a network discovery operation. The network discovery operation may include a scanning operation of the STA (300). That is, in order for the STA (300) to access a network, it must find a network that it can join. Before joining a wireless network, the STA (300) must identify a compatible network, and the process of identifying networks existing in a specific area is called scanning.

[0072] Scanning methods include active scanning and passive scanning. In active scanning, the STA (300) performing the scanning moves between channels and sends a probe request frame (322) to search for nearby APs and waits for a response. The responder sends a probe response frame (324) as a response to the probe request frame to the STA that sent the probe request frame. Here, the responder may be the AP or STA that last sent a beacon frame from the BSS of the channel being scanned. In FIG. 3, an example of a BSS that becomes the responder is shown where the AP (310) sends a beacon frame (320). In an IBSS, the responder is not constant because the STAs within the IBSS take turns sending beacon frames. For example, if an STA transmits a probe request frame on channel 1 and receives a probe response frame on channel 1, the STA can store the BSS-related information included in the received probe response frame and move to the next channel to perform scanning in the same way.

[0073] Scanning operations may be performed using a passive scanning method. In passive scanning, the STA performing the scanning detects beacon frames while switching between channels. A beacon frame is one of the management frames in IEEE 802.11, which announces the presence of a wireless network and is periodically transmitted to allow the scanning STA to find the wireless network and join it. Figure 3 illustrates an example of a BSS in which an AP (310) periodically transmits beacon frames (320) to an STA (300), and in an IBSS, STAs within the IBSS take turns transmitting beacon frames. When the scanning STA receives a beacon frame, it stores information about the BSS included in the beacon frame and records the beacon frame information in each channel while moving to another channel. When comparing active scanning and passive scanning, active scanning has the advantage of having less delay and power consumption than passive scanning.

[0074] After the STA (300) discovers the network, an authentication process may be performed. This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation (350) described later. The authentication process includes the STA (300) sending an authentication request frame (330) to the AP (310), and in response, the AP (310) sending an authentication response frame (332) to the STA (300). The authentication frame used in the authentication request / response corresponds to a management frame.

[0075] The authentication frame may include information regarding the authentication algorithm number, authentication transaction sequence number, status code, challenge text, Robust Security Network (RSN), Finite Cyclic Group, etc. These are some examples of information that may be included in the authentication request / response frame, and they may be replaced with other information or additional information may be included.

[0076] AP (310) can determine whether to allow authentication for the STA based on the information included in the received authentication request frame. AP (310) can provide the result of the authentication processing to the STA (300) through an authentication response frame.

[0077] After the STA is successfully authenticated, an association process can be performed. The association process includes the STA (300) sending an association request frame (340) to the AP (310), and in response, the AP (310) sending an association response frame (342) to the STA (300).

[0078] For example, the associated request frame may include information regarding various capabilities, beacon listen interval, SSID, supported rates, supported channels, RSN (robust security network), mobility domain, supported operating classes, traffic indication map broadcast request, interworking service capabilities, etc.

[0079] For example, an association response frame may include information related to various capabilities, status code, association ID (AID), support rate, enhanced distributed channel access (EDCA) parameter set, received channel power indicator (RCPI), received signal to noise indicator (RSNI), mobility domain, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS map, etc.

[0080] This is a partial example of the information that may be included in the associated request / response frame, and it may be replaced with other information or additional information may be included.

[0081] Although not yet described, a security setup process can be performed after the STA is successfully associated with the network. The security setup process may be described as an authentication process through RSNA (robust security network association) requests / responses, and the authentication process (330) may be called the first authentication process, and the security setup process may also be called the authentication process.

[0082] The security setup process may include, for example, a private key setup process through a 4-way handshake via an EAPOL (extensible authentication protocol over LAN) frame, or may be performed according to a security method not defined in the IEEE 802.11 standard.

[0083] The following describes the Media Access Control Protocol provided by 802.11.

[0084] In wireless LAN systems based on IEEE 802.11, the basic access mechanism of a MAC is based on a distributed coordination function (DCF) utilizing the carrier sense multiple access with collision avoidance (CSMA / CA) method. There are two methods for detecting carriers in DCF: physical carrier sense and virtual carrier sense. The physical carrier sense method detects channel conditions at the physical layer and informs the MAC layer, while the virtual carrier sense method reserves a channel in advance by broadcasting the channel occupancy time to surrounding stations. An STA or AP that has secured a transmission channel records and transmits this channel occupancy time within an RTS and / or CTS or data frame; other STAs receiving this information determine that the channel is in use during this time and avoid channel occupancy contention, thereby avoiding collisions.

[0085] The physical carrier sensing method basically employs a listen before talk access mechanism, and according to this type of access mechanism, the AP and / or STA can perform a clear channel assessment (CCA) to sense the wireless channel, carrier, or medium for a predetermined time interval before starting transmission. The predetermined time interval is referred to as the inter-frame space (IFS) and may vary depending on the priority of the traffic to be transmitted. That is, priority can be determined by the length of the time interval, and packets with higher priority may have shorter time intervals.

[0086] The above IFS may include SIFS (short IFS), PIFS (PCF IFS), DIFS (DCF IFS), AIFS (arbitration IFS), etc. SIFS is the shortest time interval and can be used primarily as a waiting time for control information. PIFS is a medium-length time interval and can be for packets of medium priority (PIFS = SIFS + 1 slot time). DIFS is the longest time interval compared to SIFS and PIFS, has a low priority, and can be used primarily as a waiting time to check channel usage (DIFS = SIFS + 2 slot time). That is, for example, an STA intending to perform transmission can listen to (or detect channel) the channel usage during the DIFS period.

[0087] If sensing results determine that the medium is in an idle state, the AP and / or STA initiate frame transmission through that medium. Conversely, if the medium is detected to be in an occupied state, the AP and / or STA may attempt frame transmission after waiting for a delay period for medium access (e.g., a random backoff period) without initiating their own transmission. For instance, the AP and / or STA may randomly select a timer value within the contention window (CW) range, wait until the timer expires, and then sense the channel again. At this point, if the medium is idle, the AP and / or STA may initiate frame transmission; if the medium is occupied, the AP and / or STA doubles the size of the contention window and selects a timer value again. The size of the initially applied contention window is the minimum window size (contention window minimum, CW). min It is referred to as the maximum window size (contention window maximum, CW), and the maximum size of the contention window that can be applied is called the maximum window size (contention window maximum, CW max It is referred to as a random backoff period. By applying a random backoff period, multiple STAs are expected to attempt to transmit frames after waiting for different periods of time, thus minimizing collisions.

[0088] 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 a WLAN and can transmit QoS data during both the contention period (CP) and the contention-free period (CFP).

[0089] According to EDCA, data has priorities ranging from 0 to 7 depending on the traffic type, and data arriving at the MAC layer is mapped to four access categories (ACs) based on these priorities. As the priority increases, the data is assigned a higher priority. Each AC has its own parameters, and backoff is performed using these differently configured parameters, resulting in different channel access priorities for the data depending on the AC. Potential AC parameters include AIFS, CWmin, CWmax, and TXOP limits. Smaller values ​​for AIFS and CWmin correspond to higher priority; consequently, channel access delays are shortened, allowing data to utilize more bandwidth in a given traffic environment. The EDCA backoff process, which generates a new backoff counter in the event of a collision between STAs during frame transmission, is similar to the existing DCF, and transmission based on traffic priority is guaranteed through EDCA parameters that include AC-specific priorities.

[0090] According to EDCA, data has priorities ranging from 0 to 7 based on traffic type, and data arriving at the MAC layer is mapped to four access categories (ACs) according to these priorities. Higher priorities correspond to higher priority, and since each AC has its own parameters and backoff is performed using differently configured AC parameter values, data has different channel access priorities depending on the AC. The AC parameters include AIFS and CW. min , CW max , TXOP limits, etc. may exist. AIFS and CW minThe smaller the value, the higher the priority, and accordingly, the channel access delay is shortened, allowing data to use more bandwidth in a given traffic environment. The backoff process of EDCA, which generates a new backoff counter when a collision occurs between STAs during frame transmission, is similar to the existing DCF, and transmission based on traffic priority is guaranteed through EDCA parameters that include priority per AC.

[0091] Figure 4 is a diagram illustrating an example of a hidden node and an exposed node, and an example of an RTS and CTS for solving the problem of a hidden node and an exposed node.

[0092] Figure 4 (a) (400) is an example of a hidden node. When STA A and STA B are communicating and STA C has information to transmit, STA A is transmitting information to STA B, but when STA C performs carrier sensing before sending data to STA B, it can be determined that the medium is idle. This is because STA C may not be able to sense STA A's transmission (i.e., medium occupancy) at its location. In this case, a collision occurs because STA B receives information from STA A and STA C simultaneously. At this time, STA A can be considered a hidden node of STA C.

[0093] (b)(410) is an example of an exposed node. In a situation where STA B is transmitting data to STA A, STA C may have information to transmit to STA D. In this case, if STA C performs carrier sensing, it can determine that the medium is occupied due to the transmission by STA B. Accordingly, STA C must wait until the medium becomes idle, even if it has information to transmit to STA D. However, in reality, since STA A is outside the transmission range of STA C, the transmission from STA C and the transmission from STA B may not conflict from STA A's perspective, so STA C ends up waiting unnecessarily until STA B stops transmitting. In this case, STA C can be referred to as the exposed node of STA B.

[0094] In order to efficiently utilize the collision avoidance mechanism in the above situation, short signaling packets such as RTS (request to send) and CTS (clear to send) may be used. An STA intending to transmit data transmits an RTS to a STA intending to receive data, and the receiving STA that receives the RTS responds to the transmitting STA with a CTS frame. The RTS and / or CTS between the two STAs may cause surrounding STA(s) to overhear, thereby causing the surrounding STA(s) to consider whether to transmit information between the two STAs.

[0095] (c)(420) is an example of how to solve the hidden node problem. Assume that both STA A and STA C are trying to send data to STA B. When STA A sends an RTS to STA B, STA B sends a CTS to STA A. STA C, which overhears the RTS and CTS, delays its media access until the data transmission of STA A and STA B is finished, thereby avoiding collisions.

[0096] (d)(430) is an example of a method for solving the exposed node problem. STA B, which intends to send data to STA A, sends an RTS, and STA A, which is to receive the data, sends a CTS to respond to the RTS. In this case, if STA C receives only the RTS sent by STA B and does not receive the CTS sent by STA A, STA C can determine that STA A is outside the carrier sensing area of ​​STC C. In this case, STA C can determine that no collision will occur even if it sends data to another STA (e.g., STA D) and can send the data.

[0097] Figure 5 is a diagram illustrating an example of a frame structure used in an IEEE 802.11 system.

[0098] The PPDU (physical layer protocol data unit) format can be configured to include 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 can be configured to include only the L-STF (legacy-STF), L-LTF (legacy-LTF), SIG field, and data field.

[0099] 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 PHY preamble, and the PHY preamble is a signal for synchronization and channel estimation in the OFDM physical layer.

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

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

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

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

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

[0105] Fields 1 through 4 of the address 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.

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

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

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

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

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

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

[0112] As previously mentioned, the CSMA / CA mechanism includes virtual carrier sensing in addition to physical carrier sensing, where the AP and / or STA directly senses 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 the medium. 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 MAC header of the frame.

[0113] Figure 6 is a diagram illustrating an example of a NAV setting.

[0114] Referring to FIG. 6, the source STA (source STA, 600) transmits an RTS frame after DIFS, and the destination (610) transmits a CTS frame after SIFS. The destination STA 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 (630), while others receive the CTS frame and set the NAV (640).

[0115] If a CTS frame (e.g., PHY-RXSTART.indication primitive) is not received within a certain period from the time 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 via the RTS frame may reset the NAV (e.g., to 0) (or this case may be referred to as NAVtimeout). The certain period may be (2*aSIFSTime + CTS_Time + aRxPHYStartDelay + 2*aSlotTime), which may be referred to as the NAVtimeout period. CTS_Time may be calculated based on the length and data rate of the CTS frame indicated by the RTS frame.

[0116] In FIG. 6, 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).

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

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

[0119] Figure 7 illustrates an example of a TXOP. An STA participating in QoS transmission can obtain a TXOP that allows it to transmit traffic for a certain period using two channel access methods, such as EDCA and HCCA. TXOP acquisition is possible by succeeding in EDCA contention or by receiving a QoS CF-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 certain amount of time to any STA to transmit a frame, or to forcibly limit the transmission time.

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

[0121] 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 through the duration field of the MAC header. That is, the TXOP holder and the TXOP responder (e.g., an Rx STA) include all the TXOP information necessary for the transmission and reception of 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.

[0122] The primary channel and secondary channel are described below. The primary channel is a common channel operated by all STAs that are members of the BSS. For example, in a 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 80 + 80 MHz BSS, the primary channel may be the primary 20 MHz channel. In this case, the 40 and 80 MHz channels containing the primary 20 MHz channel may be referred to as the primary 40 and 80 MHz channels, and the primary channel may generally refer to the primary 20 MHz channel.

[0123] A secondary channel is a channel associated with a primary channel and is used to create a channel wider than the primary channel. For example, in a 40 MHz, 80 MHz, and 160 MHz BSS, the 40 MHz channel may be the sum of the primary 20 MHz channel and the secondary 20 MHz channel, the 80 MHz channel may be the sum of the primary 40 MHz channel and the secondary 40 MHz channel, and the 160 MHz channel may be the sum of the primary 80 MHz channel and the secondary 80 MHz channel.

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

[0125] The following describes TXOP sharing. TXOP sharing is a technology defined in 802.11be, based on the concept of an AP transferring remaining TXOP resources to a STA within a BSS after using the TXOPs it has acquired. An AP can transfer TXOPs to a STA using a multi-user RTS (MU-RTS) TXOP sharing (TXS) trigger frame (TF), specifically the MU-RTS TXS TF, and the STA receiving the transfer is specified within the MU-RTS TXS TF. Recently, TXOP sharing between APs has been under research. Through TXOP sharing between APs, an AP holding TXOPs can share the remaining TXOPs with an adjacent AP after using them for traffic processing within its BSS, thereby efficiently utilizing frequency and space resources to increase network throughput and reduce latency. TXOP sharing between APs can be referred to as AP TXOP sharing or coordinated TDMA (C-TDMA).

[0126] Next, we will describe the overlapping basic service set (OBSS). 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.

[0127] Currently, it is common for multiple APs to operate in specific areas, and in such cases, wireless LAN network performance degradation occurs 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, leading to 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). To address this problem, interference avoidance techniques are being researched, such as dividing the bandwidth available to each user so that it does not overlap or performing channel switching to unused channels, as well as interference alignment techniques that minimize the impact of interference even when using the same bandwidth.

[0128] Target Wake Time (TWT) is described below. Figure 8 illustrates an example of TWT. TWT is a technology introduced in 802.11ax to reduce power consumption and increase spectrum efficiency, and it can be used particularly in IoT. It has the effect of extending the power-saving time of devices, extending battery life, and reducing contention for channel access between devices in a shared medium. According to Figure 8, using TWT allows each STA (810, 820) to negotiate a wake period (812, 822, i.e., service period, SP)) with the AP (800) to transmit and receive data packets from the SP, and the STA can save energy during the remaining time in power-saving mode (or sleep mode). TWT includes a broadcast TWT applied to multiple STAs and an individual TWT mode applied to each STA.

[0129] R-TWT (restricted TWT) was defined in 802.11be to reliably support latency-sensitive traffic within an R-TWT SP. R-TWT is defined using the reserved bit of a broadcast TWT element, and R-TWT possesses additional protection mechanisms compared to conventional TWT to ensure the successful processing of latency-sensitive traffic to be supported within the R-TWT SP. These protection mechanisms may involve APs and STAs within the BSS terminating TXOPs at the start of the R-TWT service period (SP) to increase the probability that the R-TWT SP can start, or refraining from initiating channel access procedures to initiate a new TXOP if it is expected that the start time of the R-TWT SP will be exceeded. In other words, R-TWT-enabled terminals within the BSS terminate ongoing TXOPs or refrain from initiating new TXOPs immediately before the start time of the R-TWT SP to ensure that the channel remains idle at the time the AP operates the R-TWT SP. For legacy terminals that do not support R-TWT, the AP can apply a quiet period of 1 ms before the start of the R-TWT SP to prevent the legacy terminal from occupying TXOPs before the start of the R-TWT SP. The AP can broadcast the R-TWT schedule to STAs within the BSS in the same manner as broadcast TWT; that is, the AP advertises the R-TWT schedule through TWT elements included in management frames (e.g., beacon, probe response). Traffic processed within the R-TWT SP may be limited to traffic matching the R-TWT UL / DL TID.

[0130] In R-TWT, for enhanced shared media access protection, R-TWT-supported STAs must terminate all TXOPs at the boundary where the R-TWT SP begins and give high priority to traffic belonging to the membership-specific R-TWT UL / DL TID. This ensures that transmissions by STAs belonging to the membership can be guaranteed in the R-TWT SP.

[0131] However, if an OBSS exists, the (R-)TWT SPs of multiple APs may overlap. In this case, the transmission of delay-sensitive traffic processed by R-TWT SPs within each BSS may not be guaranteed due to interference from the OBSS. To resolve this issue, CR-TWT (coordinated R-TWT, or C-TWT) may be used, and for this purpose, (R-)TWT schedule information may be shared among multiple APs. Specifically, it is expected that APs may perform actions such as setting priorities for (R-)TWT schedules and sharing them, sharing timing information for synchronization between APs, or negotiating overlapping (R-)TWT schedules. Additionally, it is expected that (R-)TWTs may be rescheduled to prevent overlap between (R-)TWT SPs, or that resources may be shared between APs if overlap cannot be avoided.

[0132] Hereinafter, CR-TWT and C-TWT may be used interchangeably. TWT can collectively refer to Individual TWT, Broadcast TWT, and R-TWT. In the following description, a TWT parameter may be understood as at least one of the parameters included in the broadcast TWT parameter set field format and the individual TWT parameter set field format described in FIGS. 12 and FIGS. 13. Additionally, the following TWT information or information regarding the TWT schedule may also be understood as including at least one of the parameters described above.

[0133] The present disclosure describes a method and apparatus for simultaneously supporting the TWT requested by the STA and the existing OBSS TWT operated by the OBSS AP, or for resolving the overlap, when the TWT schedule requested by the STA overlaps with the (R-)TWT (TWT operated by an adjacent AP, hereinafter interchangeably referred to as OBSS TWT) set in the OBSS AP. The present disclosure proposes a method for the AP and the OBSS AP to coordinate TWT schedules in real time. To this end, when the TWT schedule requested by the STA overlaps with the OBSS TWT, the AP transmits a MAP coordination negotiation request message to the OBSS AP operating the overlapping OBSS TWT, and the OBSS AP transmits a MAP coordination negotiation response message in response to the message to resolve the overlapping TWT schedule.

[0134] In addition, a specific method for performing rescheduling of OBSS TWT is proposed, and a method for negotiating a method that simultaneously supports overlapping TWT or R-TWT schedules by utilizing multi-AP coordination schemes such as C-TDMA (coordinated time division multiple access), C-JT (coordinated joint transmission), C-BF (coordinated beamforming), C-SR (coordinated spatial reuse), and C-OFDMA (coordinated orthogonal frequency division multiple access) between OBSS APs and APs, including this in a MAP coordination negotiation request and / or response message, and a method for including a preferred and / or supported MAP coordination scheme in a message are proposed.

[0135] FIG. 9 is a diagram illustrating an example of the operation of an OBSS AP and an AP according to the present disclosure. Although FIG. 9 is illustrated as having one OBSS AP and one OBSS STA, the present disclosure is not limited to the example of FIG. 9, and it is possible for multiple OBSS APs and OBSS STAs to exist. The process of the AP and STA generating a TWT is accomplished by exchanging TWT setup frames, and the frame initiating the generation of the TWT can be called a TWT request frame, and the frame responding thereto can be called a TWT response frame. The TWT request frame and the TWT response frame include a TWT setup command field, and the TWT setup command may contain a request TWT, Suggest TWT, Demand TWT, Accept TWT, Alternate TWT, Dictate TWT, reject TWT, and TWT grouping value.

[0136] According to FIG. 9, an OBSS STA (900), which is a STA belonging to OBSS, transmits a TWT setup frame (where the TWT setup command field is set to request / suggest / demand TWT) to an OBSS AP (902) (910). The following TWT creation operation can be applied not only between the OBSS STA (900) and the OBSS AP (902) but also between any STA and AP. The TWT setup frame (910) initiating TWT setup can be called a TWT request frame, and if the TWT setup command of the TWT request frame is a request TWT, a suggest TWT, or a dictate TWT, information about the TWT schedule can be included in the TWT parameters and transmitted. The OBSS STA (900) initiating TWT generation may not include a schedule requesting generation in the TWT request frame. In this case, the OBSS AP may include TWT parameters specifying the TWT schedule in the TWT response frame and set the accept TWT value in the TWT setup command to generate a TWT corresponding to the schedule included in the TWT response frame. Subsequently, the OBSS AP transmits a TWT setup frame accepting the TWT setup (a TWT response frame in which the TWT setup command field is set to accept TWT) to the OBSS STA (912). As a result of the transmission and reception of the two messages, a TWT is established between the OBSS AP (902) and the OBSS STA (900) in the OBSS.

[0137] When OBSS STA (900) transmits a TWT request frame with a TWT setup command value containing a suggest TWT or a demand TWT to generate a TWT, the TWT request frame may include TWT parameters containing setting values ​​related to the TWT, such as Target Wake Time, Wake Interval, and nominalminimumWakeUpDuration. If the OBSS AP (901) can generate the requested TWT, it can complete the TWT schedule setting by responding with a TWT response frame with the TWT setup command value set to accept TWT. Afterwards, the OBSS AP can notify surrounding APs of the TWT schedule setting generated through steps 910 and 912, and can notify surrounding APs of the TWT schedule by sending a TWT schedule announcement (914). The above TWT schedule announcement may include detailed information about the TWT schedule, such as TWT parameters set as a result of steps 910 and 912, priority information of the set TWT schedule, timing information for time synchronization between APs, whether it is an R-TWT, and DL / UL TID values ​​processed within the TWT. The AP (904) receives the above TWT schedule announcement and obtains information about the TWT operated by the OBSS AP (902).

[0138] The above TWT schedule announcement may be transmitted by being included in a beacon transmitted by the OBSS AP (902), or by being transmitted by the OBSS AP to the AP by being included in a management frame individually addressed to the AP. The TWT schedule announcement transmitted by the OBSS AP to the AP may be transmitted in HT PPDU or non-HT duplicate PPDU format, and if transmitted in non-HT duplicate PPDU format, even if the OBSS AP and the AP operate on different primary channels, if the operating bandwidths of the OBSS AP and the AP overlap, information about the generated TWT schedule can be announced through the non-HT duplicate PPDU transmitted on the overlapping 20 MHz channel.

[0139] STA (906) sends a TWT setup frame (a TWT request frame with the TWT setup command field set to request / suggest / demand TWT) to the AP requesting TWT setup (916). 920 is the case where the AP can accept the TWT schedule requested by the STA. If the AP can accept the TWT schedule requested by the STA (for example, if there is no overlap with the TWT schedule of the OBSS AP obtained from the OBSS AP via step 914 or SP, or if the priority of the TWT schedule requested by the STA is higher than that of the TWT schedule of the OBSS AP), the AP sends a TWT setup frame (a TWT response frame with the TWT setup command field set to accept TWT) to accept the TWT schedule requested by the STA (922), performs TWT setup, and can include the configured TWT parameters in the TWT schedule announcement and send it to the OBSS AP (924). For the relevant Step 924, you can refer to the explanation of the TWT schedule announcement that the OBSS AP sends to the AP in Step 914.

[0140] 930 is a case where the AP cannot accept the TWT schedule requested by the STA. If the AP cannot accept the requested TWT schedule containing TWT parameters (for example, if it overlaps with the TWT schedule of the OBSS AP or SP, but for any reason the TWT schedule needs to be modified), the AP may transmit a TWT setup frame (a TWT response frame in which the TWT setup command field is set to dictate or alternate TWT) (932). In this case, the TWT setup frame may contain TWT parameters different from those according to the TWT schedule proposed by the STA. When the STA receives the TWT setup frame and requests TWT creation again without an additional response, it may request TWT setup by referring to the TWT parameters specified by the AP.

[0141] According to the present disclosure, the AP may transmit a TWT setup frame with the TWT setup command field set to pending or / and C-TWT negotiation required instead of the TWT setup frame of step 932 (a TWT response frame with the TWT setup command field set to dictate or alternate TWT) (934). Specific methods for setting the TWT setup command field to pending or / and C-TWT negotiation required are described below. The TWT setup frame with the TWT setup command set to pending or / and C-TWT negotiation required may indicate to the STA that C-TWT negotiation between APs (between the AP and the OBSS AP) is required. Such C-TWT negotiation may be a procedure for requesting the rescheduling of the TWT of a previously created OBSS AP, determining a multiple-AP coordination scheme (MAPC scheme) to simultaneously support the OBSS TWT and the TWT to be created, and negotiating specific operational parameters. The MAPC scheme can be a coordinated-TDMA (C-TDMA) in which TXOPs are shared between APs, a shared TWT in which APs and OBSS APs share TWT SPs, or one of coordinated-beamforming (C-BF), coordinated-spatial reuse (C-SR), or coordinated-joint transmission (C-JT).By sending a TWT response frame to the STA set to pending or / and C-TWT negotiation required (934), the AP can inform the STA that a Coordinated TWT (C-TWT) negotiation with the OBSS AP is required to successfully create the TWT currently being set up, and that the approval / rejection of TWT creation will be notified later depending on the content of the C-TWT negotiation.

[0142] The AP that has sent a TWT response frame set to pending or / and C-TWT negotiation required to the STA sends a MAP (Multi-AP) negotiation request frame to the OBSS AP (936). The MAP negotiation request frame may be referred to as a C-TWT negotiation request frame, a coordinated AP (C-AP) request frame, or a MAPC (Multi-AP Coordination) request frame. In the present invention, since the transmission of the MAP negotiation request frame between the AP and the OBSS AP is performed for the coordinated (R-)TWT, it may be mainly referred to as a C-TWT negotiation request frame. The MAP negotiation request frame may include information about the OBSS TWT to be negotiated and information about the TWT to be generated. Upon receiving the above message, the OBSS AP transmits a TWT setup frame containing updated TWT parameters (setting the TWT setup command field to suggest, dictate, or update TWT) to its STA, the OBSS STA, in order to attempt to change its TWT (OBSS TWT) schedule based on the TWT information received from the AP (938). Step 938, referred to as the TWT setup frame transmitted by the OBSS AP (902) to the OBSS STA (900), and the exchange of TWT response frames (942, 952), in which the OBSS STA (900) responds to the OBSS AP (902), can be referred to as intra-BSS TWT negotiation in OBSS.

[0143] 940 is the case where the OBSS STA agrees to the use of the updated TWT parameters. If the OBSS STA agrees to the use of the updated TWT parameters, the OBSS STA may express its consent to the AP (942). For example, to express its consent, the OBSS STA may send a TWT setup frame accepting the TWT setup (the TWT setup command field is set to accept TWT). Upon receiving the message accepting the TWT setup from the OBSS STA, the OBSS AP may send a MAP negotiation response frame to the AP (944). The MAP negotiation response frame may be referred to as a C-TWT response frame, a C-AP response frame, or a MAPC response frame. The MAP (C-TWT) negotiation response frame may indicate that the TWT negotiation has been finalized, including the result of the TWT negotiation. An AP that receives the above MAP (C-TWT) negotiation response frame and receives the result of the C-TWT negotiation from the OBSS AP can transmit a TWT setup frame to the STA to transmit the TWT creation result according to the C-TWT negotiation result (946).

[0144] 950 is the case where, in step 938, the OBSS STA does not agree to the use of the TWT parameters received through the TWT setup frame, or the OBSS TWT is an R-TWT and rescheduling is impossible. If the OBSS STA does not agree to the use of the updated TWT parameters or the OBSS TWT is an R-TWT and rescheduling is impossible, the OBSS STA may express conditional consent (or / and additional adjustment is needed) to the AP (952). For example, the OBSS STA may express conditional consent by setting the value of the TWT setup command in the TWT setup frame to accept TWT and transmitting it. The TWT setup command can be used as an accept TWT value only by an AP (902, 904) that is a TWT responding STA or a TWT scheduling AP, but exceptionally in relation to C-TWT and MAP negotiation, it can be used by a STA (900, 906) that is a TWT requesting STA or a TWT scheduled STA to express the intention of conditional agreement to the AP's TWT readjustment and / or C-TWT negotiation.

[0145] Although not illustrated in the drawing, if TWT reconfiguration and / or C-TWT negotiation request is received from AP (904) by step 936, OBSS AP (902) may transmit a TWT setup frame containing TWT parameters with MAPC scheme usage in mind to OBSS STA (900) if TWT reconfiguration is not possible, in which case OBSS STA must accept the TWT setup frame of OBSS AP (902) in order to support its other delay-sensitive uplink / downlink traffic, in which case step 952 may be seen as consent to the TWT setup frame that optionally includes information on TWT reconfiguration with C-TWT negotiation or / and TWT scheduling and operation methods with MAPC scheme usage in mind transmitted by OBSS AP (902).

[0146] The OBSS AP (902), which performs intra-BSS TWT negotiation by step 952 and transmits the C-TWT negotiation result (MAP coordination is additionally required) to the AP (904) (954), determines the type of MAP coordination scheme to be performed as a result of the C-TWT negotiation request corresponding to step 936 and the operation parameters for it. That is, step 956 is not illustrated but can be performed at the OBSS AP or / and AP.

[0147] Upon receiving the OBSS AP's conditional consent from the OBSS STA, the OBSS AP may transmit a MAP (C-TWT) negotiation response frame indicating that MAP coordination is required to the AP (954). Upon receiving the MAP (C-TWT) negotiation response frame, the AP sets a coordination method (956) and transmits a TWT setup frame (with the TWT setup command field set to dictate or suggest TWT) containing TWT parameters determined according to the set coordination method to the STA (958). The specific formats of the MAP (C-TWT) negotiation request frame and the MAP (C-TWT) negotiation response frame are described below.

[0148] The flowcharts described above illustrate exemplary methods that may be implemented in accordance with the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of this specification. For example, although they are illustrated as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, steps may be omitted or replaced with other steps. The values ​​described above are merely examples, and it is fully possible to apply other values.

[0149] Below, the TWT setup frame of FIG. 9 is described. FIG. 10 is a diagram illustrating an example of a TWT setup frame format.

[0150] A TWT setup frame may be transmitted by an STA to an AP to request the setup of a TWT SP, or by an AP to indicate the status of the requested TWT SP to the STA. A TWT setup frame may consist of a TWT request frame initiating the TWT setup and a TWT response frame as a response thereto. A TWT setup frame (1000) includes a TWT element (1010), and the TWT element format includes fields for element ID (1012), length (1014), control (1016), and TWT parameter information (1018).

[0151] Here, the negotiation type (1022) included in the control (1016) indicates whether the information included in the TWT element is a parameter of a broadcast TWT or a parameter of an individual TWT. A broadcast TWT parameter is a parameter that can be applied commonly to multiple APs, and an individual TWT parameter is a parameter that can be applied to each AP.

[0152] FIG. 11 illustrates an example of the format of a TWT parameter when the negotiation type is a TWT parameter of an individual TWT. According to FIG. 11, the individual TWT parameter set field format (1100) includes a request type field, and the request type (1110) includes a TWT setup command field.

[0153] FIG. 12 illustrates an example of the format of a TWT parameter when the negotiation type is a TWT parameter of a broadcast TWT. According to FIG. 12, the broadcast TWT parameter set field format (1200) includes a request type field, and the request type (1210) includes a TWT setup command field.

[0154] The above broadcast TWT parameter set field format (1200) may include at least one of the following information.

[0155] - request type field(1210)

[0156] The format of the Request type field may include the TWT request field, TWT setup command field, trigger field, last broadcast TWT parameter set field, flow type field, broadcast TWT recommendation field, TWT wake interval exponent field, and reserved field.

[0157] The TWT request field has a value of 1 if the entity transmitting the TWT element is a TWT requesting STA or a TWT scheduled STA (usually an STA), and a value of 0 if the entity is a TWT responding STA or a TWT scheduling AP (usually an AP).

[0158] The TWT setup command field indicates the type of TWT command. The TWT setup command field is used for negotiating individual TWTs or broadcast TWTs.

[0159] The Trigger field is an indicator that indicates whether a trigger frame is transmitted within the TWT SP, and if the value is 1, at least one trigger frame must be transmitted.

[0160] The Last broadcast parameter set field is an indicator that indicates whether it is the last broadcast TWT parameter within the corresponding broadcast TWT element, and a broadcast TWT element with a last broadcast parameter set value of 1 means that it is the last broadcast TWT parameter within the broadcast TWT element.

[0161] The Flow type field indicates the form of interaction between the TWT requesting STA (or TWT scheduled STA) and the TWT responding STA (or TWT scheduling AP). A value of 0 indicates an announced TWT, meaning the TWT requesting STA (or TWT scheduled STA) must notify the TWT responding STA (or TWT scheduling AP) that it is in an awake state by sending a PS-Poll or APSD (automatic power save delivery) trigger frame before the TWT responding STA (or TWT scheduling AP) transmits a frame. A value of 1 indicates an unannounced TWT, meaning the TWT responding STA (or TWT scheduling AP) transmits a frame without the TWT requesting STA's PS-Poll or APSD.

[0162] The Broadcast TWT recommendation field is used to indicate the type of frame that the TWT scheduled STA and TWT scheduling AP can transmit during the broadcast TWT SP.

[0163] If the Broadcast TWT recommendation field value is 0, there are no restrictions on the frames transmitted within the broadcast TWT SP. If the Broadcast TWT recommendation field value is 1, it is recommended that the frames transmitted within the broadcast TWT SP be limited to solicited status and solicited feedback (e.g., PS (power save)-Poll, QoS Null frames, feedback included in QoS Control fields or HE variant HT Control, feedback within HE TB feedback NDP, BQR (Bandwidth Query Report), BSR (Buffer Status Report), frames transmitted as part of sounding feedback exchange, control response frames). Additionally, Trigger frames transmitted by the TWT scheduling AP cannot include RU (resource unit) for random access.

[0164] When the Broadcast TWT SP field value is 2, it is mostly the same as when the field value is 1, except that the TWT scheduling AP must include at least one RU for random access in the Trigger frame it transmits. When the Broadcast TWT Recommendation field value is 3, there are no restrictions other than that the AP transmits a TIM frame containing a TIM (traffic indication map) element or a FILS (fast initial link setup) Discovery frame at the very beginning of each TWT SP.

[0165] The TWT wake interval exponent field is used to represent the TWT wake interval value. The TWT wake interval is the average time interval between two consecutive TWT SP start times. The TWT Interval Exponent field represents the exponent value of the TWT wake interval value in microsecond time units.

[0166] TWT wake interval =(TWT Wake Interval Mantissa)

[0167] - Target wake time: The target wake time field indicates a positive integer value corresponding to the TSF time at which the STA should enter the wake state.

[0168] - Nominal minimum TWT wake duration: The nominal minimum TWT wake duration field refers to the minimum time an STA must remain awake for frame exchange within the corresponding TWT SP, and the unit is 256 us.

[0169] - TWT wake interval mantissa: The TWT Interval Mantissa field represents the mantissa value of the TWT wake interval, where the unit of the TWT wake interval is microsecond and the base value is 2.

[0170] - Broadcast TWT info: The above broadcast TWT info field may include the restricted TWT traffic info present field, the restricted twt schedule info field, the broadcast TWT ID field, and the broadcast TWT persistence field.

[0171] The Restricted TWT traffic info present field indicates the presence or absence of the Restricted TWT traffic info field; if the value is 1, it exists. For Non-EHT STAs, this field value may be reserved for other purposes.

[0172] The Restricted TWT schedule info field is included when the restricted TWT parameter set field is passed to a TWT element with a negotiation type field value of 2. If the value is 0, the R-TWT schedule is an 'idle R-TWT schedule', meaning there are no member STAs or the schedule is suspended for all STAs. If the Restricted TWT schedule info field value is 1, the R-TWT schedule is an active R-TWT schedule, meaning there is at least one member STA in the R-TWT schedule.

[0173] If the value of the Restricted TWT schedule info field is 2, the corresponding R-TWT schedule is a full R-TWT schedule, meaning that the resources of the R-TWT schedule are insufficient or there are too many existing member STAs, making it difficult to accept new STAs as members. If the value of the Restricted TWT schedule info field is 3, the corresponding R-TWT schedule is an advertised R-TWT schedule, meaning that it is for APs corresponding to non-transmitted BSSIDs that are members of the same multiple BSSID set or co-hosted BSSID set transmitting the Restricted TWT Schedule Info field.

[0174] The Broadcast TWT ID field is used as an identifier to refer to a specific broadcast TWT.

[0175] The Broadcast TWT persistence field is a value representing the time interval containing the Broadcast TWT SP corresponding to the broadcast TWT parameter set, expressed as the number of TBTTs (target beacon transmission times). For example, if the value is 10, it means that the Broadcast TWT SP configured with the corresponding parameters is in operation for the duration of 10 beacon transmissions, and if the value is 255, it means that it is applied permanently.

[0176] - Restricted TWT traffic info

[0177] The Restricted TWT Traffic Info field format included in the Broadcast TWT Info field format may include a Traffic info control field, a Restricted TWT DL TID bitmap field, and a Restricted TWT UL TID bitmap field.

[0178] The Restricted TWT DL TID bitmap field and the Restricted TWT UL bitmap field represent TIDs (traffic identifiers) identified as latency-sensitive traffic in the downlink and uplink directions, respectively, in the form of bitmaps.

[0179] The above Restricted TWT Traffic Info field includes the DL TID Bitmap valid field, the UL TID bitmap valid field, and the reserved field.

[0180] The DL TID Bitmap valid and UL TID Bitmap valid fields indicate whether the Restricted TWT DL TID bitmap and Restricted TWT UL TID bitmap fields are included, respectively. If the value is 1, the Restricted TWT DL TID bitmap or Restricted TWT UL TID bitmap fields are included in the Restricted TWT traffic info field, and if the value is 0, all TIDs are classified as latency sensitive traffic in the corresponding R-TWT membership.

[0181] In this disclosure, a method is proposed to indicate that the TWT setup command is pending or / and C-TWT negotiation required using the TWT setup command field. The meaning of "Pending" and "C-TWT negotiation required" is that the AP will notify the STA requesting the TWT setup that the TWT schedule request requires coordination between adjacent APs, and therefore the approval or rejection of the schedule will be announced later after coordination. If the current TWT Request field is 1, it means a TWT setup frame transmitted by the STA, and if it is 0, it means a TWT setup frame transmitted by the AP. Since the pending and C-TWT negotiation required of this disclosure is transmitted from the AP to the STA, the value of the TWT Request field becomes 0. Among the values ​​of the current TWT setup command field, Request TWT (0), Suggest TWT (1), and Demand TWT (2) are commands that can only be used by the STA, and it is determined that the AP will not use them. In this disclosure, a method is proposed to indicate pending or C-TWT negotiation required when an AP uses one of the three values ​​of the TWT setup command field (i.e., when TWT Request == 0). In particular, Suggest TWT (1) or Demand TWT (2) may additionally indicate to the STA that if the AP that received the C-TWT negotiation request is in conflict or partially overlapping and needs to readjust or utilize a MAPC scheme, the AP may readjust some of the previously created TWT parameters or that an additional MAPC scheme for C-TWT can be used within the TWT SP.

[0182] Table 1 is an example of indicating the command of the TWT setup frame according to the value of the TWT setup command in FIGS. 11 and 12. Table 1 is an example of indicating Pending and C-TWT negotiation required when the value of the TWT setup command field is 0, and the present disclosure is not limited to such description, and obvious variations are possible. In addition, Table 1 shows an example of indicating that when the value of the TWT setup command field is 1 or 2, it is used in the intra-BSS TWT negotiation process, and that some of the TWT parameters previously generated by the AP with a TWT Request field of 0 may be readjusted to the STA, or that an additional MAPC scheme for C-TWT may be used within the TWT SP.

[0183] TWT Setup Command field valueCommand nameDescription0Request TWTA TWT requesting or TWT scheduled STA requests to join a TWT without specifying a target waketime. TWT Request field가 0인 경우, TWT requesting or TWT scheduled STA가 요청한 TWT 참여의 결정 여부가 pending임을 나타냄 (인접 AP간 coordination negotiation이 필요)1Suggest TWTA TWT requesting or TWT scheduled STA requests to join a TWT and specifies a suggested set ofTWT parameters with the possibility that if the requested target wake time and / or other TWT parameters cannot be accommodated, then the TWT setup might still be accepted by the TWT requesting or TWT scheduled STA.If the TWT Request field is 0, it indicates that the decision on TWT participation requested by the TWT requesting or TWT scheduled STA is pending (coordination negotiation between adjacent APs is required). Alternatively, if used for intra-BSS TWT negotiation, if the TWT Request field is 0, it indicates that some TWT parameters previously generated by the TWT requesting or TWT scheduled STA and the TWT responding STA or TWT scheduling AP sending the message may be readjusted, or that an additional MAPC scheme for C-TWT may be used within the TWT SP. 2Demand TWTA: A TWT requesting or TWT scheduled STA requests to join a TWT and specifies a demanded set of TWT parameters. If the demanded set of TWT parameters is not accommodated by the responding STA or TWT scheduling AP, then the TWT requesting STA or TWT scheduled STA (M118) rejects the TWT setup.If the TWT Request field is 0, it indicates that the decision regarding participation in the TWT requested by the TWT requesting or TWT scheduled STA is pending (coordination negotiation between adjacent APs is required); or, if used for intra-BSS TWT negotiation, if the TWT Request field is 0, it indicates that some TWT parameters previously generated by the TWT requesting or TWT scheduled STA and the TWT responding STA or TWT scheduling AP sending the message may be readjusted, or that an additional MAPC scheme for C-TWT may be used within the TWT SP. 3TWT Grouping The TWT responding STA suggests TWT group parameters that are different from the suggested or demanded TWT parameters of the TWT requesting STA. This command is valid if the TWT Request field is 0 and the Negotiation Type subfield is 0 and sent by an S1G STA; otherwise, it is not applicable.4Accept TWTA TWT responding STA or TWT scheduling AP accepts the TWT request with the TWT parameters (see NOTE) indicated in the TWT element transmitted by the TWT requesting STA or TWT scheduled STA. This value is also used in unsolicited TWT responses.TWT Request field가 1인 경우, TWT responding STA or TWT scheduling AP가 요청한 TWT 재조정 및 C-TWT 협상 방식에 대한 동의를 나타냄5Alternate TWTA TWT responding STA or TWT scheduling AP suggests TWT parameters that are different from those suggested by the TWT requesting STA or TWT scheduled STA. This command is valid if the TWT Request field is 0; otherwise, it is not applicable.6Dictate TWTA TWT responding STA or TWT scheduling AP indicates TWT parameters that are different from those suggested by the TWT requesting STA or TWT scheduled STA. This command is valid if the TWT Request field is 0; otherwise, it is not applicable.7Reject TWTA TWT responding STA or TWT scheduling AP rejects setup, or a TWT scheduling AP terminates an existing broadcast TWT, or a TWT scheduled STA terminates its membership in a broadcast TWT.TWT Parameters are TWT, Nominal Minimum TWT Wake Duration, TWT Wake Interval, and TWT Channel subfield values indicated in the TWT element.The Trigger subfield value indicated in the TWT element is also a TWT parameter for an HE STA. When the Restricted TWT Traffic Info field is included in a Restricted TWT Parameter Set field in the TWT element, TID(s) indicated in the Restricted TWT Traffic Info field are also TWT parameters for an EHT STA.

[0184] The following describes the information included in the MAP negotiation request and response frames transmitted and received between the AP and the OBSS AP.

[0185] A MAP (C-TWT) negotiation request frame may include at least one of the following information. The information included in a MAP (C-TWT) negotiation request frame is not limited to the above example.

[0186] - TWT schedule information to be adjusted

[0187] * TWT information 1 (TWT information requested to be set to the AP, which may be information about the TWT schedule to be coordinated)

[0188] * TWT information 2 (Information about OBSS TWTs conflicting with the requested TWT)

[0189] - Requested MAP adjustment information

[0190] * SupportedMAPCoordinationCapability (This is information indicating the supported MAP coordination capability, which may be shared between APs during the MAP setup or discovery phases, in which case it may be omitted. This may be information about the possible types of MAP coordination features supported by the AP.) For example, the SupportedMAPCoordinationCapability field may be as shown in Table 2 below, but is not limited by the contents of Table 2.

[0191] SupportedMAPCoordination-Capability(Bitmap representation)Meaning0C-R-TWT supported1C-TDMA supported2C-BF supported3C-JT supported4C-SR supported5C-OFDMA supported6-7RFU (Reserved)

[0192] * PreferredMAPCoordinationMethod (a preferred MAP coordination method, which may be information about the MAP coordination method preferred by the AP (hereinafter referred to as coordination method or coordination method, which may be used interchangeably))

[0193] - Coordination level (This is information indicating the degree of adjustment available, which can be, for example, 0 (weak) to 7 (strong), where 0 indicates that adjustment is not available. The above information may be included in the frame control.)

[0194] The MAP negotiation response frame may include at least one of the following information. The information included in the MAP negotiation response frame is not limited to the above example.

[0195] - C-TWT negotiation command (this may be information indicating the method of TWT coordination, such as request, suggest, modify, accept, reject, confirmed, or coordination required). For example, the C-TWT negotiation command field may be as shown in Table 3 below, but is not limited by the contents of Table 3. This information may correspond to a response regarding whether to accept, reject, or suggest modification of the coordination method preferred (or proposed) by the AP included in the MAP negotiation request frame.

[0196] C-TWT negotiation CommandMeaning0C-TWT negotiation request1C-TWT negotiation accept2C-TWT negotiation reject3MAP coordination required4MAP coordination suggest5MAP coordination modify6MAP coordination confirmed7Reserved

[0197] - RequiredMAPCoordinationMethod (This may be specific information regarding the MAP coordination method required to support C-(R-)TWT. For example, the coordination method may be at least one of the methods disclosed in Table 2 above.)

[0198] FIG. 13 is a diagram illustrating an example of a C-TWT negotiation element that can be included in a MAP negotiation request and response frame.

[0199] According to FIG. 13, the C-TWT negotiation element (1300) may include an element ID (1302), a length (1304), an element ID extension (1306), and C-TWT negotiation element information (1308). The length of the C-TWT negotiation element information (1308) may be changed.

[0200] An example of the specific configuration of C-TWT negotiation element information (1320) is as follows. C-TWT negotiation element information (1320) may include frame control (1322), type (1324), TWT information 1 (1326), TWT information 2 (1328), requested MAP coordination information (1330), and suggested MAP coordination information (1332). For a description of TWT information 1 (1326) and TWT information 2 (1328), refer to the description above.

[0201] An example of the specific configuration of the frame control (1340) is as follows. The frame control (1340) may include a C-TWT framework version (1342), OBSS TWT info present (1344), requested MAP coordination info present (1346), suggested MAP coordination info present (1348), and a coordination level (1350). The coordination level may also be included in the requested MAP coordination info present (1346) or the suggested MAP coordination info present (1348).

[0202] The configuration of FIG. 13 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are possible in which the information described above is indicated using other fields.

[0203] FIG. 14 illustrates an example of a TWT information format. The TWT information may correspond to TWT information 1 (1326) and TWT information 2 (1328) of FIG. 13. The TWT information (1400) may include a control (1402), length (1404), TWT type (1406), TWT ID (1408), bandwidth information (1410), and TWT element (1412). The control (1402) may include a present bitmap indicating whether bandwidth information and TWT element are included. The TWT type (1406) may indicate whether the TWT is an individual TWT, a broadcast TWT, or an R-TWT. The TWT ID (1408) is an identifier of the TWT schedule, which is equal to the TWT flow identifier in the case of an individual TWT and equal to the broadcast TWT ID in the case of a broadcast TWT or R-TWT. Bandwidth information (1410) includes information about the bandwidth and primary channels used in the TWT schedule. The configuration of FIG. 14 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are possible in which the information described above is indicated using other fields.

[0204] FIG. 15 illustrates an example of a requested / suggested MAP coordination information format. The requested / suggested MAP coordination information may correspond to the requested MAP coordination information (1330) and suggested MAP coordination information (1332) of FIG. 13. The requested / suggested MAP coordination information (1500) may include a control (1502), a length (1504), a negotiation command (1506), a Supported MAP-Coordination Capability (1508), a Preferred MAP-Coordination Method (1510), a Suggested-Coordination Method (1512), and a Required-Coordination Method (1514).

[0205] The control (1502) may include a present bitmap indicating whether SupportedMAP-CoordinationCapability, PreferredMAP-CoordinationMethod, Suggested-CoordinationMethod, and Required-CoordinationMethod are included. The negotiation command (1506) may indicate a method of TWT coordination, such as requesting, suggesting, modifying, accepting, rejecting, confirming, or requiring coordination. SupportedMAP-CoordinationCapability (1508) may indicate a supported coordination capability and may be a bitmap indicating at least one supported coordination method among, for example, CR-TWT, C-TDMA, C-BF, C-JT, C-SR, C-OFDMA, etc. In this case, each bit may indicate whether each coordination method is supported. PreferredMAP-CoordinationMethod (1510) is information about the coordination method preferred by the AP, and Suggested-CoordinationMethod (1512) may be information about the coordination method that the AP suggests to the OBSS AP to support the requested TWT. Required-CoordinationMethod (1514) may be information about the coordination method that the OBSS AP suggests to support the requested TWT.

[0206] The configuration of FIG. 15 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are possible in which the information described above is indicated using other fields.

[0207] FIG. 16 illustrates an example of the requiredCoordinationMethod subfield format. According to FIG. 16, the requiredCoordinationMethod subfield (1600) may include a control (1602), a length (1604), a coordination method (1606), and a coordination specific field (1608). The control (1602) may indicate the presence and length of the coordination specific field, the coordination method (1606) is information about a coordination method for supporting C-TWT, and the coordination specific field (1608) may include information about a coordination method required to support C-TWT and / or detailed parameters.

[0208] An example of a coordination specific field (1610) is shown when the coordination method is C-TDMA (i.e., when the coordination method (1606) indicates C-TDMA). In this case, the coordination specific field (1610) contains detailed information about the C-TDMA that can be used for the C-TWT to resolve the collision between TWT1 (i.e., the requested TWT) indicated by TWT information 1 and TWT2 (i.e., the TWT of the colliding OBSS) indicated by TWT information 2. For example, the coordination specific field (1610) may include fields such as control (1612), TXS type (1614), TXS time (timestamp 1) (1616), synchronization information (timestamp 2) (1618), TXS bandwidth (1620), TXS return requirement (1622), and TXOP sharing AP address (1624).

[0209] Control (1612) may indicate the existence of one or more fields following the control field. TXS type (1614) indicates the type of AP TXOP sharing, and there may be types such as full bandwidth sharing or partial bandwidth sharing. TXS time (1616) is information about the time when TXOP sharing is performed. Synchronization information (1618) is the sharing of the value of the time synchronization function (TSF) timer to synchronize time between the two BSSs operated by the two APs, since the clocks of the AP and the OBSS AP are different. This value may be indicated as an 8-octet timestamp value, and this field may be omitted if the two APs have already synchronized time. TXS bandwidth (1620) is information specifying the bandwidth for which TXOP sharing will be performed. TXS return required (1622) is information indicating whether the AP receiving the TXOP (TXOP shared AP) must return the remaining TXOP to the AP that transferred the TXOP (TXOP sharing AP) if it cannot use all of the transferred TXOP. TXOP sharing AP (1624) is information indicating the address of the AP that will acquire the TXOP for C-TWT.

[0210] The contents of FIG. 16 above may be modified if other adjustment methods are used. Also, the configuration of FIG. 16 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are possible in which the information described above is indicated using other fields.

[0211] The MAP negotiation request and response frames described above can be transmitted in various frame forms. For example, the MAP negotiation request and response frames may be included in a multi-STA blockAck frame, a (protected) UHR action frame, or a management frame, in which case the C-TWT negotiation element of FIG. 13 may be included as a subfield of the frame. Although the present disclosure describes a specific example in which the C-TWT negotiation element is included in a multi-STA blockAck frame, a (protected) UHR action frame, or a management frame, it is also possible for the C-TWT negotiation element to be included in other frames and transmitted and received between the OBSS AP and the AP.

[0212] FIG. 17 illustrates an example in which a C-TWT negotiation element is included in a multi-STA blockAck frame. In particular, the multi-STA blockAck frame can be used for a C-TWT negotiation response.

[0213] Multi-STA blockAck (1700) may include frame control (1702), duration (1704), RA (1706), TA (1708), BA control (1710), BA information (1712), and FCS (1714). BA information (1712) may include one or more AID TID info fields. In this case, BA information (1712) may include AID TID info (1720), block Ack starting sequence control (1722), and block Ack bitmap (1724). In this case, block Ack bitmap (1724) may include C-TWT negotiation elements.

[0214] AID TID info (1720) may include AID11 (1732), Ack type (1734), and TID (1736). In this case, AID may indicate that the following block Ack bitmap (1724) field indicates a C-TWT negotiation element, Ack type (1734) may indicate a value of AID TID info specialized for a C-TWT negotiation element, and TID (1736) may indicate the length of a C-TWT negotiation element included in BA information (1712).

[0215] The configuration of FIG. 17 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are possible in which the information described above is indicated using other fields.

[0216] FIG. 18 illustrates an example in which a C-TWT negotiation element is included in a (protected) UHR action frame. FIG. 18 illustrates a case in which a C-TWT negotiation element is included within a newly defined action frame. The newly defined UHR (ultra high reliability) action frame may be configured as shown in Table 4 below, and the content of the present disclosure is not limited by Table 4.

[0217] OrderMeaning1category2UHR action or protected UHR action3Dialog token4C-TWT negotiation frame element

[0218] At this time, the category field (1800) may indicate whether it is a UHR or a protected UHR through its value, and the UHR action or protected UHR action field (1810) may indicate a C-AP negotiation or a C-TWT negotiation. These values ​​are merely examples. Among the newly defined action names, a C-TWT negotiation frame element within the action frame of C-AP negotiation or C-TWT negotiation may be included and transmitted. The configuration of FIG. 18 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are possible in which the information described above is indicated using other fields.

[0219] FIG. 19 is a diagram illustrating an example in which a C-TWT negotiation element is included in a management frame. For example, the C-TWT negotiation element may be included in a frame body within the management frame.

[0220] According to FIG. 19, a management frame may be composed of a frame control (1900), duration (1902), address 1 (1904), address 2 (1906), address 3 (1908), sequence control (1910), HT control (1912), frame body (1914), and FCS (1916). In this case, a C-TWT negotiation element may be included in the frame body (1914), and address 1 (1904) may be the address of an OBSS AP receiving a request for C-TWT negotiation as an RA (=destination address, DA). Address 2 (1906) may be the address of an AP requesting C-TWT negotiation as a TA (=source address, SA). Address 3 (1908) may be the same as address 2. The configuration of FIG. 19 is merely an example, and it is possible to omit at least one of the fields described above or to add additional fields. Alternatively, obvious variations are also possible using other fields in which the information described above is indicated.

[0221] FIG. 20 is a diagram illustrating another example of the operation of an OBSS AP and an AP according to the present disclosure. FIG. 20 is an example (2012) in which, unlike FIG. 9, when the AP receives a TWT setup frame requesting TWT setup from the STA, the AP must always inquire about the MAP coordination relationship with the OBSS AP and receive explicit confirmation from the OBSS AP before accepting the TWT requested from the STA.

[0222] According to FIG. 20, the STA (2006) transmits a TWT setup frame to the AP (2004) requesting the setup of the TWT (2010). The description of step 910 in FIG. 9 may be referenced for the above step 2010. Subsequently, the AP transmits a TWT setup frame to the STA in response to the received TWT setup frame, expressing the intent that it is pending and MAP negotiation required (2014). The description of step 934 in FIG. 9 may be referenced for the above step 2014. Subsequently, the AP transmits a C-TWT negotiation request to the OBSS AP (2002) (2016). Upon receiving the message, the OBSS AP performs an internal TWT coordination procedure with the OBSS STA (2000) if necessary (2018). The internal TWT coordination procedure may follow the description in FIG. 9.

[0223] If the OBSS AP and OBSS STA can accept the TWT schedule according to the C-TWT negotiation request without MAP adjustment (2020), the OBSS AP sends a C-TWT negotiation response to the AP (2022), and the C-TWT negotiation response may express an intention that no MAP adjustment is required. Upon receiving the C-TWT negotiation response, the AP sends a TWT setup frame and may indicate to the STA that it accepts (2024).

[0224] If the OBSS AP and OBSS STA determine that MAP coordination is necessary to accept the TWT schedule according to the C-TWT negotiation request (2030), the OBSS AP determines how to handle the requested TWT coordination (2032). Subsequently, the OBSS AP sends a C-TWT negotiation response indicating that coordination is necessary to the AP (2034), and upon receiving this, the AP sends a C-TWT negotiation confirm message to the OBSS AP (2036). The C-TWT negotiation confirm message may include information on the necessary coordination method. The C-TWT negotiation confirm message may be a MAP negotiation frame in which the C-TWT negotiation Command value indicates MAP coordination confirmed (value 6 in Table 3). Subsequently, the AP sends a TWT setup frame expressing acceptance to the STA (2038), and the TWT setup frame may include channel connection-related parameters, such as TWT parameters that need to be additionally changed. Subsequently, C-TWT operations can be performed between OBSS AP and AP according to the coordination method indicated by the C-TWT negotiation confirm message (2040).

[0225] The content of FIG. 20 can be interpreted in combination with FIG. 9, and the technical configuration of FIG. 20 can also be interpreted in combination with FIG. 9 and the content described above.

[0226] The flowcharts described above illustrate exemplary methods that may be implemented in accordance with the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of this specification. For example, although they are illustrated as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, steps may be omitted or replaced with other steps. The values ​​described above are merely examples, and it is fully possible to apply other values.

[0227] FIG. 21 is a diagram illustrating an example of the operation of an AP performing TWT scheduling according to the present disclosure.

[0228] According to FIG. 21, the AP receives a TWT setup frame from a TWT scheduled STA (a TWT-configured STA, which may be used interchangeably with the STA of the present invention) (2100). The TWT setup frame is a frame requesting the setup of a TWT, and may be used interchangeably with a TWT setup request. Upon receiving the TWT setup request, the AP determines whether the requested TWT parameter is R-TWT and whether the TWT parameter, such as TWT and TWT interval, is specified to request the TWT setup (2105). That is, the AP can determine whether the TWT parameter is included in the TWT setup request. If so, the AP determines whether the R-TWT SP requested by the STA conflicts with the OBSS TWT schedule (2110). The AP has previously received TWT schedule information of the corresponding OBSS AP from the OBSS AP, and can verify whether the requested TWT SP conflicts with the OBSS TWT SP based on the received TWT schedule information of the OBSS AP. The above OBSS AP may be one or more, and the TWT settings configured in each OBSS AP may also be one or more.

[0229] If a collision occurs, the AP sends a C-TWT negotiation request frame to the OBSS AP where the OBSS TWT is colliding (2120). The C-TWT negotiation request frame may include R-TWT schedule information that the AP intends to generate and / or OBSS TWT schedule change request information. If no collision occurs, the AP notifies the TWT scheduled STA that the R-TWT has been successfully set up (2115). At this time, the AP may send a TWT setup frame with the TWT request type (or TWT setup command) set to accept.

[0230] If a collision occurs, the AP may send a TWT setup frame containing an indicator indicating pending or / and C-TWT negotiation required to the TWT scheduled STA (2125). This procedure may be omitted. Subsequently, the AP checks whether it has received a C-TWT negotiation response frame containing an accept indicator from the OBSS AP (2130). If the AP has received a C-TWT negotiation response frame containing an accept indicator, the AP proceeds to step 2115 and notifies the TWT scheduled STA that the R-TWT has been successfully set up (2115).

[0231] If the AP does not receive a C-TWT negotiation response frame containing an accept indicator, the AP receives a C-TWT negotiation response frame containing a "coordination required" indicator from the OBSS AP and determines whether the coordination method proposed by the OBSS AP is supported (2135). If so, the AP informs the TWT scheduled STA that the R-TWT has been conditionally set up (2140). At this time, the AP may send a TWT setup frame to the TWT scheduled STA with the TWT request type (or TWT setup command) set to conditionally accept, or send a frame (e.g., a TWT setup frame) containing an indicator indicating conditionally accepted to the TWT scheduled STA. Subsequently, the AP can operate the TWT by coordinating with the OBSS AP according to the proposed coordination method. If not, the AP sends a frame expressing its intention to reject the R-TWT setup to the TWT scheduled STA (2145), and at this time, it may send a TWT setup frame with the TWT request type (or TWT setup command) == reject.

[0232] The flowcharts described above illustrate exemplary methods that may be implemented in accordance with the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of this specification. For example, although they are illustrated as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, steps may be omitted or replaced with other steps. The values ​​described above are merely examples, and it is fully possible to apply other values.

[0233] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples provided to facilitate the explanation of the technical content of the present disclosure and to aid in understanding the present disclosure, and are not intended to limit the scope of the present disclosure. That is, it is obvious to those skilled in the art that other variations based on the technical concept of the present disclosure are possible. Furthermore, each of the above embodiments may be combined and operated together as needed. For example, parts of one embodiment of the present disclosure and another embodiment may be combined to operate AP and STA.

[0234] Meanwhile, the order of description in the drawings explaining the method of the present invention does not necessarily correspond to the order of execution, and the order of precedence may be changed or executed in parallel. Alternatively, the drawings explaining the method of the present invention may omit some components and include only some components to the extent that the essence of the present invention is not compromised.

Claims

1. A method performed by an electronic device of a wireless LAN network, A step of receiving a message from an OBSS (overlapping basic service set) AP (access point) containing information about a TWT (target wake time) schedule set in the OBSS AP; A step of receiving a first TWT frame requesting TWT configuration from the STA (station); A step of transmitting a second TWT frame indicating that pending or coordination is required when the TWT requested by the STA in response to the first TWT frame overlaps with the TWT schedule set in the OBSS AP and the TWT schedule for which setting was requested; and A method characterized by including the step of transmitting a message requesting TWT coordination to the above OBSS AP.

2. A method according to claim 1, characterized in that a TWT setup command field included in the second TWT frame indicates that a determination of acceptance for the TWT requested through the first TWT frame is pending or that coordination with the OBSS AP is required, or an indicator included in the second TWT frame indicates that a determination of acceptance for the TWT requested through the first TWT frame is pending or that coordination with the OBSS AP is required.

3. A method according to claim 1, wherein the message requesting TWT coordination comprises at least one of information regarding the requested TWT, information regarding the TWT of the overlapping OBSS AP, information indicating a coordination method that the electronic device can support, and information indicating a coordination method preferred by the electronic device.

4. In Paragraph 1, The step of receiving a response message to a message requesting TWT adjustment from the above OBSS AP; and It further includes the step of transmitting a third TWT frame to the above STA, and The above response message includes information regarding the response to the adjustment method and / or parameters regarding the adjustment method, and A method characterized in that the above-mentioned third TWT frame includes information about the TWT to be set.

5. A method performed by an electronic device of a wireless LAN network, A step of transmitting a first TWT frame requesting the setting of a TWT (target wake time) to an AP (access point); and A method comprising the step of receiving a second TWT frame from the AP in response to the first TWT frame, which indicates that the TWT requested by the STA is pending or requires coordination, wherein a TWT setup command field included in the second TWT frame indicates that the requested TWT is pending or requires coordination, or an indicator included in the second TWT frame indicates that the requested TWT is pending or requires coordination.

6. A method performed by an electronic device of a wireless LAN network, A step of receiving a message requesting TWT (target wake time) coordination from an OBSS (overlapping basic service set) AP (access point); and It includes the step of transmitting a response message to a message requesting TWT adjustment to the above OBSS AP, and A method characterized in that the message requesting the above TWT coordination includes at least one of information regarding the requested TWT, information regarding the TWT of the overlapping OBSS AP, information indicating a coordination method that the electronic device can support, and information indicating a coordination method preferred by the electronic device.

7. In Paragraph 6, If the above requested TWT can be accepted, the response message includes an indicator indicating the intention to accept, and A method characterized in that, if the above requested TWT cannot be accepted, the response message includes information about the response to the adjustment method and / or parameters for the adjustment method.

8. In an electronic device of a wireless LAN network, Transmitter / receiver; and Receive a message from an OBSS (overlapping basic service set) AP (access point) containing information about a TWT (target wake time) schedule set on the OBSS AP, and Receives a first TWT frame requesting TWT configuration from STA(station), and In response to the first TWT frame, if the TWT requested by the STA overlaps with the TWT schedule set in the OBSS AP and the requested TWT schedule, a second TWT frame is transmitted indicating that pending or coordination is required. An electronic device characterized by including a control unit configured to transmit a message requesting TWT coordination to the above OBSS AP.

9. An electronic device according to claim 8, characterized in that the TWT setup command field included in the second TWT frame indicates that the determination of acceptance of the requested TWT through the first TWT frame is pending or that coordination with the OBSS AP is required, or that the indicator included in the second TWT frame indicates that the determination of acceptance of the requested TWT through the first TWT frame is pending or that coordination with the OBSS AP is required.

10. An electronic device according to claim 8, wherein the message requesting TWT coordination comprises at least one of information regarding the requested TWT, information regarding the TWT of the overlapping OBSS AP, information indicating a coordination method that the electronic device can support, and information indicating a coordination method preferred by the electronic device.

11. In paragraph 8, the control unit is, Receive a response message to a message requesting the TWT adjustment from the above OBSS AP, and It is further configured to transmit a third TWT frame to the above STA, and The above response message includes information regarding the response to the adjustment method and / or parameters regarding the adjustment method, and An electronic device characterized in that the above-mentioned third TWT frame includes information about the TWT to be set.

12. In an electronic device of a wireless LAN network, Transmitter / receiver; and Transmit a first TWT frame requesting the setting of the TWT (target wake time) to the AP (access point), and An electronic device characterized in that the control unit is further configured to receive a second TWT frame from the AP in response to the first TWT frame, which indicates that the TWT requested by the STA is pending or requires coordination, and the TWT setup command field included in the second TWT frame indicates that the requested TWT is pending or requires coordination, or the indicator included in the second TWT frame indicates that the requested TWT is pending or requires coordination.

13. In an electronic device of a wireless LAN network, Transmitter / receiver; and Receives a message requesting TWT (target wake time) coordination from an OBSS (overlapping basic service set) AP (access point), and It includes a control unit configured to transmit a response message to a message requesting TWT adjustment to the OBSS AP, and An electronic device characterized in that the message requesting the above TWT coordination includes at least one of information regarding the requested TWT, information regarding the TWT of the overlapping OBSS AP, information indicating a coordination method that the electronic device can support, and information indicating a coordination method preferred by the electronic device.

14. In Paragraph 13, If the above requested TWT can be accepted, the response message includes an indicator indicating the intention to accept, and An electronic device characterized in that, if the above-mentioned requested TWT cannot be accepted, the response message includes information regarding the response to the adjustment method and / or parameters regarding the adjustment method.

Images