Method and device for Wi-Fi easymesh UHR extension

Abstract

A mesh network, such as Wi-Fi EasyMesh (RTM), comprising two or more access points, where an access point can transmit, in a frame, its IEEE 802.11 capability parameters to another access point using Wi-Fi EasyMesh (RTM). The frame comprises information representative of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies capability. The capability parameters may be transmitted in a Type Length Value (TLV) field. The capability parameter may be an IEEE 802.11 Seamless Roaming feature, Secondary Channel Access (SCA) feature, Dynamic Subband Operation (DSO) feature, or Multi-AP Coordination (MAPC) feature. Further an access point may configure itself according to the received capability parameters from another access point corresponding to the IEEE 802.11 features mentioned above.

Description

FIELD OF THE INVENTION The present invention relates to wireless communications and more specifically to Wi-Fi EasyMesh extension to support UHR features. BACKGROUND OF THE INVENTION The approaches described in this section could be pursued but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section. Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the 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 great number of mechanisms for wireless communications between stations. In addition, Wi-Fi Alliance provides certification programs to enhance the interoperability among IEEE 802.11 technology based wireless devices. Furthermore, Wi-Fi Alliance provides their original standards such as Wi-Fi EasyConnect, Wi-Fi Direct, Wi-Fi Aware to further enhance the usage of those devices. Wi-Fi EasyMesh is one of those protocols that defines the control protocols between APs which enables to securely onboard APs to the network, as well as provision, control and manage said APs. Wi-Fi EasyMesh has evolved along its multiple releases to support the underlying IEEE 802.11 standard’s updates. SUMMARY OF THE INVENTION An aim of the invention is to improve the Wi-Fi EasyMesh standard to support the evolution of its underlying IEEE 802.11 bn (UHR) technology. To this end, according to a first aspect, the present invention aims at a communication method in a network comprising at least two access points, the communication method comprising: transmitting a frame according to the Wi-Fi EasyMesh standard, by a first access point to a second access point, said frame comprising information representative of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter of said first access point. Such provisions allow for the simple configuration and use of multi-AP networks while benefitting from the capabilities ofthe Ultra High Reliability (UHR) IEEE 802.11 technologies. In particular embodiments, the information representative of Ultra High Reliability (UHR) IEEE 802.11 technologies capabilities and / or parameter is included in the UHR Operations TLV (Type Length Value) field and / or UHR Capabilities TLV field. In particular embodiments, an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Seamless Roaming feature. In particular embodiments, an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Secondary Channel Access (SCA) feature. In particular embodiments, an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Dynamic Subband Operation (DSO) feature. In particular embodiments, an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Multi-AP Coordination (MAPC) feature. According to a second aspect, the present invention aims at a communication method in a network comprising at least two access points, the communication method comprising: transmitting a frame according to the Wi-Fi EasyMesh standard, by a first access point to a second access point, said frame comprising configuration information representative of a configuration of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter of said second access point; and configuring, by the second access point, said at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter of said second access point as a function ofthe frame transmitted by the first access point. Such provisions allow for the simple configuration and use of multi-AP networks while benefitting from the capabilities ofthe Ultra High Reliability (UHR) IEEE 802.11 technologies. In particular embodiments, the configuration information representative of a configuration of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter is included in the UHR Configuration TLV (Type Length Value) field, UHR MAP Configuration TLV field, and / or Channel Preference TLV field. In particular embodiments, the method object ofthe present invention further comprises sending, by the second access point to the first access point, configuration response information, said information being included in a UHR Configuration Response TLV (Type Length Value) field. In particular embodiments, at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to the Seamless Roaming feature. In particular embodiments, at least one configuration information of at least one (UHR) IEEE 802.11 technologies parameter corresponds to the Secondary Channel Access (SCA) feature. In particular embodiments, at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to the Dynamic Subband Operation (DSO) feature. In particular embodiments, at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to the Multi-AP Coordination (MAPC) feature. In particular embodiments, at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to a Channel selection configuration. In particular embodiments, at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to a UHR Multi-AP Group management configuration information. BRIEF DESCRIPTION OF THE DRAWINGS Some embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which: - Figure 1 illustrates an example of a network system in which some embodiments of the invention may be implemented; - Figure 2 illustrates an example of a message sequences for Wi-Fi EasyMesh protocol between Multi-AP Controller and Multi-AP Agent according to some embodiments of the invention; - Figures 3a and 3b illustrate examples of a UHR Operations TLV and UHR Capabilities TLV according to some embodiments of the invention; - Figure 4 illustrates an example of UHR Operation field according to some embodiments of the invention; - Figure 5 illustrates an example of a UHR Capabilities field according to some embodiments of the invention; - Figure 6a, 6b and 6c illustrates examples of a UHR Configuration TLV field and UHR MAP Configuration TLV and UHR Configuration Response TLV according to some embodiments of the invention; - Figure 7 illustrates an example of a Preference field and Reason code field included in the Channel Preference TLV according to some embodiments of the invention; - Figure 8 illustrates, using a flowchart, an example of a UHR MAP Configuration procedure executed in the Multi-AP Controller, according to some embodiments of the invention; - Figure 9a and 9b illustrates an example of message sequences for Wi-Fi EasyMesh UHR Configuration and UHR MAP Configuration protocol between Multi-AP Controller and Multi-AP Agent according to some embodiments of the invention; and - Figure 10 illustrates an example of hardware configuration of both AP and non-AP STA, according to some embodiments of the invention. DESCRIPTION OF SOME EMBODIMENTS Figure 1 illustrates an example of a network system in which some embodiments of the invention may be implemented. For the sake of illustration, Figure 1 represents one Wi-Fi EasyMesh Network consists of six wireless devices: three access point station (AP) 100a, 100b and 100c and three non-AP station (non-AP STA) 110a, 110b and 110c. Of course, the number of APs and / or non-AP STAs may be different from this setup. The AP manages the set of non-AP STAs that together organize their accesses to the wireless medium, known as “operating channel”, for communication purposes. The stations (including the AP) form a service set, here below referred to as basic service set, BSS (although other terminology can be used). A same physical station acting as an access point may manage two or more BSS (and thus corresponding WLANs): each BSS is thus uniquely identified by a specific basic service set identification (BSSID) and managed by a separate virtual AP implemented in the physical AP. APs 100a, 100b and 100c provide wireless connections between stations of the BSS (e.g., for the BSS of AP 100a, including non-AP STA 110a and AP 100a) and provide an access to a wider network, such as the Internet. The connection of a non-AP STA to AP (e.g. 110a to 100a) may be performed by a standardized process called association. In Figure 1, STA 110a 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 respectively. Once a non-AP STA is associated with the AP, the non-AP STA can access the operating channel, send data over it to other stations of the BSS or to the wider network via the AP and receive data from other stations or from the wider network through the AP. The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium. Wi-Fi EasyMesh further provides a mean to connect multiple APs to form a Wi-Fi EasyMesh network. Wi-Fi EasyMesh network consists of one Multi-AP Controller (MAP Controller) and one or more Multi-AP Agent (MAP Agent). A Multi-AP Controller is a logical entity that implements logic for controlling the fronthaul APs and backhaul links in the Multi-AP network. A MAP Agent is a logical entity that performs the commands received from the MAP Controller, and feedback measurements and capabilities data for fronthaul APs, clients and backhaul links to a MAP Controller and / or to other MAP Agents. One physical device may collocate both MAP Controller and MAP Agent. The MAP Controller and the MAP Agent can form a Wi-Fi EasyMesh Network on top of IEEE 1905.1 network. IEEE 1905.1 provides an abstraction layer on top of 4 different MAC / PHY networks including IEEE 802.3 (Ethernet), IEEE 802.11 (WLAN), IEEE 1901 (BPL: broadband over power lines) and MoCA (Multimedia over Coax Alliance). The MAP Agent may have a Backhaul STAthat can connect to Fronthaul AP which is setup by the other MAP Controller or MAP Agent. Or the MAP Agent may have logical Ethernet port (which may provide wired connection to one of Ethernet, BPL, MoCA) to connect to other logical Ethernet port in the other MAP Controller or MAP Agent. In Figure 1, AP 100a is configured as a MAP Controller with collocated MAP Agent, and AP 100b and AP 100c are configured as MAP Agents. AP 100b is connected to AP 100a with wired link 131 a which can be based on one of IEEE 802.3, IEEE 1901 or MoCA link with the support of IEEE 1905.1 features. It should be noted that the description is contextualized but not limited to IEEE 802.3 link for the link 131a. The AP 100c is connected to AP 100b with wireless link 131b which is based on IEEE 802.11 link with the support of IEEE 1905.1 features as well. This setup of EasyMesh Network is one example and not restrictive of any other setups. The APs 100a, 100b and 100c may comprise, be implemented as, or known as a 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 terminology. It can be a standalone product, or it may be integrated in a device, for instance in a broadband remote access server (BRAS). The non-AP STAs 110a, 110b and 110c may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, a user equipment (UE), a user station (STA), or some other terminology. In some implementations, a non-AP STA may be or may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or a 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 that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station 110a may be a wireless node. Such a wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. Figure 2 illustrates exemplary message sequences for Wi-Fi EasyMesh protocol between the Multi-AP Controller 100a and the Multi-AP Agent 100c according to some embodiments of the invention. Such a sequence is also applicable to the message sequences between the MAP Controller 100a and the MAP Agent 100b. The only difference between these two scenarios is that the MAP Controller 100a and the MAP Agent 100b can directly communicate with each other via Ethernet link 131a, which is simpler than the case between the MAP Controller 100a and the MAP Agent 100c which requires bypass through the MAP Agent 100b. Wi-Fi EasyMesh provides means of MAP Onboarding 200, MAP Discovery 201, MAP Capability exchange 202, MAP Configuration 203 and MAP Control 204 respectively. All of these protocols run on top of IEEE 1905.1 network. Thanks to this, 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 each other through the MAP Agent 100b. To begin with, MAP Onboarding 200 enables the MAP Agent 100c to securely join the MAP Network that is managed by the MAP Controller 100a. MAP Onboarding can be performed by two alternative means: PBC onboarding using an extension to the 1905 PBC onboarding method defined in Wi-Fi EashMesh Specification or DPP onboarding using the DPP protocol defined in the Wi-Fi EasyConnect Specification. During this onboarding procedure, the MAP Controller 100a shares the Wi-Fi parameters such as SSID, Authentication type, Encryption type, Network Key, BSSID to the MAP Agent 100c. After the MAP Onboarding 200, the MAP Agent 100c performs MAP Discovery 201 to discover the MAP Controller 100a. The MAP Agent 100c sends extension of 1905 AP-Autoconfiguration Search message including TLVs defined in Wi-Fi EasyMesh specification. This message is sent as Relayed Multicast message which will be forwarded among different network interfaces (i.e. from IEEE 802.11 link 131b to Ethernet link 131a) through the MAP Agent 100b so that it can reach the MAP Controller 100a. The MAP Controller 100a then responses to the MAP Agent 100c with 1905 AP-Autoconfiguration Response message through the MAP Agent 100b as well. With this MAP Discovery 201, the MAP Controller and the MAP Agent discover each other and are ready to communicate further for the MAP Capability exchange 202, MAP Configuration 203 or MAP Control 204. The described order of these three procedures is not limitative and other implementations may be used. After MAP Discovery 201, the MAP Agent may perform MAP Capability exchange 202 to exchange its Capability with the MAP Controller 100a. MAP Capability exchange 202 is performed based on AP Capability Query and AP Capability Report messages. The MAP Device (including both the MAP Controller and the MAP Agent) can send AP Capability Query and the received MAP Device responds with AP Capability Report message. Inside the AP Capability Report messages, the MAP Device can include multiple TLVs which conveys the various types of capability information. In the present document, new TLVs dedicated are proposed to inform the UHR capabilities relevant to UHR Capabilities Information Element and / or UHR Operation Information Element which may be specified in the IEEE 802.11 bn (UHR) specification. The contents of each TLV are proposed later in the description. AP Capability exchange may be performed earlier than MAP Capability exchange 202 for example included in one of the MAP Onboarding 200 or MAP Discovery 201 procedure. Knowing the capability of the MAP Agent 100c by the MAP Capability exchange 202 or any other means, the MAP Controller 100a may perform MAP Configuration 203 to configure the MAP Agent 100c. If the DPP onboarding method is used in MAP Onboarding 200, the MAP Configuration 203 may be executed during the MAP Onboarding 200 using the BSS Configuration Response message including the TLVs specifying the configuration information sent from the MAP Controller 100a to the MAP Agent 100c. Otherwise, to initiate (re)configuration, the MAP Agent 100c sends a 1905 AP-Autoconfiguration WSC message including M1, which is defined in Wi-Fi Protected Setup Specification, to the MAP Controller 100a indicating the radio that the MAP Agent 100c wants to configure by the Radio Unique Identifier in the AP Radio Basic Capabilities TLV. The MAP Controller 100a receives this message and responds with another 1905 AP-Autoconfiguration WSC message including M2, which is defined in Wi-Fi Protected Setup Specification, and other TLVs that contains various configuration information which configures the MAP Agent who is the recipient of this message. In the present description, it is proposed to include new configuration information dedicated to the features which may be specified in the IEEE 802.11 bn (UHR) specification. Based on the exchanged or pre-shared capability information relevant 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 proposed in this description such as, in a non-limitative manner, UHR Operations TLV, UHR Capabilities TLV, UHR Configuration TLV and UHR MAP Configuration TLV. The contents of TLVs relevant to UHR configuration are proposed later in this description. The MAP Controller 100a may execute the MAP Control 204 to further control the MAP Agent 100c. The MAP Control 204 includes, in a non-limitative manner, Channel selection, Link metric collection, Client steering, Backhaul optimization, Traffic separation and Service prioritization. Channel selection feature enables the MAP Controller 100a to request the MAP Agent 100c to switch its operating channel. The MAP Controller 100a can ask the MAP Agent 100c for its channel preference using the Channel Preference Query Message and the MAP Agent 100c responds with Channel Preference Report message including the Channel Preference TLV. The MAP Controller 100a can request the channel switching by sending the Channel Selection Request message which also includes Channel Preference TLV to the MAP Agent 100c. Then the MAP Agent 100c responds with Channel Selection Response message indicating the acceptance or not. If the MAP Agent 100c accepts the request from the MAP Controller, the MAP Agent switches its operating channel and then feedbacks an Operating Channel Report message. Utilizing UHR Capabilities, and / or UHR Operation information proposed in this description, the MAP Controller 100a and the MAP Agent 100c may change its channel preference to achieve a better channel distribution for UHR Multi-AP Coordination purpose. This description also proposes updates of Channel Preference TLV to express this preference. For example, in one embodiment, multiple UHR supporting APs may be gathered in a specific channel to benefit from the UHR Multi-AP Coordination features. And other non-UHR APs may be gathered in the other channel not to interfere with the UHR supporting APs. The contents of Channel Preference TLV are proposed later in this description. Figures 3a illustrates examples of a UHR Operations TLV according to some embodiments of the invention. The name of the TLV is not limited to “UHR Operations TLV” and, for example, can correspond to a Wi-Fi 8 Operations TLV. UHR AP devices supports AP MLD (Multi-Link Device) as defined in the IEEE 802.11 be D5.0 standard. The AP MLD can support one or more affiliated AP which operates in a link. AP MLD can support one or more radio channel where one or more links operate on. Reference 300a corresponds to the basic format of TLV consists of tlvType field 301a, tlvLength field 302a and tlvValue field 303a. tlvType field 301 a is a one-byte field which identifies the type of the TLV. The tlvLength field 302a is a 2 bytes field which identifies the number of bytes in the tlvValue field 303a. The tlvValue field 303a includes the value specific to its type. Each TLV has its own format for the tlvValue field 303a. For UHR Operations TLV, the tlvValue field 303a consists of Radio Number field 304a and N Radio Value fields. N is indicated in the Radio Number field 304a and indicates the number of radio channel this TLV want to configure. The Radio Value field 305a is the first Radio Value field and reference 306a may include one or more remaining Radio Value field. The Radio Value field 305a further consists of Radio ID field 307a which uniquely identifies the radio, and M BSS Value fields. M is indicated in the BSS Number field 306a. The BSS Value field 307a is the first BSS Value field and reference 308a may include one or more remaining BSS Value field. The BSS Value field 307a further consists of BSSID 309a which identifies the BSS, and the UHR Operation field 310a. Any other fields not indicated here may be added inside the tlvValue field 303a. The UHR Operations TLV can be included, in a non-limiting manner, in the AP Capability Report message, BSS Configuration Request message, BSS Configuration Response message, BSS Configuration Result message, Channel Selection Request message, Operating Channel Report message, Channel Preference Report message. Figure 3b illustrates an example of a UHR Capabilities TLV according to some embodiments of the invention. The name of the TLV is not limited to “UHR Capabilities TLV” and, for example, can correspond to Wi-Fi 8 Capabilities TLV. The function of references 300b to 307b is the same as references 300a to 307a respectively. Radio Value field 305b consists of Radio ID field 307b and UHR Capabilities field 308b. Any otherfields not indicated here may be added inside the tlvValue field 303b. UHR Capabilities TLV can be included, in a non-limiting manner, in the AP Capability Report message and BSS Configuration Request message. Figure 4 illustrates an example of a UHR Operation field according to some embodiments of the invention. The UHR Operation field 310a included in the UHR Operations TLV 300a corresponds to the UHR Operation field 400. In one embodiment, UHR Operation field 400 may be the copy of the UHR Operation Information Element which may be specified in IEEE 802.11 bn specification excluding the Element ID field, Length field and Element ID Extension field. UHR Operation field 400 may at least contain one of UHR Operation Parameters field 401, Basic UHR-MCS And Nss Set field 402 and UHR Operation Information field 403, UHR MAP Group Info field 404. It can further include one or more additional fields 405 which are not specified in this document. The UHR Operation Parameters field 401 further may include one or more field(s) that indicates the presence of a specific field that may be included in the UHR Operation Information field 403. If the presence of a specific field indicates “present" by setting to 1, this indicates the specific field is present in the UHR Operation information field 403. Otherwise, by setting to 0, this indicates the specific field is not present int the UHR Operation information field 403. The Basic UHR-MCS and Nss Set field 402 indicates the UHR-MCSs for each number of spatial streams in UHR PPDUs that are supported by all UHR STAs in the BSS (including IBSS and MBSS) for transmission and reception. UHR Operation Information field 403 may include information fields relevant to the new channel usage specified in the IEEE 802.11 such as channel centre frequency for a UHR BSS, the bandwidth of the UHR BSS, channel puncturing information of the UHR BSS, distributed-tone RU (DRU) information, Secondary Channel (or Non-Primary Channel) Access information and / or Dynamic Subband Operation information but not limited to these. UHR MAP Group Info field 404 includes information of zero or more UHR MAP Group(s) the UHR device belongs to. This may further include UHR MAP Group ID number field 406 which indicates the number of indicated groups and UHR MAP Group ID field 407 for each UHR MAP Group ID. A UHR MAP Group is a group where UHR APs may belong. Some of the UHR MAPC may be limited to be performed inside the UHR MAP Group. For example, for the Seamless Roaming feature, users of the UHR APs may want to limit the seamless roaming inside the specific UHR MAP Group which user manages and not to let the UHR STA roam to APs which are not in the specified UHR MAP Group. One UHR AP may belong to multiple UHR MAP Groups simultaneously. The format of the UHR MAP Group ID is not limited to the one disclosed herein if it the specific group can be uniquely identified. One may envisage, in particular embodiments, to use a format such as MAC Address (e.g. of the owner of the MAP group) or a string information similar to SSID. In one embodiment, the MAC Address of one of the AP MLD or its affiliated AP may be used as a UHR MAP Group ID. UHR MAP Group Detail field 408 may include the further detailed information for the corresponding UHR MAP Group indicated by the UHR MAP Group ID field 407 such as enabled MAPC Subtype in the group. UHR MAP Group Info field 404 may further include one or more additional fields 409 which are not specified in this document. Figure 5 illustrates exemplary of UHR Capabilities field according to some embodiments of the invention. The UHR Capabilities field 308b included in the UHR Capabilities TLV 300b corresponds to the UHR Capabilities field 500. In one embodiment, the UHR Capabilities field 500 may be the copy of the UHR Capabilities Information Element which may be specified in IEEE 802.11bn specification excluding the Element ID field, Length field and Element ID Extension field. UHR Capabilities field 500 may at least contain one of the Multi-AP Coordination Capabilities 501, SCA Capabilities 502, DSO Capabilities field 503 and / or Seamless Roaming Capabilities field 504. It can further include one or more other fields 505 which is not specified in this document. Multi-AP Coordination Capabilities 501 may include information that indicates the support of Multi-AP Coordination subtypes. One bit or more may be assigned to one subtype to indicate the support (e.g. 0: not supported, 1: supported) or to further indicate the level of support (e.g. 0: not supported, 1: supported but with a limited capability, 2: fully supported) or may further have one or more subfields to indicate the detail of its capability as the case for Seamless Roaming Capabilities field 504. Support of any kind of UHR Multi-AP Coordination subtypes may be included in this MAPC Capabilities field 501 such as Coordinated OFDMA, Coordinated TDMA, Coordinated (r)TWT, Coordinated MIMO, Coordinated Beamforming, Coordinate Spatial Reuse, Coordinated Transmission (Joint Transmission) and Coordinated Roaming (Seamless roaming). UHR Multi-AP Coordination subtypes shown here are examples and not limited to these. SCA Capabilities 502 includes the capabilities relevant to the Secondary Channel Access (SCA) Operation. It is also called as Non-primary Channel Access (NPCA) Operation. SCA Operation is a feature considered in IEEE 802.11 bn scope to utilize the secondary (or nonprimary) channel for the medium access when the primary channel is busy. SCA Capabilities 502 may include subfields that indicate the support of SCA Operation feature (e.g. 0: not supported, 1: supported), transmitter capability (e.g. maximum channel numbers) or type relevant to SCA Operation, receiver capability (e.g. maximum channel numbers) or type relevant to SCA Operation, available channel information for SCA operation, switching delay for the secondary channel switch, priority of the preferred secondary channel but not limited. DSO Capabilities 503 includes the capabilities relevant to Dynamic Subband Operation (DSO). DSO is a feature considered in IEEE 802.11 bn scope to utilize the secondary channel for the medium access when the BSS provides wider bandwidth than the non-AP STA supports. For example, when a BSS provides 320MHz bandwidth and a non-AP STA only supports 160MHz, BSS may dynamically allow the non-AP STA to switch to the secondary 160MHz and conduct the medium access. DSO Capabilities 503 may, in particular embodiments, include subfields that indicate the support of DSO feature (e.g. 0: not supported, 1: supported), transmitter capability (e.g. maximum channel numbers) or type relevant to DSO, receiver capability (e.g. maximum channel numbers) or type relevant to DSO, available channel information for DSO, switching delay for the secondary channel switch. The Seamless Roaming Capabilities field 504 includes the capabilities relevant to the Seamless Roaming feature. This field may not be present if Seamless Roaming coordination subtype is not indicated as supported in the Multi-AP Coordination Capabilities field. Seamless Roaming is one of the Multi-AP Coordination subtype which is discussed in the IEEE 802.11 bn task group. The Seamless Roaming feature is aimed to maintain the data continuity during the roaming procedure of the associated non-AP STA from one AP MLD to another non-collocated AP MLD. In one embodiment, Upper MAC (UMAC) and Lower MAC (LMAC) capability information may be included in the Seamless Roaming Capabilities field 504. UMAC, LMAC separation is a feature considered in IEEE 802.11 bn scope to flexibly distribute the UMAC and LMAC features separately into non-collocated devices. In particular embodiments, UMAC may have features such as Authentication, Association, Sequence Number (SN) and Packet Number (PN) assignment, Encryption / Decryption, BA buffering and reordering per SN, Replay detection PerPN. Duplicate detection and Block Ack Scoreboarding may also be an UMAC feature but it depends on whether TID-to-link mapping of specific TID is allowed among the links of multiple non-collocated AP MLD. UMAC / LMAC Capabilities field 506 may include the support of UMAC features (e.g. 0: not supported, 1: supported), support of LMAC features (e.g. 0: not supported, 1: supported). It may further include subfields that indicate detailed level of capabilities for each feature such as Authentication, Association, SN and PN assignment, Encryption / Decryption, BA buffering and reordering per SN, Replay detection Per PN, Duplicate detection and Block Ack Scoreboarding. Separating UMAC and LMAC features in non-collocated APs requires a mean to communicate the IEEE 802.11 context information such as SN (Sequence Number) and PN (Packet Number) between UMAC AP and LMAC AP. This context information can be encapsulated on top of IEEE 1905.1 abstraction layer, using the messages defined in Wi-Fi EasyMesh specification to pass through the Multi-AP Network. In the other embodiment, SMD (Seamless Mobility Domain) capability information may be included in the Seamless Roaming Capabilities field 504. SMD is a logical control plane entity considered in IEEE 802.11 bn scope to realize the Seamless Roaming feature. Instead of having the UMAC, LMAC separation, context information is transferred from the source AP to the target AP when the roaming is going to happen. Context information may include PN, SN, STA capabilities, BA (Block Ack) agreements, SCS (Stream Classification Service) information, QoS Characteristics information, TWT (Target Wake Time) information, and negotiated TID-to-Link Mapping information but not limited to these. SMD covers the group of AP MLDs where the associated non-AP MLDs can roam with the Seamless Roaming feature. SMD Capabilities field 507 may include support of the SMD feature itself (e.g. 0: not supported, 1: supported), whether the AP MLD is possible to participate to a new SMD (e.g. 0: impossible, 1: possible), and whether the AP MLD is possible to be removed from the current SMD (e.g. 0: impossible, 1: possible). As well in the UMAC, LMAC case, IEEE 802.11 context information can be encapsulated on top of IEEE 1905.1 abstraction layer, using the messages defined in Wi-Fi EasyMesh specification to pass through the Multi-AP Network. Other elements not described in this document may be added in field 508. In particular embodiments, UMAC / LMAC Capabilities field 506 and SMD Capabilities field 507 may both exist in the Seamless Roaming Capabilities field 504, or only one of them may exist. In these embodiments, all these capabilities can be included into one UHR Capabilities field 308b which is included in the UHR Capabilities TLV. However, one or more of the capabilities fields included in reference 500 may be separated into dedicated TLV or included in the other existing or new TLVs and attached to the message respectively. Figure 6a illustrates an example of a UHR Configuration TLV according to some embodiments of the invention. UHR Configuration TLV is a new Multi-AP TLVs format proposed in this document. The name of the TLV is not limited to “UHR Configuration TLV” and could correspond to a Wi-Fi 8 Configuration TLV for example. This can be included in the 1905 AP-Autoconfiguration WSC (M2) message, 1905 AP-Autoconfiguration Renew message, 1905 Topology Response message, BSS Configuration Response message, BSS Configuration Result message, but not limited to these and it may be included in any other existing or newly defined messages. For example, new Multi-AP message formats which include this TLV may be defined in the Wi-Fi EasyMesh specification such as the UHR Configuration Request message or the UHR Configuration Response message. Using these messages, the MAP Agent can indicate to the MAP Controller its status of UHR configurations, and the MAP Controller can configure one or more UHR configurations of the MAP Agent. The function of references 600a to 603a is the same as references 300a to 303a respectively. The tlvValue field 603a consists of AP MLD ID field 604a, Link ID field 605a, MAPC Config field 606a, SCA Config field 607a, DSO Config field 608a, Seamless Roaming Config field 609a and zero or more field 610a which are not specified in this document. The AP MLD ID 604a identifies which AP MLD the config is targeted to. This can be done, for example, by indicating the AP MLD MAC address. If the config is targeted to all of the AP MLDs the MAP Agent has, this field may 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 config is targeted to. This can be done, for example, by indicating the Link ID value which is defined in 35.3.3.2 Link ID of IEEE 802.11 be D5.0. If the config is targeted to all of the affiliated APs of the indicated AP MLD, this field may indicate a special value (e.g. all bit 1: value 15) to indicate such a target. The MAPC Config field 606a includes the configuration information for Multi-AP Coordination. The SCA Config field 607a includes the configuration information for Secondary Channel Access. The DSO Config field 608a includes the configuration information for Dynamic Subband Operation. The Seamless Roaming Config field 609a may include the configuration information for Seamless Roaming feature. The Seamless Roaming Config field 609a may further include subfields such as the UMAC / LMAC Config field which configures the UMAC / LMAC features, or the SMD Config field which configures the SMD features. In one embodiment, configuration information 606a, 607a, 608a and 609a may contain the same frame format of the Capabilities fields 501 to 504. In this case, the formats of Capabilities fields 501 to 504 are reused for the configuration purpose. For example, the Multi-AP Coordination Capabilities field 501 for MAPC Config field 606a, the SCA Capabilities field 502 for SCA Config field 607a, the DSO Capabilities field 503 for DSO Config field 608a and the Seamless Roaming Capabilities field 504 for Seamless Roaming Config field 609a respectively. Each bit included in the Config fields 606a to 609a can be used to configure the MAP Agent. For example, if the corresponding capability bit indicates the support of a feature (e.g. 1 for support and 0 for no support), the MAP Controller may set the corresponding config bit to 1 to enable the corresponding capability or set to 0 to disable the corresponding capability. In the other example, if the corresponding capability bit(s) indicates the range of a feature (e.g. maximum channel number), the corresponding capability field can be set to a specific number to be configured. The configuration should be affordable when the corresponding capability for the capability bit indicates that the feature is supported in the MAP Agent. Also, the configuration should not exceed the ability of the MAP Agent which is indicated in the capability field (e.g. if the maximum channel number is 4, config should be set with 4 or less). Any other fields not indicated here may be added inside the tlvValue 603a. In another embodiment, configuration information 606a, 607a, 608a and 609a may include not the same frame format of the Capabilities fields and instead, include the format of UHR Operation field 310a. Furthermore, it may have dedicated format (e.g. omitting one or more fields) to reduce the size of configuration information. In these embodiments, all these configuration fields can be included into one UHR Configuration TLV 600a. However, one can envisage a different embodiment wherein one or more of the configuration fields included in 600a may be separated to dedicated TLV or included in the other existing or new TLVs and attached to the message respectively. Figure 6b illustrates exemplary of UHR MAP Configuration TLV according to some embodiments of the invention. The name of the TLV is not limited to “UHR MAP Configuration TLV” and could correspond, for example, to a Wi-Fi 8 MAP Configuration TLV. The purpose of the UHR MAP Configuration TLV is to further configure the UHR Multi-AP features of MAP Agents by the MAP Controller to perform MAP relevant actions such as create MAP group, terminate MAP group, join MAP group, leave MAP group, enable / disable MAP subtype. These may be performed during the MAP Configuration 203 procedure. This TLV can be included in the 1905 AP-Autoconfiguration WSC (M2) message, 1905 AP-Autoconfiguration Renew message, 1905 Topology Response message (extended), BSS Configuration Response message, BSS Configuration Result message, and it may be included in any other existing or newly defined messages. For example, new Multi-AP message formats which include this TLV may be defined in the Wi-Fi EasyMesh specification such as UHR MAP Configuration Request message, UHR MAP Configuration Response message. The function of references 601 b to 603b is the same as references 601a to 603a respectively. The tlvValue field 603b may consist of AP MLD ID field 604b, Link ID field 605b, UHR MAP Action field 606b, UHR MAP Group ID field 607b, UHR MAPC Subtype field 608b, UHR MAP Action Detail field 609b and may have other fields not specified in this document in 610b. The function of references 604b and 605b is the same as references 604a and 605a respectively. The DHR MAP Action field 606b indicates the action the MAP Controller requests for the MAP Agent to perform. In one embodiment, actions such as create MAP group (0), terminate MAP group (1), join MAP group (2), leave MAP group (3), enable / disable MAP subtype (4) can be defined and assigned action values as indicated in the parenthesis. The MAP Controller specifies an action value in the UHR MAP Action field 606b to request the corresponding action to the MAP Agent. The UHR MAP Group ID field 606b identifies the target UHR MAP group to perform the requested action. UHR Multi-AP coordination may have specific coordination inside a specific group of APs. This group can be called an UHR MAP group. One AP may belong to multiple UHR MAP groups to have multiple coordination in parallel. In this case, UHR MAP groups need to be identified. UHR MAP Group ID field 607b is used to identify this UHR MAP group. If the UHR MAPC Subtype field 608b indicates the Seamless Roaming subtype, the UHR MAP Group ID field may indicate the SMD ID which uniquely identifies the SMD. The UHR MAPC Subtype field 608b indicates the target UHR MAP Coordination subtype to perform the requested action. This field may indicate one or more UHR MAP Coordination subtypes such as Coordinated OFDMA (0), Coordinated TDMA (1), Coordinated (r)TWT (2), Coordinated MIMO (3), Coordinated Beamforming (4), Coordinate Spatial Reuse (5), Coordinated Transmission (Joint Transmission) (6) and Coordinated Roaming (Seamless roaming) (7) assigning subtype values as indicated in the parenthesis. The Multi-AP Coordination subtypes shown here are examples and not limited to these. MAP Controller specifies an UHR MAPC subtype value in the UHR MAPC Subtype field 608b to indicate the corresponding subtype as the target of the specified action to the MAP Agent. In other embodiments, the UHR MAPC Subtype field 608b may include a bitmap format where each bit corresponds to one of the UHR MAP Coordination subtype. Using the bitmap format, the corresponding action specified in the UHR MAP Action field 606b applies to all of the subtypes which indicate high (or low) in the bitmap. UHR MAP Action Detail 609b may contain further detailed information for the requested action. For example, the valid time duration of the requested action may be specified (after the valid time duration the action will be invalid e.g., the enabled subtype will be disabled without any request) or the delay bound of the requested action which indicates till when the action has to be performed may be specified or the existing AP numbers in the specified UHR MAP Group may be indicated. UHR MAP Action Detail field 609b may have a dedicated parameters corresponding to the action indicated in the UHR MAP Action field 606b and / or to the subtype indicated in the UHR MAPC Subtype field 608b. Any other fields may be added in 610b to further extend the tlvValue 603b field. Figure 6c illustrates an example of a UHR Configuration Response TLV according to some embodiments of the invention. The name of the TLV is not limited to “UHR Configuration Response TLV” and could correspond, for example, to a Wi-Fi 8 Configuration Response TLV. The purpose of the UHR Configuration Response TLV is to indicate the acceptance or rejection of the UHR Configuration or UHR MAP Configuration from the MAP Agents to the MAP Controller by including this TLV into a response message. This TLV can be included in the 1905 AP-Autoconfiguration WSC message or in any other existing or newly defined messages. For example, new Multi-AP message formats which include this TLV may be defined in the Wi-Fi EasyMesh specification such as UHR Configuration Response message or UHR MAP Configuration Response message. The function of references 601c to 603c is the same as references 601a to 603a respectively. The tlvValue field 603c may consist of AP MLD ID field 604c, Link ID field 605c, Response Code field 606c, Preferred Config field 607c and may have other fields not specified in this document in 608c. The function of references 604b and 605b is the same as references 604a and 605a respectively and these fields indicate which AP MLD and which affiliated AP the Response corresponds to. Reference 600c may include multiple 603c fields to indicate multiple responses having different Response Codes (e.g. partially acceptance and remaining rejection). The Response Code field 606c includes the code which indicates the result of the configuration. The result may include at least acceptance (0), rejection (1) and may further extended having for example rejection with preferred configuration (2). The Preferred Config field 607c may be included when the Response Code is set to rejection with preferred configuration (2) to indicate the preferred configuration from the MAP Agent 100c. The Preferred Config field 607c may include the UHR Configuration TLV 600a or UHR MAP Configuration TLV 600b to indicate the preferred configuration. Figure 7 illustrates an example of a Preference field and Reason code field included in the Channel Preference TLV according to some embodiments of the invention. Reference 700 corresponds to the update of the existing Reason Code definition in the latest Wi-Fi EasyMesh Specification. The proposed updates are shown in the row 701 and 702. All the other rows remain as it is in the latest Wi-Fi EasyMesh Specification. Reference 701 corresponds to the update on Preference field to declare the most preferred channel using the value 1111. This allows MAP Devices to declare the most preferred channel with the Reason Code. Reference 702 corresponds to the update on Reason Code field to express the preference reason as UHR Multi-AP Coordination purpose using the value 1101 for instance. Using these two updates, MAP Devices can declare the most preferred channels with the reason of UHR Multi-AP Coordination. Figure 8 illustrates, using a flowchart, an example of a UHR Configuration procedure executed in the MAP Controller, according to some embodiments of the present invention. This flowchart is triggered when the MAP Controller a MAP Controller wants to (re)configure an MAP Agent. In step 800, the MAP Controller checks if the MAP Agent, which the MAP Controller wants to (re)configure, supports UHR features or not. This can be done by checking the existence of UHR Operations TLV and / or UHR Capabilities TLV exchanged during the MAP Capability exchange 202 procedures. If at least one of those TLVs exists, it means the MAP Agent supports UHR features. This information including the detailed information of each UHR capability may be saved in the memory to easily refer it when the (re)configuration is triggered. In step 801, if the MAP Agent supports UHR, proceed to step 802. Otherwise proceed to step 804 and perform the legacy Configuration and / or Control which is based on the latest Wi-Fi EasyMesh Specification and end the flowchart. In step 802, MAP Controller collects the information to optimize the UHR configuration for the MAP Agent. This information may consist of the capability of the MAP Controller itself, UHR Operations TLV and / or UHR Capabilities TLV collected from the one or more MAP Agents, Link metric information collected by the one or more MAP Agents, or any other information which may contribute to the optimization. Using this information the MAP Controller decides the optimal configuration and / or Control of the UHR MAP Agent. In step 803, MAP Controller performs the UHR Configuration and / or Control using at least one of the UHR Operations TLV, UHR Configuration TLV, UHR MAP Configuration TLV and / or Channel Preference TLV proposed in this document. Figure 9a illustrates an example of a message sequence for Wi-Fi EasyMesh UHR Configuration protocol between Multi-AP Controller and Multi-AP Agent according to some embodiments of the present invention. This sequence is included in the MAP Configuration 203 procedure shown in Figure 2. In this embodiment, UHR Configuration 901a is performed first to configure the basic UHR configuration and then, UHR MAP Configuration 902a is performed to operate the UHR Multi-AP Group management. UHR MAP Configuration 902a is further described using the Figure 9b. This embodiment shows the exemplary scenario where the MAP Controller 100a configures the MAP Agent 100c to activate only the SMD features of the Seamless Roaming features and deactivates all other UHR features for all of the affiliated APs of all of the AP MLDs that exist in the MAP Agent 100c. For UHR Configuration 901a, the MAP Controller 100a sends UHR Configuration TLV 600a to the MAP Agent 100c which may be included in one of the existing Wi-Fi EasyMesh Multi-AP message formats such as 1905 AP-Autoconfiguration WSC (M2) message, 1905 AP-Autoconfiguration Renew message, 1905 Topology Response message (extended), BSS Configuration Response message, BSS Configuration Result message, or in a newly defined Wi-Fi EasyMesh Multi-AP message format such as UHR Configuration Request message that at least includes one or more UHR Configuration TLVs. In this embodiment, the UHR Configuration Request message is used to convey the UHR Configuration TLV. In this embodiment, the AP MLD ID 604a has the special value (e.g. all 0 or all 1) to indicate the configuration is targeted to all AP MLDs. Link ID 605a has the special value (e.g. all 1: value 15) to indicate the configuration is targeted to all affiliated APs. MAPC Config 606a has the value with all 0 (i.e. deactivation) except the bit for Seamless Roaming. The bit for Seamless Roaming has value 1 (i.e. activation). The SCA Config field 607a and DSO Config field 608a have the value with all 0 (i.e. deactivation). Seamless Roaming Config field 609a field has the value with 1 (i.e. activation) for the bits relevant to SMD feature and other to 0 (i.e. deactivation). The MAP Agent 100c receives this UHR Configuration TLV 600a and may accept or reject the indicated configuration and responds a message including UHR Configuration Response TLV 600c to the MAP Controller 100a indicating the acceptance or rejection in the Response Code field 606c. If MAP Agent 100c accepts it, the MAP Agent 100c configures its UHR features as indicated in the received UHR Configuration TLV 600a. The response message may be one of the existing Wi-Fi EasyMesh Multi-AP message formats such as 1905 AP-Autoconfiguration WSC or may be a newly defined Wi-Fi EasyMesh Multi-AP message format such as UHR Configuration Response message that at least includes one or more UHR Configuration Response TLVs. For UHR MAP Configuration 902a, the MAP Controller 100a sends UHR MAP Configuration TLV 600b to the MAP Agent 100c which may be included in one of the existing Wi-Fi EasyMesh Multi-AP message formats such as 1905 AP-Autoconfiguration WSC (M2) message, 1905 AP-Autoconfiguration Renew message, 1905 Topology Response message (extended), BSS Configuration Response message, BSS Configuration Result message, or in a newly defined Wi-Fi EasyMesh Multi-AP message format such as UHR MAP Configuration Request message that at least includes one or more UHR MAP Configuration TLVs. In the other embodiment, the UHR Configuration Request message used in 901a may be reused to include UHR MAP Configuration TLV. In this embodiment, the UHR MAP Configuration Request message may be used to convey the UHR MAP Configuration TLV. the UHR MAP Configuration 902a procedure can be further detailed using the exemplary message sequences 900b to 904b shown in Figure 9b. The UHR MAP Configuration 902a procedure is performed to operate the UHR Multi-AP (MAP) Group management including operations such as UHR MAP Group creation / termination, adding a new AP into the UHR MAP group, removing an existing AP from the UHR MAP group, UHR MAPC subtype activation / deactivation in the UHR MAP group. The UHR MAP group is a group of APs that support the UHR MAPC features. The UHR MAP group may be used to determine the scope of coordination between the UHR APs supporting the UHR MAPC features. At first, the MAP Controller 100a may send a Create Group message 900b to the MAP Agent 100c. This message is a UHR MAP Configuration Request message which includes the UHR MAP Configuration TLV that indicates the configuration the MAP Agent 100c to create the indicated MAP Group. In detail, UHR MAP Configuration TLV 600b is included in the UHR MAP Configuration Request message with the AP MLD ID field 604b set to the ID of targeted AP MLD(s) (use special value such as all 0 or all 1 to indicate all AP MLDs in this embodiment) to belong to the created UHR MAP Group, Link ID field 605b set to the targeted affiliated AP(s) (use special value such as all 1 to indicate all affiliated APs in this embodiment) to belong to the created UHR MAP Group, UHR MAP Action field 606b set to 0 which indicates create MAP group as an action, the UHR MAP Group ID field 607b set to the group ID value of the target UHR MAP Group or the value of SMD ID which the new UHR MAP Group uses as its ID or the MAP Controller may let the MAP Agent to decide the new UHR MAP Group ID by indicating a special value (e.g. all 0 or all 1), UHR MAPC Subtype field 608 with the bit corresponding to Seamless Roaming subtype to high (1) and others to low (0), UHR MAP Action Detail 609b field to the detail configuration of the Seamless Roaming configuration. The MAP Agent 100c receives this UHR MAP Configuration TLV 600b included in UHR MAP Configuration Request messages (900b, 901b, 902b, 903b and 904b) and may accept or reject the indicated MAP configuration and may respond a message including UHR Configuration Response TLV 600c to the MAP Controller 100a indicating the acceptance or rejection in the Response Code field 606c. If the MAP Agent 100c accepts it, the MAP Agent 100c configures its UHR features as indicated in the received UHR MAP Configuration TLV 600b. The response message may be one of the existing Wi-Fi EasyMesh Multi-AP message formats such as 1905 AP-Autoconfiguration WSC or may be a newly defined Wi-Fi EasyMesh Multi-AP message format such as the UHR MAP Configuration Response message that at least includes one or more UHR Configuration Response TLVs. Secondly, the MAP Controller 100a may send a Join MAP Group message 901b to the MAP Agent 100c. This message is a UHR MAP Configuration Request message which includes the UHR MAP Configuration TLV that indicates the configuration the 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 with AP MLD ID field 604b set to the ID of targeted AP MLD(s) (use special value such as all 0 or all 1 to indicate all AP MLDs in this embodiment) to belong to the created UHR MAP Group, Link ID field 605b set to the targeted affiliated AP(s) (use special value such as all 1 to indicate all affiliated APs in this embodiment) to belong to the created UHR MAP Group, UHR MAP Action field 606b set to 2 which indicates join MAP group as an action, UHR MAP Group ID field 607b set to the group ID value of the target UHR MAP Group or the value of SMD ID which identifies the SMD the MAP Agent is targeted to join, UHR MAPC Subtype field 608 with the bit corresponding to Seamless Roaming subtype to high (1) and others to low (0), UHR MAP Action Detail 609b field to the detail configuration of the Seamless Roaming configuration. If the MAP Agent 100c is joining to an existing UHR MAP Group, the group ID may be known to the MAP Controller 100a by any means. One example to know the existing group ID is to gather the information from UHR MAP Group ID(s) field 404 of the UHR Operations TLV 300a from the MAP Agents. Join MAP Group message 901 b may be skipped if Create MAP Group message 900b also triggers the Join MAP Group action. Thirdly, the MAP Controller 100a may send an Enable / Disable MAP Subtype message 902b to MAP Agent 100c. This message is a UHR MAP Configuration Request message which includes the UHR MAP Configuration TLV that includes the UHR MAP Configuration TLV which indicates the configuration of the MAP Agent 100c to enable the indicated MAP Subtype. In detail, the UHR MAP Configuration TLV 600b is included in the UHR MAP Configuration Request message with AP MLD ID field 604b set to the ID of targeted AP MLD(s) (use special value such as all 0 or all 1 to indicate all AP MLDs in this embodiment) to belong to the created UHR MAP Group, Link ID field 605b set to the targeted affiliated AP(s) (use special value such as all 1 to indicate all affiliated APs in this embodiment) to belong to the created UHR MAP Group, UHR MAP Action field 606b set to 4 which indicates enable / disable MAP subtype as an action, UHR MAP Group ID field 607b set to the MAP Group ID value of the targeted MAP Group to apply this action, UHR MAPC Subtype field 608 with the bits corresponding to the subtypes targeted to enable to high (1) and targeted to disable to low (0), UHR MAP Action Detail 609b field to the detail configuration of the subtypes targeted to enable. By sending this Enable MAP subtype message 901b, the MAP Controller 100a can dynamically configure the enabled MAP subtypes of the MAP Agent 100c. Fourthly, the MAP Controller 100a may send a Leave MAP Group message 903b to the MAP Agent 100c. This message is a UHR MAP Configuration Request message which includes the UHR MAP Configuration TLV that indicates the configuration the 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 with AP MLD ID field 604b set to the ID of targeted AP MLD(s) (use special value such as all 0 or all 1 to indicate all AP MLDs in this embodiment) to belong to the created UHR MAP Group, Link ID field 605b set to the targeted affiliated AP(s) (use special value such as all 1 to indicate all affiliated APs in this embodiment) to belong to the created UHR MAP Group, UHR MAP Action field 606b set to 3 which indicates leave the MAP group as an action, the UHR MAP Group ID field 607b set to the MAP Group ID value of the targeted MAP Group to apply this action, UHR MAPC Subtype field 608 and UHR MAP Action Detail 609b field don’t have a meaning on this action and may be set to any value. Fifthly, the MAP Controller 100a may send a Terminate MAP Group message 904b to the MAP Agent 100c. This message is a UHR MAP Configuration Request message which includes the UHR MAP Configuration TLV that indicates the configuration the 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 with AP MLD ID field 604b set to the ID of targeted AP MLD(s) (use special value such as all 0 or all 1 to indicate all AP MLDs in this embodiment) to belong to the created UHR MAP Group, Link ID field 605b set to the targeted affiliated AP(s) (use special value such as all 1 to indicate all affiliated APs in this embodiment) to belong to the created UHR MAP Group, UHR MAP Action field 606b set to 1 which indicates terminate MAP group as an action, the UHR MAP Group ID field 607b set to the MAP Group ID value of the targeted MAP Group to apply this action, UHR MAPC Subtype field 608 and UHR MAP Action Detail 609b field does not have a meaning on this action and may be set to any value. Figure 10 schematically illustrates an example of a communication device, which may correspond to any of the AP stations 100a, 100b and 100c described in reference to Figures 1 to 9, of a wireless network, configured to implement at least some embodiments of the present invention. The communication device, referenced 1000, may preferably be a device such as a micro-computer, a workstation, or a light portable device. Communication device 1000 may comprise a communication bus 1006 to which may be connected: - a central processing unit 1001, such as a processor, denoted CPU; and optionally a graphics processing unit, denoted GPU which allows powerful computation especially required for AIML operation - a memory 1003, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and - at least two communication interfaces 1002 and 1002’ connected to the wireless or wired communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 1004 and 1004’, respectively or communication network according to the IEEE 802.3 (Ethernet) standard or the IEEE 1901 standard or the MoCA standards, via wired port 1005. For MAP Controller 100a, one of the communication interfaces may work as an fronthaul AP function which provides wireless link 130a to non-AP STA 110a and the other may work as a wired backhaul function which provides wired link 131a to MAP Agent 100b. For MAP Agent 100b, one of the communication interfaces may work as a fronthaul AP function which provides wireless link 130b and 131 b to MAP Agent 100c and non-AP STA 110b and the other may work as a wired backhaul link 131a to communicate with MAP Controller 100a. For MAP Agent 100c, one of the communication interfaces may work as a fronthaul AP function which provides wireless link 130c to non-AP STA 110c and the other may work as an backhaul STA function to connect to MAP Agent 100b with the wireless link 131 b. Preferably, communication bus 1006 may provide communication and interoperability between the various elements included in the communication device 1000 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1000 directly or by means of another element of the communication device 1000. The executable code may be stored in a memory that may either be read only, a hard disk, or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1002 or 1002’, in order to be stored in the memory 1003 of communication device 1000 before being executed. In some embodiments, communication device 1000 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, some embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Embodiment(s) of the present invention can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g. one or more programs) recorded on a storage medium (which may also be referred to more fully as a “non-transitory computer-readable storage medium”) to perform the functions of one or more of the above-described embodiments) and / or that includes one or more circuits (e.g. application specific integrated circuit (ASIC)) for performing the functions of one or more of the above-described embodiments), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the abovedescribed embodiment(s) and / or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). The computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium. The storage medium may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), etc.), a flash memory device, a memory card, and the like. Expressions such as “comprise”, “include”, “incorporate”, “contain”, “is” and “have” are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural and vice versa. A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed may be combined without departing from the scope of the invention. All of the names of the TLVs and fields included in the TLVs, and the order of the fields described in this document are examples and can be different name or placed in a different order if the functions provided by them remain as equivalent.

Claims

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

2. Method according to claim 1, in which the information representative of Ultra High Reliability (UHR) IEEE 802.11 technologies capabilities and / or parameter is included in the UHR Operations TLV (Type Length Value) field and / or UHR Capabilities TLV field.

3. Method according to any one of claims 1 or 2, in which an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Seamless Roaming feature.

4. Method according to any one of claims 1 to 3, in which an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Secondary Channel Access (SCA) feature.

5. Method according to any one of claims 1 to 4, in which an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Dynamic Subband Operation (DSO) feature.

6. Method according to any one of claims 1 to 5, in which an Ultra High Reliability (UHR) IEEE 802.11 technologies capability and / or parameter corresponds to the Multi-AP Coordination (MAPC) feature.

7. A communication method in a network comprising at least two access points, the communication method comprising:transmitting a frame according to the Wi-Fi EasyMesh standard, by a first access point to a second access point, said frame comprising configuration information representative of a configuration of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter of said second access point; andconfiguring, by the second access point, said at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter of said second access point as a function of the frame transmitted by the first access point.

8. Method according to claim 7, in which the configuration information representative of a configuration of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter is included in the UHR Configuration TLV (Type Length Value) field, UHR MAP Configuration TLV field, and / or Channel Preference TLV field.

9. Method according to any one of claims 7 or 8, which further comprises sending, by the second access point to the first access point, configuration response information, said information being included in a UHR Configuration Response TLV (Type Length Value) field.

10. Method according to any one of claims 7 to 9, in which at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to the Seamless Roaming feature.

11. Method according to any one of claims 7 to 10, in which at least one configuration information of at least one (UHR) IEEE 802.11 technologies parameter corresponds to the Secondary Channel Access (SCA) feature.

12. Method according to any one of claims 7 to 11, in which at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to the Dynamic Subband Operation (DSO) feature.

13. Method according to any one of claims 7 to 12, in which at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to the Multi-AP Coordination (MAPC) feature.

14. Method according to any one of claims 7 to 13, in which at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to a Channel selection configuration.

15. Method according to any one of claims 7 to 14, in which at least one configuration information of at least one Ultra High Reliability (UHR) IEEE 802.11 technologies parameter corresponds to a UHR Multi-AP Group management configuration information.

Images