METHOD AND APPARATUS FOR P2P GROUP COMMUNICATION AMONG NON-AP MULTILINK DEVICES - Patent application

Abstract

The present invention relates to a transmission method in a wireless network, the method including configuring a first associated non-access point (non-AP) station of a non-AP multilink device MLD as a P2P station for communicating with peer stations in a first basic service set (BSS) forming a peer-to-peer P2P group, and configuring at least one second associated non-AP station of the non-AP MLD as a station for communicating with an AP in a second BSS.

Description

[Technical Field]

[0001] The present invention relates generally to communication networks, and more particularly to a peer-to-peer (P2P) communication method in a wireless network comprising a plurality of stations clustered into a plurality of multi-link entities, one of which acts as an access point and the other multi-link entities are connected to the access point and serve devices.

[0002] The invention applies in particular to accessing networks of the 802.11be / uhr / bn standard. [Background technology]

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

[0004] To address the increasing bandwidth and decreasing latency requirements for wireless communication systems in high-density environments, multi-user (MU) transmissions, i.e., multiple simultaneous transmissions to or from non-AP stations, have been developed by a single access point (AP) in a wireless network. For example, one such MU scheme was adopted by the Institute of Electrical and Electronics Engineers (IEEE) in the draft version 3.0 (D3.0) of the 802.11ax standard in June 2018.

[0005] Thanks to the MU functionality, a station has the opportunity to gain access to the wireless medium via two access methods: the MU method and the conventional Enhanced Distributed Channel Access - EDCA (Single User, SU) method.

[0006] However, the SU and MU schemes compete directly with each other for access to the wireless medium (by the AP for the MU scheme and by non-AP stations for the SU scheme). In high-density environments, this competition generates a large number of undesirable collisions, thereby reducing latency and overall effective data throughput. Therefore, several mechanisms have been introduced to favor the MU scheme over the SU scheme.

[0007] As the successor to 802.11ax, the 802.11be standard, or EHT, which stands for "Extremely High Throughput," allows for a feature called multi-link operation (MLO), which allows a single device to support multiple links and for the device's data to be delivered to another device via the multiple links. Multi-link capability can increase the device's peak / average throughput. Multi-link capability is negotiated during the initial association between a non-AP station and the intended AP.

[0008] A multilink device is a station with several affiliate stations. Each affiliate station dedicates one link for itself. An Access Point Multilink Device (AP MLD) is a multilink device, and each affiliate station (STA) in the MLD is an AP. A non-AP Multilink Device (non-AP MLD) is a multilink device, and each affiliate station in the MLD is a non-AP STA. An affiliate STA provides link-specific underlying Medium Access Protocol (MAC) services within the MLD.

[0009] Multilink operation is not suitable for bandwidth-demanding communication services between two non-AP stations, e.g., video-based services such as gaming, virtual reality, and streaming applications, because all communication except for the link used passes through the AP, doubling not only the airtime for transmission but also the number of medium accesses and therefore the medium access time.

[0010] Indeed, efficient use of wireless local area network (WLAN) resources is important to provide WLAN users with bandwidth and acceptable response times. In this context of bandwidth-demanding communication services between two non-AP stations, the association duration of the two non-AP stations also matters and should be kept as short as possible. Summary of the Invention

[0011] The present invention has been devised to address one or more of the problems set forth above.

[0012] The present invention relates to a non-AP multilink device (MLD) that can configure one of its associated stations as a peer-to-peer (P2P) station to form a P2P group while other associated stations continue to operate in a WLAN.

[0013] According to one aspect of the present invention, there is provided a method for transmission in a wireless network, the method comprising: configuring a first associated non-AP station of a non-access point (non-AP) multilink device (MLD) as a peer-to-peer (P2P) station for communicating with peer stations in a first basic service set (BSS) forming a P2P group; and configuring at least one second associated non-AP station in the non-AP MLD as a station for communicating with an AP in a second BSS.

[0014] In some embodiments, the second associated non-AP station of the non-AP MLD is configured to communicate with each associated AP station of an AP MLD.

[0015] In some embodiments, the first associated non-AP station stops transmitting to the AP MLD once it is configured to communicate in the P2P group.

[0016] In some embodiments, the method further comprises: Prior to configuring the first associated non-AP station as a P2P station, disassociating the first associated non-AP station from associated AP stations in the AP MLD.

[0017] In some embodiments, the first associated non-AP station is configured to communicate with the peer station on a first channel of the first BSS, and the at least one second associated non-AP station is configured to communicate with the AP on at least one second channel of the second BSS, and the method comprises: reporting the P2P group and the first channel to the AP MLD by the at least one second associated non-AP station of the non-AP MLD; Includes.

[0018] In some embodiments, reporting the P2P group includes transmitting a P2P information element (IE).

[0019] In some embodiments, the P2P IE is sent to the AP MLD in a P2P Invitation Request frame sent to the AP MLD on the second channel by the at least one second associated non-AP station for transmission to other stations connected to the AP MLD.

[0020] In some embodiments, the P2P IE is transmitted in a Multi-Link IE of a Probe Request frame.

[0021] In some embodiments, the Probe Request frame further comprises, in addition to the Multi-Link IE containing Group Owner (GO) information, a Reduced Neighbor Report (RNR) IE identifying the first non-AP associated station acting as the GO of the P2P group, and the RNR IE and ML IE are each set to the same value but include MLD ID and Link ID subfields that are distinct from the respective subfield values ​​used for the second BSS.

[0022] In some embodiments, the method further comprises: This includes transmitting the P2P IE by AP MLD, in a probe response frame, or in a beacon frame on the second channel.

[0023] In some embodiments, the P2P IE is included in the per-STA profile in the first Basic Multi-Link IE.

[0024] In some embodiments, the Beacon frame or the Probe Response frame includes, in addition to the first Basic Multi-Link IE: an RNR IE that identifies AP-associated stations of the AP MLD and non-AP-associated stations that act as Group Owners (GOs) of a P2P group; A second Basic Multi-Link IE including information of AP-related stations of the AP MLD; The MLD ID subfield in the RNR IE and Basic Multi-Link IE is used to indicate whether the reported AP belongs to the primary or secondary BSS.

[0025] According to another aspect of the invention, a computer program product for a programmable device is proposed, the computer program product comprising a series of instructions for carrying out the method according to the invention when loaded into and executed by said programmable device.

[0026] According to another aspect of the invention, a computer readable storage medium is proposed having stored thereon instructions of a computer program for carrying out the method according to the invention.

[0027] According to another aspect of the invention, a computer program is proposed which, when executed, causes the method according to the invention to be carried out.

[0028] According to another aspect of the present invention, a non-access point (AP) multilink device (MLD) is proposed, comprising a first associated non-AP station and at least one second associated non-AP station, wherein the first associated non-AP station can be configured as a peer-to-peer (P2P) station for communicating with peer stations in a first basic service set (BSS) forming a P2P group, and the second associated non-AP station can be configured as a P2P station at the same time as the first associated non-AP station for communicating with an access point in a second BSS.

[0029] In some embodiments, the first BSS and the second BSS are not part of the same extended service set (ESS).

[0030] In some embodiments, the second associated non-AP stations are configured as stations for each communication with the associated AP station in the AP MLD.

[0031] In some embodiments, the second associated non-AP station is configured as a station for communicating with the non-MLD AP station.

[0032] In some embodiments, the non-AP MLD is: an upper MAC sublayer (424a) common to the first associated non-AP station and the second associated non-AP station; a first dedicated entity, the first dedicated entity comprising a first lower MAC sublayer (424b) and a first PHY layer (423), the first dedicated entity being dedicated to the first associated non-AP station; a second dedicated entity, the second dedicated entity comprising a second lower MAC sublayer (424b) and a second PHY layer (423), the second dedicated entity being dedicated to each of the second associated non-AP stations.

[0033] In some embodiments, a single service access point (SAP) is provided to the upper layers.

[0034] In some embodiments, a data flow of a first BSS and a data flow of the second BSS are processed independently at the upper MAC layer.

[0035] In some embodiments, the upper MAC sublayer is configured to receive an indication from the SAP that an incoming data flow belongs to the first BSS, the indication being configured to segregate the incoming data flow in accordance with the indication, the indication comprising: The value of the priority field, traffic identifiers, a Stream Classification Service Identifier (SCSID), which identifies an SCS stream characterized by a TCLAS Element and / or a TCLAS Processing Element; a local index determined by said SAP, or the address of the first associated non-AP station.

[0036] In some embodiments, the non-AP MLD is: a first upper MAC sublayer dedicated to the first associated non-AP station; a second upper MAC sublayer common to the second associated non-AP station; a first dedicated entity, the first dedicated entity comprising a first lower MAC sublayer (424b) and a first PHY layer (423), the first dedicated entity being dedicated to the first associated non-AP station; a second dedicated entity, the second dedicated entity comprising a second lower MAC sublayer (424b) and a second PHY layer (423), the second dedicated entity being dedicated to each of the second associated non-AP stations.

[0037] In some embodiments, the first BSS and the second BSS operate on different channels.

[0038] In some embodiments, the first BSS is a Wireless Fidelity (Wi-Fi) BSS.

[0039] In some embodiments, the Wi-Fi BSS implements the Wi-Fi Direct standard, and the P2P group identifier of the Wi-Fi BSS takes the Station Association Identifier (STA AID) value of the first associated non-AP station that acts as a Group Owner.

[0040] In some embodiments, a non-AP MLD is configured to provide a multilink information element to the AP, the multilink information element providing capability information for stations to join the P2P group.

[0041] In some embodiments, a first associated non-AP station is configured to communicate with the peer station on a first channel of the first BSS, and the at least one second associated non-AP station is configured to communicate with the AP on at least one second channel of the second BSS, and the non-AP MLD comprises: and reporting the P2P group and the first channel to the AP MLD by the at least one second associated non-AP station of the non-AP MLD.

[0042] In some embodiments, reporting the P2P group includes transmitting a P2P information element (IE).

[0043] In some embodiments, a P2P IE is sent to the AP MLD in a P2P Invitation Request frame sent to the AP MLD on the second channel by the at least one second associated non-AP station for transmission to another station connected to the AP MLD.

[0044] In some embodiments, the P2P IE is transmitted in a Multi-Link IE of a Probe Request frame.

[0045] In some embodiments, the Probe Request frame further comprises, in addition to the Multi-Link IE containing Group Owner (GO) information, a Reduced Neighbor Report (RNR) IE identifying the first non-AP associated station acting as a GO of the P2P group, wherein the RNR IE and the ML IE contain MLD ID and Link ID subfields that are set to the same values ​​but that are different from the respective subfield values ​​used for the second BSS.

[0046] In some embodiments, the non-AP MLD further comprises: The AP is configured to receive the P2P IE from the MLD in a Probe Response frame or in a Beacon frame on the second channel.

[0047] In some embodiments, the P2P IE is included in the per-STA profile in the first Basic Multi-Link IE.

[0048] In some embodiments, the beacon frame or the probe response frame further includes, in addition to the first Basic Multi-Link IE: an RNR IE that identifies the AP associated station in AP MLD and the non-AP associated station acting as a Group Owner (GO) of the P2P group; A second Basic Multi-Link IE including information of the AP associated station in the AP MLD; The MLD ID subfield in the RNR IE and Basic Multi-Link IE is used to indicate whether the reported AP belongs to the first or second BSS.

[0049] At least part of the methods according to the present invention may be computer-implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be generally 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.

[0050] 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, CD-ROM, hard disk drive, magnetic tape device, or solid-state memory device. A transient carrier medium may include a signal such as an electric 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 explanation of the drawings]

[0051] Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Figure 1]1 illustrates an exemplary wireless communication system in which embodiments of the present invention may be implemented; [Figure 2] 1 shows an example of a multi-link arrangement using 802.11be. [Figure 3a] Illustrates the process of forming a P2P group. [Figure 3b] Such a P2P simultaneous device is shown, with one MAC entity acting as a WLAN-STA and a second MAC entity acting as a P2P device. [Figure 4a] 1 shows a schematic diagram of a non-AP H-MLD communication device according to an embodiment of the present invention; [Figure 4b] 4b shows a schematic architecture of the communication device of FIG. 4a; [Figure 5] 1 illustrates an example block diagram of a multi-link arrangement according to an embodiment of the present invention; [Figure 6] 1 illustrates another exemplary wireless connectivity. [Figure 7a] 10 illustrates a possible implementation for advertising P2P device behavior for non-AP H-MLD devices. [Figure 7b] 10 illustrates an alternative embodiment of an MLO link information element. [Figure 8] 1 illustrates the main steps of a method for configuring a link for Wi-Fi Direct communication as operated by a P2P affiliate station of an H-MLD according to an embodiment of the present invention. [Figure 9] Device architectures are disclosed that represent two reference models of non-AP H-MLD 400 that may be used in embodiments of the present invention. [Figure 10] Device architectures are disclosed that represent two reference models of non-AP H-MLD 400 that may be used in embodiments of the present invention. [Figure 11a] 1 illustrates a process of a P2P invitation procedure for hybrid MLD according to an embodiment of the present invention. [Figure 11b]1 illustrates a process for a P2P invitation procedure for hybrid MLD according to an embodiment of the present invention. [Figure 11c] 1 illustrates a process for a P2P invitation procedure for hybrid MLD according to an embodiment of the present invention. [Figure 12] 1 illustrates a P2P group advertisement process over an infrastructure BSS according to an embodiment of the present invention. [Figure 12c] 1 illustrates a P2P group advertisement process over an infrastructure BSS according to an embodiment of the present invention. [Figure 12d] 1 illustrates a P2P group advertisement process over an infrastructure BSS according to an embodiment of the present invention. [Figure 12e] 1 illustrates a P2P group advertisement process over an infrastructure BSS according to an embodiment of the present invention. [Figure 12f] 1 illustrates a P2P group advertisement process over an infrastructure BSS according to an embodiment of the present invention. [Figure 13] 1 shows the format of an RNR (Reduced Neighbor Report) information element used in an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0052] The present invention will now be described by means of certain non-limiting exemplary embodiments and with reference to the drawings.

[0053] The techniques described herein may be used for various broadband wireless communication systems, including communication systems based on orthogonal multiplexing schemes. Examples of such communication systems include spatial division multiple access (SDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single-carrier frequency division multiple access (SC-FDMA) systems. SDMA systems can utilize different directions to simultaneously transmit data belonging to multiple user terminals. TDMA systems may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, with each time slot assigned to a different user terminal. OFDMA systems utilize orthogonal frequency division multiplexing (OFDM), which is a modulation scheme that partitions the overall system bandwidth into multiple orthogonal subcarriers or resource units. These subcarriers may also be referred to as tones, bins, etc. In OFDM, each subcarrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on subcarriers distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on blocks of adjacent subcarriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent subcarriers.

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

[0055] Although the examples are described in the context of a WiFi (RTM) network, the invention can be used in any type of wireless network, such as, for example, a mobile phone cellular network, which implements very similar mechanisms.

[0056] An AP may comprise, be implemented as, or be 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.

[0057] A non-AP station may comprise, be implemented as, or be known as a subscriber station, subscriber unit, mobile station (MS), remote station, remote terminal, user terminal (UT), user agent, user device, user equipment (UE), user station, or some other terminology. In some embodiments, a non-AP station may comprise a cellular telephone, a cordless telephone, a session initiation protocol ("SIP") telephone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a handheld device with wireless connectivity, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects disclosed herein may be incorporated into a telephone (e.g., a mobile phone or smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device configured to communicate over a wireless medium. In some aspects, a non-AP station may be a wireless node. Such a wireless node may, for example, provide 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.

[0058] An AP manages a set of stations that collectively organize their access to the wireless medium for communication purposes. The stations (including the AP) form a service set, hereafter referred to as a basic service set (BSS) (although other terms may be used). The same physical station acting as an access point may manage more than one BSS (and thus corresponding WLANs); each BSS is therefore uniquely identified by a specific basic service set identifier (BSSID) and managed by a separate virtual AP implemented within the physical AP.

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

[0060] Current discussions in Task Group 802.11be, as outlined in the October 2022 draft IEEE P802.11be / D2.2, will introduce multi-link operation (MLO) for MAC layer operation. MLO allows a multi-link device to establish or set up multiple links and operate them simultaneously.

[0061] A Multi-Link Device (MLD) is a logical entity that has more than one affiliate (AP or non-AP) station (STA) and has a single Medium Access Control (MAC) Service Access Point (SAP) for a Logical Link Control (LLC) that contains one MAC data service. Additionally, the MLD also has a single address associated with the interface that can be used to communicate over a Distributed Systems Medium (DSM).

[0062] Stations forming the same MLD may be partially or entirely co-located within the same device, or may be geographically distributed.

[0063] An Access Point Multilink Device (AP MLD) corresponds to an MLD in which each station (STA) associated with the MLD is an AP, hereafter referred to as an "affiliate AP."

[0064] Non-Access Point Multilink Device (non-AP MLD) corresponds to an MLD in which each station (STA) associated with the MLD is a non-AP station, called an "associated non-AP station."

[0065] When referring hereinafter to either an AP MLD or a non-AP MLD, the general term "station MLD" may be used.

[0066] In some literature, "multilink device", "ML device" (MLD), "multilink logical entity", "ML logical entity" (MLE), "multilink set", and "ML set" are synonyms for designating the same type of ML device.

[0067] The multiple associated non-AP STAs of the non-AP MLD can then set up communication links with the multiple associated APs of the AP MLD, thus forming a multilink channel. This can be done, for example, via traditional association procedures, i.e., ML Discovery, which includes passive scanning (ML beacons) or active scanning (ML Probe Requests and corresponding Responses), ML Authentication, and finally ML Setup, in which the non-AP MLD associates with the AP MLD (thus obtaining an Association IDentifier (AID)) and sets up ML links for its associated non-AP STAs with the APs associated with the AP MLD.

[0068] Links established for MLD (or "enabled links") are theoretically independent, meaning that channel access procedures (to the communication medium) and communications are performed independently on each link. Thus, 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 particular link).

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

[0070] Associated 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) or other wireless communication standards.

[0071] Thanks to multi-link aggregation, traffic associated with a single MLD can theoretically be transmitted over multiple parallel communication links, thereby increasing network capacity and maximizing utilization of available resources.

[0072] The terms "traffic" and / or "traffic stream," as used herein, are defined as data flows and / or streams between wireless devices.

[0073] 1 shows a wireless communication system in which several communication station devices 101-107, 110 transmit and receive data frames over a wireless transmission channel 100 of a wireless local area network (WLAN) under the control of a central station, i.e., an access point device (AP) 110. Direct communication between STAs can also be performed without the use of an access point (known as ad-hoc mode). The wireless transmission channel 100 is defined by an operating frequency band that can be a single channel, multiple channels forming a composite channel, or multiple separate channels (links) forming a multi-link operation.

[0074] In the following description, the terms "station" or "STA" may be used to describe a non-AP station operating on a given link, which may be a standalone non-AP station or an associated 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 associated AP station entity of an AP MLD device.

[0075] An exemplary situation for direct communication, which corresponds to a growing trend today, includes the existence of peer-to-peer (P2P, also known as Direct Link or "DiL") transmission between non-AP stations, e.g., STA 102 and STA 104, as shown by FIG. 1. Technologies supporting P2P transmission are, for example, WiFi-Miracast (RTM) or Wireless Display scenarios, or Tunneled Direct Link Setup (TDLS). Note that even if P2P flows are usually not numerous, the amount of data per flow can be enormous (typically low-compression video from 1080p60 to 8K UHD resolution).

[0076] Each STA 101-107 registers with 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 that uniquely identifies the STA. When an AP and a non-AP STA are associated APs of an ML AP device and associated non-APs of an ML non-AP device, respectively, they establish an ML association in which a unique AID is assigned throughout the non-AP MLD, and all associated non-AP STAs are identified by the same AID value on their respective operational links.

[0077] Stations 101-107, 110 are granted a transmission opportunity (TXOP) and can then compete with each other on a given link to access the wireless medium using Enhanced Distributed Channel Access (EDCA) contention to transmit (single-user (SU)) data frames. Stations can also use a multi-user (MU) scheme, in which a single station, typically the AP 110, is permitted to schedule MU transmissions, i.e., multiple simultaneous transmissions with other stations in the wireless network. One embodiment of such a MU scheme is adopted, for example, in the IEEE Std 802.11ax-2021 standard as the multi-user uplink and downlink OFDMA (MU UL and DL OFDMA) procedure.

[0078] FIG. 2 shows an example block diagram of a multi-link arrangement according to 802.11be.

[0079] A multilink logical entity or device may be viewed as a collection of two or more STAs, each operating on a particular link (frequency band) and with its own link-specific PHY and lower MAC layer.

[0080] An "AP Multilink Device" (AP MLD) is a multilink device where each associated STA is an AP. A client STA Multilink Device (Non-AP MLD) is a multilink device where each associated STA is a non-AP STA.

[0081] It should be noted that while the term "multilink set" may be used in some descriptions herein, the scope of the embodiments is not limited by this term. In some cases, other terms may be used, including, but not limited to, multilink logical entity (MLE), multilink AP logical entity (MLE AP), multilink non-AP logical entity (MLE STA or non-AP MLE STA), multilink device (MLD), multilink non-AP device (MLD AP), multilink non-AP device (MLD STA or non-AP MLD STA), and / or others.

[0082] 2, multiple APs 110 are included in a multi-link AP logical entity or device 210. Additionally, multiple STAs 230 are included in a multi-link non-AP logical entity or device 220.

[0083] APs 110-x, 110-y, 110-z and / or STAs 230-x, 230-y, 230-z may operate in accordance with one or more of IEEE 802.11a / b / g / n / ac / ad / af / ah / aj / ay, EHT, or another wireless communication standard.

[0084] In some embodiments, the associated AP 110 may be configured to operate in a frequency band that is different from the frequency band of at least one of the other associated APs 110 of the plurality of APs. In some embodiments, the associated AP 110 may be co-located with at least one of the other associated APs 110 of the plurality of associated APs encapsulated within the MLE AP 210.

[0085] In some embodiments, multiple associated APs 110 are co-located within an AP device 210 that supports simultaneous operation for one or more non-AP devices 220. There are different interfaces for links 201, 202, 203 between the AP 210 device and one non-AP device 220.

[0086] The AP MLD 210 may also communicate with other systems (e.g., distribution systems (DS) such as local area networks and / or broadband networks) via an interface 120 such as a backhaul interface (typically an Ethernet link).

[0087] MLD operation may allow simultaneous transmit / receive (STR) operation, i.e., one link is transmitting while another is receiving. Non-AP MLD may be STR or non-STR (NSTR).

[0088] Recently, 802.11b introduced the concept of non-simultaneous transmit / receive (NSTR) soft access point (AP) multilink devices (MLDs). The term NSTR mobile AP MLD is also used. Generally, soft AP refers to a software-enabled AP, meaning software that enables a device that is not specifically a router to become a wireless AP. IEEE 802.11be defined mechanisms to support non-STR AP MLD operation in Release 1 (R1). These mechanisms are restricted to instantiating non-STR non-AP MLDs as soft APs that can use all of their links with AP-like behavior. When a non-AP MLD operates as an AP MLD, the device becomes a soft AP MLD. However, when a non-AP MLD is a non-STR MLD as defined in IEEE 802.11 TGbe, it imposes some challenges on soft AP MLD operation due to the limitation that non-AP MLDs cannot simultaneously transmit and receive on non-STR link pairs. This soft AP MLD is typically found in mobile devices, which are battery-powered. Soft AP is a mechanism that allows a non-AP MLD station to temporarily switch to adopt AP functionality. A soft AP typically has limited capacity compared to a regular AP. The limitation can be considered bandwidth or the number of stations that can connect to the soft AP. In a non-ML context, an example of a soft AP is the connection sharing feature of modern smartphones. Note that a soft AP MLD has all its associated stations adopt the AP behavior.

[0089] 3a and 3b illustrate the Wi-Fi Direct mode of operation.

[0090] Wi-Fi Direct is a direct communication technology that can enable devices to easily connect to each other without an AP, which is fundamentally required in traditional WLAN systems. Wi-Fi Direct allows devices to connect to each other without complicated establishment procedures (device-to-device connectivity). Wi-Fi Direct allows Wi-Fi devices to connect directly to each other, making it easy and convenient to print, share, sync, play games, and display content on another device. Wi-Fi Direct devices connect to each other without the need to join a traditional home, office, or public network. Devices can make one-to-one connections, or a group of multiple devices can connect simultaneously.

[0091] Unlike the soft access point (AP) mode mentioned above in the context of 802.11 (where the mobile electronic device serves as an AP, allowing other clients to access it), the Wi-Fi peer-to-peer (P2P) mode of operation refers to a mode in which 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 can function as both a P2P group owner and a P2P client. The P2P client role performs non-AP STA functions. The P2P group owner has a role similar to the AP role, providing BSS functions and services for associated clients (P2P clients or legacy clients).

[0092] Direct device-to-device connectivity was already realized in the original IEEE 802.11 standard through its ad-hoc mode of operation, but this ad-hoc mode could not make its presence felt in the market due to several drawbacks or limitations in requirements, e.g., lack of efficient power saving support or extended QoS capabilities.

[0093] Wi-Fi Direct devices are designed in the context of 802.11a, g, or n. Therefore, Wi-Fi Direct does not benefit from recent 802.11be technologies such as multi-link operation.

[0094] Figure 3a shows the process of forming a P2P group.,Wi-Fi Direct connection is mainly carried out through three,processes, including device discovery, service discovery,,and group establishment.

[0095] Device Discovery: The device discovery process 300 is required when Wi-Fi P2P devices, e.g., first and second P2P devices (301, 302), become aware of each other in order to form a connection to establish a Wi-Fi P2P group. During this phase, the devices alternate between listening and searching states. The first P2P device searches for nearby Wi-Fi P2P devices by repeatedly performing channel scans of IEEE 802.11 channels by listening to social channels defined as channels 1, 6, and 11 in the 2.4 GHz band and searching these channels for a predetermined period of time. The basic operations of the device discovery process performed during Wi-Fi P2P group establishment are achieved by exchanging probe request and probe response messages of the IEEE 802.11 MAC protocol. These exchanges allow P2P stations to discover each other in the nearby environment.

[0096] Service Discovery: Service discovery 310 is performed after the device discovery process to provide the ability for each P2P device to exchange information about the services it can support. That is, each P2P device can identify the service protocols, services, etc. it can support through the exchange of request and response messages (346). Thus, P2P devices exchange queries to discover the set of available services and, based on this, decide whether to proceed with group formation.

[0097] Group Creation: The Group Owner (GO) negotiation process 311 is performed by a three-way exchange 345 of GO negotiation request, GO negotiation response, and GO negotiation confirm frames, whereby two devices agree on which device will act as the P2P GO and the other device will act as a client of the GO, and on which channel the group will operate, which may be, for example, in the 2.4 GHz or 5 GHz band.

[0098] Security provisioning 347 begins after discovery has occurred and, if necessary, each role has been negotiated in forming the group.

[0099] Once a P2P group is established, new P2P devices can discover and join the group using active or passive scanning mechanisms similar to those used in traditional Wi-Fi networks. Like a traditional AP, the P2P GO must announce itself via beacons (360) and support power-saving services for its associated clients. The P2P GO must also run a Dynamic Host Configuration Protocol (DHCP) server to provide IP addresses (not shown) to P2P clients.

[0100] If the Wi-Fi Direct Connection Setup between the devices is successful, the devices attempt to establish an audio-video session 312. Communication within the established P2P group uses WPA2-Personal security.

[0101] The AV control session (steps 341-342) initiates a TCP (Transmission Control Protocol) connection, with one of the P2P devices acting as a P2P Sink (e.g., 302) and the second as a P2P Source (e.g., 301) with respect to the AV data flow. The P2P source typically plays the role of a TCP server. The protocol operating on the control port is the Real Time Streaming Protocol (RTSP).

[0102] According to the standard, RTP (Real-time Transport Protocol) or RTCP (Real-time Transport Control Protocol) can be used as the data path for the AV data session 343, and RTSP can be used as the control path for the AV control session. The audio / video elementary streams generated by the P2P sources are packetized using the MPEG2-TS container format and encapsulated by RTP / UDP / IP headers before 802.11 packetization and transmission.

[0103] Some devices certified under the Wi-Fi Direct program simultaneously support connections to both infrastructure networks and Wi-Fi Direct groups (for example, a laptop may support infrastructure connections 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 achieve this, dual-MAC products that support two interfaces are used, rather than using only one interface for wireless communication.

[0104] Figure 3b shows such a P2P simultaneous device group with one MAC entity operating as a WLAN STA and a second MAC entity operating as a P2P device. The P2P group can operate in the same or different operating class and channel as the concurrently operating WLAN BSS.

[0105] Implementing multiple MAC functionality is outside the scope of the Wi-Fi P2P specification. In practice, as mentioned above, two 802.11 / Wi-Fi chipsets are used, which is an expensive and static architecture. Currently, P2P is primarily used for semi-static communication such as remote printing, photo sharing, and screen mirroring.

[0106] However, with the popularization of Wi-Fi devices and location-based services, the availability of P2P will gradually increase. The P2P devices that make up a Wi-Fi Direct group can change at any time due to the movement of P2P devices, and new Wi-Fi Direct groups can be dynamically created or deleted within a short period of time.

[0107] The Wi-Fi Direct standard does not provide a way to dynamically implement simultaneous links on modern chipsets, such as 802.11be.

[0108] With the increasing number of operating bands / channels, including the recent 6 GHz band operating bands / channels, traditional scanning of channels (active or passive) becomes too time consuming.

[0109] Additionally, specific to Wi-Fi Direct, P2P GO typically stays on the operating channel of a P2P group once it is established, which means that failure to switch to the social channel complicates the discovery and joining of new P2P devices.

[0110] Known discovery mechanisms are not sufficient to provide efficient network communication in wireless networks, and in particular are not sufficient to discover ad-hoc networks, including P22 groups, to facilitate direct device-to-device connections.

[0111] 4a shows a schematic representation of a non-AP H-MLD communication device 400 incorporating a plurality of non-AP stations 110 of a wireless network NETW, configured to implement at least one embodiment of the present invention. The communication device 400 may preferably be a device such as a microcomputer, a workstation or a lightweight portable device. The communication device 400 comprises a communication bus 413 preferably connected to: a central processing unit 401, such as a processor, denoted as CPU; a memory 403 for storing executable code of a method or method steps according to an embodiment of the present invention, as well as registers adapted to record variables and parameters necessary for carrying out the method; and At least one communication interface 402 connected via a transmit antenna and a receive antenna 404 to a wireless communication network, for example a communication network conforming to one of the IEEE 802.11 family of standards and / or the Wi-Fi (Wireless-Fidelity) standard.

[0112] Preferably, a communication bus provides communication and interoperability between the various elements included in or connected to the communication device 400. The representation of a bus is not limiting, and in particular a central processing unit is operable to communicate instructions to any element of the communication device 400 directly or by another element of the communication device 400.

[0113] The executable code may be stored in a memory, which may be read-only, on a hard disk, or on a removable digital medium, such as a disk. According to an optional variant, the executable code of the program may be received by a communications network via the interface 402, to be stored in the memory of the communications device 400 before being executed.

[0114] In one embodiment, the device is a programmable apparatus that uses software to implement embodiments of the invention, however, embodiments of the invention may alternatively be implemented wholly or partly in hardware (e.g., in the form of an application specific integrated circuit or ASIC).

[0115] 4b is a block diagram that schematically illustrates the architecture of a communications device 400 adapted to at least partially implement some embodiments of the present invention. As shown, the device 400 comprises a physical (PHY) layer block 423, a MAC layer block 422, and an application layer block 421.

[0116] The PHY layer block 423, here a number of 802.11 standardized PHY layer modules, is tasked with formatting, modulating, or demodulating any 20 MHz channel or composite channel. Thus, the PHY layer transmits and receives frames, such as 802.11 frames, over the wireless medium NETW. These frames can be, for example, medium access trigger frames for reserving transmission slots, MAC data, and management frames based on the 20 MHz width for interworking with legacy 802.11 stations and legacy Wi-Fi Direct standards, as well as OFDMA-type MAC data frames with a width smaller than the 20 MHz legacy (typically 2 or 5 MHz) to / from the wireless medium.

[0117] The MAC layer block or controller 422 preferably comprises a Multi-Link MAC 802.11 layer 424 that implements conventional 802.11 MAC operations. It may include additional blocks 425 for at least partially implementing embodiments of the present invention. The MAC layer block 422 may optionally be implemented in software, which is loaded into RAM 403 and executed by CPU 401. The ML MAC 802.11 layer 424 may implement an upper MAC stack with a series of lower MAC modules.

[0118] Preferably, an additional block 425 called P2P management module for performing multi-link operations for P2P traffic streams implements part of an embodiment of the present invention.

[0119] This block performs the operations of the methods shown in FIGS. 5-13 depending on the role of the communication device 400, a P2P device client, or a group owner peer.

[0120] The MAC 802.11 layer 424 and P2P link management module 425 interact to establish and manage proper communication over P2P links between multiple MLD non-AP stations that form a P2P group, according to an embodiment of the present invention. The MAC 802.11 layer 424 may comprise a single upper MAC layer 424a that manages multiple lower MAC layer modules 424b.

[0121] On Fig. 4b, the application layer block 421 executes applications that generate and receive data packets, e.g., video streams, etc. The application layer block 421 represents all stack layers above the MAC layer, according to ISO standardization.

[0122] 5 shows an example block diagram of a multi-link arrangement according to an embodiment of the present invention, illustrating a method of communication in a wireless network typically comprising a multi-link access point (AP) MLD 210, the wireless network comprising at least a first non-AP MLD 320 and a second non-AP station 330, which may be, for example, a legacy station.

[0123] The method comprises: Establishing a first connection represented by two links 201, 202 between a first non-AP MLD 320 and an AP MLD 210; Establishing a second connection, indicated by link 303, between the first non-AP MLD 320 and a second STA 330; Transferring data between the first non-AP MLD 320 and the AP MLD 210 via the infrastructure BSS established on the first connection; Transferring data between the first non-AP MLD 320 and the second STA 330 through the P2P group established on the second link; Includes.

[0124] It should be noted that the establishment of the first and second connections may occur in any order or simultaneously.

[0125] In summary, an embodiment of the present invention provides an extension to 802.11be multilink operation, which comprises enabling "P2P device" operation on the non-AP MLD 320 associated STAs 530, while other associated STAs remain non-AP STAs. Thus, the non-AP MLD STAs 320 are associated with two different networks that are a P2P group. Each associated STA is associated with one of the two networks. In other words, some associated stations are connected to different networks and form a P2P group, while other stations are connected to a regular BSS (infrastructure BSS managed by the AP MLD).

[0126] The term Hybrid MLD (H-MLD) is used to identify device 320 according to an embodiment, in which associated STAs are linked with two or more separate BSS entities. This means that associated STAs of an H-MLD do not communicate with associated STAs of the same MLD, but belong to different networks and operating bands. As further disclosed, data communication is separated between the separate P2P and infrastructure networks.

[0127] As will become apparent, P2P connections can be dynamically created by hybrid MLD without support from AP MLD. In some embodiments, two or more P2P connections can be established, meaning that an associated station is connected to a first P2P group and another associated station is connected to a second P2P group. According to a second aspect, discovery of such "P2P communication groups" can be made easier by AP MLD.

[0128] This diagram shows a non-AP STA 330 that is a multi-link station, which may be, but is not limited to, a legacy non-AP station, an 802.11be non-AP MLD with multiple associated non-AP STAs, or any H-MLD device 400 according to an embodiment.

[0129] FIG. 6 illustrates another exemplary wireless connectivity.

[0130] Traditionally, a non-AP STA associates with an AP to initiate its operation: 802.11be provides multilink setup between a multilink non-AP STA 220 and an AP MLD 210, achieving the functionality of a "traditional association" under the new multilink framework. Capabilities for different bidirectional links, such as link configuration, AP capabilities, and non-AP STA capabilities, can be exchanged through multilink setup.

[0131] As a result, at least one link 201 is established between the non-AP MLD 1 220 and its AP MLD 210 .

[0132] With respect to the H-MLDs 320 (H-MLD 1 and H-MLD 2), at least one link 201 is also established between each H-MLD and the AP MLD 210. Furthermore, according to an embodiment, at least one P2P link 303 is also established outside the control of the AP MLD 210 between each of the H-MLDs 1 and 2 forming the P2P group.

[0133] Among the set of established links, links 201, 202 serve infrastructure operations and link 303 serves direct P2P operations.

[0134] In some embodiments, links 201 and 303 may share operation on the same frequency.

[0135] Advantageously, link 303 does not interfere with links 201, 202, the medium access is separated and there are no problems due to heavy P2P traffic. Furthermore, since this link operates outside the network infrastructure, the AP MLD is relieved from managing P2P flows.

[0136] In some variations, a hybrid-MLD can be associated with any single-link AP (i.e., non-multi-link capable, as in previous technologies prior to 802.11be), and the H-MLD 320 can still instantiate P2P links in that context.

[0137] 7a shows a possible embodiment for advertising P2P device operation for non-AP H-MLD devices 400 in a management frame, such as a beacon frame or a probe response frame. As shown, a dedicated information element IE is used for advertising. The information element is widely used, i.e., the dedicated IE can be an addition to an existing IE in the management frame.

[0138] An information element, or IE, is a TLV (type-length-value) item. Of course, any combination of one or more of these parts is possible. For example, if the length value is fixed and known by all parties, it can be omitted.

[0139] The element ID subfield 701 identifies the IE as providing P2P device activation requirements. It can take on values ​​in the range [245-254], previously reserved in the 802.11 standard. For illustrative purposes, in some embodiments, the value 247 can be selected.

[0140] The length subfield 702 indicates the number of bytes that make up the IE, including the element ID and length subfields.

[0141] Bit 703 indicates whether a non-AP station can activate a P2P device in complement of a traditional infrastructure BSS, e.g., with a value set to 1, or whether it cannot activate a P2P device, e.g., with a value set to 0.

[0142] The Link ID Bitmap subfield 704 indicates the links to which P2P device operations apply for STAs affiliated with the non-AP MLD.

[0143] Preferably, the indicated links of the bitmap correspond to the links of the AP MLD, as shown below, but without being limited thereto, the H-MLD device 400 can instantiate links different from the AP MLD.

[0144] Figure 9 shows a reference model for Hybrid MLD, which is described in more detail below. Some aspects of the 802.11 Management Layer Structure will be described in relation to Figure 9.

[0145] The MAC and PHY layers conceptually include management entities called MAC Sublayer Management Entity 901 (MLME) and Physical Layer Management Entity 902 (PLME), respectively, which provide a layer management service interface that operates the layer management functions.

[0146] Additionally, a Station Management Entity (SME) 900 resides within each 802.11 device. The SME is a layer-independent entity that can be considered to reside within a separate management plane.

[0147] The MLME and SME interact in various ways. For example, the entities can interact by sending and receiving GET / SET primitives. A primitive represents a set of elements or parameters for a specific purpose. The "XX-GET.request" primitive is used to request the value of a given Management Information Base (MIB) attribute. The "XX-GET.confirm" primitive is used to return the appropriate MIB attribute value if the status is "success", otherwise it returns an error indication in the Status field. The "XX-SET.request" primitive is used to request that the indicated MIB attribute be set to a given value. If this MIB attribute implies a specific action, it requests that the action be performed. Then, the "XX-SET.confirm" primitive is used, and if the status is "success", it confirms that the indicated MIB attribute has been set to the requested value, otherwise it returns an error condition in the Status field. If this MIB attribute implies a specific action, it confirms that the action has been performed.

[0148] The MLME and SME can also send and receive various MLME_GET / SET primitives via the MLME Service Access Point (MLME_SAP) 911. Various PLME_GET / SET primitives may also be sent and received between the PLME and SME via the PLME_SAP 912, and between the MLME and PLME via the MLME-PLME_SAP 913.

[0149] After correlation of lower layer MLME and PLME events, the SME can synthesize indications to upper layer entities via SME SAP 910. Other aspects of the reference model illustrated by Figure 9 are described in detail below.

[0150] FIG. 8 shows the main steps of a method for configuring a link for Wi-Fi Direct communication as operated by a P2P affiliate of an H-MLD in an embodiment of the present invention.

[0151] In step 810, the hybrid MLD 400 notifies the AP MLD of the activation of the P2P device capabilities of the associated non-AP stations and closes the corresponding links to the AP MLD.

[0152] A Hybrid Non-AP MLD, as most WLAN connected devices, is equipped with a Management Information Base for storing a set of parameters that play a role in the behavior of the device. Embodiments provide specific capabilities specified in the dot11StationConfigTable in the H-MLD's local Management Information Base (MIB), which serves as a configuration interface for upper layers.

[0153] For example, a hybrid non-AP MLD is a non-AP MLD that sets dot11P2PDeviceMLDImplemented to true. This attribute, when true, indicates the ability of an EHT STA to support P2P Device Multilink operation on one of its associated stations for multilink operation. If the attribute is false, the station does not support P2P Device Multilink operation.

[0154] This information must also be advertised over the wireless medium.

[0155] For example, the EHT Capabilities element includes several fields used to advertise the EHT capabilities of an EHT STA. Typically, the included EHT MAC Capabilities Information field can be modified to support P2P devices according to an embodiment. The subfield "P2P Device in MLD Support" indicates whether a non-AP MLD device STA can be activated as a P2P device. This capability is reserved for AP MLD. For a non-AP MLD STA, when the previous MIB entry is configured, the subfield is set to 1 to indicate that the non-AP MLD STA can have at least one of its associated STAs operating as a P2P device. Otherwise, it is set to 0.

[0156] The EHT Capability element, as modified, is further declared by stations during the association procedure with the infrastructure BSS so that the AP can decide whether to grant or deny the requested association based on the declared capabilities. This may enable the centric AP MLD to determine which stations have P2P device capability and direct them to operate on the same link to facilitate the discovery process between them.

[0157] Another option is to provide a specific P2P device capability that indicates the Link ID to be used for the establishment (element 700, see FIG. 7a).

[0158] Other options are further provided in FIG. 11 and through the options below.

[0159] To activate P2P device operation, the MLME-START.request requests that the MAC entity start a new P2P device service through the EHT Capability Element or P2P Device Capability, along with an indication of the link ID.

[0160] The Link ID is indicated by non-AP STAs and provides a channel, called the Listen Channel, over which P2P device discovery occurs, as specified in the context of AP MLD.

[0161] Also, the H-MLD device 400 must perform an ML Reconfiguration operation so that the link corresponding to the link ID is closed for infrastructure use (AP MLD). One possibility consists in a multilink (re)setup procedure between the non-AP MLD 400 and the AP MLD, which is completed through the sending and receiving of (re)association request and (re)association response frames. As another simpler and more dynamic possibility, the deletion may consist in updating the TID-to-Link mapping with the TID not mapped to the intended link.

[0162] Note that the AP MLD is free to maintain its own activity on the designated link used for P2P operations.

[0163] In step 820, the H-MLD devices perform discovery on the dedicated link. The "P2P discovery" phase enables P2P devices to quickly find each other and form P2P connections on the intended link. Figure 11 and below provide enhancements for P2P discovery according to embodiments. In summary, these enhancements address the ability to operate P2P communications and fast discovery of the intended link.

[0164] One major action in this phase is Device Discovery, which uses Probe Request and Probe Response frames to send and receive device information on the desired link.

[0165] Compared to normal P2P discovery, there is no need to perform a scan on several channels, as the link ID refines the channel to be used, which acts as a common channel to enable communication.

[0166] In step 830, a group formation step is performed.

[0167] When a P2P device 400 discovers another P2P device 400 that it wishes to connect with, it can initiate a Group Formation Procedure on the intended link ID.

[0168] Typically, Group Owner Negotiation is performed by sending a "GO Negotiation Request" frame, where, among other parameters of interest, the Channel List attribute indicates only the channels of the link corresponding to the link ID as the single Operating Channel of the P2P group.

[0169] Furthermore, Wi-Fi Direct specifies that the P2P group owner assigns a globally unique P2P group ID to each P2P group when the P2P group is formed, which remains the same for the lifetime of that P2P group. Thus, embodiments assume that the station AID (obtained by the non-AP MLD during association with the AP MLD) is used as the P2P group ID.

[0170] This is also advantageous because the station AID is already known by other stations in the infrastructure BSS, as opposed to the individual MAC addresses of each associated station of device 400, such as a MAC address that may serve as the BSSID for the group owner BSS.

[0171] Once the P2P direct link is established, the P2P device acting as a client proceeds directly to step 860, while the group owner performs step 840, which is used to send beacon frames, and step 850, where other P2P devices can be admitted into the P2P group.

[0172] For beacon frames issued by the GO, the TSF timer set for the P2P link is preferably the same as the value indicated in the beacon frame received from the AP MLD for the infrastructure link.

[0173] Note that a searching P2P device discovers the P2P group owner during the scan phase via received beacon or probe response frames. Since the link used for the P2P group is (preferably) specified by the AP MLD, searching devices 400 operating on the link ID should know, due to their received beacon frames, that the P2P group owner has initiated its operation and may therefore attempt to join the P2P BSS.

[0174] In step 860, communication within the P2P group may begin.

[0175] P2P devices can communicate by streaming content, for example, by using a direct link session of the link. In the embodiment disclosed below, rules for traffic separation can be exchanged between two peers before data communication begins, as shown in Figure 9. In a variant, all traffic between the peers is conducted over the P2P group link, as shown in Figure 10.

[0176] As a result of the proposed embodiment, the H-MLD 400 is configured to simultaneously transmit different MSDU units to client stations of different Extended Service Sets (ESSs), stations in a P2P group, or AP MLDs. This is because all APs affiliated with the same AP MLD are members of the same ESS and are connected to the same distributed system. As a result, all APs affiliated with the same AP MLD advertise the same SSID.

[0177] Conversely, a P2P group is decoupled from the AP MLD ESS and has a single SSID prefixed with "DIRECT-" in the SSID field, providing a single security domain.

[0178] 9 and 10 disclose device architectures representing two reference models of a non-AP H-MLD 400 that may be used in embodiments of the present invention.

[0179] The two architectures are intended to be compatible with Wi-Fi Direct or Wi-Fi Direct upgrades. An upgrade is likely required, as the current version of Wi-Fi Direct is specified based on 802.11n and does not account for newer multi-link devices. The reference model presented below provides fully independent, simultaneous P2P group and WLAN operation.

[0180] For simplicity, FIG. 9 shows a reference model with two links, one P2P and one infrastructure, but in general, an MLD can support more than two infrastructure links, and an H-MLD 400 can support more than one P2P link.

[0181] In that reference model, an SME coordinates the management of multiple MAC sublayers and corresponding PHY layers. Preferably, the model maintains the classic 802.11be reference model, where a common MAC SAP and MLME SAP (SAP stands for Service Access Point) are used to control a common upper MAC and various lower MAC and PHY entities that form the associated STAs.

[0182] When instantiated by the SME, the associated P2P STA 530 activates some blocking functions for P2P traffic differentiation above the upper MAC component 950 but still inside the H-MLD 400.

[0183] In this case, the H-MLD device 400 still operates in an infrastructure BSS, but instantiates a P2P group for improved communication to P2P peers. Thus, incoming data traffic, whether P2P data traffic or WLAN data traffic, is destined for the same receiving device and belongs to the same VLAN ID when passing through the MAC SAP.

[0184] The low-level mechanisms occurring in the MLD Upper MAC sublayer 424a, MLD Lower MAC sublayer 424b, and PHY sublayer 423 allow operation over multiple links and remain standard: the MLD Upper MAC sublayer performs functions common across all links, while the MLD Lower MAC sublayer performs functions local to each link, essentially medium access.

[0185] There is also a new block called P2P Device Agent 531, whose purpose is to enable a pair of H-MLDs 400 to discover, synchronize, (de)authenticate, (re)associate, disassociate and manage resources with each other on the target P2P link. This actor may be partly or fully part of the P2P-associated STAs 530, as will be explained later, and may be activated through the SME SAP 910 to control the data plane.

[0186] During transmission, MSDUs from the MAC SAP pass through P2P Frame Mapping block 532 before being stored in the appropriate transmit or receive buffer 533 (new buffer dedicated to P2P data) or 543 (legacy buffer). This advantageously attributes separate block acknowledgment sessions to coordinate transmissions, P2P transmissions on the one hand and WLAN transmissions on the other.

[0187] P2P Frame Mapping 532 captures MSDUs directly from upper layers for routing to the appropriate buffers and providing proper sequencing.

[0188] Individually addressed data or management frames are intended for a given associated STA for wireless transmission, and therefore it is essential to differentiate traffic among the intended associated STAs. To perform in-data traffic separation, various non-limiting means may be contemplated: The use of traffic-to-link (TID) mapping is the first possibility for distinguishing incoming traffic between P2P and WLAN traffic. IEEE 802.11be defines a directionality-based TID-to-link mapping mechanism between MLD setup links. This mechanism allows a TID to be mapped to one or more links. Frames belonging to a TID are transmitted on the mapped links. Such traffic separation can support delay-sensitive traffic flows by allocating large amounts of delay-tolerant traffic flows to a subset of links while mapping delay-sensitive flows to all links. This is the role of the "Link Mapping (tx) and Merger (rx)" block in the MLD upper MAC 424a.

[0189] P2P Frame Mapping 532 provides a novel use of TID to link mapping aimed at separating infrastructure and P2P UL / DL flows.

[0190] By default, after multilink setup, all TIDs are mapped to all setup links. Dedicated TID values ​​may be reserved for P2P data. P2P link setup should include TID-to-link mapping renegotiation when TID-to-link mapping is supported by both MLDs.

[0191] Optionally, a set of higher TID values ​​may be dedicated for P2P traffic (e.g., 8-15 for P2P traffic). Such values ​​are called "Traffic Stream Identifier" (TSID) values ​​defined in the 802.11e standard. Traffic specified by such TSID values ​​may be characterized in a TSPEC element included in an ADDTS Request / Response frame. In other words, peers perform admission control of traffic to a P2P group based on this TSID. Note that admission control may be limited to the identification of a given traffic, such as minimum data rate, average data rate, and delay bound, but not its QoS characteristics.

[0192] Another possibility is to use the Stream Classification Service (SCS) mechanism, which allows a non-AP MLD to define and advertise AP MLDs for local traffic streams identified by an SCS identifier (SCSID). In essence, the SCS mechanism aims to distinguish between separate traffic streams within the same access category or the same TID. According to 802.11be, the TCLAS element and the TCLAS processing element describe the criteria for traffic classification that are applied to identify the data or MSDUs that form the corresponding SCS stream. Thus, a P2P device agent can establish an SCS stream with its peer non-AP MLD, indicating the traffic separation rules used to identify data for transport over a given link's P2P group.

[0193] Another mechanism that can be used is a QoS Map element that is sent between peers (e.g., a QoS Map Configure frame) and provides a mapping of higher layer quality of service configurations to user priorities for transmission. This element maps higher layer priorities from the DSCP field used with the Internet Protocol to user priorities. This mechanism results in TID assignment that allows P2P traffic to be identified.

[0194] In some embodiments, the Link Mapping / Merge block of the MLD Upper MAC 424a may be extended to support link switching according to SCSID and TID. In a variant, any MMPDU issued by the P2P device agent 531 or data frame stored in the P2P dedicated transmit buffer 533 includes an MLO Link Information element 750, shown in FIG. 7b, that identifies the intended link for forwarding.

[0195] According to the 802.11be standard, the MLO Link Information element identifies the intended link of the MMPDU that carries it. This element can also be applied to data frames. In this case, the Link ID Bitmap field 754 indicates only one link on which the intended peer STA is operating, i.e., the P2P link.

[0196] In some embodiments, P2P Device Agent 531 and P2P Frame Mapping 532 may be partially implemented in a higher layer, typically the Logical Link Control (LLC) sublayer (not shown), via the MAC layer. They can be viewed as software implementations within the network stack, interacting via SME SAPs to activate modules 531 / 532 in the MAC layer. With respect to P2P Frame Mapping 532, the tagging function may be easily performed at the LLC layer consisting of tagging (TID, SCSID) data before sending to the MAC SAP interface.

[0197] Another example of a reference model for the architecture of an H-MLD device is shown in Figure 10. In this approach, the P2P device functionality is performed by a virtual P2P STA.

[0198] The H-MLD device 400 configures at least one virtual P2P client, in which case a new Upper MAC 1030 is instantiated for that purpose, which is different from the Upper MAC (424a) common to the different associated non-AP STAs associated with the AP MLD.

[0199] A virtual P2P device is enabled by a combination of software and hardware. For example, a software module may control one of the underlying network interfaces to function as a P2P device in addition to other associated STAs operating as normal non-AP STAs.

[0200] The device 330 is configured as a virtual P2P device 1030 linked with a conventional Low-MAC / PHY 1040. In some embodiments, to dedicate the P2P link to the P2P group, the lower entity name given to the lower MAC sublayer and its associated PHY layer 1040 is decoupled from infrastructure operations, as indicated by cross 1050.

[0201] Each MAC sublayer is dedicated to a P2P virtual station and dedicated to normal WLAN operation, but as shown has separate MAC and SME SAPs 910. A MAC SAP, along with its corresponding MLME SAP, is identified by a dedicated MAC address, meaning that the H-MLD is given a dedicated MAC address for the P2P virtual station that is separate from the MAC address it uses for the WLAN.

[0202] In a variant not shown, the same SME SAP is used to control the entire MAC device, but a separate MLME is connected to the new virtual MAC, in which case the SME SAP can handle multiple MAC addresses.

[0203] In another variant not shown, the virtual MAC-SAP and SME-SAP are implemented via a common MAC-SAP and SME-SAP, but may have local indexes identifying the respective P2P SAPs.

[0204] Optionally, the architecture of Figure 10 can provide the advantage of providing simultaneous operation for WLAN BSSs on the same link. In this case, connection 1050 may or may not be dynamically maintained on the "P2P" link for legacy associated STAs. This method of operation allows the same primary channel to be used for co-located stations in the H-MLD; i.e., the same lower-order MAC and PHY pair is shared by the P2P group and the WLAN.

[0205] Nevertheless, this approach using virtual stations requires that MSDUs for peer STAs be routed directly to the appropriate MAC SAP, which must be performed by Layer 2 bridging outside the H-MAC due to the different MAC addresses attributed by the P2P virtual station and the BSS station.

[0206] In more detail regarding addressing, the V-MAC SAP exports the MAC address of the lower layer PHY 1040 as the P2P interface address. When concurrent operations are performed across 1040, the P2P associated STAs determine a new MAC address to be applied to P2P operations at 1040, different from the one used for infrastructure operations, and this address is also used by the V-MAC SAP for interactions within the P2P group.

[0207] The P2P SAP interface expires at the end of the P2P group session, which is when the virtual affiliated P2P station 1030 is deactivated.

[0208] According to a second aspect, the present invention aims to provide a new mechanism for improving the discovery of such "P2P communication groups" formed by related stations configured as P2P group owners.

[0209] According to an embodiment, a second associated station (230) operating in the WLAN transmits a P2P discovery frame indicating that the first associated station (530) is the P2P group owner, as shown in Figure 11. In some embodiments, as shown by Figures 12-12f, the second associated station operating in the WLAN can report the P2P group to APs of the infrastructure BSS to allow existing APs to advertise the communication group over their operating channels.

[0210] Stations operating on the same channel or link as an existing AP MLD become aware of the P2P group without having to scan multiple channels, and may then decide to join the P2P group by switching to the corresponding operating channel and establishing a new (P2P) link on that channel.

[0211] The operating link of a P2P GO in a hybrid MLD may or may not be operated by an infrastructure AP, and therefore the link ID value used to identify the P2P link may be independent of the link ID advertised by the infrastructure AP, meaning that embodiments provide support for various channels or links for P2P and infrastructure operation and are more efficient for data communication.

[0212] Thanks to this support for advertising P2P communication groups, the average time required by a station to discover a group is reduced, and thus the initial link setup time for establishing a communication link between, for example, a P2P device and a soft AP (P2P GO) is substantially reduced.

[0213] 11a-11c show a process for a P2P Invitation procedure for a hybrid MLD according to an embodiment. This embodiment is advantageous when a hybrid MLD wishes to invite a known remote device to join a P2P group that it has hosted at one of its associated stations. By known device, we mean a station of an infrastructure BSS, which provides capability information 703 for joining a P2P group, as described above in connection with FIG. 7a.

[0214] The P2P invitation procedure is an optional procedure that is typically used by a P2P group owner to invite P2P devices to become P2P clients in its P2P group.

[0215] To signal P2P attributes in exchanged Management frames, P2P protocol communication is based on the use of the so-called P2P Information Element (P2P IE, 1180) shown in Fig. 11a. It is based on the Vendor Specific Information Element as defined in IEEE Std 802.11-2012, where Element ID 1181 is set to 0xDD to signal the P2P IE, Length field 1182 indicates the length of the IE in bytes, WFA OUI field 1183 indicates the WFA-specific organization identifier, and OUI Type field 1184 indicates the P2P version. WFA refers to Wi-Fi Alliance, and OUI refers to OUI to Organization Unique Identifier.

[0216] Several P2P attributes 1190 are defined. A single P2P IE may carry one or more P2P attributes 1190. P2P attributes 1190 are defined to have a common general format consisting of a one-octet P2P Attribute ID field, a two-octet Length field, and a variable-length attribute-specific information field.

[0217] The P2P invitation request / response frame is a Public Action frame (1100), as shown in Figure 11b.

[0218] The Category field 1101 takes the value 4 to identify the use of IEEE 802.11 public actions.

[0219] The Public Action field 1102 in the octet immediately following the Category field distinguishes between different Public Action frame formats: a value of 9 indicates vendor-specific use.

[0220] The Organization Unique Identifier (OUI) field 1103 is three octets in length and takes the hexadecimal value "50 6F 9A" for the Wi-Fi Alliance specific OUI.

[0221] The OUI subtype identifies the type of P2P public action frame (for the previously specified OUI): value 3 for a P2P invitation request, value 4 for a P2P invitation response.

[0222] Dialog Token 1106 is set to a non-zero value to identify a request / response transaction.

[0223] The Element field 1107 is variable in length and contains any information element defined in the P2P IE (1180) or IEEE 802.11-2020.

[0224] A P2P invitation request frame sent to the AP MLD by an associated station 230 collocated with a P2P group owner in a hybrid MLD contains the P2P Group ID, P2P Group BSSID, Channel List, Operating Channel, and Configuration Timeout attributes in the P2P IE (in Elements 1107) corresponding to the P2P group.

[0225] The Operating Channel attribute indicates the operating channel of the P2P group operated by the GO, which corresponds to the channel of the link on which the GO is located. The Channel List attribute usually indicates the channels and Operating Classes that the P2P device can support. Therefore, it is limited to the values ​​taken by the Operating Channel attribute of the P2P group, since channel negotiation is not intended.

[0226] The P2P Group ID attribute (Attribute ID = 15) contains a unique P2P group identifier for the P2P group, for example formed by the pair {P2P device address, and SSID} of the P2P group owner. As previously disclosed, the P2P group identifier takes the Station Association Identifier (STA AID) value of the first associated non-AP station acting as the group owner.

[0227] The P2P device information attribute (Attribute ID = 13) contains information about the P2P device (such as device address, configuration method, and device name).

[0228] Set the Client Configuration Timeout field of the Configuration Timeouts attribute to 0.

[0229] The Invitation Flags attribute contains flags used in the P2P invitation procedure and intended to distinguish the use of P2P invitation requests. Currently, only bit 0 is used, which is set to 1 to indicate a P2P invitation request to restart a persistent group, or set to 0 to indicate a P2P invitation request to join an active P2P group. Use the value 0.

[0230] Additionally, one could consider using bit 1 (which means currently reserved and not in use) to indicate that the invitation is provided by a device that is not a member of the P2P group (as 230 in the context of hybrid MLD).

[0231] 11c illustrates the delivery of a P2P invitation request / response frame, according to an embodiment. A P2P invitation request frame 1110 is transmitted by non-AP STA2 230-y of device 320 toward device 1130. This device may be a legacy device, such as device 330 of FIG. 5, or a hybrid MLD 1130 as shown in FIG. 11c. In the latter case, device 1130 can use information in the received P2P element of the P2P invitation frame, i.e., the P2P attribute, to set up an associated station 1130-z on link 3, where channel "z" corresponds to the operating channel of the P2P group.

[0232] In particular, since two non-AP MLDs 320 / 1130 are performing multilink setup with the same AP MLD 210 , the path for the P2P invitation request frame 1110 travels via the AP MLD and further reaches the device 1130 .

[0233] Frames that traverse the intermediate AP MLD are sent or received by non-AP STAs affiliated with the non-AP MLD 1130. As shown in the figure, a P2P invitation request frame is sent on link 2 by an associated station 230-y of the non-AP MLD 320 to an associated station 1130-y of the MLD 1130.

[0234] The addressing of the P2P invitation request frame (1110) is as follows: The value of the Address 1 (DA / RA) field in the MAC header of the frame is the MAC address of the receiving STA affiliated with the MLD corresponding to that link, for example, the MAC address of station 1130-y.

[0235] The value of the Address 2 (TA / SA) field in the MAC header of the frame is the MAC address of the sending STA affiliated with the MLD corresponding to that link, eg, the MAC address of station 230-y.

[0236] The value of the Address 3 field (BSSID) in the MAC header of the frame is set to the BSSID of the AP affiliated with the AP MLD corresponding to that link, eg, the BSSID of AP2 110-y.

[0237] The P2P invitation response frame is then preferably issued over the direct link 303. The initiating non-AP MLD 1130 can determine the link on which the peer STA or non-AP MLD is operating, and all information in the P2P element in the request is useful for that determination.

[0238] The P2P invitation response frame 1120 uses the P2P public action frame format.

[0239] As a result, the dialog token field 1106 is set to a non-zero value received in the P2P invitation request frame to identify the request / response transaction. Note that this token is set by the second associated station 230 in the P2P invitation request frame and received by the P2P GO 530 in the P2P invitation response frame, and therefore this value must be internal between the two associated stations of the non-AP MLD 320.

[0240] The Elements field in a P2P Invitation Response frame contains a P2P IE containing a Status attribute used to signal status information in the response frame of an Invitation Request-Response transaction. This value can be 0 (success) if the invitation is accepted, otherwise the Status attribute is set to an appropriate failure code such as 2 (failure; incompatible parameters) or 7 (failure; no common channel), the Configuration Timeout attribute maintains the value 0 if there is no common link between the two peers, the Operating Channel attribute maintains the same value as the equivalent attribute in the request, the P2P Group BSSID attribute maintains the same value as the equivalent attribute in the request, and the Channel List attribute is the same as the equivalent attribute in the request.

[0241] The addressing of the P2P invitation request frame (1110) is as follows: the values ​​of the Address 1 (DA / RA) field and Address 3 field (BSSID) in the MAC header of the frame take the BSSID of the intended P2P GO, and the value of the Address 2 (TA / SA) field in the MAC header of the frame is the MAC address of the sending STA affiliated with the MLD corresponding to that link, e.g., the MAC address of station 230-y.

[0242] This addressing may be per bit 1 of the invitation flags attribute to indicate that the recipient of the invitation response is not a P2P device in the intended P2P group, and then the response should be addressed to the P2P GO.

[0243] As a result, sending and receiving P2P invitation frames can be viewed as new out-of-band device discovery using associated stations in a hybrid MLD.

[0244] The invited device can then listen for management frames from the P2P GO on the link and associate with it.

[0245] 12-12f illustrate a process for advertising a P2P group over an infrastructure BSS according to an embodiment of the present invention.

[0246] The following description refers to the Multi-Link procedure, as beacon and probe frames contain the Multi-Link Information element introduced by 802.11be. Legacy devices, i.e., devices using standards prior to 802.11be, can still understand these frames but ignore the ML information element.

[0247] Management frames sent and received during the ML discovery and ML setup procedures contain a new information element specific to multi-link operation (MLO), called the Basic Multi-Link Element, which carries a description of the associated STA entities in the MLD transmitting the frame other than the sender's associated STA entity, known as the "reporting STA." More precisely, the reporting STA's profile is provided in an information element (IE) in the frame outside the Basic Multi-Link Element. The Basic Multi-Link Element carries one or more Per-STA Profile subelements corresponding to each additional associated STA, known as a "reported STA," within the same MLD. The ML discovery procedure enables a non-AP MLD to discover various links to the wireless communication network 100, i.e., AP MLDs provided by multiple affiliate APs. The ML discovery procedure therefore seeks to advertise the various associated APs in the AP MLD along with their respective network information, including, for example, all or part of their capabilities and operating parameters.

[0248] In active scanning, a non-AP STA sends a probe request frame (with a wildcard SSID) and waits for a probe response frame from the AP. Therefore, the active discovery process mainly relies on the transmission and reception of probe request and probe response frames between the AP and the non-AP. In the case of ML discovery, the discovery procedure can be performed by using either link-by-link probe request / response frame transmission and reception, or a single ML probe request / response frame exchange that carries all information of the various APs affiliated with the AP MLD on one of the available links.

[0249] The current 802.11be revision also defines a specific multilink element, the so-called Probe Request Multilink Element, for the Probe Request frame in which a Probe Response frame can be sent by the AP MLD. The Probe Request Multilink Element is used to request the Reporting AP to provide information (full or partial profiles) of other (Reported) APs affiliated to the same AP MLD as the Reporting AP. The Probe Request Multilink Element contains a Per-STA Profile field for each requested Reported AP.

[0250] Figure 12a of Figure 12 illustrates a schematic of a probe request frame 1210 according to IEEE 802.11b, where a probe request multilink element 1215 includes common information and one per-STA profile for each requested reported AP.

[0251] Since either the Address 1 or Address 3 field of the Multilink Probe Request is set to the MAC address of the responding AP operating on the same link on which the Multilink Probe Request is sent, the AP MLD ID subfield shall be present in the Probe Request Multilink Element of the Multilink Probe Request, and it shall be set to the same AP MLD ID value used by the AP in the Beacon frame, so that the target AP MLD is identified by the AP MLD ID subfield.

[0252] If the Probe Request Multilink Element in the Multilink Probe Request does not include a Per-STA Profile, then all APs affiliated to the same AP MLD as the AP identified in the Address 1 or Address 3 field or AP MLD ID of the Multilink Probe Request are the requested APs.

[0253] As shown in the figure, the AP MLD ID is set to an exemplary value "j" as advertised by the AP MLD in beacon frames emitted on the various setup links.

[0254] Figure 12b of Figure 12 illustrates schematically the contents of a multilink probe request frame 1220 according to an embodiment of the present invention.

[0255] The ML probe request frame 1220 adds new elements 1240 and 1250 to the original frame 1210 .

[0256] Element 1240 is a conventional abbreviated Neighbor Report (RNR) information element, even though such elements are not expected to be inserted into ML probe request frames according to the IEEE 802.11 standard. Element 1250 is a new multilink element that carries only information about the AP, as indicated in RNR 1240 of ML probe request 1220. In some embodiments, multilink element 1250 is based on the format of the basic ML element.

[0257] As previously discussed, the Multi-Link Probe Request allows a non-AP STA associated with a non-AP MLD to request that an AP associated with the AP MLD include a full or partial set of capabilities, parameters, and operational elements of an AP associated with the target AP MLD (identified by 1215). This new format of the Multi-Link Probe Request 1220 allows a second non-AP STA associated with the non-AP MLD to inform the AP MLD, via the AP associated with the link, of the existence of a full or partial set of capabilities, parameters, and operational elements of a P2P Go / softAP (soft AP) operated by a first associated station in the hybrid MLD.

[0258] Traditionally, a Multilink Probe Response is a probe response frame sent in response to a received Multilink Probe Request and containing basic Multilink elements that can carry full or partial profiles for each of the requested APs associated with the target AP MLD based on the probe request. Thus, only the APs associated with the Probe Request ML element 1215 are carried in the ML Probe Response (i.e., the ML Probe Response does not carry information about 1250).

[0259] The AP MLD ID for infrastructure AP MLD operation takes the value advertised by the AP MLD, for example, the value "j".

[0260] As a result, the AP MLD IDs in the RNR 1240 and ML elements 1250 are set to different values, eg, the value "i," to indicate that these elements do not pertain to an infrastructure BSS.

[0261] FIG. 13 shows the format of a Reduced Neighbor Report (RNR) information element 1300.

[0262] A specific value is provided when the RNR 1300 is the RNR 1240 included in the ML probe request frame 1220.

[0263] The RNR element 1300 contains channel and other information about neighboring APs, including "reported APs" in the context of a multi-link environment.

[0264] The element ID field 1301 is equal to the value 101, which indicates that the information element is an RNR element. The length field 1302 specifies the length of the information element in octets, including the Neighbor AP information field 1303.

[0265] Neighbor AP Information Fields field 1303 contains a set of one or more ("n" in the illustrated example) Neighbor AP Information Fields 1320, each Neighbor AP Information Field providing element or network information about a neighboring or "reported" AP different from the reporting AP (the AP sending the information element). Specific to RNR 1240, n is equal to 1, since there is only one P2P GO in a hybrid MLD, which is a simple link. Of course, more than one P2P GO may be envisioned in a hybrid MLD, each on a given link (and therefore a separate operating class and channel), and individual elements 1321 must be considered.

[0266] Each Neighbor AP Information field 1320 comprises a Target Beacon Transmission Time (TBTT), represented in a Time Unit (TU) Information Header subfield 1321, an Operation Class subfield 1322, a Channel Number subfield 1323, and a TBTT Information Set subfield 1324, all relating to a given reported AP.

[0267] The TBTT Information Header subfield 1321 contains several fields that indicate how many TBTT information fields 1330 are present in the TBTT Information Set subfield 1324 (e.g., TBTT Information Count, which indicates the number of TBTT information fields contained in 1324), and their length type (the TBTT Information Field Type has a value of 0 or 1 for 802.11 devices operating in bands greater than 1 MHz). Multiple reported APs with the same operating channel are reported in the same TBTT Information Set subfield 1324 ("p" in the illustrated example). Specific to the RNR 1240, p is equal to 1 because there are only P2P GOs being reported.

[0268] The Operating Class field 1322, together with the Channel Number field 1323, indicates the channel starting frequency that defines the primary (and therefore operating) channel of the BSS of the reported AP corresponding to its Neighbor AP Information field 1320. Specific to the RNR 1240, these fields correspond to the operating link of P2P GO in hybrid MLD.

[0269] Each TBTT information field 1330 comprises various fields, including a neighbor AP TBTT offset subfield 1331, a BSS parameters subfield 1340, and possibly an MLD parameters subfield 1350.

[0270] The Neighbor AP TBTT Offset subfield 1331 indicates the offset in TUs, rounded down to the nearest TU, from the TBTT immediately preceding the reporting AP sending this element to the next TBTT of the reporting AP's BSS. A value of 254 indicates an offset of 254 TUs or greater. A value of 255 indicates an unknown offset value. The RNR 1240 can consider using 255, and in fact the TBTT is the same as the TBTT of the infrastructure BSS.

[0271] The BSS parameters subfield 1340 contains various fields, including the following: - The OCT Recommended subfield 1341 is set to 1 to indicate that on-channel tunnel (OCT) is recommended to exchange MMPDUs with the reported AP identified in the TBTT information field (set to 0 otherwise). The RNR 1240 may consider using the value 0.

[0272] The Same SSID subfield 1342 is set to 1 to indicate that the reported AP has the same SSID as the reporting AP (set to 0 otherwise). The RNR 1240 may consider using the value 0.

[0273] - The Multiple BSSID subfield 1343 is set to 1 to indicate that the reported AP is part of a multiple BSSID set (set to 0 otherwise). The RNR 1240 may consider using the value 0.

[0274] - The Transmitted BSSID subfield 1344 is set to 1 to indicate that the reported AP is a transmitted BSSID (otherwise it is set to 0). The RNR 1240 may consider using a value of 0.

[0275] - The Member Of ESS With 2.4 / 5 GHz Colocated AP subfield 1345 indicates whether the reported AP is part of an ESS with no 6 GHz-only APs that can be detected by STAs receiving this frame. This means that all APs operating in the 6 GHz band that are part of that ESS that can be detected by STAs receiving this frame can be discovered in the 2.4 GHz and / or 5 GHz bands. RNR 1240 may consider using a value of 0.

[0276] - The Unsolicited Probe Responses Active subfield 1346 is set to 1 to indicate that the reported AP is part of an ESS and that all APs are sending unsolicited probe response frames every 20 TU or less (this is for scanning operation at 6 GHz) (otherwise it is set to 0). The RNR 1240 may consider using the value 0.

[0277] - The Colocated AP subfield 1347 is set to 1 to indicate when the reported AP is in the same co-located AP set as the sending / reporting AP (set to 0 otherwise). The RNR 1240 may consider using a value of 1 because P2P GO is co-located with associated stations associated with the AP MLD. This bit simply helps the receiving device determine that the reported neighbor AP is in a hybrid MLD.

[0278] The MLD Parameters field 1350 contains information about the link associated with the reported AP, and includes, among other things, an AP MLD ID subfield 1351, a Link ID subfield 1352, a BSS Parameters Change Count subfield 1353, an All Updates Included subfield 1354, and a Disabled Link Indication subfield 1355.

[0279] The AP MLD ID subfield 1351 specifies the identifier of the AP MLD to which the reported AP is affiliated. Note that RNRs are classically sent by APs, not by non-AP stations, as in this embodiment of the invention. If the reported AP is affiliated to the same MLD as the reporting AP, the MLD ID subfield 1351 is set to 0. Otherwise, if the reported AP is part of another AP MLD, the AP MLD ID subfield 351 is set to a value higher than 0. According to an embodiment, the AP MLD ID subfield is set to a value selected by the reporting non-AP station (e.g., 230-y) to uniquely identify the MLD of the reported P2P GO (with respect to Figure 12b in Figure 12, the AP MLD ID in RNR 1240 and ML element 1250 is set to the value "i"). Preferably, the MLD ID value is selected taking into account existing values ​​used in infrastructure BSSs: when multiple BSSIDs are set up by an infrastructure AP, the value used is 2 n Higher than -1 and lower than 255 (n, which corresponds to the value of the MaxBSSID indicator for infrastructure APs).

[0280] The Link ID subfield 1352 is a unique identifier (within the MLD) of the link corresponding to the reported AP. The Link ID subfield 1352 is set to 15 if the reported AP is not part of the AP MLD or if the reporting AP does not have that information. The RNR 1240 can consider using any value as it is unique in the context of the new MLD ID. Alternatively, the Link ID value of the P2P GO link is set to the same value (if any) that identifies the same link by the infrastructure AP MLD, e.g., corresponding to Link 2 as shown by FIG. 12f.

[0281] The BSS Parameter Change Count subfield 1353 contains a counter that is incremented modulo 255 each time a critical parameter of a BSS managed by the reported AP is updated in a beacon frame. The Include All Updates subfield 1354 indicates whether, in the case of an update, all updated elements are present in the current RNR report. It is therefore set to 0 in the RNR 1240.

[0282] The Invalid Link Indication subfield 1355 is set to 1 if the reported AP is operating on a link that is advertised as invalid and the reported AP is affiliated with the same AP MLD as the reporting AP. Therefore, it is set to 0 in the RNR 1240.

[0283] As defined in this manner, the MLD parameters field 1350 allows a link to be made (through the link ID subfield 1352 and the MLD ID 1351) between the neighbor AP information field 1320 defining the reported AP in the RNR element 1240 (format 1300) and the corresponding per-STA profile sub-element for the same reported AP in the multilink element 1250. This is shown, for example, in Figure 12b of Figure 12 through the arrows.

[0284] Returning to Figure 12b of Figure 12, the ML element 1250 consists of a common information field and a per-STA profile, both of which can carry the P2P IE 1180.

[0285] Preferably, the P2P IE 1180 includes a P2P group ID, a P2P group BSSID, a channel list, an operating channel, and a configuration timeout attribute in the P2P IE corresponding to the P2P group. These are a subset of the P2P elements required to locate and identify a P2P group. Of course, this subset can be further reduced by omitting the channel list and operating channel elements, as already disclosed in the RNR's operating class 1322 and channel number 1323.

[0286] FIG. 12c shows the format of a beacon or ML probe response frame 1260 as transmitted by the infrastructure AP MLD 210 upon receipt of the ML probe request frame 1220 by one of its associated APs (eg, 110-y).

[0287] Because the AP MLD 210 is multilink, the RNR can be used to provide information (full or partial profiles) of other reported APs affiliated with the same AP MLD, and elements 1320b and 1320c reference the per-STA profile for each reported AP in the basic multilink element 1216.

[0288] The illustrated RNR 1241 embeds these pieces of information (1320b, 1320c) and adds the new reported AP outside the AP MLD 210. The new Neighbor AP Information field 1320a is inserted based on the received RNR 1240 in the ML Probe Request frame 1220 of Figure 12b of Figure 12 and forwards the detailed information present in the Multilink element 1250. Thanks to the dedicated MLD ID, the RNR 1320a identifies the ML element 1250 and the per-STA profile including the P2P IE 1180.

[0289] Having a reduced set of P2P attributes in frame 1220 aims to avoid cluttering management frames for ML probe responses 1260, as these elements are reposted by the AP MLD in beacons or ML probe response frames 1260.

[0290] Alternatively, the P2P IE 1180 may contain all P2P elements that may be obtained via a beacon frame on the target link (P2P Capability, P2P Device ID, Listen Channel, Extended Listen Timing, P2P Device Information, Operating Channel, Service Hash), which helps a receiving non-AP station that wants to join a P2P group directly issue a probe request frame, as shown by the example frame 1270 of FIG. 12d.

[0291] Figure 12e shows alternative embodiments of an ML probe response, which may also be used in beacons emitted by soft AP / GOs.

[0292] These embodiments provide that a soft AP (P2P GO) can advertise in its beacon / probe response frame 1280 that at least one of its co-located affiliate stations is operating with an AP of an infrastructure BSS, in addition to the information about the P2P group provided in the P2P IE 1180. Thus, a device intending to operate as a P2P device for a P2P link can more easily select a P2P group for which the GO is embedded in a hybrid MLD for the intended infrastructure BSS.

[0293] This can be supported by the insertion of at least one Neighbor Report (NR) element: The neighbor element may be an RNR 1281 as shown in Figure 12d, which includes several neighbor AP information fields 1320a and 1320b, each indicating a reported AP for infrastructure AP MLD. Furthermore, it is assumed that the MLD parameter subfield format 1350 provides one of its reserved bits (B22-B23) to indicate a "P2P Concurrent Device" capability. This bit informs the receiving peer that a hybrid MLD affiliate non-AP STA operates with that link as a P2P concurrent device (in other words, a GO can operate on a first link to a WLAN STA simultaneously on a second link for the infrastructure WLAN specified by the RNR element).

[0294] The neighbor element may be formed from several neighbor report elements 1282a and 1282b according to the IEEE 802.11 format, each corresponding to a reported AP in infrastructure AP MLD. Similar to the modified RNR, the Capabilities subfield is expected to provide one of its reserved bits (B4-B5) as a capability of non-AP associated STAs in hybrid MLD to indicate "P2P simultaneous device" mode.

[0295] A Neighbor Element may be formed from several Multiband Elements 1283a and 1283b according to the IEEE 802.11-2020 format, each corresponding to a reported non-AP STA in Hybrid MLD. The Band ID field provides identification of the frequency band associated with the provided Operational Class and Channel Number fields, thus unambiguously identifying the associated STA. The STA Role subfield (within the Multiband Control field) specifies the role the transmitting STA plays on the channel of the Operational Class indicated in this Multiband Element. Perhaps a new value for STA Role will be envisioned in Table 9-265 of IEEE 802.11-2020 to indicate a "Hybrid MLD" role (in other words, P2P simultaneous device operation by this associated STA in Hybrid MLD). Note that this Multiband information is not intended for fast BSS switching as a legacy Multiband Element. In this embodiment, this allows a multi-band capable P2P device to support two or more frequency bands for simultaneous WLAN operation (the BSSID field specifies the BSSID of the infrastructure BSS operating on the channel and frequency band indicated by the Channel Number and Band ID fields).

[0296] FIG. 12f illustrates the link positions of the various management frames 1220, 1260, 1270, and 1280 described in connection with the previous figures, according to an embodiment.

[0297] Management frame 1220 is a probe request frame sent by an affiliate non-AP STA according to an embodiment of the present invention to report a P2P group to the AP MLD.

[0298] Management frame 1260 is sent by AP MLD to stations and, according to an embodiment of the present invention, is a beacon frame or probe response frame reporting a P2P group to stations in an infrastructure BSS. The reported information corresponds to the information received in probe request 1220.

[0299] The management frame 1270 is a classic probe request frame containing a P2P attribute (1180) and is sent to the P2P GO on operational link 3.

[0300] Management frame 1280 is a probe response sent by soft AP / GO on link 3 in response to probe request 1270 according to an embodiment of the present invention, reporting AP MLD for hybrid MLD and / or AP associated stations for non-AP associated stations according to the embodiment of Figure 12e.

[0301] Any step of an algorithm of the present invention may be implemented in software by execution of a set of instructions or programs by a programmable computing machine such as a PC ("personal computer"), a DSP ("digital signal processor") or a microcontroller, or in hardware by a machine or dedicated component such as an FPGA ("field programmable gate array") or an ASIC ("application specific integrated circuit").

[0302] Although the present invention has been described with reference to particular embodiments, the present invention is not limited to those embodiments and modifications will be apparent to those skilled in the art that are within the scope of the present invention.

[0303] Many further modifications and variations will be suggested to those skilled in the art by reference to the exemplary embodiments described above, which are not intended to limit the scope of the invention, which is determined solely by the appended claims. In particular, different features from the various embodiments can be interchanged as needed.

[0304] Each of the above-described embodiments of the present invention can be practiced alone or in combination with other embodiments, and features from various embodiments can be combined as needed or where a combination of elements or features from the individual embodiments in a single embodiment is beneficial.

[0305] 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 used to advantage.

Claims

1. A method of transmission in a wireless network, comprising: Configuring a first associated non-AP station of a non-access point (non-AP) multi-link device (MLD) as a peer-to-peer (P2P) station for communicating with peer stations in a first basic service set (BSS) forming a P2P group; configuring at least one second associated non-AP station of the non-AP MLD as a station for communication with the AP in a second BSS; A method comprising:

2. The method of claim 1 , wherein the second associated non-AP station of the non-AP MLD is configured to communicate with a respective associated AP station of an AP MLD.

3. The method of claim 2 , wherein the first associated non-AP station stops transmitting to the AP MLD when configured to communicate in the P2P group.

4. The method of claim 1 , further comprising disassociating the first associated non-AP station from associated AP stations of the AP MLD before configuring the first associated non-AP station as a P2P station.

5. The first associated non-AP station is configured to communicate with the peer station on a first channel of the first BSS, and the at least one second associated non-AP station is configured to communicate with the AP on at least one second channel of the second BSS, and the method comprises: The method of claim 1 , further comprising reporting the P2P group and the first channel to the AP MLD by the at least one second associated non-AP station of the non-AP MLD.

6. The method of claim 5 , wherein reporting the P2P group includes transmitting a P2P information element (IE).

7. 7. The method of claim 6, wherein the P2P IE is sent to the AP MLD in a P2P invitation request frame sent on the second channel by the at least one second associated non-AP station to be sent to other stations connected to the AP MLD.

8. The method of claim 6 , wherein the P2P IE is transmitted in a multilink IE of a probe request frame.

9. 9. The method of claim 8, wherein the probe request frame further comprises, in addition to the Multilink IE containing Group Owner (GO) information, a Reduced Neighbor Report (RNR) IE that identifies the first non-AP associated station acting as the GO of the P2P group, and the RNR IE and ML IE are each set to the same value but include MLD ID and Link ID subfields that are distinct from respective subfield values ​​used for the second BSS.

10. The method of claim 8 or 9, further comprising transmitting the P2P IE by the AP MLD in a probe response frame or a beacon frame on the second channel.

11. The method of claim 10 , wherein the P2P IE is included in a per-STA profile in a first basic multilink IE.

12. The beacon frame or probe response frame may include, in addition to the first basic multilink IE: an RNR IE that identifies the AP associated stations in the AP MLD and the non-AP associated stations that act as Group Owners (GOs) of the P2P group; A second basic multilink IE containing information of the AP associated station of the AP MLD; further comprising The method of claim 11 , wherein an MLD ID subfield in an RNR IE and a Basic Multilink IE is used to indicate whether a reported AP belongs to the first or second BSS.

13. 13. A computer program product for a programmable device comprising a set of instructions for performing the method of any one of claims 1 to 12 when loaded into and executed by said programmable device.

14. A computer-readable storage medium having stored thereon computer program instructions for carrying out the method of any one of claims 1 to 12.

15. A computer program which, when executed, causes the computer to carry out the method of any one of claims 1 to 12.

16. A non-access point (AP) multilink device (MLD) comprising a first associated non-AP station and at least one second associated non-AP station, wherein the non-AP MLD can be configured as a peer-to-peer (P2P) station simultaneously with the first associated non-AP station as a P2P station for communicating with peer stations in a first basic service set (BSS) forming a P2P group, and the second associated non-AP station as a station for communicating with an access point in a second BSS.

17. 17. The non-AP MLD of claim 16, wherein the first BSS and the second BSS are not part of the same extended service set (ESS).

18. 17. The non-AP MLD of claim 16, wherein the second associated non-AP stations are configured as stations for each communication with an associated AP station of the AP MLD.

19. 17. The non-AP MLD of claim 16, wherein the second associated non-AP station is configured as a station for communicating with a non-MLD AP station.

20. The non-AP MLD is an upper MAC sublayer (424a) common to the first associated non-AP station and the second associated non-AP station; a first dedicated entity, the first dedicated entity comprising a first lower MAC sublayer (424b) and a first PHY layer (423), the first dedicated entity being dedicated to the first associated non-AP station; a second dedicated entity, the second dedicated entity comprising a second lower MAC sublayer (424b) and a second PHY layer (423), the second dedicated entity being dedicated to each of the second associated non-AP stations; 17. The non-AP MLD of claim 16, comprising:

21. The non-AP MLD of claim 20, wherein a single service access point (SAP) is provided to upper layers.

22. The non-AP MLD according to claim 20 or 21, wherein the data flow of the first BSS and the data flow of the second BSS are processed independently in the upper MAC layer.

23. The upper MAC sublayer is configured to receive an indication from the SAP that an incoming data flow belongs to the first BSS, the indication being configured to segregate the incoming data flow according to the indication, the indication comprising: The value of the priority field, traffic identifiers, a Stream Classification Service Identifier (SCSID) that identifies the SCS stream characterized by the TCLAS element and / or the TCLAS processing element; a local index determined by said SAP; or the address of the first associated non-AP station; The non-AP MLD according to claim 21, which is any one of

24. The non-AP MLD is a first upper MAC sublayer dedicated to the first associated non-AP station; a second upper MAC sublayer common to the second associated non-AP station; a first dedicated entity, the first dedicated entity comprising a first lower MAC sublayer (424b) and a first PHY layer (423), the first dedicated entity being dedicated to the first associated non-AP station; a second dedicated entity, the second dedicated entity comprising a second lower MAC sublayer (424b) and a second PHY layer (423), the second dedicated entity being dedicated to each of the second associated non-AP stations; 17. The non-AP MLD of claim 16, comprising:

25. The non-AP MLD of claim 16 , wherein the first BSS and the second BSS operate on different channels.

26. The non-AP MLD of claim 16, wherein the first BSS is a Wireless Fidelity (Wi-Fi) BSS.

27. 27. The non-AP MLD of claim 26, wherein the Wi-Fi BSS implements the Wi-Fi Direct standard, and the P2P group identifier of the Wi-Fi BSS takes the Station Association Identifier (STA AID) value of the first associated non-AP station that acts as a group owner.

28. The non-AP MLD of claim 16, wherein the non-AP MLD is configured to provide a multilink information element to the AP, the multilink information element providing capability information for stations to join the P2P group.

29. the first associated non-AP station is configured to communicate with the peer station on a first channel of the first BSS, and the at least one second associated non-AP station is configured to communicate with the AP on at least one second channel of the second BSS, and the non-AP MLD comprises: reporting the P2P group and the first channel to the AP MLD by the at least one second associated non-AP station of the non-AP MLD; The non-AP MLD of claim 16, configured to:

30. 30. The non-AP MLD of claim 29, wherein reporting the P2P group includes transmitting a P2P information element (IE).

31. 31. The non-AP MLD of claim 30, wherein the P2P IE is sent to the AP MLD in a P2P invitation request frame sent on the second channel by the at least one second associated non-AP station to be sent to another station connected to the AP MLD.

32. The non-AP MLD of claim 30, wherein the P2P information element is transmitted in a multilink information element of a probe request frame.

33. 33. The non-AP MLD of claim 32, wherein the probe request frame further comprises, in addition to the Multilink IE containing Group Owner (GO) information, a Reduced Neighbor Report (RNR) IE that identifies the first non-AP associated station that acts as the GO of the P2P group, and the RNR IE and ML IE include MLD ID and Link ID subfields that are set to the same values ​​but that are different from the respective subfield values ​​used for the second BSS.

34. receiving the P2P IE from the AP MLD in a Probe Response frame or in a Beacon frame on the second channel; 34. The non-AP MLD of claim 32 or 33, further configured to:

35. The non-AP MLD of claim 34, wherein the P2P IE is included in a per-STA profile in a first Basic Multi-Link IE.

36. The beacon frame or the probe response frame further includes, in addition to the first basic multi-link IE: an RNR IE that identifies the AP associated stations in the AP MLD and the non-AP associated stations that act as Group Owners (GOs) of the P2P group; a second Basic Multi-Link IE containing information of the AP-associated stations of the AP MLD; Including, The MLD ID subfield in the RNR IE and Basic Multi-Link IE is used to indicate whether the reported AP belongs to the first or second BSS; 36. The non-AP MLD of claim 35.

Images