Method and apparatus for multi-AP transmission

Abstract

This is a method and apparatus for multi-AP transmission. At least one embodiment of the communication method in a wireless network includes transmitting or receiving a management frame at one of the access points (APs) in the wireless network, the management frame includes parameters used to coordinate the APs, the parameters including at least one of an Association Identifier (AID) assigned to an AP that is triggered by another AP, an operating channel on which the AP transmitting the management frame operates, a recommended channel to be used for multi-AP transmission, and the AIDs of neighboring APs.

Description

Technical Field

[0001] The present invention generally relates to wireless communication.

Background Art

[0002] Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks can be multi-connection networks capable of supporting multiple users by sharing available network resources. Examples of such multi-connection networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single Carrier FDMA (SC-FDMA) networks.

[0003] To address the issues of increased bandwidth requirements and reduced latency requirements for wireless communication systems in high-density environments, a Multi-User (MU) scheme has been developed in a wireless network that enables a single Access Point (AP) managing a Basic Service Set (BSS) to schedule multi-user (MU) transmissions, i.e., multiple simultaneous transmissions to or from non-AP stations of the BSS. For example, one such MU scheme has been adopted by the Institute of Electrical and Electronics Engineers (IEEE) in the 802.11ax-2021 standard published in May 2019.

[0004] Thanks to the MU function, non-AP stations have the opportunity to acquire access to the wireless medium via two access methods, namely, the MU scheme and the conventional Enhanced Distributed Channel Access (EDCA) (single-user) scheme.

[0005] Each BSS defines the primary basic channel (known as the primary channel, typically a 20MHz channel or a multiple of 20MHz) on the radio medium in which a station (including an AP) performs EDCA contention. To increase the bandwidth for subsequent transmissions, stations may simultaneously compete for additional 20MHz channels known as secondary channels. Thus, the communication channels permitted for transmission include the primary channel and, optionally, the secondary channels.

[0006] The 802.11ax standard allows an AP to perform MU downlink (DL) transmissions when access to the radio medium is acquired for a transmit opportunity (TXOP). During MU DL transmissions on an authorized communication channel, the AP performs multiple simultaneous basic transmissions to various non-AP stations via so-called resource units (RUs). For example, resource units divide the communication channels of a radio network in the frequency domain, for example, based on orthogonal frequency division multiple access (OFDMA) technology. The assignment of RUs to non-AP stations is signaled at the start of the MU downlink frame by providing an association identifier (AID) for each RU defined in the transmit opportunity (acquired individually by each station during the association procedure with the AP).

[0007] Furthermore, the 802.11ax standard allows MU uplink (UL) transmissions to be triggered by the AP when access to the wireless medium is gained. During an MU UL transmission, various non-AP stations can transmit data to the AP in parallel via resource units that form a communication channel. To control MU UL transmissions by non-AP stations, the AP preemptively transmits a control frame known as a trigger frame (TF). The trigger frame assigns resource units to non-AP stations of the same BSS using the 16-bit Association Identifier (AID) assigned to the non-AP station upon registration with the AP, and / or using a reserved AID that specifies a group of non-AP stations. The TF also defines the start and length of the MU UL transmission by the non-AP station.

[0008] Recently, the IEEE 802.11be standard task group has begun considering so-called multi-access point (Multi-AP or MAP) technology. The latter aims to provide some degree of coordination between adjacent access points (APs managing separate BSSs) to have a more efficient use of available time, frequency, and spatial resources. This is especially important when adjacent APs operate on the same communication channel.

[0009] On the other hand, the Target Wake Time (TWT) mechanism, originally defined in the IEEE 802.11ah and 802.11ax standards, has been adapted to be included in the 802.11be standard. This adaptation is known as Restricted Target Wake Time (rTWT), which schedules dedicated (and protected) service periods (SPs) for stations (affiliated to non-AP multilink devices (MLDs)) to transmit their latency-sensitive traffic through their BSSs. The agreement for rTWT is solely the agreement for Broadcast TWT, which is negotiated between the AP and the associated non-AP stations for a given link's BSS. The non-AP stations establish membership with the AP in the scheduling of Broadcast TWT (or rTWT). The rTWT service period (SP) of an rTWT schedule is advertised in a broadcast management frame (e.g., a beacon) using rTWT information about the negotiated rTWT SP, typically the Broadcast TWT ID (bTWT ID). [Overview of the project]

[0010] The broadest purpose of this disclosure is to improve coordination between adjacent APs. Another purpose of this disclosure is to coordinate TWT or rTWT procedures with multi-AP transmissions, for example, to avoid OBSS (Overlapping Basic Service Set) interference between BSSs in a multi-AP coordination group.

[0011] According to a first aspect of this disclosure, a communication method in a wireless network, wherein at one of a plurality of access points (APs) in the wireless network, This includes sending or receiving management frames. The management frame includes multi-access point (MAP) parameters to be used to coordinate the AP, and the MAP parameters are: The Association Identifier (AID) assigned to an AP that is triggered by another AP, The operational channel on which the AP that sends the aforementioned management frame operates, The recommended channel to be used for MAP transmission, The AID of the adjacent AP, A communication method is provided that includes at least one of the following.

[0012] Therefore, the method disclosed herein makes it possible to improve multi-AP coordination and limit the risk of collisions, particularly collisions between AP identifiers.

[0013] In some embodiments, the management frame is a management request frame that is transmitted, the management request frame includes a MAP setup command, the MAP setup command is a request command to participate in a MAP transmission, a suggestion command to participate in a MAP transmission using suggested MAP parameters, or a request command to suggest MAP parameters to be used to coordinate the AP.

[0014] In some embodiments, the method further includes receiving a management response frame in response to sending the management request frame, the management response frame including an alternative MAP setup command that suggests the use of MAP parameters different from the corresponding parameters of the management request frame.

[0015] In some embodiments, the method further includes receiving a management response frame in response to sending the management request frame, the management response frame including an approval MAP setup command that accepts MAP parameters associated with the proposed or alternative command in the management request frame.

[0016] In some embodiments, the method further includes receiving a management response frame in response to sending the management request frame, the management response frame including an instruction MAP setup command that compels the use of MAP parameters associated with the proposed command in the management request frame.

[0017] In some embodiments, the method further includes receiving a management response frame in response to sending the management request frame, the management response frame including a reject MAP setup command that rejects MAP parameters, or a conflict command that warns of conflicting AIDs.

[0018] In some embodiments, the management frame is a received management request frame, which includes a request MAP setup command to participate in a MAP transmission, a proposal command to participate in a MAP transmission using proposed MAP parameters, or a request command proposing MAP parameters to be used to coordinate the AP.

[0019] In some embodiments, the method further includes, in response to receiving the management request frame, analyzing the received management request frame, and in response to the analysis, generating and transmitting a management response frame, the management response frame including an alternative MAP setup command that proposes MAP parameters different from the corresponding parameters of the management request frame.

[0020] In some embodiments, the method further includes, in response to receiving the management request frame, analyzing the received management request frame, and in response to the analysis, generating and transmitting a management response frame, the management response frame including an approval MAP setup command that accepts MAP parameters associated with the proposed or alternative command of the management request frame.

[0021] In some embodiments, the method further includes analyzing the received management request frame in response to receiving the management request frame, and generating and transmitting a management response frame in response to the analysis, wherein the management response frame includes an instruction MAP setup command that enforces the use of MAP parameters associated with the proposed command of the management request frame.

[0022] In some embodiments, the method further includes analyzing the received management request frame in response to receiving the management request frame, and generating and transmitting a management response frame in response to the analysis, wherein the management response frame includes a rejection MAP setup command that rejects the MAP parameters received in the management request frame, or includes a conflict MAP setup command that warns of conflicting AIDs.

[0023] In some embodiments, the management frame includes a Target Wake Time (TWT) information element, and the TWT information element includes the parameters and TWT parameters associated with the MAP setup command.

[0024] In some embodiments, the TWT information element includes a TWT Setup Command field, and the TWT Setup Command field includes a request, proposal, request, alternative, acceptance, instruction, rejection, or conflict MAP setup command to be transmitted or received.

[0025] In some embodiments, the TWT information element includes a MAP Setup Command field, and the MAP Setup Command field includes a request, proposal, request, alternative, acceptance, instruction, rejection, or conflict MAP setup command to be transmitted or received.

[0026] According to a second aspect of the present disclosure, a management frame used in a wireless network including a plurality of access points (APs), the management frame includes multi-AP (MAP) parameters used to adjust the APs in the wireless network, and the parameters are an Association Identifier (AID) assigned to an AP triggered by another AP, and an operating channel on which the AP transmitting the management frame operates, and a recommended channel to be used for multi-AP transmission, and AIDs of adjacent APs, and A management frame is provided that includes at least one of.

[0027] Therefore, the method of the present disclosure makes it possible to improve multi-AP adjustment and limit the risk of collisions, particularly collisions between AP identifiers.

[0028] In some embodiments, the management frame includes a Target Wake Time (TWT) information element, and the TWT information element includes the parameters and TWT parameters.

[0029] In some embodiments, the management frame further includes a MAP setup command, and the MAP setup command is a request, proposal, requirement, alternative, acceptance, command, rejection, or conflict MAP setup command.

[0030] In some embodiments, the TWT information element. Includes a TWT Setup Command field, and the TWT Setup Command field includes a request, proposal, requirement, alternative, acceptance, command, rejection, or conflict MAP setup command.

[0031] In some embodiments, the TWT information element includes a MAP Setup Command field, which includes a MAP Setup Command for request, suggestion, demand, alternative, acceptance, command, rejection, or conflict.

[0032] At least a portion of the methods described herein can be implemented on a computer. Therefore, the disclosure may take the form of a hardware embodiment in whole, a software embodiment in whole (including firmware, resident software, microcode, etc.), or a combination of software and hardware embodiments, all of which may collectively be referred to herein as “circuits,” “modules,” or “systems.” Furthermore, the disclosure may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in that medium.

[0033] Since this disclosure can be implemented in software, it may also be implemented as computer-readable code for provision to a programmable device on any suitable transport medium. The tangible transport medium may include storage media such as hard disk drives, magnetic tape devices, or solid-state memory devices. The transient transport medium may include signals such as electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals, or electromagnetic signals, such as microwave or RF signals. [Brief explanation of the drawing]

[0034] Herein, embodiments of the present disclosure will be described, merely as examples, with reference to the following drawings: [Figure 1] Figure 1 shows an exemplary network environment in which embodiments of the present disclosure may be implemented. [Figure 2a] Figure 2a is a schematic diagram of a communication device according to an embodiment of the present disclosure. [Figure 2b]Figure 2b is a schematic block diagram showing the architecture of the communication device of Figure 1a, adapted to at least partially implement the present disclosure. [Figure 3a] Figure 3a shows the format of a Target Wake Time (TWT) information element, enhanced to constitute multi-AP transmission, according to an embodiment. [Figure 3b] Figures 3b and 3c show examples of formats for Multi-AP (MAP) Target Wake Time (TWT) information elements for negotiating multi-AP transmissions according to some embodiments of the present disclosure. [Figure 3c] Figures 3b and 3c show examples of formats for Multi-AP (MAP) Target Wake Time (TWT) information elements for negotiating multi-AP transmissions according to some embodiments of the present disclosure. [Figure 4a] Figures 4a and 4b show the format of information elements enhanced to constitute a multi-AP transmission according to an embodiment. [Figure 4b] Figures 4a and 4b show the format of information elements enhanced to constitute a multi-AP transmission according to an embodiment. [Figure 5a] Figures 5a and 5b are flowcharts illustrating the typical steps in a shared AP according to an embodiment of the present disclosure. [Figure 5b] Figures 5a and 5b are flowcharts illustrating the typical steps in a shared AP according to an embodiment of the present disclosure. [Figure 6] Figure 6 is a flowchart illustrating the typical steps in a shared AP according to an embodiment of the present disclosure. [Figure 7a] Figures 7a and 7b are flowcharts illustrating the general steps of an example of a management multi-AP negotiation procedure in a shared AP and a shared AP, respectively, according to embodiments of the present disclosure. [Figure 7b]Figures 7a and 7b are flowcharts illustrating the general steps of an example of a management multi-AP negotiation procedure in a shared AP and a shared AP, respectively, according to embodiments of the present disclosure. [Modes for carrying out the invention]

[0035] The techniques described herein can be used for various broadband wireless communication systems, including communication systems based on orthogonal multiplexing schemes. Examples of such communication systems include spatial division multiplexing (SDMA) systems, time division multiplexing (TDMA) systems, orthogonal frequency division multiplexing (OFDMA) systems, and single-carrier frequency division multiplexing (SC-FDMA) systems. SDMA systems can utilize sufficiently different directions to transmit data belonging to multiple user terminals, i.e., wireless devices or stations, in parallel. TDMA systems can enable multiple user terminals to share the same frequency channel by dividing the transmitted signal into different time slots or resource units, where each time slot is assigned to a different user terminal. OFDMA systems utilize orthogonal frequency division multiplexing (OFDM), a modulation technique that divides the entire system bandwidth into multiple orthogonal subcarriers or resource units. These subcarriers are sometimes called tones or bins. In OFDM, each subcarrier can be independently modulated with data. The SC-FDMA system can utilize Interleaved FDMA (IFDMA) for transmission over subcarriers distributed across the system bandwidth, Localized FDMA (LFDMA) for transmission within blocks of adjacent subcarriers, or Enhanced FDMA (EFDMA) for transmission across multiple blocks of adjacent subcarriers.

[0036] The teachings herein can be incorporated into various devices (e.g., stations) (e.g., implemented within them or performed by them). In some embodiments, the wireless devices or stations implemented according to the teachings herein may include access points (so-called APs) or non-access points (so-called non-AP stations or STAs).

[0037] An access point (represented as AP) includes, is implemented as, or may be known as, a node B, a radio network controller ("RNC"), an evolved node B (eNB), a 5G next-generation base station (gNB), a base station controller ("BSC"), a base station transceiver ("BTS"), a base station ("BS"), a transceiver function ("TF"), a radio router, a radio transceiver, a basic service set ("BSS"), an extended service set ("ESS"), a radio base station ("RBS"), or any other term.

[0038] Non-AP stations include, are implemented as, or may be known as, subscriber stations, subscriber units, mobile stations (MS), remote stations, remote terminals, user terminals (UT), user agents, user devices, user equipment (UE), user stations, or any other terms. In some implementations, an STA may include a cellular phone, a cordless phone, a Session Initiation Protocol ("SIP") phone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a handheld device with wireless connectivity, or any other suitable processing device connected to a wireless modem. Thus, one or more embodiments taught herein may be incorporated into a telephone (e.g., a cellular phone or smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a Global Positioning System (GPS) device, or any other suitable device configured to communicate via wireless or wired media. In some embodiments, a non-AP station may be a wireless node. Such wireless nodes may, for example, provide connectivity to or from a network via wired or wireless communication links (for example, a wide area network such as the Internet or a cellular network).

[0039] An AP manages a set of STAs (associated with itself), and that set of STAs organizes their access to the wireless medium for communication purposes. The STAs (including the AP) form a service set, which is referred to here as a Basic Service Set (BSS) (other terms may be used). The same physical STA acting as an access point may manage two or more BSSs, and so each BSS is uniquely identified by a specific Basic Service Set Identifier (BSSID) and managed by a separate virtual AP implemented in the physical AP. Each STA is identified within the BSS by an Identifier (AID) assigned by the AP during the association procedure.

[0040] The 802.11 family of standards defines various media access control (MAC) mechanisms for driving access to wireless media.

[0041] Current discussions within Task Group 802.11be propose introducing Multi-Link Operation (MLO) with respect to MAC layer operation, as outlined in the March 2023 draft IEEE P802.11be / D3.0. MLO will enable multilink devices to establish or set up multiple links and operate them simultaneously.

[0042] A multilink device (MLD) is a logical entity that has two or more affiliated STAs (STAs) and a single Media Access Control (MAC) service access point (SAP) to a logical link control (LLC) containing one MAC data service. An access point multilink device (or AP MLD) corresponds to an MLD, where each STA associated with the MLD is an AP and is therefore called an "affiliated AP". A non-access point multilink device (or non-AP MLD) corresponds to an MLD, where each STA associated with the MLD is a non-AP STA and is therefore called an "affiliated non-AP STA". Depending on the literature, "multilink device", "ML device" (MLD), "multilink logical entity", "ML logical entity" (MLE), "multilink set", and "ML set" are synonyms for specifying the same type of ML device.

[0043] Furthermore, multiple associated non-AP STAs of a non-AP MLD can set up communication links with multiple associated APs of an AP MLD, and thus form a multilink channel.

[0044] Links established for MLD (or "enable links") are theoretically independent, meaning that channel access procedures and communications (to the communication medium) are performed independently on each link. Therefore, different links may have different data rates (e.g., different bandwidths, number of antennas, etc.) and may be used to communicate different types of information (each over a specific link).

[0045] Therefore, a communication link or "link" corresponds to a given channel (e.g., 20MHz, 40MHz, etc.) in a given frequency band (e.g., 2.4GHz, 5GHz, 6GHz) between an AP associated with an AP MLD and a non-AP STA associated with a non-AP MLD.

[0046] The associated APs and non-AP STAs operate on their respective channels in accordance with one or more of the IEEE 802.11 standard (a / b / g / n / ac / ad / af / ah / aj / ay / ax / be / bn) or other wireless communication standards.

[0047] Thanks to multilink aggregation, traffic associated with a single MLD can theoretically be transmitted across multiple parallel communication links, thereby increasing network capacity and maximizing the use of available resources.

[0048] The following explanation will focus primarily on a single link for the sake of clarity. However, similar considerations may be made for each link that forms a set of multiple links for an MLD device. Thus, the term STA may refer to one associated STA of a non-AP MLD (non-AP STA of a non-AP MLD), and AP may refer to one associated AP of an AP MLD.

[0049] According to some embodiments of this disclosure, two or more adjacent APs may share resources in terms of frequency and / or time, thus intended to prevent interference. Two main roles of APs participating in coordination are defined: • Sharing APs - APs that initiate and manage multi-AP coordination by sharing their own authorized TXOP resources are called sharing or coordinating APs. They maintain an AP Candidate Set, which registers candidate APs to participate in the coordination that have requested to be part of the set; • Shared APs (APs) - All APs allocated with resources for coordinated transmission by a shared AP. APs participating in multi-AP coordination and using shared resources are also called Coordinated APs. The corresponding BSS (Blockchain Service System) is known as a Coordinated BSS.

[0050] The scope of multi-AP coordination can be extended to provide optimized coordination not only for shared transmission but also for OBSS interference reduction. In other words, multi-AP coordination is becoming one of the emerging features for interference management in WLAN networks, where multiple APs can coordinate to intelligently manage interference caused by overlapping basic service sets (OBSS), thereby improving network performance.

[0051] Figure 1 shows an exemplary network environment in which embodiments of the present disclosure may be implemented.

[0052] The illustrated wireless network environment includes a group of multiple AP systems 100 formed by a common communication channel or wireless medium. The common communication channel may correspond to some (e.g., 20 MHz) or all of the operating channels (e.g., 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 320 MHz).

[0053] The first wireless network BSS1 includes an access point (AP) 110 and three non-AP stations (STAs) 111, 112, and 113 associated with (i.e., registered with) AP110. The second wireless network BSS2 includes AP120 and three associated non-AP STAs 121, 122, and 123. The third wireless network BSS3 includes AP130 and three associated non-AP STAs 131, 132, and 133. Hereinafter, BSSx represents one of the wireless networks, while 1x1, 1x2, or 1x3 represents one of the non-AP stations. Naturally, another number of wireless networks and any number of non-AP stations for each wireless network can be assumed. In this disclosure, AP110, 120, and 130 are also referred to as AP1, AP2, and AP3, respectively. The device may operate as an AP in one wireless network and simultaneously belong to another wireless network as an associated STA.

[0054] Stations (APs and non-APs) in each wireless network exchange data frames over a communication channel (not shown) under the management of the APs. A primary channel, typically a 20MHz channel, is defined for each wireless network, on which management frames are exchanged. Any other 20MHz channels in the communication channel, if any, are known as secondary channels.

[0055] Each non-AP STA1x1~1x3 registers with AP1x0 of one wireless network BSSx during the association procedure. During the association procedure on the primary channel, the AP assigns a specific Association Identifier (AID) to the requesting station. For example, the AID is a 16-bit value that uniquely identifies the station.

[0056] Stations (including APs) compete with each other via communication channels (including a primary channel and optionally secondary channels to increase bandwidth) using EDCA (Enhanced Distributed Channel Access) contention to gain access to the communication channels and be granted a Transmit Opportunity (TXOP). A TXOP can then be used to transmit (single-user, SU) data frames or to perform multi-user (MU) transmissions. In the MU scheme, a single station, typically an AP in a wireless network BSSx, can schedule MU transmissions, i.e., multiple parallel transmissions to and from other stations in the wireless network. One implementation of such an MU scheme is adopted, for example, in the IEEE 802.11ax modification known as the Multi-User Uplink and Downlink OFDMA (MU UL and DL OFDMA) procedure. In the MU scheme, resources are defined across the 20MHz channel or multiple channels used and are known as resource units.

[0057] More generally, resources may include spatial, frequency, and time resources, and may be acquired according to different multiplexing schemes. Examples of these schemes include spatial division multiple access (SDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single-carrier frequency division multiple access (SC-FDMA) systems.

[0058] The IEEE 802.11 wireless local area networking standard allows multiple AP systems to support an Extended Service Set (ESS), while each member of the wireless network can support a Basic Service Set (BSS).

[0059] While the embodiments described herein are given in the context of IEEE 802.11, the embodiments are not limited thereto and may be applicable to other types of wireless networks and protocols.

[0060] Figure 2a schematically shows a communications device 200 configured to implement at least one embodiment of the present disclosure, for example, one of the (AP and non-AP) stations shown in Figure 1. The communications device 200 is either a coordinator device, a coordinated device managed by a coordinator, a station, or a coordinated device in a multi-AP set.

[0061] The communication device 200 may preferably be a device such as a microcomputer, workstation, or lightweight portable device. The communication device 200 has a communication bus 213, to which the following are preferably connected: A central processing unit such as a processor, referred to as a CPU; Memory 203 for storing executable code for a method or step of a method according to embodiments of the present disclosure, and registers adapted to record variables and parameters necessary for performing the method; At least one communication interface 202 connected via a transmit / receive antenna 204 to a wireless communication network, for example, a communication network conforming to one of the standards of the IEEE 802.11 family.

[0062] Preferably, the communication bus 213 provides communication and interoperability between various elements included in or connected to the communication device 200. The representation of the bus is not limited, and in particular, the central processing unit can be operated to communicate instructions to any element of the communication device 200, either directly or through another element of the communication device 200.

[0063] The executable code may be stored in memory, which may be read-only, a hard disk, or a removable digital medium such as a disk. According to an optional modification, the program's executable code may be received via a communication network through a communication interface 202 in order to be stored in the memory of the communication device 200 before execution.

[0064] In embodiments, the device is a programmable device that uses software to implement embodiments of the present disclosure. Alternatively, embodiments of the present disclosure may be implemented in whole or in part in hardware (for example, in the form of an application-specific integrated circuit (ASIC)).

[0065] Figure 2b is a schematic block diagram illustrating the architecture of a communication device 200 adapted to at least partially implement the present disclosure. As shown, the device 200 has a physical (PHY) layer block 223, a MAC layer block 222, and an application layer block 221.

[0066] PHY layer block 223 (here, the 802.11 standardized PHY layer) formats, modulates, or demodulates from any 20 MHz channel or common communication channel and thus transmits or receives 802.11 frames, such as a medium access trigger frame TF for reserving a transmit slot, MAC data and management frames based on a 20 MHz width for interacting with legacy 802.11 stations, and OFDMA type MAC data frames having a smaller width (typically 2 or 5 MHz) than the 20 MHz legacy frames, to or from that radio medium.

[0067] The MAC layer block or controller 222 preferably includes a MAC802.11 layer 224 that implements the MAC operation of conventional 802.11be and an additional block 225 for at least partially implementing the present disclosure. The MAC layer block 222 may optionally be implemented in software, which is loaded into memory (e.g., RAM) 203 and executed by the CPU 201.

[0068] Preferably, an additional block 225, called a multi-AP interference management module, has different operations for performing parts of this disclosure depending on the role played by the communication device 200. Since the same device may play different roles over time, the additional block 225 is preferably designed to selectively perform different operations.

[0069] The MAC802.11 layer 224 and the multi-AP TWT management module 225 interact with each other to accurately process single-user and / or multi-user communications destined for multiple stations, according to embodiments of the present disclosure.

[0070] In the upper part of Figure 2, the application layer block 221 runs an application that generates and receives data packets, such as video streams. The application layer block 221 represents all stack layers above the MAC layer, according to ISO standards.

[0071] Figure 3a shows an example of a Target Wake Time (TWT) information element format enhanced to constitute multi-AP transmission (multi-AP coordination) according to an embodiment.

[0072] The Target Wake Time (TWT) mechanism, originally defined in the IEEE 802.11ah and 802.11ax standards, has been adapted for inclusion in the 802.11be D3.0 standard. This adaptation is known as Restricted Target Wake Time (rTWT), which schedules dedicated (and protected) service periods (SPs) for stations (associated with non-AP MLDs) to transmit their latency-sensitive traffic through their BSSs. rTWT can be considered a Broadcast TWT agreement negotiated between the AP and associated non-AP stations for a given link's BSS. Non-AP stations establish membership with the AP in the Broadcast TWT (or rTWT) schedule. The schedule may be defined for several TIDs. The rTWT Service Period (SP) of an rTWT schedule is advertised in a broadcast management frame (e.g., a beacon) using an rTWT information element related to the negotiated rTWT SP, typically the Broadcast TWT ID (bTWT ID).

[0073] Mechanisms such as TWT or rTWT are negotiated on a per-link basis, i.e., between the initiator-related STA of a non-AP MLD and the corresponding associated AP of an AP MLD.

[0074] Given a link, a non-AP station establishes membership in the AP's Broadcast TWT schedule, while the AP distributes a Broadcast TWT parameter set to the non-AP station. The non-AP station is referred to as a TWT-scheduled station, and the AP is referred to as a TWT scheduling station.

[0075] Negotiations to become a member of an rTWT schedule (more commonly a Broadcast TWT) or to terminate membership are performed using the exchange of frames carrying TWT elements, as shown below, with the Negotiation Type subfield set to 3 (Broadcast TWT). In particular, a non-AP STA MLD may request to become a member of a TWT schedule by sending a TWT setup frame containing the TWT elements for a given rTWT schedule to its associated AP MLD. TWT parameters can be interpreted as request, suggestion, demand, alternative, acceptance, dictation, or rejection. Either the AP or STA can tear down a TWT by sending a TWT teardown frame.

[0076] The AP then advertises scheduled Broadcast TWTs (or rTWTs) using the Broadcast TWT element in its management frames, typically in beacon frames, FILS discovery frames, and broadcast probe response frames.

[0077] TWT parameters are described in section 9.4.2 of the 802.11-2020 standard and are transmitted by an information element identified by field 300. The "Control" field 310 allows the detection of a Broadcast TWT through the "Negotiation Type" field 311. The MSB bit of this field is set to 1 to promote a Broadcast TWT. The TWT scheduling AP then sets the "TWT Request" subfield 350 to 0 and the TWT Setup Command subfield 351 as "Accept" to announce the next TWT SP, as "Alternate" to announce the next TWT SP with a new set of TWT parameters, and as "Reject" to tear down the Broadcast TWT (the end date and time are specified in the "Broadcast TWT Persistence" subfield 343). The Broadcast TWT includes a Broadcast TWT element 320 that defines the set of TWT parameters. Each Broadcast TWT is identified by a "Broadcast TWT ID" field 331, which allows an AP to schedule multiple sets of Broadcast TWT SPs using different sets of TWT parameters. An STA may request to become a member of a Broadcast TWT by sending a frame containing a TWT element in which the "Negotiation Type" subfield 311 is set to 3 and the "TWT Setup Command" field 351 is set to "Request TWT", "Suggest TWT", or "Demand TWT" to the AP it is associated with. The attached TWT parameter set indicates the Broadcast TWT ID of the Broadcast TWT that the STA is requesting to join.

[0078] The "Broadcast TWT Recommendation" field 353 is used in the 802.11 standard to advise the STA to transmit PS-Poll, QoS Null, BQR, or BSR frames when requested by the AP. However, it is only a recommendation; there is no pure restriction if the STA wishes to transmit any other type of frame. The 802.11be amendment introduced a new value "4" to define a new TWT format named Restricted TWT (rTWT). In one embodiment, a further new value (e.g., "5", but could be any other value) may be added to define a TWT information element that simultaneously indicates the use of two features, namely Restricted TWT and Multi-AP features.

[0079] In another embodiment, support for multi-AP functionality can be added by setting the value "1" to a bit such as the "Multi AP Info Present" field 330. The "Multi AP Info Present" field 330 indicates the presence of an optional "Multi AP info" field 320.

[0080] The "Multi AP info" field 320 contains all the parameters used to configure multi-AP transmission. In this case, an AP can include multi-AP (MAP) information elements within any management frame (such as a beacon frame, probe request, or response frame) that supports the information element format in order to advertise its multi-AP parameters to all neighboring APs. In particular, field 321 "Multi AP AID12" defines the AID12 assigned to an AP that is triggered by another AP. As a reminder, the trigger frame is the frame used by the AP to allocate bandwidth for multi-user transmission. Each User Info field in the trigger frame allows the STA to request an association identifier (the so-called AID12) by using it. The AID12 value is assigned when the STA associates this AID12 value with the AP that provides it. Previously, the 802.11-2020 standard did not have a procedure for assigning AID12 values ​​to APs. Therefore, this field "Multi AP AID12" is a way to spread the AP's AID12 value to all other neighboring APs. This assignment is particularly useful for scheduling multi-AP transmissions. Field 322, "Operating channels," defines a list of operating channels on which the AP operates. Field 323, "preferred Multi AP channel," defines the preferred channel to be used for multi-AP transmissions, as an AP may dedicate only a portion of its operating channels to multi-AP transmissions. Field 340, "Neighbor AP AID12 list," includes a set of multi-AP AID12 values ​​(341) and the associated MAC addresses (342) of APs already received by the AP broadcasting its multi-AP parameters. This is a way to easily spread the multi-AP parameters to all neighboring APs.

[0081] Figures 3b and 3c show examples of formats for Multi-AP (MAP) Target Wake Time (TWT) information elements for negotiating multi-AP transmissions according to some embodiments of the present disclosure.

[0082] As illustrated with reference to Figure 3a, negotiation to become a member of a multi-AP transmission schedule or to terminate its membership is performed by exchanging frames carrying the multi-AP TWT information elements described below, with the Negotiation Type subfield set to 3 (Broadcast TWT). In particular, a non-AP STA MLD may request to become a member of a multi-AP transmission schedule by sending a multi-AP TWT setup frame containing the multi-AP information elements for a given multi-AP transmission schedule to the AP MLD to which its device is associated. The multi-AP information elements may be interpreted as a suggestion, demand, alternative, acceptance, dictation, conflict, or rejection. Either the AP or STA can tear down a multi-AP TWT by sending a multi-AP TWT teardown frame.

[0083] In this case as well, the TWT parameters are described in section 9.4.2 of the 802.11-2020 standard and transmitted by an information element identified by field 300. The "Control" field 310 allows the Broadcast TWT to be detected through the "Negotiation Type" field 311. The MSB bit of this field is set to 1 to promote the Broadcast TWT. Next, as shown in Figure 3b, the TWT scheduling AP sets the "TWT Request" subfield 350 to 0 and the TWT Setup Command subfield 351 to "Accept" to announce the next TWT SP, to "Alternate" to announce the next TWT SP with a new set of TWT parameters, and to "Reject" to tear down the Broadcast TWT (the end date and time are specified in the "Broadcast TWT Persistence" subfield (not shown)). The Broadcast TWT includes a Broadcast TWT element 320 that defines a set of TWT parameters. Each Broadcast TWT is identified by a "Broadcast TWT ID" field (not shown), allowing the AP to schedule multiple sets of Broadcast TWT SPs using different sets of TWT parameters.

[0084] According to the embodiment shown in Figure 3b, a shared AP may request to become a member of a multi-AP TWT by sending a frame to the shared AP containing a multi-AP TWT element in which the "Negotiation Type" subfield 311 is set to 3 and the "TWT Setup Command" field 351 is set to "Request TWT", "Suggest TWT", or "Demand TWT". Attached restrictive TWT parameters are placed in the "Restricted TWT Traffic Info" subfield 324, and multi-AP parameters are placed in the "multi-AP info" subfield 320. In response, the shared AP's TWT may respond by sending a frame to the shared AP containing a multi-AP TWT element in which the "Negotiation Type" subfield 311 is set to 3 and the "TWT Setup Command" field 351 is set to "Alternate", "Accept", "Dictate", "Reject", or "Conflict".

[0085] According to the embodiment shown in Figure 3c, a shared AP may request to become a multi-AP TWT by sending a frame containing a multi-AP TWT element to a responder AP, in which the "Negotiation Type" subfield 311 is set to 3, the "Multi-AP Info Present" subfield 330 is set to 1, and the "Multi-AP Setup Command" field 325 is set to "Request TWT", "Suggest TWT", or "Demand TWT". Attached restricted TWT parameters are placed in the "Restricted TWT Traffic info" subfield 324, and multi-AP parameters are placed in the "multi-AP info" subfield 320. In response, the responder's AP TWT may respond by sending a frame containing a multi-AP TWT element to the shared AP, in which the "Negotiation Type" subfield 311 is set to 3, and the "Multi-AP Setup Command" field 325 is set to "Alternative", "Accept", "Command", "Reject", or "Conflict".

[0086] The "Broadcast TWT Recommendation" field 353 (Figure 3b) is used in the 802.11 standard to advise the STA to transmit PS-Poll, QoS Null, BQR, or BSR frames when requested by the AP. However, it is only a recommendation; there is no pure restriction if the STA wishes to transmit any other type of frame. The 802.11be amendment introduced a new value "4" to define a new TWT format named Restricted TWT (rTWT). In one embodiment, a new value (e.g., "5") may be added to define a TWT information element that simultaneously indicates the use of two features, namely, Restricted TWT and Multi-AP features.

[0087] In another embodiment, support for multi-AP functionality can be added by setting the value "1" to a bit such as the "Multi AP Info Present" field 330. The "Multi AP Info Present" field 330 indicates the presence of an optional "Multi AP info" field 320.

[0088] The "Multi AP info" field 320 contains all parameters used to negotiate the configuration for the next multi-AP transmission with one or more APs. In this case, an AP may include the multi-AP (MAP) TWT information element within any management frame (such as a beacon frame, probe request, or response frame) that supports the information element format in order to advertise its multi-AP parameters to all neighboring APs. In particular, field 321 "Multi AP AID12" defines the AID12 assigned to an AP that is triggered by another AP. As a reminder, the trigger frame is the frame used by the AP to allocate bandwidth for a multi-user transmission. Each User Info field in the trigger frame allows the STA to request an association identifier (the so-called AID12) by using it. The AID12 value is assigned when the STA associates with the AP that provides this AID12 value. Currently, there is no procedure in the 802.11-2020 standard for assigning an AID12 value for an AP. Therefore, the field "Multi AP AID12" is how the AP's AID12 value is spread to all other neighboring APs. This assignment is particularly useful for scheduling multi-AP transmissions. Field 322 "Operating channels" defines a list of operating channels on which the AP operates. Field 323 "preferred Multi AP channel" defines the preferred channel that should be used for multi-AP transmissions, as an AP may dedicate only a portion of its operating channels to multi-AP transmissions. Field 340 "Neighbor AP AID12 list" includes a set of multi-AP AID12 values ​​(341) and the associated MAC addresses (342) of APs already received by the AP broadcasting its multi-AP parameters. This is an easy way to spread the multi-AP parameters to all neighboring APs.

[0089] The MAP setup commands described in this disclosure with reference to Figures 3a, 3b, and 3c may be as follows: - The request MAP setup command is intended for participating in multi-AP transmission; - The suggested MAP setup command aims to participate in multi-AP transmission while suggesting multi-AP parameters; - The demand MAP setup command is intended to suggest multi-AP parameters without adjustment; - The alternate MAP setup command is intended to suggest multi-AP parameters other than those associated with a previously received MAP setup command; - The accept MAP setup command is intended to accept the multi-AP parameters associated with a previously received proposal or alternative MAP setup command; -The instruction (dictate)MAP setup command is intended to enforce the use of multi-AP parameters associated with a previously received proposed MAP setup command; - The reject MAP setup command is intended to reject multi-AP transmission; - The conflictMAP setup command is intended to warn of conflicting multi-AP AID12 or adjacent AP AID12 in the provided list.

[0090] Figures 4a and 4b show the format of information elements enhanced to constitute a multi-AP transmission according to several embodiments.

[0091] In another embodiment, multi-AP parameters are disseminated within a dedicated information element that is not linked to a restricted TWT information element. Multi-AP (MAP) information elements (IEs) can generally be included in a beacon frame to broadcast the AP's multi-AP capability to all of its neighboring APs. A MAP IE400 includes a set of fields that collect the parameters necessary to perform multi-AP transmission: • Element ID field 401 identifies the multi-AP element. • The Length field (402) indicates the number of bytes in the element, excluding the Element ID and Length fields. • Multi-AP AID12 field 410 indicates the AID12 assigned to the AP that should be triggered by another AP. This is the same field as the aforementioned field 321. • The Multi AP capable subfield 411 indicates the AP's ability to support multi-AP transmission. For example, the value of this field may be equal to 1 to indicate support for multi-AP functionality, otherwise it may be 0. • The Multi AP status subfield 412 indicates whether the AP currently supports multi-AP functionality. For example, the value of this field can be equal to 1 to enable multi-AP functionality, and 0 otherwise. • Field 450 "Operating channels" defines a list of operating channels on which the AP operates. Since an AP can dedicate only a portion of its operating channels to multi-AP transmission, field 460, "preferred Multi AP channel," defines the preferred channel that should be used for multi-AP transmission. Field 440, "Neighbor AP AID12 list," contains a set of multi-AP AID12 values ​​(441) and the associated MAC addresses (442) of APs already received by the AP broadcasting its own multi-AP parameters. This is a way to easily spread the multi-AP parameters to all neighboring APs.

[0092] MAP IE can also be transmitted using a dedicated action frame. As specified in the 802.11 standard, the Action frame provides a mechanism for specifying extended management actions. The Category field 470 specifies the category of actions specific to the multi-AP functionality, and field 400 corresponds to all fields specified in the MAP IE. This frame can be unicast, multicast, or broadcast. This allows for the advertisement of multi-AP functionality to a single neighbor AP, a set of neighbor APs, or all neighbor APs.

[0093] Figures 5a and 5b illustrate the general steps in a shared AP according to an embodiment of the present disclosure using flowcharts.

[0094] A shared AP is an AP that wishes to initiate multi-AP transmission. Conversely, a shared AP is an AP that receives multi-AP parameters from a shared AP and is requested to initiate multi-AP transmission by the shared AP. Note that APs are not uniquely shared or shared APs. This naming convention varies depending on the procedure being executed.

[0095] A shared access point (AP) must share its multi-AP parameters with one, some, or all of its neighboring APs.

[0096] Figure 5a is a flowchart used by a shared AP to broadcast multi-AP parameters to all neighboring APs. An AP is a neighboring AP of another AP if it can receive frames from that other AP. Step 500 sets appropriate values ​​for all fields described in Figure 3, corresponding to the desired multi-AP configuration. Since beacon frames are transmitted periodically, the APs transmit the beacon frames created in step 500 on the following dates (steps 510 and 520) to transmit the beacon frames.

[0097] Figure 5b shows another embodiment of advertising a MAP IE encapsulated within a management request frame (such as a probe request or action frame) (step 550). Step 560 sends the newly created management request frame to the destination shared AP. The shared AP awaits a response to acknowledge the multi-AP configuration associated with the multi-AP parameters encapsulated in the previously sent management request frame.

[0098] Figure 6 shows a flowchart illustrating the general steps in a shared AP according to an embodiment of the present disclosure.

[0099] When the shared AP receives a management frame containing MAP IE from the shared AP (600), the shared AP compares its own multi-AP parameters with those received from the shared AP (610). In response, the shared AP sends a management response frame containing its own multi-AP parameters (620).

[0100] Figures 7a and 7b illustrate, using flowcharts, the general steps of an example management multi-AP negotiation procedure in a shared AP and a shared AP, respectively, according to embodiments of the present disclosure.

[0101] In step 710, a shared AP may request a shared AP to become a member of the multi-AP TWT by sending a frame (a management request frame). The management request frame includes a multi-AP TWT element whose "Negotiation Type" subfield (reference 311 in Figure 3b) is set to 3. In one embodiment, the "TWT Setup Command" field of the multi-AP TWT element (reference 351 in Figure 3b) is set to "Request TWT", "Suggest TWT", or "Demand TWT". In another embodiment, the multi-AP command is defined by the "Multi-AP Setup Command" field (reference 325 in Figure 3c) which is set to "Request TWT", "Suggest TWT", or "Demand TWT".

[0102] The attached restricted TWT parameters are placed in the "Restricted TWT Traffic info" subfield (reference 324 in Figures 3b and 3c), and the multi-AP parameters are placed in the "multi-AP info" subfield (reference 320 in Figures 3b and 3c). A multi-AP command is set to "Request TWT" to join a multi-AP transmission group, or more generally, a TWT group that does not have parameters associated with the request. A multi-AP command is set to "Suggest TWT" to join a multi-AP transmission group, or more generally, a TWT group that has proposed parameters for multi-AP transmission. A multi-AP command is set to "Demand TWT" to join a multi-AP transmission group, or more generally, a TWT group that has the parameters required for multi-AP transmission without coordination.

[0103] Next, the created management request frame is sent to the shared AP (step 720).

[0104] A response is awaited from one or more shared APs (step 730). Upon receiving a management request frame containing multi-AP information elements (step 750), the shared AP may respond by sending a frame (management response frame) to the shared AP containing a multi-AP TWT element with the "Negotiation Type" subfield (reference 311 in Figures 3b and 3c) set to 3. In one embodiment, the "TWT Setup Command" field (reference 351 in Figure 3b) is set to "Alternate", "Accept", "Dictate", "Reject", or "Conflict" depending on the analysis of the recommended or requested multi-AP parameters received from the shared AP (step 760). In another embodiment, a multi-AP command is defined thanks to the "Multi-AP Setup Command" field (reference 325 in Figure 3c) set to "Alternate", "Accept", "Dictate", "Reject", or "Conflict".

[0105] The multi-AP command may be set to "Accept" to accept a multi-AP command just received from a shared AP without modification. Alternatively, the multi-AP command may be set to "Alternate" to propose a new set of multi-AP parameters to the shared AP. Alternatively, the multi-AP command may be set to "Dictate" to enforce a different set of multi-AP parameters in response to a multi-AP command received from a shared AP. Alternatively, the multi-AP command may be set to "Reject" to reject a multi-AP transmission requested from a shared AP. Alternatively, the multi-AP command may be set to "Conflict" when a conflict is detected in the multi-AP AID12 field (reference 321 in Figures 3b and 3c) or in the list of neighboring APs' AID12s (reference 340 in Figures 3b and 3c). For example, when the first AP (AP1) sends its list of neighboring APs, the second AP (AP2) may detect some AID12 conflict for a third AP (AP3) (hidden AP scenario) that is not detectable by the first AP.

[0106] Next, an administrative response frame is sent (step 770).

[0107] Upon receiving a management response frame (step 730), the shared AP analyzes the received management response frame to determine whether the shared AP configuration should be enabled (step 740), for example whether MAP parameters should be accepted or updated by the shared AP (step 741), for example whether further instruction commands proposing MAP parameters should be received, or whether there is an AID conflict (step 735).

[0108] Note that in the event of a MAP parameter conflict, the shared AP may send a multi-AP command set to "Alternate" using the updated multi-AP parameters to one or more shared APs.

[0109] According to another embodiment, multi-AP parameters may be transmitted within a dedicated action frame, as shown in Figure 4a. This action frame may transmit multi-AP request and response commands.

[0110] It should be noted that expressions such as "comprise," "include," "incorporate," "contain," "is," and "have" should be interpreted in a non-exclusive manner when interpreting the description and the related claims, that is, they should be interpreted to allow for the existence of other items or components that are not explicitly defined. Singular references should also be interpreted as plural references, and vice versa.

[0111] Those skilled in the art will readily understand that the various parameters disclosed in the description may be modified, and that the various embodiments disclosed may be combined without departing from the scope of this disclosure.

Claims

1. A communication method in a wireless network, wherein at one of a plurality of access points (APs) in the wireless network, This includes sending or receiving management frames; The management frame includes multi-access point (MAP) parameters to be used to coordinate the AP, and the MAP parameters are: An Association Identifier (AID) assigned to an AP that is triggered by another AP, The operational channel on which the AP that sends the aforementioned management frame operates, Recommended channels to be used for MAP transmission, The AID of the adjacent AP, A communication method that includes at least one of the following.

2. The method according to claim 1, wherein the management frame is a transmitted management request frame, the management request frame includes a MAP setup command, the MAP setup command is a request command to participate in a MAP transmission, a suggestion command to participate in a MAP transmission using suggested MAP parameters, or a request command to suggest MAP parameters to be used to adjust the AP.

3. The method according to claim 2, further comprising receiving a management response frame in response to sending the management request frame, wherein the management response frame includes an alternative MAP setup command that suggests the use of MAP parameters different from the corresponding parameters of the management request frame.

4. The method according to claim 2, further comprising receiving a management response frame in response to sending the management request frame, wherein the management response frame includes an approval MAP setup command that accepts MAP parameters associated with the proposed or alternative command of the management request frame.

5. The method according to claim 2, further comprising receiving a management response frame in response to sending the management request frame, wherein the management response frame includes an instruction MAP setup command that compels the use of the MAP parameters associated with the proposed command of the management request frame.

6. The method according to claim 2, further comprising receiving a management response frame in response to sending the management request frame, wherein the management response frame includes a reject MAP setup command that rejects MAP parameters, or a conflict command that warns of conflicting AIDs.

7. The method according to claim 1, wherein the management frame is a received management request frame, and the management request frame includes a request MAP setup command for participating in a MAP transmission, a proposal command for participating in a MAP transmission using proposed MAP parameters, or a request command for proposing MAP parameters to be used to coordinate the AP.

8. The method according to claim 7, further comprising analyzing the received management request frame in response to receiving the management request frame, and generating and transmitting a management response frame in response to the analysis, wherein the management response frame includes an alternative MAP setup command that proposes MAP parameters different from the corresponding parameters of the management request frame.

9. The method according to claim 7, further comprising analyzing the received management request frame in response to receiving the management request frame, and generating and transmitting a management response frame in response to the analysis, wherein the management response frame includes an approval MAP setup command that accepts MAP parameters associated with the proposed or alternative command of the management request frame.

10. The method according to claim 7, further comprising analyzing the received management request frame in response to receiving the management request frame, and generating and transmitting a management response frame in response to the analysis, wherein the management response frame includes an instruction MAP setup command that compels the use of MAP parameters associated with the proposed command of the management request frame.

11. The method according to claim 7, further comprising analyzing the received management request frame in response to receiving the management request frame, and generating and transmitting a management response frame in response to the analysis, wherein the management response frame includes a reject MAP setup command that rejects the MAP parameters received in the management request frame, or a conflict MAP setup command that warns of a conflicting AID.

12. The method according to any one of claims 1 to 11, wherein the management frame comprises a Target Wake Time (TWT) information element, the TWT information element includes the parameter, and includes a TWT parameter associated with a MAP setup command.

13. The method according to claim 12, wherein the TWT information element includes a TWT Setup Command field, and the TWT Setup Command field includes a MAP setup command of request, suggestion, demand, alternative, acceptance, command, rejection, or conflict to be sent or received.

14. The method according to claim 12, wherein the TWT information element includes a MAP Setup Command field, and the MAP Setup Command field includes a MAP setup command of request, suggestion, demand, alternative, acceptance, command, rejection, or conflict to be sent or received.

15. A management frame used in a wireless network including multiple access points (APs), wherein the management frame includes multi-AP (MAP) parameters used to coordinate the APs in the wireless network, and these parameters are: An Association Identifier (AID) assigned to an AP that is triggered by another AP, The operational channel on which the AP that sends the aforementioned management frame operates, Recommended channels to be used for multi-AP transmission, The AID of the adjacent AP, A management frame containing at least one of the following.

16. The management frame according to claim 15, comprising a Target Wake Time (TWT) information element, wherein the TWT information element comprises the parameter and the TWT parameter.

17. The management frame according to claim 15 or 16, further comprising a MAP setup command, wherein the MAP setup command is a request, proposal, demand, alternative, acceptance, order, rejection, or conflict MAP setup command.

18. The management frame according to claim 17, wherein the TWT information element includes a TWT Setup Command field, the TWT Setup Command field includes a MAP setup command of request, suggestion, demand, alternative, acceptance, command, rejection, or conflict.

19. The management frame according to claim 17, wherein the TWT information element includes a MAP Setup Command field, and the MAP Setup Command field includes a MAP setup command of request, suggestion, demand, alternative, acceptance, command, rejection, or conflict.

20. A computer program product for a programmable device, the computer program product comprising instructions for performing each step of the method according to any one of claims 1 to 14 when the program is loaded and executed by the programmable device.

21. A non-temporary computer-readable storage medium storing instructions for a computer program to perform the method according to any one of claims 1 to 14.

22. A processing apparatus having a processing unit configured to perform each step of the method according to any one of claims 1 to 14.

Images