Methods and apparatus for wi-fi easy mesh uhr extension

Abstract

A communication method in a network comprising at least two access points, the communication method comprising: transmitting, with a first access point, a frame according to the Wi-Fi EasyMesh standard to a second access point, the frame comprising information representative of at least one Ultra High Reliability (UHR) IEEE 802.11 technology capability of the first access point.

Description

Technical Field

[0001] This invention relates to wireless communication, and more particularly to a Wi-Fi EasyMesh extension for supporting UHR features. Background Technology

[0002] The methods described in this section can be implemented, but are not necessarily methods previously conceived or implemented. Therefore, unless otherwise indicated herein, the methods described in this section are not prior art as claimed in this application, and are not admitted to be prior art by virtue of their inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems raised in this section.

[0003] Wireless communication networks are widely deployed to provide various communication services, such as voice, video, packet data, messaging, and broadcasting. These wireless networks can be multiple access networks capable of supporting multiple users by sharing available network resources. Examples of such multiple access 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. The 802.11 family of standards adopted by the Institute of Electrical and Electronics Engineers (IEEE) provides a large number of mechanisms for wireless communication between stations. In addition, the Wi-Fi Alliance provides verification procedures to enhance interoperability between wireless devices based on IEEE 802.11 technology. Furthermore, the Wi-Fi Alliance provides its original standards (such as Wi-Fi EasyConnect, Wi-Fi Direct, and Wi-Fi Aware) to further enhance the use of these devices. Wi-Fi EasyMesh is one of those protocols that define the control protocol between access points (APs), enabling secure AP access to the network, as well as the configuration, control, and management of those APs. Wi-Fi EasyMesh has evolved through several versions to support updates to the underlying IEEE 802.11 standard. Summary of the Invention

[0004] The purpose of this invention is to improve the Wi-Fi EasyMesh standard to support the evolution of its underlying IEEE 802.11bn (UHR) technology.

[0005] Therefore, according to a first aspect, the present invention aims to provide a communication method in a network including at least two access points, the communication method comprising:

[0006] A frame according to the Wi-Fi EasyMesh standard is transmitted from a first access point to a second access point, the frame including information representing at least one Ultra-High Reliability (UHR) IEEE 802.11 technical capability and / or parameter of the first access point.

[0007] Such a specification allows for simple configuration and use of multi-AP networks while benefiting from the capabilities of Ultra-High Reliability (UHR) IEEE 802.11 technology.

[0008] In a particular embodiment, the information representing Ultra High Reliability (UHR) IEEE 802.11 technical capabilities and / or parameters is included in the UHR Operation TLV field and / or the UHR Capability TLV (Type Length Value) field.

[0009] In certain embodiments, the ultra-high reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to seamless roaming features.

[0010] In certain embodiments, the Ultra High Reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to the Non-Master Channel Access (NPCA) characteristics.

[0011] In certain embodiments, the ultra-high reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to the dynamic subband operation (DSO) feature.

[0012] In certain embodiments, the Ultra High Reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to the Multi-AP Coordination (MAPC) feature.

[0013] According to a second aspect, the present invention aims to provide a communication method in a network comprising at least two access points, the communication method comprising:

[0014] A frame, conforming to the Wi-Fi EasyMesh standard, is transmitted from a first access point to a second access point. The frame includes configuration information representing at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter of the second access point; and...

[0015] Using the second access point, the at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter of the second access point is configured according to the frames transmitted by the first access point.

[0016] Such a specification allows for the simple configuration and use of multi-AP networks while benefiting from the capabilities of Ultra-High Reliability (UHR) IEEE 802.11 technology.

[0017] In a particular embodiment, the configuration information representing the configuration of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter is included in the UHR Configuration TLV (Type Length Value) field, the UHR MAP Configuration TLV field, and / or the Channel Preference TLV field.

[0018] In a particular embodiment, the method of the present invention further includes: sending configuration response information to the first access point using the second access point, wherein the configuration response information is included in the UHR configuration response TLV (type length value) field.

[0019] In a particular embodiment, at least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the seamless roaming feature.

[0020] In a particular embodiment, at least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Non-Master Channel Access (NPCA) feature.

[0021] In a particular embodiment, at least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Dynamic Subband Operation (DSO) feature.

[0022] In a particular embodiment, at least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Multi-AP Coordination (MAPC) feature.

[0023] In a particular embodiment, at least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to a channel selection configuration.

[0024] In a particular embodiment, at least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to UHR multi-AP group management configuration information. Attached Figure Description

[0025] Some embodiments of the invention are illustrated in the accompanying drawings by way of example rather than limitation. In the drawings, the same reference numerals refer to similar elements, and in the drawings:

[0026] - Figure 1 Examples of network systems that can implement some embodiments of the present invention are illustrated;

[0027] - Figure 2Examples of message sequences for the Wi-Fi EasyMesh protocol between a multi-AP controller and a multi-AP agent are illustrated according to some embodiments of the present invention;

[0028] - Figure 3a and Figure 3b Examples of UHR operation TLV and UHR capability TLV according to some embodiments of the present invention are illustrated;

[0029] - Figure 4 Examples of UHR operation fields according to some embodiments of the present invention are shown;

[0030] - Figure 5 Examples of UHR capability fields according to some embodiments of the present invention are shown;

[0031] - Figure 6a , Figure 6b and Figure 6c Examples of UHR configuration TLV fields, UHRMAP configuration TLV, and UHR configuration response TLV are illustrated according to some embodiments of the present invention;

[0032] - Figure 7 Examples of preference fields and reason code fields included in the channel preference TLV according to some embodiments of the present invention are shown;

[0033] - Figure 8 A flowchart illustrates an example of a UHRMAP configuration process performed in a multi-AP controller according to some embodiments of the present invention;

[0034] - Figure 9a and Figure 9b Examples of message sequences for Wi-Fi EasyMesh UHR configuration and UHR MAP configuration protocols between a multi-AP controller and a multi-AP agent, according to some embodiments of the present invention, are illustrated; and

[0035] - Figure 10 Examples of hardware configurations for both AP and non-AP STA are illustrated according to some embodiments of the present invention. Detailed Implementation

[0036] Figure 1 Examples of network systems that can implement some embodiments of the present invention are illustrated.

[0037] For the sake of illustration, Figure 1This represents a Wi-Fi EasyMesh network consisting of six wireless devices: three access point stations (APs) 100a, 100b, and 100c, and three non-AP stations (non-AP STAs) 110a, 110b, and 110c. Of course, the number of APs and / or non-AP STAs can vary. The APs manage the set of non-AP STAs, which together organize their access to the wireless medium (called the "operation channel") for communication purposes. The stations (including the APs) form a service set, hereinafter referred to as a Basic Service Set (BSS) (although other terms may be used). The same physical station acting as an access point can manage two or more BSSs (and thus the corresponding WLANs): each BSS is therefore uniquely identified by a specific Basic Service Set Identifier (BSSID) and managed by a separate virtual AP implemented within the physical AP.

[0038] APs 100a, 100b, and 100c provide wireless connectivity between BSS stations (e.g., for the BSS of AP 100a, including non-AP STA 110a and AP 100a) and provide access to a wider range of networks, such as the Internet. Connections from non-AP STAs to APs (e.g., 110a to 100a) can be established through a standardized process called association. Figure 1 In this configuration, STA110a is associated with AP 100a via wireless link 130a, STA 110b is associated with AP 100b via wireless link 130b, and STA 110c is associated with AP 100c via wireless link 130c.

[0039] Once a non-AP STA is associated with an AP, it can access the operational channel, transmit data to other stations on the BSS or via the AP to a wider network, and receive data from other stations or via the AP from the wider network. The 802.11 standard family defines various Media Access Control (MAC) mechanisms to drive access to the wireless medium.

[0040] Wi-Fi EasyMesh also provides a way to connect multiple access points (APs) to form a Wi-Fi EasyMesh network. A Wi-Fi EasyMesh network consists of a multi-AP controller (MAP controller) and one or more multi-AP agents (MAP agents). The multi-AP controller is a logical entity that implements the logic for controlling the fronthaul APs and backhaul links in the multi-AP network. The MAP agent is a logical entity that executes commands received from the MAP controller and feeds back measurement results and capability data of the fronthaul APs, clients, and backhaul links to the MAP controller and / or other MAP agents. A single physical device can contain both a MAP controller and a MAP agent. The MAP controller and MAP agent can form a Wi-Fi EasyMesh network over an IEEE 1905.1 network. IEEE 1905.1 provides an abstraction layer over four different MAC / PHY networks: IEEE 802.3 (Ethernet), IEEE 802.11 (WLAN), IEEE 1901 (BPL: Power Line Broadband), and MoCA (Multimedia over Coaxial Cable Alliance). A MAP agent can have a backhaul STA that can connect to a fronthaul AP configured by another MAP controller or MAP agent. Alternatively, a MAP agent can have a logical Ethernet port (which can provide a wired connection to one of Ethernet, BPL, or MoCA) to connect to other logical Ethernet ports in other MAP controllers or MAP agents. Figure 1 In this configuration, AP 100a is configured as a MAP controller with a shared MAP agent, and AP 100b and AP 100c are configured as MAP agents. AP 100b connects to AP 100a via wired link 131a, which can be based on one of IEEE 802.3, IEEE 1901, or MoCA links and supports IEEE 1905.1 features. It should be noted that this description is contextualized but not limited to an IEEE 802.3 link used for link 131a. AP 100c connects to AP 100b via wireless link 131b, which is based on an IEEE 802.11 link and also supports IEEE 1905.1 features. This setup for an EasyMesh network is an example and does not limit any other setup.

[0041] APs 100a, 100b, and 100c may include, be implemented as, or be referred to as Node B, Radio Network Controller (RNC), Evolved Node B (eNB), 5G Next Generation Base Station (gNB), Base Station Controller (BSC), Base Transceiver Station (BTS), Base Station (BS), Transceiver Function (TF), Radio Router, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Radio Base Station (RBS), or some other term. APs 100a, 100b, and 100c may be standalone products, or they may be integrated into an apparatus, such as an Integrated Broadband Remote Access Server (BRAS).

[0042] Non-AP stations 110a, 110b, and 110c may include, be implemented as, or be referred to as a subscriber station, subscriber unit, mobile station (MS), remote station, remote terminal, user terminal (UT), user agent, user device, user equipment (UE), subscriber station (STA), or any other term. In some implementations, a non-AP STA may be or may include a cellular phone, cordless phone, Session Initiation Protocol (SIP) phone, Wireless Local Loop (WLL) station, personal digital assistant (PDA), handheld device with wireless connectivity, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects of the teachings herein may be incorporated into a telephone (e.g., a cellular phone or smartphone), a computer (e.g., a laptop computer), a tablet computer, 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 aspects, non-AP station 110a may be a wireless node. Such wireless nodes can provide connectivity to or from a network (e.g., a wide area network such as the Internet or cellular networks) via wired or wireless communication links.

[0043] Figure 2Exemplary message sequences for a Wi-Fi EasyMesh protocol between a multi-AP controller 100a and a multi-AP agent 100c, according to some embodiments of the present invention, are illustrated. Such sequences also apply to message sequences between a MAP controller 100a and a MAP agent 100b. The only difference between these two scenarios is that the MAP controller 100a and the MAP agent 100b can communicate directly with each other via Ethernet link 131a, which is simpler than the scenario where communication between the MAP controller 100a and the MAP agent 100c requires navigating through the MAP agent 100b. Wi-Fi EasyMesh provides means for MAP onboarding 200, MAP discovery 201, MAP capability exchange 202, MAP configuration 203, and MAP control 204, respectively. All these protocols operate on top of an IEEE 1905.1 network. Therefore, even if the MAP agent 100c is not directly connected to the MAP controller 100a, the MAP controller 100a and the MAP agent 100c can communicate with each other through the MAP agent 100b.

[0044] First, MAP network entry 200 enables MAP agent 100c to securely join the MAP network managed by MAP controller 100a. MAP network entry can be performed through two alternative methods: extended PBC network entry using the 1905 PBC network entry method defined in the Wi-Fi EashMesh specification, or DPP network entry using the DPP protocol defined in the Wi-Fi EasyConnect specification. During this network entry process, MAP controller 100a shares Wi-Fi parameters with MAP agent 100c, such as SSID, authentication type, encryption type, network key, and BSSID.

[0045] After MAP entry into the network 200, MAP agent 100c performs MAP discovery 201 to discover MAP controller 100a. MAP agent 100c sends an extension of the 1905 AP-Autoconfiguration Search message, which includes the TLV defined in the Wi-Fi EasyMesh specification. This message is sent as a relay multicast message, which is forwarded via MAP agent 100b between different network interfaces (i.e., from IEEE 802.11 link 131b to Ethernet link 131a) so that it can reach MAP controller 100a. MAP controller 100a then also responds to MAP agent 100c with a 1905 AP-Autoconfiguration Response message via MAP agent 100b. Using this MAP discovery 201, the MAP controller and MAP agent discover each other and are ready for further communication to perform MAP capability exchange 202, MAP configuration 203, or MAP control 204. The order of these three processes described is not restrictive and other implementations can be used.

[0046] Following MAP discovery 201, the MAP agent can perform MAP capability exchange 202 to exchange its capabilities with the MAP controller 100a. MAP capability exchange 202 is based on AP capability query and AP capability report messages. MAP devices (including both the MAP controller and the MAP agent) can send AP capability queries, and the MAP device receiving the AP capability query responds with an AP capability report message. Within the AP capability report message, the MAP device can include multiple TLVs that transmit various types of capability information. In this document, dedicated new TLVs are proposed to inform about UHR capabilities associated with UHR capability information elements and / or UHR operation information elements that may be specified in the IEEE 802.11bn (UHR) specification. The contents of each TLV are described later in the specification. AP capability exchange can occur earlier than, for example, MAP capability exchange 202 included in either MAP access 200 or MAP discovery 201.

[0047] If the capabilities of MAP agent 100c are learned through MAP capability exchange 202 or any other means, MAP controller 100a can perform MAP configuration 203 to configure MAP agent 100c. If the DPP network entry method is used in MAP network entry 200, MAP configuration 203 can be performed during MAP network entry 200 using a BSS configuration response message, which includes a TLV specifying the configuration information sent from MAP controller 100a to MAP agent 100c. Otherwise, to initiate (re)configuration, MAP agent 100c sends a 1905 AP AutoConfiguration WSC message to MAP controller 100a, including M1 as defined in the Wi-Fi Protected Setup specification. This 1905 AP AutoConfiguration WSC message indicates the radio frequency that MAP agent 100c wants to configure via a radio frequency unique identifier in the AP radio frequency basic capability TLV. The MAP controller 100a receives the message and responds with another 1905 AP Auto-Configuration WSC message, which includes M2 as defined in the Wi-Fi Protected Setup specification, and other TLVs containing various configuration information for configuring the MAP agent, which is the recipient of the message.

[0048] This specification presents new configuration information, including information specific to features that can be specified in the IEEE 802.11bn (UHR) specification. Based on exchanged or pre-shared capability information related to UHR features, the MAP controller 100a can configure the UHR features of the MAP agent 100c. Configuration is based on new or updated TLVs presented in this specification, such as, in a non-limiting manner, UHR operation TLV, UHR capability TLV, UHR configuration TLV, and UHR MAP configuration TLV. The content of TLVs related to UHR configuration will be presented later in this specification.

[0049] MAP controller 100a can execute MAP control 204 to further control MAP agent 100c. MAP control 204 includes, in a non-limiting manner, channel selection, link metric collection, client bootstrapping, backhaul optimization, traffic separation, and service prioritization. Channel selection features enable MAP controller 100a to request MAP agent 100c to switch its operating channel. MAP controller 100a can use a channel preference query message to inquire about its channel preferences from MAP agent 100c, and MAP agent 100c responds with a channel preference report message including the channel preference TLV. MAP controller 100a can also request channel switching by sending a channel selection request message to MAP agent 100c that also includes the channel preference TLV. MAP agent 100c then responds with a channel selection response message indicating acceptance or rejection. If MAP agent 100c accepts the request from the MAP controller, the MAP agent switches its operating channel and then sends an operating channel report message. Using the UHR capabilities and / or UHR operational information presented in this specification, the MAP controller 100a and MAP agent 100c can modify their channel preferences to achieve a better channel distribution for UHR multi-AP coordination purposes. This description also proposes an update to the channel preference TLV to express this preference. For example, in one embodiment, multiple UHR-enabled APs can be collected in a specific channel to benefit from the UHR multi-AP coordination features. Other non-UHR APs can be collected in other channels without interfering with UHR-enabled APs. The content of the channel preference TLV will be presented later in this specification.

[0050] Figure 3aExamples of UHR operation TLVs according to some embodiments of the present invention are illustrated. The name of the TLV is not limited to "UHR operation TLV" and may, for example, correspond to a Wi-Fi 8 operation TLV. UHR AP devices support AP MLDs (Multi-Link Devices) as defined in the IEEE 802.11be D5.0 standard. An AP MLD may support one or more affiliated APs operating in a link. An AP MLD may support one or more radio channels operating on one or more links. Reference numeral 300a corresponds to the basic format of the TLV, which consists of a tlvType field 301a, a tlvLength field 302a, and a tlvValue field 303a. The tlvType field 301a is a 1-byte field identifying the type of the TLV. The tlvLength field 302a is a 2-byte field identifying the number of bytes in the tlvValue field 303a. The tlvValue field 303a includes a value specific to its type. Each TLV has its own format for the tlvValue field 303a. For UHR operation TLV, the tlvValue field 303a consists of the radio frequency quantity field 304a and N radio frequency value fields. N is indicated in the radio frequency quantity field 304a, and N indicates the number of radio frequency channels that the TLV wants to configure. The radio frequency value field 305a is the first radio frequency value field, and reference numeral 306a may include one or more of the remaining radio frequency value fields. The radio frequency value field 305a further consists of the radio frequency ID field 307a that uniquely identifies the radio frequency and M BSS value fields. M is indicated in the BSS quantity field 306a. The BSS value field 307a is the first BSS value field, and reference numeral 308a may include one or more of the remaining BSS value fields. The BSS value field 307a further consists of the BSSID 309a that identifies the BSS and the UHR operation field 310a. Any other fields not indicated here may be added within the tlvValue field 303a. UHR operation TLVs can be included in AP capability report messages, BSS configuration request messages, BSS configuration response messages, BSS configuration result messages, channel selection request messages, operation channel report messages, and channel preference report messages in a non-restrictive manner.

[0051] Figure 3bExamples of UHR capability TLVs according to some embodiments of the present invention are illustrated. The name of the TLV is not limited to "UHR capability TLV" and may, for example, correspond to a Wi-Fi 8 capability TLV. The functions of reference numerals 300b to 307b are the same as those of reference numerals 300a to 307a, respectively. The radio frequency value field 305b consists of the radio frequency ID field 307b and the UHR capability field 308b. Any other fields not indicated herein may be added to the tlvValue field 303b. The UHR capability TLV may be included in AP capability report messages and BSS configuration request messages in a non-limiting manner.

[0052] Figure 4Examples of UHR operation fields according to some embodiments of the present invention are illustrated. UHR operation field 310a included in UHR operation TLV 300a corresponds to UHR operation field 400. In one embodiment, UHR operation field 400 may be a copy of a UHR operation information element (excluding the element ID field, length field, and element ID extension field) that may be specified in the IEEE 802.11bn specification. UHR operation field 400 may include at least one of the following: UHR operation parameter field 401, basic UHR-MCS and NSS set field 402, and UHR operation information field 403 and UHR MAP group information field 404. UHR operation field 400 may also include one or more additional fields 405 not specified in this document. UHR operation parameter field 401 may also include one or more fields for indicating the presence of a specific field that may be included in UHR operation information field 403. If the presence of a specific field is indicated by setting it to 1 to indicate "existence," this indicates that the specific field exists in UHR operation information field 403. Otherwise, by setting it to 0, this indicates that the specific field does not exist in the UHR Operation Information field 403. The Basic UHR-MCS and NSS Set field 402 indicates the UHR-MCS for each spatial stream number in the UHR PPDU supported by all UHR STAs in the BSS (including IBSS and MBSS) for transmission and reception. The UHR Operation Information field 403 may include, but is not limited to, information fields related to new channel usage specified in IEEE 802.11, such as the channel center frequency of the UHR BSS, the bandwidth of the UHR BSS, the channel puncturing information of the UHR BSS, the Distributed Frequency Modulation RU (DRU) information, secondary channel (or non-primary channel) access information, and / or dynamic subband operation information. The UHR MAP Group Information (Info) field 404 includes information on zero or more than zero UHR MAP groups to which the UHR device belongs. This may also include a UHR MAP Group ID Quantity field 406 indicating the number of groups indicated, and a UHR MAP Group ID field 407 for each UHR MAP Group ID. A UHR MAP group is a group to which a UHR AP may belong. Some UHR MAPCs may be restricted to UHR MAP groups. For example, for seamless roaming features, a UHR AP user may want to restrict seamless roaming to specific UHR MAP groups managed by the user, rather than allowing the UHR STA to roam to APs not in the specified UHR MAP group. A UHR AP can belong to multiple UHR MAP groups simultaneously. The format of the UHR MAP group ID is not limited to the format disclosed herein, as long as a particular group can be uniquely identified.In certain embodiments, it is conceivable to use a format such as the MAC address (e.g., the owner of the MAP group) or a string of information similar to an SSID. In one embodiment, the MAC address of one of the AP MLDs or its associated APs can be used as the UHR MAP group ID. The UHR MAP group details field 408 may include further details of the corresponding UHR MAP group indicated by the UHR MAP group ID field 407, such as the MAPC subtypes enabled in the group. The UHR MAP group information field 404 may also include one or more additional fields 409 not specified in this document.

[0053] Figure 5 Examples of UHR capability fields according to some embodiments of the present invention are illustrated. UHR capability field 308b included in UHR capability TLV300b corresponds to UHR capability field 500.

[0054] In one embodiment, the UHR capability field 500 may be a copy of the UHR capability information element (excluding the element ID field, length field, and element ID extension field) that may be specified in the IEEE 802.11bn specification. The UHR capability field 500 may contain at least one of the following: Multi-AP Coordination Capability 501, NPCA (also known as SCA) Capability 502, DSO Capability Field 503, and / or Seamless Roaming Capability Field 504. The UHR capability field 500 may also include one or more other fields 505 not specified in this document. The Multi-AP Coordination Capability 501 may include information indicating support for the Multi-AP Coordination subtype. One or more bits may be assigned to a subtype to indicate support (e.g., 0: not supported, 1: supported) or further indicate the level of support (e.g., 0: not supported, 1: supported with limited capability, 2: fully supported), or may further have one or more subfields to indicate details of its capabilities, such as in the case of the Seamless Roaming Capability Field 504. Support for any type of UHR multi-AP coordination subtype, such as the following, may be included in the MAPC capability field 501: Coordinated OFDMA, Coordinated TDMA, Coordinated (r)TWT, Coordinated MIMO, Coordinated Beamforming, Coordinated Space Reuse, Coordinated Transport (Joint Transport), and Coordinated Roaming (Seamless Roaming). The UHR multi-AP coordination subtypes shown herein are examples and are not limited to these.

[0055] SCA capability 502 includes capabilities related to Secondary Channel Access (SCA) operation. SCA capability 502 is also referred to as Non-Primary Channel Access (NPCA) operation. SCA operation is a feature considered within the IEEE 802.11bn scope for media access using secondary (or non-primary) channels when the primary channel is busy. SCA capability 502 may include subfields indicating support for SCA operation features (e.g., 0: not supported, 1: supported), transmitter capabilities (e.g., maximum number of channels) or type associated with SCA operation, receiver capabilities (e.g., maximum number of channels) or type associated with SCA operation, available channel information for SCA operation, handover delay for secondary channel handover, and preferred secondary channel priority, but without limitation.

[0056] DSO capability 503 includes capabilities related to Dynamic Subband Operation (DSO). DSO is a feature considered within the IEEE 802.11bn scope to enable media access using secondary channels when the BSS provides a wider bandwidth than supported by a non-AP STA. For example, when the BSS provides 320MHz bandwidth and a non-AP STA only supports 160MHz, the BSS can dynamically allow the non-AP STA to switch to the secondary 160MHz and access the media. In a particular embodiment, DSO capability 503 may include subfields indicating support for DSO features (e.g., 0: not supported, 1: supported), transmitter capabilities (e.g., maximum number of channels) or type associated with DSO, receiver capabilities (e.g., maximum number of channels) or type associated with DSO, available channel information for DSO, and handover delay for secondary channel handover.

[0057] The Seamless Roaming Capability field 504 includes capabilities associated with the Seamless Roaming feature. This Seamless Roaming Capability field 504 may not exist if the Seamless Roaming Coordination subtype is not indicated as supported in the Multi-AP Coordination Capability field. Seamless Roaming is one of the Multi-AP Coordination subtypes discussed in the IEEE 802.11bn task group. The Seamless Roaming feature is designed to maintain data continuity during roaming from one AP MLD to another non-co-located AP MLD for an associated non-AP STA.

[0058] In one embodiment, upper-layer MAC (UMAC) and lower-layer MAC (LMAC) capability information may be included in the seamless roaming capability field 504. UMAC and LMAC separation is a feature considered within the IEEE 802.11bn scope to flexibly distribute UMAC and LMAC features across non-co-located devices. In a particular embodiment, UMAC may have features such as authentication, association, sequence number (SN) and packet number (PN) allocation, encryption / decryption, BA buffering and reordering by SN, replay detection by PN, etc. Duplicate detection and block acknowledgment (Ack) scoreboards may also be UMAC features, but this depends on whether TID-to-link mapping for a specific TID is allowed between links of multiple non-co-located AP MLDs. The UMAC / LMAC capability field 506 may include support for UMAC features (e.g., 0: not supported, 1: supported) and support for LMAC features (e.g., 0: not supported, 1: supported). The UMAC / LMAC capability field 506 may also include subfields indicating detailed capability levels for features such as: authentication, association, SN and PN assignment, encryption / decryption, BA buffering and reordering by SN, replay detection by PN, duplicate detection, and block acknowledgment scoreboard. Separating UMAC and LMAC features in non-co-located APs requires a method for communicating IEEE 802.11 context information (such as SN (serial number) and PN (packet number)) between UMAC and LMAC APs. This context information can be encapsulated above the IEEE 1905.1 abstraction layer using messages defined in the Wi-Fi EasyMesh specification for transmission over multi-AP networks.

[0059] In another embodiment, SMD (Seamless Mobility Domain) capability information may be included in the Seamless Roaming Capability field 504. SMD is a logical control plane entity considered within the IEEE 802.11bn scope to enable seamless roaming features. Instead of having UMAC and LMAC separation, context information is transmitted from the source AP to the target AP when roaming is about to occur. Context information may include, but is not limited to, PN, SN, STA capabilities, BA (Block Acknowledgment) protocol, SCS (Flow Classification Service) information, QoS characteristic information, TWT (Target Wake-Up Time) information, and negotiated TID-to-link mapping information. SMD covers groups of AP MLDs where associated non-AP MLDs can roam using the seamless roaming feature. SMD capability field 507 may include support for the SMD feature itself (e.g., 0: not supported, 1: supported), whether the AP MLD is likely to participate in a new SMD (e.g., 0: not possible, 1: possible), and whether the AP MLD is likely to be removed from the current SMD (e.g., 0: not possible, 1: possible). Similarly, in the UMAC and LMAC cases, messages defined in the Wi-Fi EasyMesh specification can be used to encapsulate IEEE 802.11 context information on top of the IEEE 1905.1 abstraction layer for transmission over multi-AP networks.

[0060] Other elements not described in this document may be added to field 508. In a particular embodiment, both the UMAC / LMAC capability field 506 and the SMD capability field 507 may exist in the seamless roaming capability field 504, or only one of them may exist.

[0061] In these embodiments, all of these capabilities can be included in a single UHR capability field 308b within the UHR capability TLV. However, one or more capability fields included in reference numeral 500 may be separated into dedicated TLVs, or included in other existing or new TLVs and appended separately to the message.

[0062] Figure 6aExamples of UHR configuration TLVs according to some embodiments of the present invention are illustrated. The UHR configuration TLV is a new multi-AP TLV format proposed in this document. The name of the TLV is not limited to "UHR configuration TLV" and may, for example, correspond to a Wi-Fi 8 configuration TLV. This TLV may be included in, but not limited to, the 1905 AP Autoconfiguration WSC(M2) message, the 1905 AP Autoconfiguration Renew message, the 1905 Topology Response message, the BSS Configuration Response message, and the BSS Configuration Result message, and may be included in any other existing or newly defined message. For example, a new multi-AP message format including this TLV (such as a UHR configuration request message or a UHR configuration response message, etc.) may be defined in the Wi-Fi EasyMesh specification. Using these messages, the MAP agent can indicate the status of its UHR configuration to the MAP controller, and the MAP controller can configure one or more UHR configurations of the MAP agent. The functions of reference numerals 600a to 603a are the same as those of reference numerals 300a to 303a, respectively. The tlvValue field 603a consists of the following fields: AP MLD ID field 604a, Link ID field 605a, MAPC Configuration (Config) field 606a, NPCA Configuration field 607a, DSO Configuration field 608a, Seamless Roaming Configuration field 609a, and zero or more than zero fields 610a not specified in this document. The AP MLDID 604a identifies which AP MLD the configuration applies to. This can be done, for example, by indicating the AP MLD MAC address. If the configuration applies to all AP MLDs that the MAP agent has, this field can indicate a special value (e.g., all bits 1 or 0) to indicate such a target. The Link ID field 605a identifies which affiliated AP the configuration applies to. This can be done, for example, by indicating the Link ID value defined in IEEE 802.11be D5.0 35.3.3.2 Link ID. If the configuration applies to all affiliated APs of the indicated AP MLD, this field can indicate a special value (e.g., all bits 1: value 15) to indicate such a target. MAPC configuration field 606a includes configuration information for multi-AP coordination. SCA configuration field 607a includes configuration information for secondary channel access. DSO configuration field 608a includes configuration information for dynamic subband operation. Seamless roaming configuration field 609a may include configuration information for seamless roaming features. Seamless roaming configuration field 609a may also include subfields such as a UMAC / LMAC configuration field for configuring UMAC / LMAC features or an SMD configuration field for configuring SMD features.In one embodiment, configuration information 606a, 607a, 608a, and 609a may contain the same frame format for capability fields 501 to 504. In this case, the format of capability fields 501 to 504 is reused for configuration purposes. For example, the following are examples: Multi-AP Coordination Capability Field 501 is used for MAPC configuration field 606a, SCA Capability Field 502 is used for SCA configuration field 607a, DSO Capability Field 503 is used for DSO configuration field 608a, and Seamless Roaming Capability Field 504 is used for Seamless Roaming configuration field 609a. The bits included in configuration fields 606a to 609a can be used to configure the MAP agent. For example, if a corresponding capability bit indicates support for a feature (e.g., 1 for support and 0 for non-support), the MAP controller can set the corresponding configuration bit to 1 to enable the corresponding capability, or set the corresponding configuration bit to 0 to disable the corresponding capability. In another example, if a corresponding (one or more) capability bit indicates a range of features (e.g., maximum number of channels), the corresponding capability field can be set to a specific number to be configured. This configuration should be feasible when the corresponding capability indication for the capability bit supports the feature in the MAP agent. Furthermore, this configuration should not exceed the capability of the MAP agent indicated in the capability field (e.g., if the maximum number of channels is 4, the config should be set to 4 or less). Any other fields not indicated here can be added within tlvValue 603a.

[0063] In another embodiment, configuration information 606a, 607a, 608a, and 609a may not include the same frame format as the capability field, but instead include the format of the UHR operation field 310a. Furthermore, the configuration information may have a dedicated format (e.g., omitting one or more fields) to reduce the size of the configuration information.

[0064] In these embodiments, all these configuration fields may be included in a single UHR configuration TLV 600a. However, different embodiments are conceivable in which one or more of the configuration fields included in 600a may be separated into a dedicated TLV, or included in other existing or new TLVs and appended separately to the message.

[0065] Figure 6bExamples of UHR MAP configuration TLVs according to some embodiments of the present invention are illustrated. The name of the TLV is not limited to "UHR MAP Configuration TLV" and may, for example, correspond to a Wi-Fi 8 MAP configuration TLV. The purpose of the UHR MAP configuration TLV is for the MAP controller to further configure the UHR multi-AP characteristics of the MAP agent to perform MAP-related actions, such as creating a MAP group, terminating a MAP group, joining a MAP group, leaving a MAP group, enabling / disabling MAP subtypes, etc. These can be performed during the MAP configuration 203 process. The TLV can be included in the 1905 AP Auto-Configuration WSC(M2) message, the 1905 AP Auto-Configuration Reconfiguration message, the 1905 Topology Response message (Extended), the BSS Configuration Response message, the BSS Configuration Result message, and can also be included in any other existing or newly defined message. For example, a new multi-AP message format including this TLV (such as a UHR MAP configuration request message, a UHR MAP configuration response message, etc.) can be defined in the Wi-Fi EasyMesh specification. The functions of reference numerals 601b to 603b are the same as those of reference numerals 601a to 603a, respectively.

[0066] The tlvValue field 603b can consist of the AP MLD ID field 604b, the Link ID field 605b, the UHR MAP Action field 606b, the UHR MAP Group ID field 607b, the UHR MAPC Subtype field 608b, and the UHR MAP Action Details field 609b, and may have other fields not specified in this document in 610b.

[0067] The functions of reference numerals 604b and 605b are the same as those of reference numerals 604a and 605a, respectively.

[0068] The UHR MAP Action field 606b indicates the action that the MAP controller requests the MAP agent to perform. In one embodiment, actions such as creating a MAP group (0), terminating a MAP group (1), joining a MAP group (2), leaving a MAP group (3), enabling / disabling a MAP subtype (4) can be defined, and action values ​​as indicated in parentheses can be assigned to these actions. The MAP controller specifies the action value in the UHR MAP Action field 606b to request the corresponding action from the MAP agent.

[0069] The UHR MAP Group ID field 606b identifies the target UHR MAP group for the requested action. UHR multi-AP coordination can have specific coordination within a specific AP group. This group can be referred to as a UHR MAP group. An AP can belong to multiple UHR MAP groups to allow multiple coordinations to occur in parallel. In this case, the UHR MAP group needs to be identified. The UHR MAP Group ID field 607b is used to identify the UHR MAP group. If the UHR MAPC subtype field 608b indicates a seamless roaming subtype, the UHR MAP Group ID field can indicate an SMD ID that uniquely identifies the SMD.

[0070] The UHR MAPC subtype field 608b indicates the target UHR MAP coordination subtype for the requested action. This field may indicate one or more UHR MAP coordination subtypes, such as those assigned subtype values ​​as indicated in parentheses, including: Coordinated OFDMA (0), Coordinated TDMA (1), Coordinated (r)TWT (2), Coordinated MIMO (3), Coordinated Beamforming (4), Coordinated Space Reuse (5), Coordinated Transport (Joint Transport) (6), and Coordinated Roaming (Seamless Roaming) (7). The multi-AP coordination subtypes shown herein are examples and are not limited to these. The MAP controller specifies the UHR MAPC subtype value in the UHR MAPC subtype field 608b to indicate to the MAP agent the corresponding subtype as the target of the specified action. In other embodiments, the UHR MAPC subtype field 608b may include a bitmap format, where each bit corresponds to one of the UHRMAP coordination subtypes. Using this bitmap format, the corresponding action specified in the UHR MAP action field 606b applies to all subtypes indicated as high (or low) in the bitmap.

[0071] UHR MAP Action Details 609b may contain further details of the requested action. For example, it may specify the effective duration of the requested action (after which the action will be invalid; for example, a subtype enabled without any request will be disabled), or it may specify a delay limit for the requested action (indicating until the action must be performed), or it may indicate the number of existing APs in the specified UHR MAP group. UHR MAP Action Details field 609b may have dedicated parameters corresponding to the actions indicated in UHR MAP Action field 606b and / or the subtypes indicated in UHRMAPC Subtype field 608b.

[0072] You can add any other fields to 610b to further extend the tlvValue 603b field.

[0073] Figure 6c Examples of UHR configuration response TLVs according to some embodiments of the present invention are illustrated. The name of the TLV is not limited to "UHR configuration response TLV" and may, for example, correspond to a Wi-Fi 8 configuration response TLV. The purpose of the UHR configuration response TLV is to indicate acceptance or rejection of UHR configuration or UHR MAP configuration from the MAP agent to the MAP controller by including the TLV in a response message. The TLV may be included in the 1905 AP Auto-Configuration WSC message or any other existing or newly defined message. For example, a new multi-AP message format (such as a UHR configuration response message or a UHR MAP configuration response message, etc.) including the TLV may be defined in the Wi-Fi EasyMesh specification. The functions of reference numerals 601c to 603c are the same as those of reference numerals 601a to 603a, respectively.

[0074] The tlvValue field 603c can consist of the AP MLD ID field 604c, the Link ID field 605c, the Response Code field 606c, and the Preference Configuration field 607c, and may have other fields not specified in this document in 608c.

[0075] Reference numerals 604b and 605b function the same as reference numerals 604a and 605a, respectively, and these fields indicate which AP MLD and which affiliated AP the response corresponds to. Reference numeral 600c may include multiple fields 603c to indicate multiple responses with different response codes (e.g., partial acceptance and partial rejection). The response code field 606c includes a code for indicating the result of the configuration. The result may include at least acceptance (0) and rejection (1), and may be further extended to include, for example, rejection (2) with a preferred configuration. When the response code is set to rejection (2) with a preferred configuration, a preferred configuration field 607c may be included to indicate the preferred configuration from MAP agent 100c. The preferred configuration field 607c may include UHR configuration TLV 600a or UHR MAP configuration TLV 600b to indicate the preferred configuration.

[0076] Figure 7Examples of the preference field and reason code field included in the channel preference TLV according to some embodiments of the present invention are illustrated. Reference numeral 700 corresponds to an update to the existing reason code definition in the latest Wi-Fi EasyMesh specification. The proposed updates are shown in lines 701 and 702. All other lines remain unchanged in the latest Wi-Fi EasyMesh specification. Reference numeral 701 corresponds to an update to the preference field to declare the most preferred channel using the value 1111. This allows MAP devices to declare the most preferred channel using the reason code. Reference numeral 702 corresponds to an update to the reason code field to express the preference reason as a UHR multi-AP coordination purpose, for example, using the value 1101. Using these two updates, MAP devices can declare the most preferred channel with a reason for UHR multi-AP coordination.

[0077] Figure 8 A flowchart illustrates an example of a UHR configuration process performed in a MAP controller according to some embodiments of the present invention. This flowchart is triggered when the MAP controller wants to (re)configure the MAP agent. In step 800, the MAP controller checks whether the MAP agent it wants to (re)configure supports UHR features. This can be done by checking the presence of the UHR operation TLV and / or UHR capability TLV exchanged during the MAP capability exchange 202 process. If at least one of these TLVs is present, it means that the MAP agent supports UHR features. This information, including details of each UHR capability, can be stored in memory for easy reference when triggering (re)configuration. In step 801, if the MAP agent supports UHR, proceed to step 802. Otherwise, proceed to step 804 and perform conventional configuration and / or control based on the latest Wi-Fi EasyMesh specification, and end the flowchart. In step 802, the MAP controller gathers information to optimize the UHR configuration for the MAP agent. This information may consist of the following: the capabilities of the MAP controller itself, UHR operation TLVs and / or UHR capability TLVs collected from one or more MAP agents, link metric information collected from one or more MAP agents, or any other information that may aid in optimization. Using this information, the MAP controller determines the optimal configuration and / or control of the UHR MAP agents. In step 803, the MAP controller uses at least one of the UHR operation TLVs, UHR configuration TLVs, UHRMAP configuration TLVs, and / or channel preference TLVs as presented in this document to perform UHR configuration and / or control.

[0078] Figure 9aExamples of message sequences for the Wi-FiEasyMesh UHR configuration protocol between a multi-AP controller and a multi-AP agent are illustrated according to some embodiments of the present invention. The sequence includes... Figure 2 The MAP configuration 203 process is shown below. In this embodiment, UHR configuration 901a is first performed to configure the basic UHR configuration, and then UHR MAP configuration 902a is performed to operate UHR multi-AP group management. Figure 9b The UHR MAP configuration 902a is further described below. This embodiment illustrates an exemplary scenario in which the MAP controller 100a configures the MAP agent 100c to activate only the SMD feature of the Seamless Roaming feature and deactivate all other UHR features for all affiliated APs of all AP MLDs present in the MAP agent 100c.

[0079] For UHR configuration 901a, MAP controller 100a sends UHR configuration TLV 600a to MAP agent 100c. This UHR configuration TLV 600a can be included in one of the existing Wi-Fi EasyMesh multi-AP message formats (such as 1905 AP Auto-Configuration WSC(M2) message, 1905 AP Auto-Configuration Reconfiguration message, 1905 Topology Response message (extended), BSS Configuration Response message, BSS Configuration Result message, etc.), or in a newly defined Wi-Fi EasyMesh multi-AP message format (such as a UHR configuration request message including at least one or more UHR configuration TLVs). In this embodiment, the UHR configuration request message is used to transmit the UHR configuration TLV. In this embodiment, AP MLD ID 604a has a special value (e.g., all 0s or all 1s) to indicate that the configuration is for all AP MLDs. Link ID 605a has a special value (e.g., all 1s: value 15) to indicate that the configuration is for all affiliated APs. Except for the bit used for seamless roaming, MAPC configuration 606a has all 0 values ​​(i.e., deactivated). The bit used for seamless roaming has a value of 1 (i.e., activated). SCA configuration field 607a and DSO configuration field 608a have all 0 values ​​(i.e., deactivated). Seamless roaming configuration field 609a has a value of 1 (i.e., activated) for the bit associated with the SMD feature, and the other bits have a value of 0 (i.e., deactivated). MAP agent 100c receives this UHR configuration TLV 600a and can accept or reject the indicated configuration, and responds to MAP controller 100a with a message including a UHR configuration response TLV 600c, which indicates acceptance or rejection in the response code field 606c. If MAP agent 100c accepts the indicated configuration, MAP agent 100c configures its UHR features as indicated in the received UHR configuration TLV 600a. The response message can be one of the existing Wi-Fi EasyMesh multi-AP message formats (such as 1905 AP Auto Configuration WSC), or it can be a newly defined Wi-Fi EasyMesh multi-AP message format (such as a UHR configuration response message that includes at least one or more UHR configuration response TLVs).

[0080] For UHR MAP configuration 902a, MAP controller 100a sends a UHR MAP configuration TLV 600b to MAP agent 100c. This UHR MAP configuration TLV 600b can be included in one of existing Wi-Fi EasyMesh multi-AP message formats (such as 1905 AP Auto-Configuration WSC(M2) message, 1905 AP Auto-Configuration Reconfiguration message, 1905 Topology Response message (Extended), BSS Configuration Response message, BSS Configuration Result message, etc.), or in a newly defined Wi-Fi EasyMesh multi-AP message format (such as a UHR MAP configuration request message including at least one or more UHR MAP configuration TLVs). In another embodiment, the UHR configuration request message used in 901a can be reused to include a UHR MAP configuration TLV. In this embodiment, the UHR MAP configuration request message can be used to transmit the UHR MAP configuration TLV. Figure 9b The exemplary message sequences 900b to 904b shown further detail the UHR MAP configuration 902a procedure. The UHR MAP configuration 902a procedure is performed to operate UHR multi-AP (MAP) group management, which includes operations such as: UHR MAP group creation / termination, adding new APs to a UHR MAP group, removing existing APs from a UHR MAP group, and activating / deactivating UHR MAPC subtypes in a UHR MAP group. A UHR MAP group is a group of APs that support UHR MAPC features. UHR MAP groups can be used to determine the scope of coordination between UHR APs that support UHR MAPC features.

[0081] First, MAP controller 100a can send a create group message 900b to MAP agent 100c. This message is a UHR MAP configuration request message, which includes a UHR MAP configuration TLV for instructing MAP agent 100c to create the specified MAP group. Specifically, the UHR MAP configuration TLV 600b is included in the UHR MAP configuration request message, wherein: the AP MLD ID field 604b is set to (one or more) the ID of the target AP MLD (in this embodiment, a special value such as all 0s or all 1s is used to indicate all AP MLDs) to belong to the created UHR MAP group; the Link ID field 605b is set to (one or more) the ID of the target affiliated AP (in this embodiment, a special value such as all 1s is used to indicate all affiliated APs) to belong to the created UHR MAP group; the UHR MAP Action field 606b is set to 0, which indicates the creation of a MAP group as an action; the UHR MAP Group ID field 607b is set to the group ID value of the target UHR MAP group or the SMD ID value used as the ID of the new UHR MAP group, or the MAP controller can allow the MAP agent to determine the new UHR MAP group ID by indicating a special value (e.g., all 0s or all 1s); UHR MAPC subtype field 608b, in which the bit corresponding to the seamless roaming subtype is set to high (1) and the other bits are set to low (0); UHR MAP action details field 609b is set to detailed configuration of the seamless roaming configuration.

[0082] MAP agent 100c receives the UHR MAP configuration TLV 600b included in the UHR MAP configuration request messages (900b, 901b, 902b, 903b, and 904b), and can accept or reject the indicated MAP configuration. It can also respond to MAP controller 100a with a message including a UHR configuration response TLV 600c, which indicates acceptance or rejection in the response code field 606c. If MAP agent 100c accepts the indicated configuration, it configures its UHR characteristics as indicated in the received UHR MAP configuration TLV 600b. The response message can be one of the existing Wi-Fi EasyMesh multi-AP message formats (such as 1905 AP Auto-Configuration WSC), or it can be a newly defined Wi-Fi EasyMesh multi-AP message format (such as a UHR MAP configuration response message including at least one or more UHR configuration response TLVs).

[0083] Secondly, MAP controller 100a can send a join MAP group message 901b to MAP agent 100c. This message is a UHRMAP configuration request message, which includes a UHRMAP configuration TLV for instructing MAP agent 100c to join the indicated MAP group. In detail, the UHR MAP configuration TLV 600b is included in the UHR MAP configuration request message, wherein: the AP MLD ID field 604b is set to (one or more) the ID of the target AP MLD (in this embodiment, a special value such as all 0s or all 1s is used to indicate all AP MLDs) to belong to the created UHR MAP group; the Link ID field 605b is set to (one or more) the ID of the target affiliated AP (in this embodiment, a special value such as all 1s is used to indicate all affiliated APs) to belong to the created UHR MAP group; the UHR MAP Action field 606b is set to 2, which indicates joining the MAP group as an action; the UHR MAP Group ID field 607b is set to the group ID value of the target UHR MAP group or the SMD ID value used to identify the SMD to which the MAP agent is to join; the UHR MAPC Subtype field 608b, wherein the bit corresponding to the Seamless Roaming subtype is set high (1) and the other bits are set low (0); UHR The MAP action details field 609b is set to detailed configuration for seamless roaming. If MAP agent 100c is about to join an existing UHR MAP group, MAP controller 100a can obtain the group ID by any means. An example of obtaining the existing group ID is gathering information from the UHR MAP group ID field 404 (one or more) from the UHR operation TLV 300a of the MAP agent. If the create MAP group message 900b also triggers the join MAP group action, the join MAP group message 901b can be skipped.

[0084] Third, MAP controller 100a can send an enable / disable MAP subtype message 902b to MAP agent 100c. This message is a UHR MAP configuration request message, which includes a UHR MAP configuration TLV, which includes a UHR MAP configuration TLV for instructing MAP agent 100c to enable the configuration of the indicated MAP subtype. In detail, the UHR MAP configuration TLV 600b is included in the UHR MAP configuration request message, wherein: the AP MLD ID field 604b is set to (one or more) the ID of the target AP MLD (in this embodiment, a special value such as all 0s or all 1s is used to indicate all AP MLDs) to belong to the created UHR MAP group; the Link ID field 605b is set to (one or more) the ID of the target affiliated AP (in this embodiment, a special value such as all 1s is used to indicate all affiliated APs) to belong to the created UHR MAP group; the UHR MAP Action field 606b is set to 4, which indicates enabling / disabling the MAP subtype as an action; the UHR MAP Group ID field 607b is set to the MAP group ID value of the target MAP group to apply the action; the UHR MAPC Subtype field 608b, wherein the bit corresponding to the subtype to be enabled is set high (1) and the bit corresponding to the subtype to be disabled is set low (0); and the UHR MAP Action Details field 609b is set to the detailed configuration of the subtype to be enabled. By sending the Enable MAP Subtype message 901b, the MAP controller 100a can dynamically configure the enabled MAP subtype of the MAP agent 100c.

[0085] Fourth, MAP controller 100a may send a leave MAP group message 903b to MAP agent 100c. This message is a UHRMAP configuration request message, which includes a UHRMAP configuration TLV for instructing MAP agent 100c to leave the indicated MAP group. In detail, the UHR MAP configuration TLV 600b is included in the UHR MAP configuration request message, wherein: the AP MLD ID field 604b is set to (one or more) the ID of the target AP MLD (in this embodiment, a special value such as all 0s or all 1s is used to indicate all AP MLDs) to belong to the created UHR MAP group; the Link ID field 605b is set to (one or more) the ID of the target affiliated AP (in this embodiment, a special value such as all 1s is used to indicate all affiliated APs) to belong to the created UHR MAP group; the UHR MAP Action field 606b is set to 3, which indicates leaving the MAP group as an action; the UHR MAP Group ID field 607b is set to the MAP group ID value of the target MAP group to apply the action; the UHRMAPC subtype field 608b; and the UHR MAP Action Details field 609b are meaningless for this action and can be set to any value.

[0086] Fifth, MAP controller 100a may send a MAP group termination message 904b to MAP agent 100c. This message is a UHRMAP configuration request message, which includes a UHRMAP configuration TLV for instructing MAP agent 100c to leave the indicated MAP group. In detail, the UHR MAP configuration TLV 600b is included in the UHR MAP configuration request message, wherein: the AP MLD ID field 604b is set to (one or more) the ID of the target AP MLD (in this embodiment, a special value such as all 0s or all 1s is used to indicate all AP MLDs) to belong to the created UHR MAP group; the Link ID field 605b is set to (one or more) the ID of the target affiliated AP (in this embodiment, a special value such as all 1s is used to indicate all affiliated APs) to belong to the created UHR MAP group; the UHR MAP Action field 606b is set to 1, which indicates terminating the MAP group as an action; the UHR MAP Group ID field 607b is set to the MAP group ID value of the target MAP group to apply the action; the UHRMAPC subtype field 608b; and the UHR MAP Action Details field 609b are meaningless for this action and can be set to any value.

[0087] Figure 10Examples of communication devices configured to implement at least some embodiments of the present invention are illustrated schematically. These communication devices may correspond to reference [reference]. Figures 1 to 9b Any of the AP stations 100a, 100b, and 100c described. The communication device designated 1000 may preferably be a device such as a microcomputer, workstation, or portable device. Communication device 1000 may include a communication bus 1006, which may be connected to:

[0088] - A central processing unit 1001 labeled CPU, such as a processor; and a graphics processing unit optionally labeled GPU, which allows for the powerful computations required, especially for AIML operations.

[0089] - A memory 1003, designated MEM, is used to store executable code of the method or method steps according to embodiments of the present invention, and registers suitable for recording variables and parameters required to implement the method; and

[0090] - At least two communication interfaces 1002 and 1002' are connected to a wireless or wired communication network, for example, via transmit antenna 1004 and receive antenna 1004' respectively, to a communication network according to one of the IEEE 802.11 standard families, or via wired port 1005 to a communication network according to the IEEE 802.3 (Ethernet) standard, the IEEE 1901 standard, or the MoCA standard. For MAP controller 100a, one of these communication interfaces can act as a fronthaul AP function to provide wireless link 130a to non-AP STA 110a, and the other communication interface can act as a wired backhaul function to provide wired link 131a to MAP agent 100b. For MAP agent 100b, one of these communication interfaces can act as a fronthaul AP function to provide wireless links 130b and 131b to MAP agent 100c and non-AP STA 110b, and the other communication interface can act as a wired backhaul link 131a to communicate with MAP controller 100a. For MAP agent 100c, one of these communication interfaces can act as a fronthaul AP function to provide wireless link 130c to non-AP STA 110c, and the other communication interface can act as a backhaul STA function to connect to MAP agent 100b using wireless link 131b.

[0091] Preferably, the communication bus 1006 can provide communication and interoperability between various elements included in or connected to the communication device 1000. The representation of the bus is not limiting, and in particular, the central processing unit is operable to instruct any element of the communication device 1000 to communicate directly or by means of another element of the communication device 1000.

[0092] The executable code can be stored in memory, which can be a read-only hard disk or a removable digital medium (e.g., a disk). According to an alternative variation, the executable code of the program can be received via interface 1002 or 1002' through a communication network and stored in memory 1003 of communication device 1000 before being executed.

[0093] In some embodiments, the communication device 1000 may be a programmable device that implements embodiments of the present invention using software. However, alternatively, some embodiments of the present invention may be implemented wholly or partially in hardware (e.g., in the form of an application-specific integrated circuit or ASIC).

[0094] One or more embodiments of the present invention can also be implemented by a computer that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be more fully referred to as a "non-transitory computer-readable storage medium") to perform the functions of one or more of the above embodiments and / or includes one or more circuits (e.g., application-specific integrated circuits (ASICs)) for performing the functions of one or more of the above embodiments, and by a method performed by the computer of the system or device, for example, by reading and executing computer-executable instructions from the storage medium to perform the functions of one or more of the above embodiments and / or controlling one or more circuits to perform the functions of one or more of the above embodiments. The computer may include one or more processors (e.g., a central processing unit (CPU), a microprocessor unit (MPU)) and may include a network of separate computers or separate processors for reading and executing the computer-executable instructions. The computer-executable instructions may be provided to the computer, for example, from a network or storage medium. Storage media may include one or more of the following: hard disk, random access memory (RAM), read-only memory (ROM), storage device for distributed computing systems, optical discs (such as compact discs (CDs), digital multifunction discs (DVDs), etc.), flash memory devices, and memory cards.

[0095] When interpreting the specification and its related claims, expressions such as “comprising,” “containing,” “incorporating,” “including,” “is,” and “having” shall be interpreted in a non-exclusive manner, meaning that they are understood to allow for the presence of other items or components not explicitly defined. References to the singular shall also be interpreted as references to the plural, and vice versa.

[0096] Those skilled in the art will readily understand that the various parameters disclosed in the specification can be modified and the various disclosed embodiments can be combined without departing from the scope of the invention.

[0097] The names of TLVs, the fields included in TLVs, and the order of the fields described in this document are all examples and may have different names or be placed in different orders while providing the same functionality.

Claims

1. A communication method in a network including at least two access points, the communication method comprising: A frame according to the Wi-Fi EasyMesh standard is transmitted from a first access point to a second access point, the frame including information representing at least one Ultra-High Reliability (UHR) IEEE 802.11 technical capability and / or parameter of the first access point.

2. The method according to claim 1, wherein, The information indicating Ultra High Reliability (UHR) IEEE 802.11 technical capabilities and / or parameters is included in the UHR Operation Type Length Value (TLV) field and / or the UHR Capability TLV field.

3. The method according to any one of claims 1 and 2, wherein, Ultra-high reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to seamless roaming features.

4. The method according to any one of claims 1 to 3, wherein, Ultra-high reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to the characteristics of non-primary channel access (NPCA).

5. The method according to any one of claims 1 to 4, wherein, Ultra-high reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to dynamic subband operation (DSO) characteristics.

6. The method according to any one of claims 1 to 5, wherein, Ultra-high reliability (UHR) IEEE 802.11 technical capabilities and / or parameters correspond to the Multi-AP Coordination (MAPC) feature.

7. A communication method in a network including at least two access points, the communication method comprising: A frame according to the Wi-Fi EasyMesh standard is transmitted from a first access point to a second access point, the frame including configuration information representing configuration of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter of the second access point; as well as Using the second access point, the at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter of the second access point is configured according to the frames transmitted by the first access point.

8. The method according to claim 7, wherein, The configuration information representing the configuration of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter is included in the UHR Configuration Type Length Value (TLV) field, the UHR MAP Configuration TLV field, and / or the Channel Preference TLV field.

9. The method according to any one of claims 7 and 8, further comprising: The second access point sends configuration response information to the first access point, and the configuration response information is included in the UHR Configuration Response Type Length Value (TLV) field.

10. The method according to any one of claims 7 to 9, wherein, At least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Seamless Roaming feature.

11. The method according to any one of claims 7 to 10, wherein, At least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Non-Primary Channel Access (NPCA) feature.

12. The method according to any one of claims 7 to 11, wherein, At least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Dynamic Subband Operation (DSO) feature.

13. The method according to any one of claims 7 to 12, wherein, At least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the Multi-AP Coordination (MAPC) feature.

14. The method according to any one of claims 7 to 13, wherein, At least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the channel selection configuration.

15. The method according to any one of claims 7 to 14, wherein, At least one configuration information of at least one Ultra-High Reliability (UHR) IEEE 802.11 technical parameter corresponds to the UHR multi-AP group management configuration information.

Images