Method and apparatus for P2P group communication with multi-link devices

Abstract

The present invention concerns a method for configuring a peer-to-peer (P2P) wireless network comprising configuring a first affiliated non-Access Point station, non-AP STA 110, of a P2P non-AP Multi Link Device, MLD 210, to advertise multilink capabilities of the P2P MLD for establishing a P2P connection with a second non-AP station 230 of a second non-AP MLD 220. Advertising multilink capabilities may occur during discovery and association processes. The advertising comprises transmitting a P2P MLD information attribute in management frames such as beacon frames, Probe response frames, association response frames, group owner GO negotiation request frames, GO negotiation response frames or P2P invitation request and response frames.

Description

FIELD OF THE INVENTION The present invention relates generally to communication networks and more specifically to Peer-to-Peer (P2P) communication methods in wireless network comprising a plurality of stations clustered into a plurality of multi-link entities, one of these multi-link entities playing the role of an access point, the other multi-link entities being connected to the access point and corresponding devices. The invention finds application in particular to the access of an 802.11be / bn and Wi-Fi Direct standard network. BACKGROUND OF INVENTION 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 multipleaccess 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 Institute of Electrical and Electronics Engineers (IEEE) in the 802.11 be standard, draft version 5.0 (D5.0) of November 2023, namely EHT standing for “Extremely High Throughput,” is being considering a feature called multi-link operation (MLO), wherein a single device can support multiple links and the data of the device can be delivered to another device through the multiple links. The multi-link feature can increase the peak / average throughput of the device. The multi-link capability is negotiated during the initial association between a non-AP station and the intended AP. A multi-link device is a station comprising several affiliated stations. Each affiliated station is dedicated to handling one link for the station. An Access Point multi-link device (AP MLD) is a multi-link device, wherein each affiliated station (STA) within the MLD is an AP. A non-AP multi-link device (non-AP MLD) is a multi-link device, wherein each affiliated station within the MLD is a non-AP STA. An affiliated STA provides link-specific, lower medium access protocol (MAC) services within the MLD. Driven by the desire of users to easily connect their devices, the Wi-Fi Alliance introduced a Wi-Fi Direct (WFD) standardization and certification programs to provide an improved way for devices to connect to each other using their Wi-Fi interfaces without using traditional infrastructure services. Wi-Fi Direct specification provides simple Access Point functionality to allow connection of Wi-Fi devices (e.g., restricted regarding the supported number of connections compared to a hardware-AP). It is used for P2P communications. Wi-Fi Direct was released in 2010 and, even subsequently evolved since, still relies on old version of 802.11 amendments (up to 802.11 ax). The Wi-Fi Direct Specification does not support multiple links offered by recent 802.11 devices. With the fast-growing market for wireless display, device share &collaboration, and emerging XR technology, there is a strong demand to improve Wi-Fi Direct technology with the latest and greatest Wi-Fi technologies that provide higher throughput and robust communication. Indeed, the use of multiple links could offer great improvement for P2P communications and user experience, especially for enhancing discovery and communication performances. SUMMARY OF THE INVENTION The present invention has been devised to address one or more of the foregoing concerns. The aim is to provide support for the Wi-Fi Direct specification to form a P2P group operating multiple links. According to a first embodiment, there is provided a method for configuring a peer-to-peer (P2P) wireless network comprising: configuring a first affiliated non-Access Point, non-AP, station of a P2P non-AP Multi Link Device, MLD, to advertise multilink capabilities of the P2P MLD for establishing a P2P connection with a second non-AP station. Accordingly, the established P2P network may use the multilink capability of the MLD. Other features and embodiments of the method are: - advertising the multilink capabilities occurs during discovery and association processes; - advertising the multilink capabilities comprises transmitting a P2P MLD information attribute in management frames, such as Beacon frames, Probe Response frames, Association Response frames, Group Owner, GO, Negotiation Request frames, GO Negotiation Response frames, GO Confirmation Response frames, P2P Invitation Request frames and P2P Invitation Response frames; - the P2P MLD information attribute is included into a P2P Information Element; - the P2P MLD information attribute comprises information of affiliated station interfaces that the P2P MLD is concurrently able to operate as P2P communication; - the P2P MLD information attribute comprises the maximum number of affiliated stations of the P2P MLD which supports simultaneous transmission or reception of frames on their respective links; - the P2P MLD information attribute comprises a list of link information fields associated with the simultaneous links supported by the P2P MLD; - the link information fields comprise an information that the link cannot be used for a P2P communication, an information that the link is a primary link or an information that the link is a discovery link; - when the P2P MLD information attribute is conveyed in a Beacon or ML Probe Request frame, the link information fields refer to the detailed station profile contained into a basic multi-link element present in that frame; - a P2P Device Address of the P2P MLD advertised in a P2P IE to uniquely reference the P2P Device, is set as the MLD MAC address advertised in Multi-link element of management frames and the P2P interface address of the P2P MLD, advertised in the P2P IE for communication on a link, is set to the address of the affiliated station of the P2P MLD operating on the link; - when the P2P MLD is the group owner of the P2P network, the SSID of the P2P network is set to the SSID of the P2P MLD and the SA and BSSID of the group are set to the P2P interface address of the P2P MLD; - the P2P MLD which is the group owner of the P2P network maintains a social channel for discovery and association purpose on a link operated by one of its affiliated STA; - during negotiation protocol for defining the group owner of the P2P network, the negotiation protocol provides for an election scheme considering the multilink capability of the P2P MLD; and / or - the negotiation protocol defines as P2P Group Owner, the P2P MLD comprising the greatest number of available links, the greatest number of available bands or a combination thereof. According to a second aspect of the invention, there is provided a computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method as disclosed hereabove, when loaded into and executed by the programmable apparatus. According to a third aspect of the invention, there is provided a computer-readable storage medium storing instructions of a computer program for implementing a method as disclosed hereabove. According to a fourth aspect of the invention, there is provided a computer program which upon execution causes the method as disclosed hereabove to be performed. According to a fifth aspect of the invention, there is provided a non-access point, AP, multi-link device, MLD, comprising a first affiliated non-Access Point, non-AP, station configured to advertise multilink capabilities of the MLD for establishing a P2P connection with a second non-AP station. An embodiment of the fifth aspect comprises that the non-AP MLD comprises a P2P management module and a MAC layer controller which interacts one with the other to establish and process communications in between multiple MLD non-AP stations forming a P2P group according to the method disclosed hereabove. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, or microcode) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit”, “module” or “system”. Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer-readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal, or an electromagnetic signal, e.g., a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates a typical wireless communication system in which embodiments may be implemented; Figures 2a and 2b illustrate an example of a multi-link arrangement in accordance with 802.11 be; Figure 3a illustrates the process of forming a P2P group; Figure 3b illustrates the frame format for establishing a P2P group; Figure 4a shows a schematic representation of a non-AP H-MLD communication device in embodiments; Figure 4b illustrates schematically the architecture of the communication device of Figure 4a; Figure 5 illustrates exemplary format of a P2P information attribute according to an embodiment; Figure 6a, 6b and 6c illustrate the list of P2P attributes for a P2P IE and frame organization; Figure 7 illustrates the format of beacon or response frames sent by a P2P MLD acting as group owner; Figure 8 illustrates the main steps of a method for configuring multiple links in a P2P network; Figure 9 illustrates 3 examples of connectivity in a P2P network; and Figures 10a-10d illustrate different embodiments for the group owner election. DETAILED DESCRIPTION The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and SingleCarrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize different directions to simultaneously transmit data belonging to multiple user terminals. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminals. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal subcarriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localised FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise a non-access point station (so-called non-AP station). While the examples are described in the context of Wi-Fi (RTM) networks, the teaching may be used in any type of wireless networks like, for example, mobile phone cellular networks that implement very similar mechanisms. An AP may comprise, be implemented as, or known as a Node B, Radio Network Controller (“RNC”), evolved Node B (eNB), 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. A non-AP station may comprise, be implemented as, or known as a subscriber’s station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a non-AP station 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 smart phone), 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 medium. In some aspects, the non-AP station may be a wireless node. Such 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. An AP manages a set of stations that together organize their accesses to the wireless medium 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 BSSs (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. On the other hand, in ad hoc networks, no infrastructure AP that provides medium access control (i.e., a dedicated router forming required infrastructure for the infrastructure network) is needed. A station of the ad hoc network is elected as the group owner (GO) or soft AP (standing for software enabled access point) to emulate some of the AP functionalities and services (e.g., discovery procedure through transmission of Beacon frames and Probe Response frames). The ad hoc network is mainly used for direct connectivity, hence communication, between peer stations. An exemplary application of the ad hoc networks includes Wi-Fi Direct. The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium. The current discussions in the task group 802.11 be, as illustrated by draft IEEE P802.11be / D5.0 of November 2023, introduce the Multi-Link Operation (MLO) when it comes to MAC layer operation. The MLO allows multi-link devices to establish or setup multiple links and operate them simultaneously. A multi-link device (MLD) is a logical entity and has more than one affiliated (AP or non-AP) station (STA) and has a single medium access control (MAC) service access point (SAP) to logical link control (LLC), which includes one MAC data service. Besides, the MLD also comprises a single address associated with the interface, which can be used to communicate on the distribution system medium (DSM). The stations forming the same MLD may be partly or all collocated within the same device or geographically dispersed. An access point multi-link device (AP MLD) corresponds to a MLD where each station (STA) affiliated with the MLD is an AP, referred to as “affiliated AP” hereinafter. A non-access point multi-link device (non-AP MLD) corresponds to a MLD where each station (STA) affiliated with the MLD is a non-AP station, referred to as “affiliated non-AP station”. When referring hereinafter to either an AP MLD or a non-AP MLD, the general term “station MLD” may be used. Depending on the literature, “multilink device”, “ML device” (MLD), “multilink logical entity”, “ML logical entity” (MLE), “multilink set” and “ML set” are synonyms to designate the same type of ML device. Multiple affiliated non-AP STAs of a non-AP MLD can then setup communication links with multiple affiliated APs of an AP MLD, hence forming a multi-link channel. This is for instance done through the conventional association procedure: ML Discovery including passive scanning (ML beacons) or active scanning (ML Probe Request and corresponding Response), following by ML Authentication and finally by ML Setup where the non-AP MLD associates with the AP MLD (hence obtained an Association IDentifier, AID) and sets up the ML links for its affiliated non-AP STAs with the APs affiliated with the AP MLD. The links established (or “enabled links”) for MLDs are theoretically independent, meaning that the channel access procedure (to the communication medium) and the communication are performed independently on each link. Hence, different links may have different data rates (e.g., due to different bandwidths, number of antennas, etc.) and may be used to communicate different types of information (each over a specific link). A communication link or “link” thus corresponds to a given channel (e.g., 20 MHz, 40 MHz, and so on) in a given frequency band (e.g., 2.4 GHz, 5 GHz, 6 GHz) between an AP affiliated with the AP MLD and a non-AP STA affiliated with the non-AP MLD. The affiliated APs and non-AP STAs operate on their respective channels in accordance with one or more of the IEEE 802.11 standards (a / b / g / n / ac / ad / af / ah / aj / ay / ax / be / bn) or other wireless communication standards. Thanks to the multi-link aggregation, traffic associated with a single MLD can theoretically be transmitted across multiple parallel communication links, thereby increasing network capacity and maximizing utilization of available resources. The terms “traffic” and / or “traffic stream(s)” as used herein, are defined as a data flow and / or stream between wireless devices. Figure 1 illustrates a wireless communication system in which several communication station devices 101-107, 110 exchange data frames over a radio transmission channel 100 of a wireless local area network (WLAN), under the management of a central station in the network infrastructure, namely access point device (AP) 110. This is known as the infrastructure mode. Direct communications between STAs (e.g., between STA2 and STA4) can also be implemented without the use of such an infrastructure access point. It is known as the ad hoc mode. The radio transmission channel 100 is defined by an operating frequency band constituted by a single channel, a plurality of channels forming a composite channel, or a plurality of distinct channels (links) forming a multi-link operation. In the following description, the term “station” or “STA” may be used to describe a non-AP station operating on a given link of 100, which may be a standalone non-AP station or an affiliated non-AP station entity of a non-AP MLD device. Similarly, the term “AP” describes an AP station operating on a given link, which may be a standalone AP station or an affiliated AP station entity of an AP MLD device. Exemplary situations of direct communications, corresponding to an increasing trend nowadays, include the presence of peer-to-peer (P2P, also known as Direct Link or “DiL”) transmissions in between non-AP stations, e.g., STA 102 and STA 104 as illustrated by Figure 1. Technologies that support P2P transmissions are for example WiFi-Miracast (RTM) or Wireless Display scenario, or Tunneled Direct Link Setup (TDLS). Note that even if P2P flows are usually not numerous, the amount of data per flow may be huge (typically low-compressed video, from 1080p60 up to 8K UHD resolutions). Each STA 101-107 registers to the AP 110 during an association procedure. During the association procedure, the AP 110 assigns a specific Association IDentifier (AID) to the requesting STA. For example, the AID is a 16-bit value uniquely identifying the STA. When the AP and non-AP STA are respectively an affiliated AP of a ML AP device and an affiliated non-AP of a ML non-AP device, they establish a ML association wherein a unique AID is assigned to the entire non-AP MLD: all affiliated non-AP STAs are identified by the same AID value on their respective operation link. The stations 101-107, 110 may compete on a given link one against the other using EDCA (Enhanced Distributed Channel Access) contention, to access the wireless medium to be granted a transmission opportunity (TXOP) and then transmit (single user, SU) data frames. The stations may also use a multi-user (MU) scheme in which a single station, usually the AP 110, is allowed to schedule a MU transmission, i.e., multiple simultaneous transmissions to or from other stations, in the wireless network. One implementation of such a MU scheme has been for example adopted in IEEE Std 802.11ax-2021 standard, as the Multi-User Uplink and Downlink OFDMA (MU UL and DL OFDMA) procedures. Figure 2a illustrates a block diagram example of a multi-link arrangement in accordance with 802.11 be, in which a Multi-Link logical entity or device may be seen as a collection of two or more STAs; each STA operating on a specific link (frequency band) and comes with its own link specific PHY and lower MAC layer. An “AP multi-link device” (AP MLD) is a multi-link device, wherein each affiliated STA is an AP. A client STA multi-link device (non-AP MLD) is a multi-link device, wherein each affiliated STA is a non-AP STA. It should be noted that the term “multi-link set” may be used in some descriptions herein, but the scope of embodiments is not limited by this terminology. Other terminology may be used, in some cases, including but not limited to a multi-link logical entity (MLE), a multi-link AP logical entity (MLE AP), a multi-link non-AP logical entity (MLE STA or non-AP MLE STA), multi-link device (MLD), a multi-link AP device (MLD AP), a multi-link non-AP device (MLD STA or non-AP MLD STA) and / or other. As illustrated by Figure 2a, multiple APs 110-x / y / z are included in a multi-link AP logical entity or device 210. In addition, multiple STAs 230-x / y / z are included in a multilink non-AP logical entity or device 220. The APs 110-x, 110-y, 110-z and / or the STAs230-x, 230-y, 230-z operate in accordance with one or more of IEEE 802.11 a / b / g / n / ac / ad / af / ah / aj / ax / be, or another wireless communication standard. In some embodiments, an affiliated AP 110-a may be configured to operate in a frequency band that is different from a frequency band of at least one of the other affiliated APs 110-b of the plurality of APs. In some embodiments, an affiliated AP 110-a may be co-located with at least one of the other affiliated APs 110-b of the plurality of affiliated APs enclosed in the MLE AP 210. In some embodiments, multiple affiliated APs are collocated in an AP device 210 that supports simultaneous operations to one or more non-AP devices 220. Between the AP210 device and one non-AP device 220, there are different interfaces related to links 201,202, 203. The AP MLD210 may also be in communication with other systems (e.g., a distribution system [DS] such as a local area network and / or wide-band network) via an interface 120, such as a backhaul interface (typically an Ethernet Link). In MLD operation, simultaneous transmit and receive (STR) operation may be allowed. That is, while one link is transmitting, another link is receiving. Non-AP MLDs maybe STR or non-simultaneous transmit and receive (NSTR). Recently, 802.11 be introduced the concept of non-simultaneous transmit and receive (NSTR) soft access point (AP) multi-link device (MLD). The term NSTR mobile AP MLD is also used. In general, a soft AP represents a software enabled AP and implies a software enabling a device which has not been specifically made to be a router into a wireless AP. IEEE 802.11 be defines mechanisms to support the operation of a Non-STR AP MLD in release 1 (R1). The mechanisms are limited to instantiate a Non-STR Non-AP MLD as a Soft AP that could utilize all its links under AP-like operation: If a non-AP MLD intends to operate as an AP MLD, this device becomes the soft AP MLD. However, when a non-AP MLD is a non-STR MLD defined in IEEE 802.11 TGbe, it imposes some issues for the soft AP MLD operation due to the restriction that the non-AP MLD cannot transmit and receive simultaneously on the non-STR link pair. This soft-AP MLD is in a mobile device that is typically battery powered. Soft AP is a mechanism allowing a non-AP MLD station to be temporally turned to adopt AP functionality. A soft AP has typically limited capacity compared to a regular AP. The limitation may regard the bandwidth, the number of stations that can connect to the soft AP. In a non-ML context, an example of soft AP is the connection sharing functionality of modern smartphones. It is to be noted that a soft AP MLD has all its affiliated station adopting the AP behaviors. Figure 2b illustrates, using frame exchanges in a timeline, an exemplary scenario for discovery and association process between a non-AP MLD or non-AP STA and an AP MLD. The example involves STA A1 101 (either affiliated to the non-AP MLD 220 as station 220-b or being a single-link non-AP station) and AP1 110-x affiliated to the AP MLD 110. The following description is referring to Multi-Link procedures, in a way that Beacon and Probing frames contain Multi-Link Information element(s) introduced by 802.11 be. Legacy devices (prior to 802.11 be) are still able to understand those frames, but will ignore the ML Information elements. The discovery phase is referred to as a ML discovery procedure, and the multilink setup phase (or association phase) is referred to as a ML setup procedure. Management frames exchanged during the ML discovery and ML setup procedures contain a new Information Element specific to the Multi-Link Operation (MLO), referred to as Basic Multi-Link element, which conveys a description of the affiliated STA entities of the MLD sending the frame that are additional to the sending affiliated STA entity (known as “reporting STA”). More precisely, the profile of the reporting STA is provided in Information Elements, lEs, of the frame outside the Basic Multi-Link element. The Basic Multi-Link element carries one or more Per-STA Profile sub element(s) corresponding to each additional affiliated STA (known as “reported STA”) within the same MLD. The ML discovery procedure allows the non-AP MLD to discover the wireless communication network 100, i.e., the various links to the AP MLD offered by the multiple affiliated APs. The ML discovery procedure thus seeks to advertise the various affiliated APs of the AP MLD, together with the respective network information, e.g., including all or part of capabilities and operation parameters. The discovery may be based on active or passive scanning. In an active scanning, a non-AP STA transmits a Probe Request frame 212 (with a wildcard SSID) and waits for a Probe Response frame 213 from an AP. The active discovery process thus mainly relies on the exchange of Probe Request and Probe Response frames between an AP and a non-AP. For ML discovery, the discovery procedure may be performed either by using a Probe Request / Response frame exchange per link or one ML Probe Request / Response frame exchange carrying all the information of the various APs affiliated to the AP MLD on one of the available links. In the passive scanning, the non-AP STA listens on each channel for Beacon frames 211 periodically sent by an AP on its operating channel and then transmits a Probe Request frame 212 with the SSID (retrieved from the Beacon frames) corresponding to an AP of interest. When sent by a non-AP MLD for instance non-AP MLD 101 through the STA A1 220-b, a Probe Request frame 212 allows the affiliated non-AP station to request an affiliated AP (AP1 110-x; “reporting AP”) to include, in addition to its network information, the complete or partial set of capabilities and operation elements (i.e., network information) of the other APs affiliated with the same AP MLD (“reported APs”) 110. When sent by an AP MLD for instance AP MLD 110 through the AP1 110-x, a Beacon frame 211 or a Probe Response frame 213 includes both a Basic Multi-Link element carrying one or more Per-STA Profile subelement(s) which describe network information of the other (“reported”) APs affiliated to the AP MLD and a Reduced Neighbor Report (RNR) element describing reduced network information about the same “reported” APs. Current 802.11 be revision defines two configurations for the Basic Multi-Link element, regarding respectively the Beacon and Probe Response frames. A first type is used for Beacon frames in which the Basic Multi-Link element carries only information that is common to all reported APs (communication interfaces). The common information is conveyed in a so-called Common Info field of the Basic MultiLink element. For instance, this includes the MLD MAC address, the set of enabled links, or the STR capability. A second type is used for the Probe Response frames in which the Basic MultiLink element carries, in addition to the common information (Common Info field), partial or complete profile (i.e., network information) of those reported APs different from the advertising one (reporting AP). The profile of each reported AP is conveyed through an individual and independent field, known as Per-STA Profile field. Current 802.11 be revision also defines a specific Multi-Link element, so-called Probe Request Multi-Link element, regarding the Probe Request frames to which Probe Response frames can be sent by the AP MLD. The Probe Request Multi-Link element is used to request a reporting AP to provide information (complete or partial profile) of other (reported) APs affiliated with the same AP MLD as the reporting AP. The Probe Request Multi-Link element includes Per-STA Profile fields for each requested reported AP. To avoid such a situation, it has been provided in 802.11 be to reuse the Reduced Neighbor Report (RNR) element already defined in 802.11v, as mentioned above, to announce, as soon as the Beacon frames, some basic information about the other interfaces (than the transmitting one) of the same AP MLD. 802.11v defines the use of the RNR information element to include information about a neighbor AP. This is currently used to offer out-of-band discovery by informing clients about 6 GHz APs: the “neighbor AP” is actually the 6 GHz radio housed in the same AP along with the 2.4 GHz and 5 GHz radios. 6 GHz clients will thus learn about the available 6 GHz radio from the RNR information in either Beacon or Probe Response frames sent by the AP’s 2.4 and 5 GHz radios. By using the RNR element in the Multi-Link environment, a station can directly probe the AP MLD to request the complete profile (capabilities, parameters and operation elements) of their other interfaces (reported APs). As a result, a non-AP MLD can use the information gathered from the Reduced Neighbor Report element and the Basic Multi-Link element (from Beacon and Probe Response frames) to decide whether to perform a multi-link setup with the AP MLD. Air-time occupancy of management frames, as well as, the time required by the station to pass from the discovery process to the multi-link setup can then be reduced. Figures 3a and 3b illustrate Wi-Fi Direct modes of operation. Wi-Fi Direct is a direct communication technology that may enable devices to be easily connected with each other without the AP basically required in a conventional WLAN system. According to Wi-Fi Direct, devices may be connected to each other without a complicated establishment procedure (device-to-device connectivity). Wi-Fi Direct enables Wi-Fi devices to connect directly to each other, making it simple and convenient to print, share, sync, play games, and display content to another device. WiFi Direct devices connect to one another without having to join a traditional home, office, or public network. Devices can make a one-to-one connection, or a group of several devices can connect simultaneously. The Wi-Fi operating peer-to-peer (P2P) mode refers to a mode where each party has the same capabilities and either party can initiate a communication session. More generally, a P2P Device is a Wi-Fi Direct device that is capable of acting as both a P2P Group Owner (hence acting like a soft AP) and a P2P Client. The P2P Client role implements non-AP STA functionality. The P2P Group Owner has a role which is similar to the AP role providing BSS functionality and services for associated Clients (P2P Clients or Legacy Clients). Wi-Fi Direct devices have been designed in the context of 802.11a, g, or n. Therefore, Wi-Fi Direct does not benefit from recent 802.11 be technology, such as multilink operation. Figure 3a illustrates the process of forming a P2P group. A Wi-Fi Direct connection is mainly performed through three processes including a device discovery, a service discovery and group establishment. The Device Discovery facilitates two P2P Devices arriving on a common channel and exchanging device information. The Service Discovery is an optional feature that allows a P2P Device to discover available higher-layer services prior to forming a connection. The Group Formation or Establishment is used to determine which device will be the P2P Group Owner and form a new P2P Group. Device discovery The Device Discovery process 300 is required when Wi-Fi P2P devices, for example, a first and a second P2P devices 301, 302, have to recognize each other to configure a connection and to establish the Wi-Fi P2P group. In this phase, each of the P2P devices alternates between a listen state and a search state. A first P2P device searches for neighboring Wi-Fi P2P devices by repeatedly performing channel scans of IEEE 802.11 channels by listening to predefined channels, known as “social channels”, defined as channel 1, 6 and 11 in the 2.4 GHz band, and by searching these channels for a predetermined period. This phase is used to ensure that two simultaneously searching P2P Devices arrive on a common channel to enable communication. This is achieved by cycling between states where the P2P Device waits on a fixed channel for Probe Request frames (in the Listen State) or sends Probe Request frames on a fixed list of channels (in the Search State). Convergence of two devices on the same channel is assisted by randomizing the time spent in each cycle of the Listen State. In other words, the exchanges of Probe Request and Probe Response frames enable the P2P devices to discover each other on a nearby environment. Service discovery The optional service discovery procedure 310 is performed after the Device Discovery process to provide a function of exchanging information on services that each P2P device can support. That is, each P2P device may identify a supportable service protocol, a service and the like through exchange of a request message and a response message 340. P2P Devices thus exchange queries to discover the set of available services and, based on this, decide whether to continue the group formation or not. In other words, this procedure can be used to determine compatibility information on the services offered by a P2P Device. Group generation The Group Formation or Creation procedure 311 is a negotiation process to agree on a group owner (GO) for the P2P group being established. It is performed by a three-way exchange of a GO negotiation request 344, a GO negotiation response 345, and a GO negotiation confirm frame 346, whereby the two devices agree on which device will act as P2P GO, the other one acting as a client of the GO, and on the channel where the group will operate, which can be, for example, in the 2.4 GHz or 5 GHz bands. Security provisioning 347 starts after discovery has taken place and, if required, the respective roles have been negotiated upon forming the group. Once the P2P Group is established, new P2P devices can discover and join the group using active or passive scanning mechanisms like the ones used in traditional WiFi networks. Like a traditional AP, a P2P GO announces itself through beacons 360 and has to support power-saving services for its associated clients. The P2P GO is also required to run a Dynamic Host Configuration Protocol (DHCP) server to provide P2P Clients with IP addresses (not represented in the figure). Upon successful Wi-Fi Direct Connection Setup between devices, the P2P devices can use the Wi-Fi Direct connection to directly exchange data. Communication within a P2P Group established shall employ WPA2-Personal security. For example, they may attempt to establish an Audio-Video Session 312. An AV control session, steps 341-342, initiates a Transmission Control Protocol (TCP) connection, wherein one of the P2P devices acts as a P2P Sink (e.g., device 302) and the second as a P2P Source (e.g., device 301) with regards to the AV data flow. The P2P Source typically plays the TCP server role. The protocol running on the Control Port is a Real Time Streaming Protocol (RTSP). A Real-time Transport Protocol (RTP) or a Real-time Transport Control Protocol (RTCP) may be used as the data path for the AV data session 343; an RTSP may be used as a control path for the AV control session. AudioA / ideo elementary streams generated by the P2P Source can be packetized using a MPEG2-TS container format and encapsulated by RTP / UDP / IP headers prior to 802.11 packetization and transmission. Some devices certified under the Wi-Fi Direct program support connections to both an infrastructure network and Wi-Fi Direct group at the same time (e.g., a laptop may support an infrastructure connection while also belonging to a Wi-Fi Direct-certified group). Simultaneous connection to a Wi-Fi Direct group and an infrastructure network is an optional feature. To do so, the Wi-Fi chip does not use only one interface for wireless communication, but dual MAC products that support two interfaces are used. To signal P2P attributes in the frames exchanged during the above three phases, P2P protocol communication is based on the use of a so-called P2P Information Element (P2P IE 380) as depicted in Figure 3b. It is based on the Vendor Specific Information Element as defined in IEEE Std 802.11-2012, wherein Element ID 381 is set to OxDD to signal a P2P IE, WFA GUI field 383 indicating WFA-specific and OUI Type field 384 indicating P2P version. P2P attributes 390 are defined in the P2P IE. A single P2P IE may carry one or more P2P attributes 390. The P2P attributes 390 are defined to have a common general format consisting of a 1-octet P2P Attribute ID field 391, a 2-octet Length field 392 and variable-length attribute-specific information fields 393. Various attributes are listed in the table 395 of the figure, from among which: - The P2P Capability attribute (Attribute ID = 2) contains a set of parameters that can be used to establish a P2P connection. It is included in Beacon frames, Probe Request frames, (Re) association Request frames, and GO Negotiation frames. - The P2P Device ID attribute (Attribute ID = 3) contains the P2P Device’s Address (6 octets sized), and is present in the Beacon frame. - The Listen Channel attribute (Attribute ID = 6) contains the Listen Channel and Operating Class information, and is included in Probe Request frames and GO Negotiation Request frames. If the P2P Device has not selected a Listen Channel, the Listen Channel attribute can be omitted. - The P2P Group BSSID attribute (Attribute ID = 7) contains the BSSID used by a P2P Group Owner for a P2P Group. - The Channel List attribute (Attribute ID = 11) contains a list of Operating Class and Channel pair information, and is included in GO Negotiation frames and P2P Invitation frames. - The Operating Channel attribute (Attribute ID = 17) is only present in the P2P IE if the P2P Device is an operating P2P Group Owner. The attribute indicates the Operating class and Channel number on which the P2P Device is operating as P2P Group Owner. In other words, it defines the operating channel of the P2P Group. The Operating Class and Channel Number fields of the Operating Channel attribute correspond to the same elements as defined in 802.11 REVme D4.0 (Appendix E). - The P2P Device Info attribute (Attribute ID = 13) contains information on a P2P Device (Device Address, configuration method, device name, etc.). The P2P Device Info attribute is included in the (Re) association Request frame, Probe Response frame and GO Negotiation frames. - The P2P Group ID attribute (Attribute ID = 15) contains a unique P2P Group identifier of the P2P Group, for example formed by the pair {P2P Device address of the P2P Group Owner and SSID}. The use of a globally unique P2P Device Address of the P2P Group Owner assures that different P2P Devices create P2P Groups differentiated from each other. Each SSID begins with the ASCII characters “DIRECT—” followed by two ASCII characters “xy”, randomly selected. This SSID requirement enables users of Legacy Clients to differentiate between a P2P Group and an infrastructure network. The P2P Group ID attribute is included in the P2P Invitation Request frames. The above description shows that unknown soft AP (including P2P GO) can be discovered by stations (or P2P devices) only through intensive scanning over multiple channels (either predefined / social channels or potential channels on which such soft AP may operate) because both client and soft AP have to be in-band for the discovery. This issue also exists for any unknown AP of infrastructure BSS. With the increasing number of operating bands / channels including those of the recent 6 GHz band, traditional scan (active or passive) of the channels takes too much time. Furthermore, specific to Wi-Fi Direct link, the P2P GO usually stays on the operating channel of its P2P Group once the latter is established. This means that, by failing to switch back to the social channels, it becomes complicated for new P2P devices to discover and thus to join the P2P Group. This issue could be solved by using ML Devices, and positioning one link on a social channel. It comes that the known discovery mechanisms are not sufficient to provide efficient network communication in wireless networks, to discover ad hoc networks, including P2P groups, to promote direct device-to-device connectivity and in a more general aspect to take the benefit of multiple channels or links for their communications. In this context, the disclosure intends to provide new mechanisms to support ML operations for WFD devices. Figure 4a schematically illustrates a non-AP H-MLD communication device 400, embedding a plurality of non-AP stations of a radio network NETW, configured to implement at least one embodiment of the disclosure. The communication device 400 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 400 comprises a communication bus 413 to which there are preferably connected: a central processing unit 401, such as a processor, denoted CPU; a memory 403 for storing an executable code of methods or steps of the methods according to embodiments as well as the registers adapted to record variables and parameters necessary for implementing the methods; and at least one communication interface 402 connected to a wireless communication network, for example, a communication network according to one of the IEEE 802.11 families of standards and / or Wireless-Fidelity (Wi-Fi) specifications, via transmitting and receiving antennas 404. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 400 or connected to it. The representation of the bus is not limiting, and the central processing unit is operable to communicate instructions to any element of the communication device 400 directly or by means of another element of the communication device 400. 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 402, to be stored in the memory of the communication device 400 before being executed. In an embodiment, the device is a programmable apparatus which uses software to implement embodiments. However, alternatively, embodiments may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Figure 4b is a block diagram schematically illustrating the architecture of the communication device 400, adapted to carry out, at least partially, some embodiments. As illustrated, device 400 comprises a physical (PHY) layer block 423, a MAC layer block 422, and an application layer block 421. The PHY layer block 423, here a plurality of 802.11 standardized PHY layer modules, has the task of formatting, modulating on or demodulating from any 20 MHz channel or composite channel. The PHY layer thus sends or receives frames over the radio medium NETW, such as 802.11 frames. These frames may be for instance medium access trigger frames to reserve a transmission slot, MAC data and management frames based on a 20 MHz width to interact with legacy 802.11 stations and with legacy Wi-Fi Direct specification, as well as of MAC data frames of OFDMA type having smaller width than 20 MHz legacy (typically 2 MHz or 5 MHz) to / from that radio medium. The MAC layer block or controller 422 preferably comprises a Multi-Link MAC 802.11 layer 424 implementing conventional 802.11 MAC operations. It may comprise additional block 425 for carrying out, at least partially, embodiments. The MAC layer block 422 may optionally be implemented in software, which software is loaded into RAM 403 and executed by CPU 401. The ML MAC 802.11 layer 424 may implement an upper-MAC stack along with a series of lower-MAC modules. Preferably, the additional block 425, referred to as P2P management module for performing multi-link operations for P2P Devices, implements part of the embodiments. This block performs the operations of the methods illustrated particularly in relation with Figures 8,10b-10d depending on the role of the communication device 400, P2P Device client or Group-Owner peer. MAC 802.11 layer 424 and P2P Link management module 425 interact one with the other in order to establish and process communications accurately over a P2P Link in between multiple MLD non-AP stations forming a P2P group according to embodiments. The MAC 802.11 layer 424 may comprise a single upper MAC layer 424a handling a plurality of lower MAC layer modules 424b. On top of the Figure 4b, application layer block 421 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 421 represents all the stack layers above MAC layer according to ISO standardization. Figure 5 illustrates possible format of a new P2P information attribute, namely P2P MLD Information attribute 500. The P2P MLD Information attribute 500 contains information of WLAN AP(s) that P2P Device's WLAN STA interface is concurrently able to operate. For a P2P Device acting as a non-AP STA of a P2P group, this corresponds to affiliated non-AP(s) STA of the MLD P2P Device. For a P2P Device acting as a GO of a P2P group, this corresponds to affiliated AP(s) of the MLD P2P GO. The P2P MLD Information attribute 500 is present in the P2P IE if the P2P device supports MLD operation, and that is included in Management frames. The Management frames may include as examples: Beacon frames, Probe Response frames, (Re)Association Response frames for APs, (Re)Association Request frames, GO Negotiation Request frames, GO Negotiation Response frames, GO Negotiation Confirmation frames, P2P Invitation Request frames and P2P Invitation Response frames. The P2P MLD Information attribute 500 is now described. The Attribute ID identifies the P2P MLD Information attribute among the types of P2P attributes as listed per Table 395 of Figure 3b (e.g., any value ‘To Be Defined’ in the Reserved range 29-220). A P2P Device that encounters an unknown or reserved Attribute ID value in a P2P IE received without error ignores that P2P attribute and parses any remaining fields for additional P2P attributes with recognizable Attribute ID values. The ‘Max Number of Simultaneous Links’ 510 indicates the maximum number of STAs affiliated with the MLD P2P Device that supports simultaneous transmission or reception of frames on the respective links. It is set to a value between 0 and 14, which is the maximum number of affiliated STAs of the MLD that support simultaneous transmission or reception of frames minus 1. The value 15 is reserved. Then, a Link Info List attribute 511 includes the one or more Link Info fields 550 corresponding to the Max Number of Simultaneous Links’ 510. As an option (not shown in the figure), Element 500 may contain the MLD MAC Address. Otherwise, the MLD MAC Address is provided in P2P elements only through P2P Device Address attribute (see Fig. 6c). As another option (not shown in the figure), Element 500 may contain the MLD ID or AP MLD ID. This element is only relevant when the emitting STA is an operative MLD GO. The MLD ID field indicates the identifier of the AP MLD with which the reported AP is affiliated: it is used in ML Probe Response or beacon frames as illustrated in Figure 7 so that the MLD ID subfield is set to same value (generally starting from 0) for all elements reported in those frames The Link Info field 550 is now described. Flag (551) is one byte field that can handle additional parameters of the indicated Link. - As an example, a first bit B0 may be used to indicate that P2P Device's WLAN affiliated STA interface is concurrently associated with an infrastructure AP. This means that the affiliated STA operating on the link can act as a P2P Concurrent Device (meaning concurrently operates as a WLAN STA in WLAN). A P2P Concurrent Device that is an MLD according to the disclosure may have one affiliated MAC entity operating as a WLAN-STA (the one as indicated by B0) and at least one second affiliated MAC entity operating as a P2P Device. In an alternative embodiment, the affiliated MAC entity with BO set to 1 is purely indicative, which means that the MAC entity does not support P2P group on that link. - A second bit B1 may be used to indicate a primary link. An NSTR MLD can designate one of the links of an NSTR link pair as the primary link of the MLD. The primary link shall not be disabled or removed and the nonprimary link may be disabled or removed. The other link of the NSTR link pair is the nonprimary link. This is especially useful for an NSTR GO MLD (also called NSTR mobile AP), because the NSTR GO MLD schedules for transmissions of Beacon and Probe Response frames and group addressed Data frames only on the primary link. - A third bit B2 may be used to indicate a discovery link. When set to 1, the present link is used for Device discovery only (not for communication, nor primary link) and remains permanent (for a P2P GO, because in charge of admitting new devices to the group). When set to 0, the present link is used for communication and may be removed (if not a primary link). The value of the Link ID field 552 is set to the link ID that is assigned to this affiliated STA. As long as the P2P Device is not involved in a P2P group, the link ID value is an index local to the emitting STA (when sent in Probe Request, Probe response, GO Negotiation Request frames, GO Negotiation Response frames, GO Negotiation Confirmation frames). When the P2P Group is already formed, the Link ID value corresponds to an affiliated AP of the Per-STA Profile sub element of the GO MLD. In that case, it corresponds in the Beacon or Probe Response Multi-Link element to the link that identifies the AP affiliated with a GO MLD (see Figure 7). The MAC address field identifies the affiliated STA operating on the link. This could be either a MAC address of the AP (BSSID) that is affiliated with an MLD GO; or a MAC address of the non-AP STA that is affiliated with an MLD P2P Client Device. The Operating Class 555 and Channel Number 556 field (and the Country String filed 554) together indicate the primary channel of the link being reported. Valid operating classes are listed in Annex E of P802.11-REVme specification. In alternative embodiments, the ‘P2P MLD Information’ attribute (500) may include an NSTR Indication Bitmap (not shown). The NSTR Indication Bitmap subfield indicates NSTR link pairs for the non-AP MLD. Each bit Bj Q # i) in the NSTR Indication Bitmap subfield included in the Link Info element 550 with Link ID subfield equal to i (where 0 <i <15) is set to 1 if the link pair corresponding to link IDs equal to <i, j> is an NSTR link pair; otherwise, bit Bj is set to 0. Bit Bi in the NSTR Indication Bitmap subfield included in the Link Info element 550 with Link ID subfield value equal to i is reserved. This inclusion is not mandatory, as this information can be obtained via each of the Per-STA Profile sub element of the Basic ML element present in Beacon frame or ML Probe Response frames (the Link ID coherence been kept with ‘P2P MLD Information’ attribute). P2P Devices in discovery A P2P Device in the Scan Phase may discover a P2P Device in the Listen State. The Find Phase is used to ensure that two P2P Devices that are both in In-band Device Discovery arrive on a common channel to exchange device information. They then can initiate Group Owner Negotiation to attempt to form a new P2P Group. A ML P2P Device that is already operating as a ML P2P Group Owner stays on the Operating Channel and waits for other devices to discover it. According to embodiments, an MLD P2P Group Owner can thus search on other links to find desired devices or services, while remaining on (at least one, that is the primary link) operating link for P2P group communication. Figure 6a illustrates the list of P2P attributes for a P2P IE that is included in the Probe Request frame. In embodiments, last displayed element is the new P2P MLD Information 500 attribute. P2P Devices in the Search State transmit one or more Probe Request frames on each of the Social Channels supported by the P2P Device. All Probe Request frames transmitted by P2P Devices in the Search State: Include the P2P IE 300, including the elements as listed here after. Include the WSC IE, with Device Name, Primary Device Type, and Device Password ID as required attributes. Secondary Device Type List is an optional attribute. Have the SSID field set to the P2P Wildcard SSID. Have the BSSID field set to the Wildcard BSSID. The P2P IE list 600 contains: - The P2P Capability attribute 601 contains a set of parameters that can be used to establish a P2P connection, namely a Device Capability Bitmap field (601a - Figure 6b) and a group Capability Bitmap field. In embodiments, the Device Capability Bitmap field (601a) may be updated to support the indication of ML Operation (6011), at bit 7 (see Figure 6b: format of the Device Capability Bitmap field). - The P2P Device ID attribute 602, that contains P2P Device Address (An identifier used to uniquely reference a P2P Device). The Multi-Link Operation bitfield shall be set to 1 when the P2P Device supports Multi-Link Operation (MLD device), and is set to 0 otherwise. - The Listen Channel attribute 603, that contains the Listen Channel and Operating Class information. It means it identifies the channel chosen from the set of Social Channels (Channels 1,6, and 11 in the 2.4 GHz band), which is used by a P2P Device to be discoverable. When the P2P Device is an MLD Device, this may correspond to a specific link dedicated to Listen State operation. Optionally, an Extended Listen Timing attribute 604 when a Device adopts different availability timing within the Listen State to that generally recommended for discoverability. - The P2P Device Info attribute 605, that contains information on a P2P Device (such as P2P Device Address (specific value as specified below when MLD), its Device Name, Primary Device Type, and optionally Secondary Device Type List information). - The Operating Channel attribute 606 contains Operating Channel and Operating Class information, that respectively indicates the frequency band and channel number at which the P2P Device is operating as the P2P Group Owner, or a preferred operating band / channel. - A Service Hash 607. According to embodiments, the P2P IE list 600 contains the P2P MLD Attribute (500) of present disclosure. In that case, the Operating Channel and Operating Class information of Operating Channel attribute 606 are corresponding to a legacy link for the MLD, that is to say the link that will be used by default by a legacy P2P Device, not able to support MLD operation as presented in the disclosure. This corresponds to primary link, bit 1 set to 1 in 551. P2P Device addressing. The Wi-Fi Direct specification mandates the following rules for device addressing. A P2P Device shall have a P2P Device Address, which is used to uniquely reference that P2P Device. The P2P Device Address of a P2P Device is its globally administered MAC address. The P2P Device Address is used as the receiver address (RA) for all frames sent to a P2P Device during P2P Discovery, with the sole exception of using a broadcast receiver address in a Probe Request. The P2P Device Address is used as the transmitter address (TA) for all frames sent by a P2P Device during P2P Discovery. The P2P Device assigns a P2P Interface Address, which is used to communicate with the P2P Group Owner or Clients within a P2P Group. A P2P Interface Address is not required to be globally unique and may be locally administered. A P2P Interface Address may be the same as the P2P Device address. A P2P Device uses its P2P Interface Address as the transmitter address (TA) for all frames sent within a P2P Group. A P2P Device uses the P2P Interface Address of the intended recipient P2P Device as the receiver address (RA) for all unicast frames sent within a P2P Group. A P2P Device only uses a P2P Interface Address for communication within a P2P Group. All other communications between P2P Devices use the P2P Device Address. Therefore, in the context where P2P Device supports MLD operation, embodiments provide that: P2P Device Address is set to the MLD MAC address, that singly identifies the MLD; - P2P Interface Address is set to the address of an affiliated STA of the MLD Device. This still ensure that the MLD MAC address of a P2P MLD (P2P Device Address) might be the same as the MAC address of at most one affiliated STA or might be different from the MAC address of any affiliated STA (P2P Interface Address). Figure 6c schematically illustrates a Probe Request frame 610 according to embodiments, in which a group of P2P IE 600 is included. As it can be seen, more than one P2P IE may be included in a single frame. If multiple P2P lEs are present, the complete P2P attribute data consists of the concatenation of the P2P Attribute fields of the P2P lEs. One of those elements is especially the P2P MLD Information Attribute 500. According to Wi-Fi P2P specification (shown in Figure 3a), Probe Request frames can be transmitted by any P2P Device. P2P Device Discovery uses Probe Request and Probe Response frames to exchange device information. Note that a P2P Device does not transmit Beacon frames unless it will operate as a P2P Group Owner. The 'P2P MLD Information Attribute’ (500) of present disclosure aims to provide capabilities of the sender device to any recipient. Once the capabilities are exchanged, a GO negotiation can be proceeded (as the enhanced scheme disclosed in Figures 10). According to IEEE802.11be D5.0 section “9.4.2.312.3 Probe Request Multi-Link element”, in which the Probe Request Multi-Link element 1215 includes common information and one Per-STA profile per each affiliated AP, the Probe Request Multi-Link element is used by a non-AP STA to request an AP MLD to provide information of the APs affiliated with an AP MLD. The inclusion of a Probe Request Multi-Link element in a Probe Request frame identifies it as a multi-link probe request. As one can see, in case of ML Probe Request frame, the ‘P2P MLD Information Attribute’ 500 refers to capabilities of sender P2P Device while the Probe Request ML element 615 requests additional ML Info to the recipient AP MLD (which can be a GO). No relationship exists in between those two elements. With that, during P2P Device Discovery on social channel, the Probe Request ML element may not be present. Now, description will focus on Figure 7. A searching P2P Device discovers a P2P Group Owner in the Scan Phase through received Beacon or Probe Response frames. The beacon frames can replace legacy beacon frames 211 or 360 and are sent by P2P GO once a P2P group is formed. The Probe Response frames can be transmitted by a P2P Device either in its Operating Channel (as illustrated by frame 213 in Figure 2b) or Listen Channel (as illustrated by frame 352 in Figure 3a). Information in the ‘P2P MLD Information attribute’ may be used to decide whether to attempt to join a P2P Group. Until a P2P group is formed, Probe Request and Probe Response frames are subsequently used to exchange device information, therefore Probe Response frames may contain uniquely the P2P MLD Information Attribute (500). Once a P2P group is formed, Probe Response frames may add a Probe Response ML element 741 (as beacon frames). Figure 7 illustrates the common format of beacon or ML Probe Response frames 710 as sent by P2P Device MLD GO. The P2P Group Owner may be determined through the legacy Group Formation Procedure, or through an enhanced Group Formation Procedure as disclosed by Figures 10a-d. A P2P Device indicates that it is a P2P Group Owner by setting the Group Owner field of the P2P Capability attribute to 1 in transmitted Beacon, Announce, and Probe Response frames. Like a traditional AP, a P2P GO announces itself through beacons containing additional P2P Information Element. P2P IE is included in all management frames. Legacy devices ignore these information elements and action frames. When a P2P Group Owner responds to a Probe Request frame containing the P2P IE with ‘P2P MLD Information attribute’ 500, it includes its own ‘P2P MLD Information attribute’ 500 in P2P IE 700 along with a Basic Multi-Link element 716. According to IEEE802.11be D5.0, as AP MLD (here, this is a GO) is multi-link, an RNR 740 is used to provide information (complete or partial profile) of other reported APs affiliated with the same GO MLD: The elements 741 and 742 refers to Per-STA profile per each reported AP in the Basic Multi-Link element 716. This is for ease of affiliated AP discovery for legacy non-AP STA (aka non-P2P Devices). The AP MLD ID information is RNR 410 and Basic Multi-Link element 716 have same value. In the same way, the ‘P2P MLD Information attribute’ 500 aims to provide quick information of the affiliated AP of the MLD GO, therefore each Link Info element 550 of ‘P2P MLD Information attribute’ 500 refers to the detailed Per-STA Profile of the Basic Multi-Link element 716. In the illustration, there are 2 affiliated APs acting as GO on their respective link (741 and 742), which are listed as 2 entries 550 in the list 511. In all ML Probe Responses or beacon frames that it sends, a P2P Group Owner sets the SSID to the SSID of the group, that is common to the MLD, and sets the SA and BSSID to its P2P Interface Address (affiliated STA). Inheritance of P2P IE (700) in a Basic Multi-Link element In the illustration, the frame carries a Basic Multi-Link element that is carrying two Per-STA Profile sub elements corresponding to AP 1 and AP 2 that operate the MLD GO. The P2P IE preferably remains outside the Basic Multi-Link element 716. This P2P element carried in the same frame outside the Basic Multi-Link element is thus inherited by all per-STA profiles (AP1 and AP2), and P2P IE is forbidden to be carried inside the profiles. In other words, the P2P IE is set at MLD level and applies to all links. There may be an exception however in an implementation where a MAC entity does not support P2P group on a link, the P2P IE will not apply to that link. Figure 8 illustrates the main steps of a method for configuring multiple links for Wi-Fi Direct communication as operated by a P2P affiliated station of a P2P-MLD 400 in the disclosure. Note that a P2P MLD that is already operating as a P2P Group Owner stays on the Operating Channel / link (especially primary link) and waits for other devices to discover it. This algorithm applies to P2P MLD 400 that is currently not a P2P GO. In a step 810, the P2P MLD 400 instantiates a Link (may be called social link) on one social channel (as example, this may correspond to one of the social channels in the 2.4GHz band as stipulated by WFD specification), that is to say an affiliated non-AP STA of the P2P Device is operation Device Discovery on that link / channel. In a step 820, the P2P MLD 400 prepares the ‘P2P MLD Information attribute’ 500, that informs of the existing link setup on social channel and the expected link(s) for supporting communication in a P2P group. This element is included in Probe Request frames, as illustrated in Figures 6a-6b-6c. In a step 830, the P2P MLD 400 performs a discovery on the dedicated link instantiated in 810. The P2P device enables “P2P Discovery” phase to quickly find each other and form a P2P connection on the intended link. One major action of this phase is the Device Discovery, which uses Probe Request and Probe Response frames to exchange device information (especially attribute 500 according to embodiments) on the dedicated ‘social’ link. The searching P2P MLD discovers a P2P Group Owner in the Scan Phase through received Beacon or Probe Response frames. Information in the P2P Capability and the ‘P2P MLD Information attribute’ 500 attributes may be used to decide whether to attempt to join or create a P2P Group. If it is decided to join an existing P2P Group, step 850 is executed. Otherwise, if no existing P2P Group is found but P2P Devices have discovered each other, at step 830, if a P2P MLD successfully completes Device Discovery with a peer (MLD) P2P Device, it decides to proceed to step 840 with establishing a P2P connection with the peer P2P Device. At step 840, the group formation procedure is performed. This could be the legacy algorithm of P2P Specification, even if not suitable to support MLD operation. This can be the enhanced protocol as further disclosed by Figures 9-10a-d. Resulting from execution of step 840, if the P2P MLD is determined to operate as P2P Client Device, this conducts to step 850. If the P2P MLD is determined to operate as P2P GO Device, this conducts to step 860. The P2P MLD GO will instantiate as many links it wants, according to the listed ones in ‘P2P MLD Information attribute’ 500. In addition, Wi-Fi Direct specifies that the P2P Group Owner assigns a globally unique P2P Group ID for each P2P Group when the P2P Group is formed and this remains the same for the lifetime of that P2P Group. Embodiments thus envisage that the same Group ID is provided through all links. Compared to usual P2P discovery, the social link may remain used by an MLD GO 400, in parallel to P2P communication links; this is more advantageous for group discovery, as the legacy scheme does not allow GO to fallback to social channel(s) once the P2P group is formed. As an additional advantage, operating several communication links by ML P2P Devices avoids any session transfer that would imply connectivity break during the transmission (that is the case for legacy, non-ML, P2P devices that need to proceed at a band / channel switch operation). The P2P MLD GO will transmit (step 870) beacon frames as illustrated by figure 7. The P2P MLD GO can admit new devices on any social link or operation link (step 880). Then, data is exchanged between the P2P Group Owner and each connected (MLD) Client on at least one communication link (step 890). Figure 9 illustrates exemplary different wireless connectivity, depending of which is the Group Owner. Illustration 900 illustrates the prior-art, where in case of the P2P Devices are MLD compliant, at most one link 901 can be setup in the P2P group. No multiple links are possible. Second illustration 910 illustrates the present embodiments with no enhancement on the P2P group formation: the P2P GO is randomly selected among any of the P2P Devices, even those which are MLD compliant and those which are legacy ones. The illustration shows that MLD P2P 915 was elected as GO, so 2 links 911, 912 can be setup (mainly because MLD 915 hosts 2 links, and at least one of the P2P MLD Device can also host 2 links). We recall that each P2P MLD keep same GO / Client role for each link. This illustrates that the P2P Group does not benefit of all available links (e.g., between 916 and 917). Possibly (not shown in the figure), it could happen that a legacy P2P Device is elected as GO, thus preventing multiple links to be operated when MLDs are present in the group. This scheme corresponds to fallback to a legacy scheme with only one link, even if MLDs are present. This is why embodiments provide an enhanced GO election mechanism, based on MLD support as introduced in previous embodiments. This is illustrated by scheme 920, wherein the P2P GO to be elected is one having the higher number of links (e.g., 926) among the P2P Devices 925, 926 and 927 (thus P2P Devices 925 and 927 result in operating a P2P Client role), therefore providing support of 3 links 921, 922 and 923. Even if not all possible links are setup at the start of the P2P group (e.g., the MLD GO has only Client with few links), more links may be set up in the future while keeping the P2P group active (e.g., when a new Client device having more links than the existing client(s) is joining the P2P group, the MLD GO can setup new link(s) for the P2P group, up to a maximum number of links fitting its own (GO’S) capacity). Adding or deleting links is performed by 802.11 be mechanism. Figure 10a illustrates the legacy P2P Group. Once the two P2P Devices have found each other, they start the GO Negotiation phase. This is implemented using a three-way handshake, namely GO Negotiation Request 344 / Response 345 I Confirmation 346, whereby the two devices agree on which device will act as P2P GO and on the channel where the group will operate. In order to agree on the device that will act as P2P GO, P2P devices send a numerical parameter, the GO Intent value, within the three-way hand-shake, and the device declaring the highest value becomes the P2P GO. If the P2P Device must be the P2P Group Owner (decided by configuration or service, such as cross-connection with infrastructure network), the Intent field in the Group Owner Intent attribute can be set to 15 (maximum value). To prevent conflicts when two devices declare the same GO Intent, a tie-breaker bit is included in the GO Negotiation Request 344, which is randomly set every time a GO Negotiation Request is sent. If the Intent values in the GO Negotiation Request and Response frames are equal and less than 15, then the device sending the Tie breaker bit equal to 1 becomes the GO. If a P2P Device that must be P2P Group Owner (i.e., that P2P Device would indicate an Intent value of 15) receives GO Negotiation Request frame that also contains an Intent value of 15, the P2P Device responds with a GO Response frame containing a Status attribute with the Status Code field set to “Fail: both P2P Devices indicated an Intent of 15 in Group Owner Negotiation”. Group Formation ends on transmission or reception of a GO Negotiation Response frame with the Status Code set to a value other than Success Figure 10b illustrates modified GO Negotiation Request 344 I Response 345 I Confirmation 346 frames, based on insertion of the ‘P2P MLD Information attribute’ 500. A P2P MLD Device initiates Group Owner Negotiation by sending the GO Negotiation Request frame 1044. The GO Negotiation Request frame includes a P2P IE with the P2P Capability, P2P MLD Information (500), P2P Device Info, Channel List, Listen Channel, Operating Channel, Group Owner Intent, Configuration Timeout and Intended P2P Interface Address attributes and a WSC IE with the Device Password ID attribute. The Max Number of simultaneous Links field in the P2P MLD Info (500) attribute indicates the maximum number of links of the P2P Group to be formed if the P2P Device sending the GO Negotiation request becomes Group Owner. The P2P Device receiving a GO Negotiation Request frame examines the received information and responds with a GO Negotiation Response frame 1045. The P2P MLD Device indicates its intent to enter Group Formation by sending a GO Negotiation Response frame that indicates a Status of Success. The GO Negotiation Response frame includes a P2P IE with the P2P Capability, P2P MLD Information (500), Status, P2P Device Info, Channel List, Operating Channel, Group Owner Intent, Configuration Timeout and Intended P2P Interface Address attributes and a WSC IE with the Device Password ID attribute. A P2P MLD Device that will become the P2P Group Owner constructs the GO Negotiation Response frame 1045 corresponding to the following rule: The Channel List attribute and P2P MLD Information (500) attribute indicate the channels that the current P2P Device uses as Operating Channel(s) of the P2P Group. The channels indicated only include channels from the Channel List attribute and P2P MLD Information (500) in the GO Negotiation Request frame. Among those, at least one Operating Channel / link is indicated as the intended Operating Channel / link of the P2P Group. A P2P MLD Device that will become a P2P Client constructs the GO Negotiation Response frame 1045 corresponding to the following rule: The Channel List attribute and P2P MLD Information (500) attribute indicate the channels that the P2P GO Device that the P2P Device can support as Operating Channel of the P2P Group. It can be a reduced set compared to its original list. A P2P MLD Device that will become the P2P Group Owner constructs the GO Negotiation Confirmation frame 1046 corresponding to the following rules. The Channel List / P2P MLD Information (500) attributes indicate the channels that the P2P Device may use as Operating Channel of the P2P Group. The channels indicated only include channels / links from the GO Negotiation Response frame. The channel / link indicated in the Operating Channel / link shall be one of the channels in the Channel List attribute and P2P MLD Information (500) in the GO Negotiation Confirmation frame. A P2P MLD Device that will become a P2P Client constructs the GO Negotiation Confirmation frame corresponding to the following rules. The Channel List and P2P MLD Information (500) attributes indicate the channels / links that the P2P Device can support as Operating Channel of the P2P Group. The channels indicated in the Channel List only include channels from the GO Negotiation Response frame and include the (primary) channel indicated in the Operating Channel attribute I P2P MLD Information (500) attributes in the GO Negotiation Response frame. The Operating Channel attribute in the GO Negotiation Confirmation frame is the Operating Channel attribute from the GO Negotiation Response frame. Figure 10c illustrates an enhanced implementation at a MLD Device receiving a GO Negotiation Request (344) (step 1010) embedding the ‘P2P MLD attribute’ 500. This algorithm is only applied by the recipient device, and does not need to modify the legacy election algorithm (Fig. 10a). At step 1011, the MLD Device determines the “The Max Number of simultaneous Links” 510 value of the peer device. In one implementation, the MLD device determines, at step 1012, if this number is greater than its own one. In other implementations, other parameters than the number of simultaneous links may be considered as discussed below. This scheme is compliant with legacy devices. When the P2P Device determines it has more benefits to provide to the group of being GO than other devices, it can arrange its intent value to be greater than the received one corresponding to its peer device (step 1013). The P2P Device may have more benefits to be a GO based on at least one of: higher number of simultaneous links as the implementation illustrated by test 1012, larger operational bandwidth, newer generation chipset compared to the peer devices, etc. Otherwise, it arranges an intent less than the other device’s intent (step 1014). The new Intent, generated from information received by the GO Negotiation Request (344) frame, is provided (step 1015) in the sent GO Negotiation Response (345). Figure 10d illustrates an enhanced P2P Group formation based on the ‘P2P MLD attribute’ 500, operated by both MLD peer Devices. This algorithm enhances the first part of legacy one, that is to say other the Tie Breaker that remains unchanged (in dashed lines). Purpose is to favour the MLD device for Group Owner election by providing a scale factor to the original GO Intent. First, in step 1050, the two Intents X1, X2 are obtained, one for each P2P Device. That means both devices will do the same algorithm, one when receiving the GO Negotiation Request 1044 and the second when receiving the GO Negotiation response 1045. In step 1051, a coefficient COEF is applied to these values: PX1 = COEF x X1 PX2 = COEF x X2 COEF = Coeff_1 * Coeff_2 * Coeff_3 *. Wherein: Coeff_1 = Max Number of simultaneous Links (510) Coeff_2 = Max Number of bands (extracted from field 556 of each Link Info List 511) - Coeff_3 = rank of Wi-Fi chipset generation; as example 802.11ac / Wi-Fi5 or prior generation takes value 1, 802.11ax / Wi-Fi6 takes value 2, 802.11be / Wi-Fi7 takes value 3, ... The COEF can be based on at least one of previous coefficients, or a combination of part or all of them. Aim is to provide a large range in values PX1 and PX2, therefore having much less chance to have an equal value. Then, the winner of GO election is the one with greatest PXi value. In embodiments, a P2P MLD Device may apply both algorithm of Figures 10c and 10d. As example, when the device determines that the remote device is a legacy one, it cannot apply algorithm of figure 10c as the legacy device does not do this. Therefore, the P2P MLD will not emit a GO Negotiation Request (344) towards legacy P2P devices, but wait from them to receive a GO Negotiation Request (344) and apply algorithm of Figure 10c. When the P2P MLD Device determines than the other peer is also a P2P MLD Device, then both can apply algorithm of figure 10d consisting in an enhanced election scheme considering capabilities of the devices (e.g., number of links or bands). Any step of the algorithms of the disclosure may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC (“Personal Computer”), a DSP (“Digital Signal Processor”) or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA (“Field-Programmable Gate Array”) or an ASIC (“Application-Specific Integrated Circuit”). Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention. Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different 5 features from different embodiments may be interchanged, where appropriate. Each of the embodiments described above can be implemented solely or as a combination of a plurality of the embodiments. Also, features from different embodiments can be combined where necessary or where the combination of elements or features from individual embodiments in a single embodiment is beneficial. 10 In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A method for configuring a peer-to-peer (P2P) wireless network comprising:- configuring a first affiliated non-Access Point, non-AP, station of a P2P non-AP Multi Link Device, MLD, to advertise multilink capabilities of the P2P MLD for establishing a P2P connection with a second non-AP station.

2. The method of claim 1, wherein advertising the multilink capabilities occurs during discovery and association processes.

3. The method of claim 1 or 2, wherein advertising the multilink capabilities comprises transmitting a P2P MLD information attribute in management frames, such as Beacon frames, Probe Response frames, Association Response frames, Group Owner, GO, Negotiation Request frames, GO Negotiation Response frames, GO Confirmation Response frames, P2P Invitation Request frames and P2P Invitation Response frames.

4. The method of claim 3, wherein the P2P MLD information attribute is included into a P2P Information Element (P2P IE).

5. The method of claim 3 or 4, wherein the P2P MLD information attribute comprises information of affiliated station interfaces that the P2P MLD is concurrently able to operate as P2P communication.

6. The method of claim 3, 4 or 5, wherein the P2P MLD information attribute comprises the maximum number of affiliated stations of the P2P MLD which supports simultaneous transmission or reception of frames on their respective links.

7. The method of claim 3, 4, 5 or 6, wherein the P2P MLD information attribute comprises a list of link information fields associated with the simultaneous links supported by the P2P MLD.

8. The method of claim 7, wherein the link information fields comprise an information that the link cannot be used for a P2P communication, aninformation that the link is a primary link or an information that the link is a discovery link.

9. The method of claim 7 or 8, wherein, when the P2P MLD information attribute is conveyed in a Beacon or ML Probe Request frame, the link information fields refer to the detailed station profile contained into a basic multi-link element present in that frame.

10. The method of any one of claims 1 to 9, wherein a P2P Device Address of the P2P MLD, advertised in a P2P IE to uniquely reference the P2P Device, is set as the MLD MAC address advertised in Multi-link element of management frames, and the P2P Interface Address of the P2P MLD, advertised in the P2P IE for communication on a link, is set to the MAC address of the affiliated station of the P2P MLD operating on the link.

11. The method of any one of claims 1 to 10, wherein, when the P2P MLD is the group owner of the P2P group, the SSID of the P2P group is set to the SSID of the P2P MLD and the SA and BSSID of the group are set to the P2P interface address of the P2P MLD.

12. The method of any one of claims 1 to 11, wherein, the P2P MLD which is the group owner of the P2P group (P2P Group Owner) maintains a social channel for discovery and association purpose on a link operated by one of its affiliated STA.

13. The method of any one of claims 1 to 12, wherein, during negotiation protocol for determining the group owner of the P2P group, the negotiation protocol provides for an election scheme considering the multilink capability of the P2P MLD.

14. The method of claim 13, wherein the negotiation protocol defines as P2P Group Owner, the P2P MLD comprising the greatest number of available links, the greatest number of available bands or a combination thereof.

15. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 1 to 14, when loaded into and executed by the programmable apparatus.

16. A computer-readable storage medium storing instruction of a computer program for implementing a method according to any one of claims 1 to 14.

17. A computer program which upon execution causes the method of any one of claims 1 to 14 to be performed.

18. A non-access point, AP, multi-link device, MLD, comprising a first affiliated non-Access Point, non-AP, station configured to advertise multilink capabilities of the MLD for establishing a P2P connection with a second non-AP station.

19. The non-AP MLD of claim 18, wherein the non-AP MLD comprises a P2P management module and a MAC layer controller which interacts one with the other to establish and process communications in between multiple MLD non-AP stations forming a P2P group according to the method of claims 1 to 14.

Images