Communication apparatus and communication method for EHT virtualization with multi-link devices

Abstract

To provide communication devices and methods for EHT virtualization for MLD devices.SOLUTION: A non-AP MLD comprises: a receiver that receives, from an AP MLD comprising a first virtual AP and a second virtual AP, a frame including an SSID field indicating a first common SSID, a multi-link element for the AP MLD, and a multi-BSSID element for other AP MLDs; and a controller that, when it determines that the non-AP MLD itself joins the first common SSID indicated by the SSID field included in the received frame, determines whether to associate the non-AP MLD itself with the AP MLD on the basis of the multi-link element included in the frame. The multi-link element comprises a MAC Address of the AP MLD and the multi-BSSID element comprises a nontransmitted BSSID profile of a first nontransmitted BSSID belonging to a first multi-BSSID set for a first channel.SELECTED DRAWING: Figure 46

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate generally to communication devices, and more particularly to a method and apparatus for Extra High Throughput (EHT) virtualization of a multi-link device (MLD). [Background technology]

[0002] In the standardization of next-generation wireless local area networks (WLANs), a new wireless access technology that is backward compatible with IEEE 802.11a / b / g / n / ac / ax technologies is being discussed in the IEEE 802.11 working group, and is named 802.11be Extremely High Throughput (EHT) WLAN.

[0003] IEEE 802.11be EHT WLAN is expected to increase the maximum channel bandwidth from 160 MHz to 320 MHz, increase the maximum number of space-time streams from 8 to 16, and support multi-link operation to provide better link adaptation and higher throughput than 802.11ax high-efficiency (HE) WLAN.

[0004] Additionally, to enable multi-link operation between an access point (AP) multi-link device (MLD) and a non-AP MLD, an affiliated station (STA) may establish associations on one or more links by performing a multi-link setup over one of the supported links. A virtual AP (VAP) may also be implemented. Summary of the Invention [Problem to be solved by the invention]

[0005] However, there has been no discussion about EHT virtualization of MLD devices, especially about interconnection with Virtual LAN (VLAN).

[0006] Therefore, what is needed is a communication apparatus and method that can solve the above problems. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.

[0007] Non-limiting exemplary embodiments facilitate providing a communications apparatus and method for EHT virtualization of MLD devices. [Means for solving the problem]

[0008] According to one aspect of the present disclosure, there is provided an access point (AP) multi-link device (MLD) that is included in a plurality of APs that belong to the AP, each of the plurality of APs advertising a Basic Service Set Identifier (BSSID) and providing a link identified by a link identifier (ID), the AP comprising: circuitry that, in operation, generates a frame carrying a multi-link element that includes information about the AP MLD and the plurality of APs; and a transmitter that, in operation, transmits the frame on the link, the multi-link element indicating a link ID of the link on which the frame is transmitted.

[0009] According to another aspect of the present disclosure, there is provided a non-AP station (STA) included in a plurality of non-AP STAs belonging to a non-AP MLD, the non-AP STA comprising: a circuit for generating, in operation, a probe request frame holding a multi-link element including an MLD MAC address of the AP MLD and one or more link IDs of links belonging to the AP MLD; and a transmitter for transmitting, in operation, the probe request frame to request information regarding the AP MLD and one or more links of the AP MLD.

[0010] According to another aspect of the present disclosure, there is provided a communication method including: generating a frame at an AP included in a plurality of APs belonging to an AP MLD, where each of the plurality of APs advertises a BSSID and provides a link identified by a link ID, and the frame carries a multilink element containing information about the AP MLD and the plurality of APs; and transmitting the frame on the link, where the multilink element indicates a link ID of the link on which the frame is transmitted.

[0011] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof. Further benefits and advantages of the disclosed embodiments will be apparent from the specification and drawings. Benefits and / or advantages may be obtained individually by various embodiments and features of the specification and drawings, and it is not necessary for all of them to be provided to obtain one or more of such benefits and / or advantages.

[0012] The accompanying drawings, in which like reference numbers refer to identical or functionally similar elements throughout the different views, and which, together with the following detailed description, are incorporated in and form a part of this specification, illustrate various embodiments and serve to explain various principles and advantages according to embodiments of the present invention. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 illustrates an example implementation of VLANs. [Figure 2] FIG. 1 illustrates a network implementation according to an example. [Figure 3] FIG. 1 is a diagram of AP MLD with Tier 1 virtualization, according to various embodiments. [Figure 4A] FIG. 1 illustrates an implementation of a network with Tier 1 virtualization using only physical APs, according to various embodiments. [Figure 4B] FIG. 1 illustrates an implementation of a network with Tier 1 virtualization using only physical APs, according to various embodiments. [Figure 4C] FIG. 1 illustrates an authentication frame used to request authentication for a specific SSID. [Figure 5A] FIG. 1 illustrates an implementation of a network with Tier 1 virtualization without interconnection to VLANs, according to various embodiments. [Figure 5B] FIG. 1 illustrates an implementation of a network with Tier 1 virtualization without interconnection to VLANs, according to various embodiments. [Figure 6A] FIG. 1 illustrates an implementation of a network with Tier 1 virtualization using a combination of physical APs and VAPs, according to various embodiments. [Figure 6B] FIG. 1 illustrates an implementation of a network with Tier 1 virtualization using a combination of physical APs and VAPs, according to various embodiments. [Figure 7] FIG. 6C is a diagram of broadcast 802.11 and 802.3 frames for the network shown in FIGS. 4A-6B. [Figure 8] 1 is a diagram of AP MLD with Tier 1 virtualization using a shared upper medium access control (UMAC) structure, according to various embodiments. [Figure 9]FIG. 2 is a diagram of co-located APs grouped into two or more AP groups to create multiple AP MLDs for Tier 2 virtualization, in accordance with various embodiments. [Figure 10A] FIG. 1 illustrates an implementation of a network with Tier 2 virtualization using multiple AP MLDs, according to various embodiments. [Figure 10B] FIG. 1 illustrates an implementation of a network with Tier 2 virtualization using multiple AP MLDs, according to various embodiments. [Figure 11A] FIG. 1 illustrates an implementation of a network with Tier 2 virtualization using multiple AP MLD with only physical APs, according to various embodiments. [Figure 11B] FIG. 1 illustrates an implementation of a network with Tier 2 virtualization using multiple AP MLD with only physical APs, according to various embodiments. [Figure 12] 10A-11B show diagrams of broadcast 802.11 and 802.3 frames for the network shown in FIG. 10A-11B. [Figure 13] FIG. 1 is a diagram of Tier 2 AP MLD without hypervisor virtualization, according to various embodiments. [Figure 14] FIG. 1 is a diagram of Tier 2 AP MLD using hypervisor virtualization, according to various embodiments. [Figure 15] 1 is a diagram of a multilink element configured for unified signaling according to various embodiments. [Figure 16] FIG. 2 is a simplified diagram of a beacon / broadcast probe response frame configured for Tier 1 virtualization using all physical APs according to a first embodiment. [Figure 17] 4C is a diagram of a beacon frame transmitted by AP-1 of the network shown in FIG. 4A and FIG. 4B according to the first embodiment. [Figure 18] FIG. 2 is a simplified diagram of a beacon / broadcast probe response frame configured for Tier 1 virtualization using a VAP according to a first embodiment. [Figure 19] 6C is a diagram of a beacon frame transmitted by AP-1 of the network shown in FIG. 6A and FIG. 6B according to the first embodiment. [Figure 20] 6C is a diagram of a beacon frame transmitted by VAP-3 of the network shown in FIG. 6A and FIG. 6B according to the first embodiment. [Figure 21] 6C is a diagram of a beacon frame transmitted by VAP-5 of the network shown in FIG. 6A and FIG. 6B according to the first embodiment. [Figure 22] 3 is a simplified diagram of a beacon / probe response frame configured for Tier 2 virtualization according to a first embodiment. [Figure 23] 10C is a diagram of a beacon frame transmitted by VAP-1 of the network shown in FIGS. 10A and 10B according to the first embodiment. FIG. [Figure 24] 10B according to the first embodiment. FIG. 10C is a diagram of a beacon frame transmitted by VAP-4 of the network shown in FIG. [Figure 25] 10A and 10B according to the first embodiment. FIG. [Figure 26] FIG. 1C is a diagram of a probe request frame sent by non-AP MLD to VAP-1 in the network shown in FIGS. 10A and 10B according to the first embodiment. [Figure 27] FIG. 1C is a diagram of a probe response frame sent from VAP-1 to a non-AP MLD in the network shown in FIGS. 10A and 10B according to the first embodiment. [Figure 28] 10 is a simplified diagram of a beacon / probe response frame according to a second embodiment. [Figure 29] FIG. 10 illustrates a Neighbor Report (NR) element according to a second embodiment. [Figure 30] FIG. 10 is a diagram of a Reduced Neighbor Report (RNR) element according to a second embodiment. [Figure 31] FIG. 10 is a simplified diagram of a beacon / probe response frame according to a third embodiment. [Figure 32] 10C is a diagram of a beacon frame transmitted by VAP-1 of the network shown in FIGS. 10A and 10B according to a third embodiment. FIG. [Figure 33] 33 is a diagram of a reduced neighbor report element in the beacon frame shown in FIG. 32 according to a third embodiment. [Figure 34] FIG. 10 is a diagram of a multilink element for unified signaling according to a fourth embodiment. [Figure 35] 10B according to a fourth embodiment of the present invention. FIG. 10C is a diagram of a beacon frame transmitted by VAP-1 of the network shown in FIG. 10A and FIG. [Figure 36] FIG. 11 is a diagram of a neighbor MLD report element transmitted by VAP-6 of the network shown in FIGS. 10A and 10B according to a fourth embodiment. [Figure 37] FIG. 11 is a diagram of an RNR element transmitted by VAP-6 of the network shown in FIGS. 10A and 10B according to a fourth embodiment. [Figure 38] FIG. 11 is a diagram of an association request frame sent to VAP-1 of the network shown in FIGS. 10A and 10B according to the fourth embodiment. [Figure 39] FIG. 11 is a diagram of a multilink re-setup frame sent to VAP-1 of the network shown in FIGS. 10A and 10B to update the L2 MAC address according to the fourth embodiment. [Figure 40] FIG. 10 is a simplified diagram of a beacon / probe response frame according to a fifth embodiment. [Figure 41] FIG. 16 is a diagram of an RNR element transmitted by VAP-1 of the network shown in FIGS. 10A and 10B according to a fifth embodiment. [Figure 42] FIG. 10 is a diagram of an AP MLD serving both legacy devices and MLD simultaneously according to a sixth embodiment; [Figure 43A]FIG. 10 is a simplified diagram of a beacon / probe response frame according to a sixth embodiment. [Figure 43B] FIG. 10 is a diagram illustrating an RNR element according to a sixth embodiment. [Figure 44A] FIG. 13 is a simplified diagram of a broadcast data frame according to the sixth embodiment. [Figure 44B] FIG. 13 is a simplified diagram of a broadcast management frame according to the sixth embodiment. [Figure 44C] FIG. 13 is a simplified diagram of a generic MAC frame according to the sixth embodiment. [Figure 45] 1 is a flow diagram illustrating a method for EHT virtualization of an MLD device according to various embodiments. [Figure 46] 1 is a schematic, partially segmented diagram of one of the serving APs or STAs of a multi-link device that can be implemented for EHT virtualization of an MLD device, according to various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0014] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.

[0015] The following detailed description is merely exemplary in nature and is not intended to limit the embodiments or the application and uses of the embodiments. Furthermore, there is no intention to be bound by the preceding background or any theory presented in this detailed description. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.

[0016] A VAP allows a physical AP to function as two or more logical APs. Typically, all VAPs in a network operate on the same channel. The BSSIDs (Basic Service Set Identifiers) corresponding to different VAPs typically have different settings (security, Quality of Service (QoS), etc.).

[0017] There are two main ways to implement a VAP: - Legacy Method (Co-hosted BSSID): Each VAP transmits a unique beacon frame. - Multiple BSSID: A single beacon frame carrying the information of all VAPs is transmitted. The BSSID transmitting the beacon frame is the transmitting BSSID, and the rest are non-transmitting BSSIDs. Up to 8 VAPs can be supported.

[0018] A VLAN logically groups two or more devices together, regardless of whether they are physically present in a wired network. VLANs allow devices on the same physical network to be separated into separate broadcast domains for simplicity, improved security, traffic management, etc. Each VLAN is identified by a VLAN ID. One of the main purposes of implementing VLANs is to reduce broadcast traffic. The VLAN specification is standardized by IEEE 802.1Q.

[0019] A common way to extend VLANs to a wireless LAN is to create a separate service set identifier (SSID) for each VLAN. More than one VLAN can be mapped to an SSID. Each SSID is then mapped to a VAP (BSSID). Frames destined for different VLANs are transmitted wirelessly by the VAP on different SSIDs, ensuring that only clients associated with that VLAN receive those packets.

[0020] 1 illustrates one example of how VLANs can be implemented. There are n VAPs in network 100: VAP-1 102, VAP-2 104, through VAP-n 106. BSSID-1 108 corresponds to VAP-1 102, BSSID-2 110 corresponds to VAP-2 104, and BSSID-n 112 corresponds to VAP-n 106. There are also n VLANs in the network: VLAN1 114, VLAN2 116, through VLANn 118. For example, VLAN1 114 is designated for staff and is mapped to SSID:Staff, VLAN2 116 is designated for guests and is mapped to SSID:Guest, and VLANn 118 is designated for the Internet of Things (IOT) and is mapped to SSID:IOT. Each of these SSIDs is then mapped to a VAP. SSID:Staff is mapped to VAP-1 102 (or BSSID-1 108), SSID:Guest is mapped to VAP-2 104 (or BSSID-2 110), and SSID:IOT is mapped to VAP-n 106 (or BSSID-n 112). Even though all VAPs and non-AP STAs are operating on the same channel, only non-AP STA-1 120 can receive packets transmitted by VAP-1 102, only non-AP STA-2 122 can receive packets transmitted by VAP-2 104, and only non-AP STA-n 124 can receive packets transmitted by VAP-n 106.

[0021] Typically, VLANs are mapped to SSIDs, and in legacy systems, this is simple because there is a one-to-one mapping between BSSIDs and SSIDs. However, with MLD, the mapping from SSID to BSSID is less clear because there can be multiple ways to do it. Referring to the exemplary system shown in FIG. 2, AP MLD 202 is composed of AP-1 204 and AP-2 206. AP-1 204 operates two virtual APs: VAP-1.1 208 and VAP-1.2 210. This allows AP MLD 202, which has only two physical APs (AP-1 204 and AP-2 206), to support three SSIDs (SSID: Staff, SSID: Guest, and SSID: IOT) or VLANs (VLAN1 212, VLAN2 214, and VLANn 216). However, such deployments cannot support non-AP MLD because, although non-AP MLD operates on multiple links simultaneously and theoretically can participate in multiple SSIDs, it should not be allowed to participate in multiple SSIDs simultaneously due to security and other considerations.

[0022] To address the above challenges, this disclosure proposes a two-tier approach to implementing virtualization using MLD. Furthermore, we propose unified signaling that can support different virtualization architectures and usages, allowing MLD to quickly find information about other links in a peer link (e.g., during discovery, multi-link setup, etc.).

[0023] Tier 1 virtualization groups the APs in an AP MLD into two or more AP groups, creating multiple virtual AP MLDs from a single AP MLD. There is a single MLD MAC address and a single MAC-SAP (medium access control-service access point) to the DS (distribution service). There can be two or more SSIDs per AP MLD, and multiple virtual networks per AP MLD. Advantageously, Tier 1 virtualization is suitable for small deployments where only a few virtual networks are sufficient, such as a home network or small enterprise. It is simple to implement and has low hardware requirements. Reconfiguring an SSID is also easier because there is no need to redefine the MLD.

[0024] Tier 2 virtualization involves grouping co-located APs into two or more AP groups to create multiple AP MLDs. There can be multiple MLD MAC-SAPs and multiple MLD MAC addresses to the DS, one per AP MLD. There is a single SSID per AP MLD, and one AP MLD per virtual network. The advantage of Tier 2 virtualization is that it is suitable for large deployments requiring many more virtual networks, such as corporate networks or large facilities like airports. However, implementation can be complex, and hardware requirements are higher than with Tier 1 virtualization.

[0025] FIG. 3 shows a diagram of an AP MLD 300 implementing Tier 1 virtualization, according to various embodiments. The AP MLD 300 is composed of AP-1 302, AP-2 304, AP-3 306, and AP-4 308. AP-1 302 and AP-2 304 form virtual AP MLD-1 310, while AP-3 306 and AP-4 308 form virtual AP MLD-2 312. Furthermore, virtual AP MLD-1 310 is mapped to SSID-1, and virtual AP MLD-2 312 is mapped to SSID-2. In other words, the APs in the AP MLD 300 are grouped into two or more AP groups, creating multiple virtual AP MLDs from a single AP MLD. Each group of APs is mapped to a unique SSID, so that all APs in the virtual AP MLD advertise the same SSID, allowing for more than one SSID per AP MLD. In this Tier 1 virtualization example, there is a single MLD MAC address and a single MAC-SAP to the DS. Non-AP MLDs are only allowed to perform multi-link setup for links that are part of the same virtual AP MLD (i.e., the same SSID). An ID may also be assigned to the virtual MLD for easy identification.

[0026] 4A and 4B illustrate an implementation of a network 400 with Tier 1 virtualization using only physical APs, according to various embodiments. In the network 400 of FIG. 4A, the four physical APs of the AP MLD 402 are divided into two groups. AP-1 404 (corresponding to BSSID-1.1 420) and AP-2 406 (corresponding to BSSID-1.2 422) advertise SSID:Staff. AP-3 408 (corresponding to BSSID-2.2 424) and AP-4 410 (corresponding to BSSID-2.1 426) advertise SSID:Guest. SSID:Staff is mapped to VLAN1 412, and SSID:Guest is mapped to VLAN2 414. In other words, the AP MLD 402 bridges wireless frames between multiple APs and multiple VLANs, such that each SSID is mapped to a corresponding VLAN. Non-AP MLD-1 416 is associated with SSID:Staff, and non-AP MLD-2 418 is associated with SSID:Guest. Figure 4B shows another diagram of four APs. AP-1 404, AP-2 406, AP-3 408, and AP-4 410 operate on links 1, 2, 3, and 4, with link IDs 1, 2, 3, and 4, respectively. The link ID uniquely identifies the BSSID of the APs that belong to the AP MLD. The link ID is also associated with the operating channel (i.e., operating class and channel number) associated with the BSSID, but the link ID remains the same even if the operating channel changes. In this example, the wireless network represented by SSID Staff operates on links 1 and 2, and the wireless network represented by SSID Guest operates on links 3 and 4. An example of the AP MLD 402 and the MAC addresses of the four APs is shown below: - MLD MAC address=0A-20; - BSSID-1.1(AP-1)=0A-21;BSSID-1.2(AP-2)=0A-22; - BSSID-2.1(AP-3)=0D-21;BSSID-2.2(AP-4)=0D-22;

[0027] For simplicity, the MAC addresses are shown as only two octets rather than the full six octets. Advantageously, this implementation of network 400 is simple and suitable for AP MLD with more than two APs. However, using this method, only a limited number of VLANs can be supported.

[0028] Further analysis shows that the implementation of network 400 is equivalent to logically splitting the MLD into two virtual MLDs. During discovery, different APs can advertise different SSIDs. For multi-link setup, non-AP MLD only requires the setup of links belonging to the SSID of interest. From a security perspective, there is no problem because the group key (GTK / IGTK) is allowed to be different for each link. The pairwise key (PTK) is the same for all links, but this is also not a problem because the PTK is dedicated to a single non-AP MLD. However, all SSIDs will have the same security scheme (e.g., WPA-2). In some security associations, such as simultaneous authentication of equals (SAE), the network's SSID and corresponding password are used to generate a session-specific ECC group password element (PWE). Specifically, the SSID and password are used to generate a pwd-seed, which is then used to generate the PWE. pwd-seed=HKDF-Extract(ssid,password[||identifier])

[0029] Here, HKDF-Extract is a hash function defined in IETF RFC5869, and [||identifier] indicates the optional inclusion of a password identifier, if present. In such cases, security associations between different non-AP MLDs and AP MLDs occur at the same MAC-SAP, but different non-AP MLDs generate PWEs using different SSID and password combinations depending on the SSID to which the non-AP MLDs are joining. Because PWEs are used in SAE commit messages (during authentication), in such cases, the non-AP MLD or non-AP STA also includes an SSID field in its authentication frame to explicitly inform the AP MLD of the SSID for which it is requesting authentication. This is shown in Figure 4C, where the non-AP MLD indicates that it is requesting authentication from the network Staff by including an SSID field 432 set to Staff in the authentication frame 430 sent by the non-AP MLD to the AP MLD. Since the AP MLD is informed of the SSID that the non-AP MLD is joining, there is no confusion on the AP MLD side about how to generate the PWE.

[0030] For interconnection with VLANs, one VLAN ID is mapped to one SSID. MLD must ensure that incoming frames (from the DS) are sent to the correct SSID (BSSID) based on their VLAN ID, and that outgoing frames (to the DS) have the correct VLAN ID attached based on the SSID (BSSID) on which the frame was received. MLD can also assign a virtual MLD ID to each SSID (or VLAN), but there is only one MLD MAC address and one MAC SAP to the DS. The constraint is that APs in a virtual MLD must not advertise different SSIDs. Otherwise, non-AP MLDs associated with the virtual MLD would receive frames from multiple VLANs. In this way, it is possible to segment an MLD and map it to more than two VLANs. However, the number of VLANs that can be supported is limited (maximum is half the number of APs).

[0031] 5A and 5B illustrate implementations of a network 500 with Tier 1 virtualization without interconnection to VLANs, according to various embodiments. In the network 500 of FIG. 5A, the AP MLD 502 provides two virtual networks based on device type: one for regular MLD and one for single-link MLD and legacy STAs. The three physical APs in the AP MLD 502 are divided into two groups. AP-1 504 (corresponding to BSSID-1.1 510) and AP-2 506 (corresponding to BSSID-1.2 512) advertise SSID: Multi-links and support multi-link non-AP MLDs, such as non-AP MLD-1 516. AP-3 508 (corresponding to BSSID-2 514) advertises SSID: Single-link to accommodate legacy STAs and single-link MLDs, i.e., MLDs that can switch between multiple links but can only operate on one link at a time, such as single-link non-AP MLD-2 518. Non-AP MLD-1 516 is associated with SSID: Multi-links, and single-link non-AP MLD-2 518 is associated with SSID: Single-link. Figure 5B shows another view of three APs. AP-1 504, AP-2 506, and AP-3 508 operate on links 1, 2, and 3, with link IDs 1, 2, and 3, respectively.

[0032] 6A and 6B illustrate an implementation of a network 600 with Tier 1 virtualization using a combination of physical APs and VAPs, according to various embodiments. In the network 600 of FIG. 6A, one physical AP and two sets of VAPs in the MLD are divided into three SSIDs. The AP MLD 602 ​​consists of AP-1 604, VAP-2 606, VAP-3 608, and VAP-4 610. VAP-5 612 is a standalone AP. AP-1 604 (corresponding to BSSID-1 614) and VAP-2 606 (corresponding to BSSID-2.1 616) advertise the SSID:Staff, while VAP-3 608 (corresponding to BSSID-2.2 618) and VAP-4 610 (corresponding to BSSID-3.1 620) advertise the SSID:Guest. Standalone VAP-5 612 (corresponding to BSSID-3.2 622) advertises SSID:IOT. SSID:Staff is mapped to VLAN1 624, SSID:Guest is mapped to VLAN2 626, and SSID:IOT is mapped to VLAN3 628. In other words, the AP MLD 602 ​​bridges wireless frames between multiple APs and multiple VLANs so that each SSID is mapped to a corresponding VLAN. Non-AP MLD-1 630 joins the network with SSID:Staff, and non-AP MLD-2 632 joins the network with SSID:Guest. STA-3 634 joins the network with SSID:IOT.

[0033] VAP-2 606 and VAP-3 608 are virtual APs of the same AP and form VAP Set 1. VAP-4 610 and VAP-5 612 are virtual APs of the same AP and form VAP Set 2. Furthermore, AP-1 604 and VAP-2 606 form VAP MLD-1 (Virtual AP MLD-1), and VAP-3 608 and VAP-4 610 form VAP MLD-2. A VAP can be a member of a co-host BSSID set or a member of a multi-BSSID set. In this example, the VAP is implemented as a multi-BSSID. VAP-2 606 and VAP-3 608 are members of multi-BSSID set 1, which includes BSSID-2.1 616 and BSSID-2.2 618, and VAP-4 610 and VAP-5 612 are members of multi-BSSID set 2, which includes BSSID-3.1 620 and BSSID-3.2 622. In these multi-BSSID sets, the transmitting BSSID corresponds to VAP-3 608 and VAP-5 612, and the non-transmitting BSSID corresponds to VAP-2 606 and VAP-4 610. AP-1 604, VAP-3 608, and VAP-5 612 transmit beacon frames. Although multiple APs / VAPs may operate on the same link (frequency channel), different link IDs may be assigned to the APs / VAPs. Figure 6B shows another diagram of five APs / VAPs. AP-1 604 operates on link 3, VAP-2 606 and VAP-3 608 operate on link 2, and VAP-4 610 and VAP-5 612 operate on link 1. AP-1 604, VAP-2 606, VAP-3 608, and VAP-5 612 are assigned link IDs 1, 2, 3, and 4, respectively. An example of the AP MLD 602 ​​and the MAC addresses of the five APs / VAPs is shown below: - MLD MAC address = 0A-20 - BSSID-1(AP-1)=0A-21 - BSSID-2.1(VAP-2)=0D-21, BSSID-2.2(VAP-3)=0D-22 - BSSID-3.1(VAP-4)=0E-21, BSSID-3.2(VAP-5)=0E-22

[0034] Advantageously, this implementation of network 600 allows extending MLD using VAPs to map to more than one VLAN, however the number of VLANs that can be supported is small (maximum number of VLANs = number of physical APs).

[0035] Further analysis shows that the implementation of network 600 is logically equivalent to extending the MLD to two virtual MLDs and one standalone AP. During discovery, VAPs can advertise different SSIDs without any issues. For multilink setup, all APs (including VAPs) in the MLD advertise the same MLD address. However, different VAPs operate on different links (even though some of them operate on the same channel). From a security perspective, different VAPs must have different group keys (GTK / IGTK). Regarding interconnection with VLANs, one VLAN ID is mapped to the SSID (and virtual MLD). There is a single MLD MAC address and one MAC SAP to the DS. The virtual MLD ID can be used for faster translation between the VLAN ID and the SSID. The constraint is that APs in the virtual MLD must not advertise different SSIDs. Otherwise, the non-AP MLD associated with the virtual MLD will receive frames from multiple VLANs. In this way, it is possible to extend the MLD using VAPs and map them to more than two VLANs. However, the number of VLANs that can be supported is limited, up to the number of physical APs. Another note about the deployment shown in Figures 6A and 6B is that VAPs belonging to the same VAP set (co-host BSSID set or multi-BSSID set) are part of the same AP MLD and cannot transmit and receive simultaneously. This requires special coordination between virtual MLDs for multilink transmission. For example, if AP1 604 and VAP2 606 are involved in multilink transmission with non-AP MLD-1 in the Staff network, VAP3 608 cannot transmit simultaneously with VAP2 606 because they share hardware resources. Therefore, only VAP4 610 can transmit and receive frames to and from non-AP MLD-2 in the Guest network.

[0036] In Tier 1 virtualization, each SSID is mapped to one or more VLANs. When a VLAN-tagged frame (e.g., a frame tagged with VLAN1) is received on the AP MLD's wired interface, the AP MLD must ensure that the frame is broadcast only on WLANs (e.g., WLANs with SSIDs mapped to VLAN1) whose SSIDs are mapped to the VLAN whose ID is tagged in the received frame. Similarly, when a frame destined for a DS is received on one of the wireless interfaces, based on the SSID, the AP MLD must ensure that the correct VLAN ID is tagged on the outgoing wired frame. To do so, the AP MLD must maintain a mapping from VLAN IDs to SSIDs and AP MAC addresses. An example mapping is shown in Table 1 below. [Table 1]

[0037] An example of an 802.3 frame 700 and an 802.11 frame 702 broadcast based on the mapping in Table 1 is shown in Figure 7. 802.3 frame 700 is sent from the router to AP-MLD. The 802.1Q header of 802.3 frame 700 indicates VLAN 1 in VID field 706. According to Table 1, VLAN 1 is mapped to SSID:Staff. Therefore, the resulting 802.11 frame 702 can only be broadcast by the AP that is mapped to the SSID corresponding to the received Ethernet frame, i.e., the VLAN ID of 802.3 frame 700. In this example, the received broadcast Ethernet packet is transmitted by AP1 or AP2 with SSID:Staff.

[0038] Since in Tier 1 virtualization multiple SSIDs may share the same MAC-SAP, especially for broadcast data, the MA-UNITDATA.request primitive must indicate the destination SSID (or alternatively the virtual MLD ID, if present). An example of such a MAC data service primitive is shown below: MA-UNITDATA.request( Source address, destination address, routing information, data, Priorities, drop eligible, Service class, Station Vector, MSDU format, SSID )

[0039] Based on the SSID field indicated in the MAC data service primitive, broadcast data frames are transmitted only on the BSSIDs corresponding to the indicated SSID. Alternatively, a list of BSSIDs can be provided instead of SSIDs.

[0040] The Tier 1 AP MLD can be implemented as a shared Upper MAC (UMAC) structure without requiring complex virtualization technologies such as a hypervisor. FIG. 8 shows a diagram of an AP MLD 800 with Tier 1 virtualization using a shared UMAC structure, according to various embodiments. The shared UMAC 802 is responsible for ensuring proper translation between wired VLAN frames and wireless frames. Because the constituent APs (AP-1 804, AP-2 806, AP-3 808, and AP-4 810) are tightly coupled to each other, sharing information is easier, but sharing common resources (e.g., memory, etc.) can impact performance.

[0041] In Tier 2 virtualization, co-located APs are grouped into two or more AP groups to create multiple AP MLDs. Figure 9 shows a diagram of co-located APs grouped into two or more AP groups to create multiple AP MLDs for Tier 2 virtualization, according to various embodiments. In this diagram, co-located APs (AP1 902, AP2 904, and AP3 906) are used to create AP MLD1 908, AP MLD2 910, and VAP 912. Each AP MLD is mapped to a unique SSID. Each SSID is mapped to one or more VLANs. There are multiple MAC-SAPs to the DS and multiple MAC addresses, one per AP MLD or VAP. A large number of VLANs can be supported by creating many MLDs using VAPs (up to eight per physical AP). Because APs / VAPs can belong to different AP MLDs, link IDs can be assigned in two ways: 1. Link IDs are local to an AP MLD, i.e., each AP MLD assigns link IDs to its associated APs independently of other co-located AP MLDs. 2. Link IDs are assigned globally to co-located AP MLDs such that no link ID is repeated within a set of co-located AP MLDs.

[0042] 10A and 10B illustrate an implementation of a network 1000 with Tier 2 virtualization using multiple AP MLDs, according to various embodiments. Three sets of VAPs are mapped to two MLDs and three SSIDs. AP MLD1 1002 is composed of VAP-1 1008 (corresponding to BSSID-1.1 1020), VAP-3 1012 (corresponding to BSSID-1.2 1022), and VAP-5 1016 (corresponding to BSSID-1.3 1024) and advertises SSID:Staff. AP MLD2 1004 is composed of VAP-2 1010 (corresponding to BSSID-2.1 1026) and VAP-4 1014 (corresponding to BSSID-2.2 1028) and advertises SSID:Guest. Standalone VAP-6 1018 corresponds to BSSID-3 1030 and advertises SSID:IOT. Non-AP MLD-1 1032 is associated with SSID:Staff, non-AP MLD-2 1034 is associated with SSID:Guest, and STA-3 1036 is associated with SSID:IOT. In this example, the VAP may be a co-host BSSID or a multi-BSSID. If the VAP is a member of a multi-BSSID set, the transmitting BSSID corresponds to VAP-1 1008, VAP-4 1014, and VAP-6 1018, and therefore VAP-1 1008, VAP-4 1014, and VAP-6 1018 transmit beacon frames so that each virtual network has at least one beacon frame.

[0043] FIG. 10B shows another diagram of APs / VAPs. VAP-1 1008 and VAP-2 1010 operate on link 3, VAP-3 1012 and VAP-4 1014 operate on link 2, and VAP-5 1016 and VAP-6 1018 operate on link 1. Because the VAPs belong to different AP MLDs, link IDs can be assigned in two ways. In the first way, link IDs are local to the AP MLD. For example, VAP-1 1008, VAP-3 1012, and VAP-5 1016 are assigned link IDs 1, 2, and 3, respectively, by AP MLD1 1002, and VAP-2 1010 and VAP-4 1014 are assigned link IDs 1 and 2 by AP MLD2 1004. In the second way, link IDs are assigned globally to the co-located MLDs. For example, VAPs 1 to 5 are assigned link IDs 1 to 5, respectively. An example of the MLD and MAC addresses of the six VAPs is shown below. - MLD-1 MAC address = 0A-20, MLD-2 MAC address = 0D-20, VAP-6 MAC address = 0D-32 - BSSID-1.1(VAP-1)=0A-21, BSSID-1.2(VAP-3)=0D-22, BSSID-1.3(VAP-5)=0A-23 - BSSID-2.1(VAP-2)=0A-22, BSSID-2.2(VAP-4)=0D-21 - BSSID-3(VAP-6)=0D-31

[0044] Further analysis shows that the implementation of network 1000 is equivalent to extending a group of co-located physical APs to multiple MLDs using VAPs. During discovery, if the number of MLDs is greater than the number of physical APs, the multi-BSSID approach faces challenges in advertising MLD information (e.g., MLD MAC addresses). MLD MAC address allocation and signaling efficiency can also be challenging. For multi-link setup, non-AP MLDs must be able to easily discover APs or VAPs on other links in the MLD, especially when the VAP is a non-transmitting BSSID. From a security perspective, different VAPs must have different group keys (GTK / IGTK). Regarding interconnection with VLANs, one VLAN ID is mapped to an SSID (and virtual MLD). There are multiple MLD MAC addresses and multiple MAC SAPs to the DS. When a single SSID maps to a single MLD, the VLAN ID can be mapped to the MLD MAC address. However, if there is only one physical connection to the DS, a single MLD MAC address may be more appropriate. In this way, by using VAP, MLD can be virtualized to support multiple VLANs.

[0045] 11A and 11B illustrate an implementation of a network 1100 with Tier 2 virtualization using multiple AP MLDs with only physical APs, according to various embodiments. Referring to FIG. 11A, two sets of VAPs are mapped to two MLDs and two SSIDs. AP MLD1 1102 is composed of VAP-1 1106 and VAP-2 1108 and advertises SSID: Staff. AP MLD2 is composed of VAP-3 1110 and VAP-4 1112 and advertises SSID: Guest. Non-AP MLD-1 1114 is associated with SSID: Staff, and non-AP MLD-2 1116 is associated with SSID: Guest. FIG. 11B shows another view of the VAPs. VAPs 1-4 operate on Links 1-4, respectively. Because the VAPs belong to different AP MLDs, link IDs can be assigned in two ways: In the first method, link IDs are local to the AP MLD. For example, VAP-1 1106 and VAP-2 1108 are assigned link IDs 1 and 2, respectively, by AP MLD1 1102, and VAP-3 1110 and VAP-4 1112 are also assigned link IDs 1 and 2 by AP MLD2 1104. In the second method, link IDs are assigned globally to the co-located MLD. For example, VAPs 1-4 are assigned link IDs 1-4, respectively.

[0046] In Tier 2 virtualization, each SSID is mapped to one or more VLANs. When a VLAN-tagged frame is received on the AP MLD's wired interface, the AP MLD must ensure that the frame is broadcast only on WLANs that have an SSID mapped to the VLAN ID tagged in the received frame. Similarly, when a frame destined for a DS is received on one of the wireless interfaces, based on the SSID, the AP MLD must ensure that the correct VLAN ID is tagged in the outgoing wired frame. Additionally, the AP MLD must maintain a mapping from VLAN IDs to SSIDs and MLD / AP MAC addresses. The mapping based on network 1000 is shown in Table 2 below. [Table 2]

[0047] Further, an example of an 802.11 frame 1200 and an 802.3 frame 1202 based on the mapping in Table 2 is shown in Figure 12. 802.11 frames are broadcast only by APs that belong to the AP MLD mapped to the SSID corresponding to the VLAN ID of the received Ethernet frame. In this example, broadcast 802.11 packets received by VAP-3 1012 and VAP-4 1014 with SSID: Guest are tagged with an IEEE 802.1Q tag with VLAN ID=VLAN2 (as shown in the VID field 1204 of the 802.3 frame 1202) before forwarding to the Ethernet interface.

[0048] Tier 2 AP MLD can be implemented without hypervisor virtualization when only physical APs or only a few VAPs are involved. Figure 13 shows a diagram 1300 of Tier 2 AP MLD1 1302 and AP MLD2 1304 without hypervisor virtualization, according to various embodiments. AP MLD1 1302 includes AP-1 1306 and AP-2 1308, and AP MLD2 1304 includes AP-3 1310 and AP-4 1312. In this implementation, each AP MLD1 1302 and AP MLD2 1304 operates as a separate entity using its own MAC-SAP to the DS. Advantageously, the one-to-one mapping between AP MLDs and VLANs simplifies the translation of VLAN and wireless frames.

[0049] When many VAPs are involved, tier 2 AP MLD may need to be implemented using hypervisor virtualization. Figure 14 shows a diagram 1400 of tier 2 AP MLD1 1402, AP MLD2 1404, and VAP-6 1406 using hypervisor virtualization, according to various embodiments. AP MLD1 1402 includes VAP-1 1408, VAP-3 1412, and VAP-5 1416, while AP MLD2 1404 includes VAP-2 1410 and VAP-4 1414. The virtualization layer 1424 is responsible for ensuring that the virtual APs are properly associated with the physical APs AP-1 1418, AP-2 1420, and AP-3 1422. Each AP MLD1 1402, AP MLD2 1404, and VAP-6 1406 operates as a separate entity with its own MAC-SAP to the DS. Advantageously, the one-to-one mapping between AP MLDs and VLANs simplifies the translation of VLAN and wireless frames.

[0050] We propose a unified signaling that can support different architectures and different usages. Figure 15 shows a diagram of a multilink element 1500 configured for unified signaling according to various embodiments. The multilink element 1500 includes an element ID field, a length field, an element ID extension field, a type field 1502, a common information field 1504, and one or more link-specific information fields 1506. The type field 1502 is set to discovery when used by AP MLD to advertise link information, or to multilink setup when used by non-AP MLD during multilink setup. An example of various type field values ​​that can be implemented is shown in Table 3 below. [Table 3]

[0051] The common information field 1504 includes a common control field 1508, a host link ID field 1510, an MLD MAC address field, a multilink capability field, and an SSID field. The common control field 1508 includes a host link ID present field, an MLD MAC address present field, a multilink capability present field, an SSID present field, and a link-specific information count field 1512. The link-specific information count field 1512 indicates how many link-specific information fields are present; 0 indicates none. The common information field 1504 holds information about the MLD that is common to all links, such as the MLD MAC address, multilink capability, and common SSID. The host link ID field 1510 indicates the link ID assigned to the link (i.e., the host link) on which the multilink element 1500 is transmitted. If all links in the AP MLD advertise the same SSID, an MLD-level SSID can be defined and indicated in the common information field, and the SSID field is omitted in the link-specific information field. In such cases, the beacon frame carries an SSID for legacy devices, which may be different from the MLD-level SSID defined for non-AP MLD.

[0052] The link-specific information field 1506 includes a presence bitmap field 1512, a link ID field, a capability information field, a listen interval field, an AID field, an SSID field, a BSSID / MAC address field, a non-transmitting BSSID information field 1514, an operating channel field 1516, and zero or more optional subelement fields. The presence bitmap field 1512 includes a capability information present field, a listen interval present field, an SSID present field, a BSSID / MAC address present field, a non-transmitting BSSID information present field, and an operating channel present field. The non-transmitting BSSID information includes a transmit BSSID field 1518, a MaxBSSID indicator field 1520, and a BSSID index field 1522. The operating channel field 1516 includes an operating class field and a channel number field. If present, each link-specific information field represents one of the links in the MLD; information about the host link (the link over which the frame carrying the multilink element is transmitted or the link on which the AP / VAP associated with the multilink element operates) is typically not held in the link-specific information field. If the link supports a non-transmitting BSSID, the non-transmitting BSSID information field 1518 provides the identity of the transmitting BSSID. Other sub-elements associated with the link, such as EHT operation elements, EDCA (Enhanced Distributed Channel Access) parameter set elements, etc., may be retained if they differ from the information in the host link.

[0053] Alternatively, the common control field may be located outside the common information field immediately after the type field, or may even replace the type field. In such a case, the common control field may indicate whether the ML element holds a common information field or a link-specific information field. Instead of a field, each link-specific information field may be a sub-element. Also, instead of the full SSID, a 4-octet short / compressed SSID (32-bit CRC calculated over the SSID) may be used in the common information field as well as the link-specific information field. The multilink element may also hold a non-inheritance element to indicate which elements held in the host frame are not inherited by the link information. The concept of non-inheritance can be useful when the reported link / AP does not inherit a specific element. For example, if the reporting AP (i.e., the AP corresponding to the host link / element) supports UORA (UL OFDMA-based Random Access) and the reported AP (the AP corresponding to the link-specific information) does not support UORA, the non-inheritance element signals that this information, i.e., UORA, will not be inherited.

[0054] For this reason, the link ID of the host link is indicated in the host link ID field 1510 of the multi-link element 1500. Advantageously, if the link of the MLD is a non-transmitting BSSID (i.e., does not transmit beacons), the link-specific information field 1506 of the multi-link element 1500 provides information of the corresponding transmitting BSSID to help the non-AP MLD easily detect the beacon.

[0055] Apart from the Link ID field, which is always present, the presence of other fields in the link-specific information varies depending on the usage scenario. For example, when used during discovery, the Capability Information, Listen Interval, and AID fields may be omitted. Similarly, when used during multilink setup, the Operating Channel and Non-Transmitting BSSID Information fields may be omitted. The Listen Interval field is only present in association request frames sent by non-AP MLD, and the AID field is only present in association response frames sent by AP MLD. If the SSID associated with the link is different from the SSID indicated in the host frame or common information field, the SSID field may be included in the link-specific information field 1506. The BSSID / MAC Address field holds the BSSID corresponding to the link indicated in the association response frame and the MAC address of the link in the association request frame. It will be understood that other names may be used, for example, a "host link" may be called a "sending link," a "host link ID" may be called a "sending link ID," and "link-specific information" may be called "AP information" or "STA-specific information," etc.

[0056] Several embodiments are possible for implementing the above-described technique. In a first embodiment, the beacon and probe response frame carries a multi-link element (ML element) that holds MLD common information (e.g., MLD MAC address) as well as information on other links in the MLD. The ML element identifies the link ID assigned to the host link. The host link information does not need to be held in the ML element. The ML element also holds basic information (e.g., link ID, SSID, BSSID, operating channel) of other links in the AP MLD to which the AP transmitting the frame belongs. The same information as the host link does not need to be repeated, but is inherited (inherited) from the information held in the frame or from the non-transmitting BSSID profile (in the multi-BSSID element) that holds the multi-link element. If the link in the MLD corresponds to a non-transmitting BSSID, the link information in the ML element also provides the information necessary to identify the corresponding transmit BSSID. Advantageously, the ML element has low overhead but provides enough information to help a non-AP MLD quickly find more information about the link of interest before deciding whether to associate with this AP MLD.

[0057] In a second embodiment, the host frame also carries an RNR element and / or a Neighbor Report element that holds information on some of the other APs (co-located or non-co-located). These elements also indicate the MLD MAC addresses and link IDs associated with the APs that belong to the MLD. The ML element holds the minimum information (link IDs) of the links already included in the RNR / Neighbor Report element, and holds full / complete information (link IDs, SSIDs, BSSIDs, operating channels, TBTTs (Target Beacon Transmission Time), etc.) of the other links (except the host link). Advantageously, non-AP MLD can receive information on all APs hosted on the same device from a single frame.

[0058] In a third embodiment, the host frame carries an RNR or Neighbor Report element that holds information for all co-located APs. The ML element holds minimal information (link ID, BSSID) of other links that are used to reference the RNR or Neighbor Report element for more information. The advantage of this implementation is that no changes are made to the RNR or Neighbor Report element for legacy compatibility. Furthermore, the overhead of the ML element is very low, but it relies on the inclusion of other Neighbor Report elements to provide further details of other links in the MLD.

[0059] In a fourth embodiment, the advertisement of neighbor MLDs is made more efficient by defining a new neighbor MLD report element. The neighbor MLD element can be used to maintain information about co-located MLDs as well as non-co-located MLDs. Advantageously, non-AP STAs can obtain information about MLDs from a single report element. However, if RNR or neighbor report elements for legacy STAs are also maintained, duplication of information may occur.

[0060] 16 shows a simplified diagram of a beacon / broadcast probe response frame 1600 configured for Tier 1 virtualization using all physical APs, according to a first embodiment. The beacon / broadcast probe response frame 1600 may be implemented as a beacon frame or a broadcast probe response frame. It contains a multi-link element 1604 that contains MLD common information (e.g., MLD MAC address) as well as information of other links in the MLD. The ML element 1604 identifies a host link ID, i.e., the link ID assigned to the host link (the link on which the frame is transmitted). The host link information is not contained in the ML element 1604; instead, the host link ID is used to reference the host link information 1602 contained by the beacon / broadcast probe response frame 1600.

[0061] The Multi-Link element 1604 also holds basic information about other links in the AP MLD to which the AP transmitting the frame belongs (e.g., Link ID, SSID, BSSID, operating channel, etc.). Information identical to the host link may not be repeated. This is known as inheritance, and means that the information is already present in the host frame / element or common information field. The host element references a Multi-BSSID element, which holds more information about the link referenced by the Link ID. Fields in the Multi-Link element 1604 are not repeated in the Link-Specific Information field unless the information for that link is different, in which case the information is also present in the Link-Specific Information field. It will be understood that some exceptions may exist for some fields, such as the SSID, which may be repeated for faster discovery. Additionally, if the SSID associated with a link is different from the SSID indicated in the host frame or common information field, the SSID may be included in the Link-Specific Information field. A non-AP MLD can use information from other links in the ML element 1604 to gather complete information about APs on multiple links (e.g., by scanning multiple links or by referencing RNR or neighbor report elements held in host frames) and associate with APs advertising the same SSID.

[0062] FIG. 17 shows a diagram of a beacon frame 1700 transmitted by AP-1 404 of the network 400 shown in FIGS. 4A and 4B according to a first embodiment. The beacon frame 1700 indicates the BSSID MAC address 1702 of AP-1 404 as “0A-21” and the associated SSID 1704 as “Staff.” The multi-link element 1706 indicates the type field 1708 as “Discovery.” Under common information, the host link ID 1710 is set to “1,” indicating that link ID 1 is assigned to the host link, and the MLD MAC address 1712 is indicated as “0A-20.” The multi-link element 1706 also includes three link-specific information fields 1714 representing AP-2, AP-3, and AP-4. Each link-specific information field provides information such as the link ID, SSID, BSSID, and operating channel of the represented / reported AP. Although the common control and presence bitmap fields are not shown in the ML element 1706, it will be understood that the ML element format is the same as the ML element 1500 of FIG.

[0063] 18 shows a simplified diagram of a beacon / probe response frame 1800 configured for Tier 1 virtualization using a VAP according to a first embodiment. The beacon / probe response frame 1800 includes host link information 1802, a multi-BSSID element 1804, and a multi-link element 1806 (same format as the ML element 1500). In this example, at least one BSSID in the virtual MLD preferably transmits beacon frames (i.e., is a transmitting BSSID) so that each SSID has its own beacon frame. If a link in the MLD corresponds to a non-transmitting BSSID, then instead of or in addition to the BSSID, the link information in the ML element 1806 also provides the information necessary to identify the transmitting BSSID corresponding to the non-transmitting BSSID (e.g., non-transmitting BSSID information 1808), for example, in an RNR element or neighbor report element carried in a host frame or a beacon / probe response frame of a different VAP. The transmit BSSID field 1810 identifies the AP that transmits the beacon frame 1800 that holds the non-transmit BSSID profile 1816, and the MaxBSSID indicator field 1812 and the BSSID index field 1814 can be used in conjunction with the transmit BSSID field 1810 to calculate the non-transmit BSSID.

[0064] The non-transmitting BSSID profile 1816 (within the multi-BSSID element 1804) may also contain other ML elements 1818 as optional subelements if the non-transmitting BSSID belongs to an MLD. If the link corresponds to a physical AP or a co-host AP transmitting its own beacon frame, the link-specific information identifies the BSSID of the AP. Furthermore, if an ML element 1818 is contained within the non-transmitting BSSID profile 1816 of the multi-BSSID element 1804, the host link ID field in the ML element 1818 indicates the link ID assigned to the link on which the AP corresponding to the non-transmitting BSSID operates (not the link on which the beacon frame containing the multi-BSSID element is transmitted). The AP may also split the non-transmitting BSSID profile into two or more multi-BSSID elements within the frame. If the transmit BSSID indicated in the transmit BSSID field 1810 in the non-transmit BSSID information 1808 matches the BSSID of the frame, the non-AP MLD can use the non-transmit BSSID information 1808 to obtain complete information of the link corresponding to the non-transmit BSSID from the multi-BSSID element 1804 carried in the same frame. Otherwise, the non-AP MLD can scan the link and collect complete information of the link from the beacon / probe response frame from the AP corresponding to the transmit BSSID.

[0065] The SSID field of the multilink element may be replaced by a short SSID field, which is a 32-bit CRC calculated over the SSID. The operating channel field indicates the operating channel of the link and consists of the operating class field and the channel number field, which together uniquely identify the channel on which the link operates.

[0066] 19 shows a diagram of a beacon frame transmitted by AP-1 604 of the network 600 shown in FIGS. 6A and 6B according to a first embodiment. The beacon frame 1900 indicates the BSSID MAC address 1902 of AP-1 604 as "0A-21" and the associated SSID 1904 as "Staff." The multi-link element 1906 indicates the type field 1908 as "Discovery." Under common information, the host link ID 1910 is indicated as "1" and the MLD MAC address 1912 is indicated as "0A-20." The multi-link element 1906 also includes three link-specific information fields 1914, 1916, and 1918, representing VAP-2 606, VAP-3 608, and VAP-4 610, respectively. The link-specific information field 1914 provides information about the represented VAP-2 606, such as link ID (denoted as "2"), SSID (denoted as "Staff"), non-transmitting BSSID information, and operating channel. The link-specific information field 1916 provides information about the represented VAP-3 608, such as link ID (denoted as "3"), SSID (denoted as "Guest"), BSSID (denoted as 0E-21), and operating channel. The link-specific information field 1918 provides information about the represented VAP-4 610, such as link ID (denoted as "4"), SSID (denoted as "Guest"), non-transmitting BSSID information 1920, and operating channel. Non-transmitting BSSID information 1920 provides information about VAP-5 612 (because VAP-4 610 and VAP-5 612 are virtual APs of the same AP and form VAP Set 2), such as the transmit BSSID (denoted as 0E-22), MaxBSSID indicator, and BSSID index. The common control and presence bitmap fields are not shown in the ML element 1906, although it will be understood that the ML element format is the same as the ML element 1500 of FIG. 15.

[0067] 20 shows a diagram of a beacon frame 2000 transmitted by VAP-3 608 of the network 600 shown in FIGS. 6A and 6B according to a first embodiment. The beacon frame 2000 indicates the BSSID MAC address 2002 of VAP-3 608 as "0D-22" and the associated SSID 2004 as "Guest." The multi-link element 2006 indicates the type field 2008 as "Discovery." Under common information, the host link ID 2010 is set to "3," indicating that the link ID assigned to the host link is 3, and the MLD MAC address 2012 is indicated as "0A-20." The multi-link element 2006 also includes three link-specific information fields 2014, 2016, and 2018, representing AP-1 604, VAP-2 606, and VAP-4 610, respectively. The link-specific information field 2014 provides information about the represented AP-1 604, such as a link ID (denoted as "1"), SSID (denoted as "Staff"), BSSID (denoted as "0A-21"), and operating channel. The link-specific information field 2016 provides information about the represented VAP-2 606, such as a link ID (denoted as "2"), SSID (denoted as "Staff"), non-transmitting BSSID information 2022, and operating channel. The link-specific information field 2018 provides information about the represented VAP-4 610, such as a link ID (denoted as "4"), SSID (denoted as "Guest"), non-transmitting BSSID information 2020, and operating channel. The non-transmitting BSSID information 2020 provides information about VAP-5 612, i.e., refers to the non-transmitting BSSID of a different VAP set.

[0068] The beacon frame 2000 also includes a multi-BSSID element field 2024 that provides information of the non-transmitting BSSID VAP-2 606 (because VAP-2 606 and VAP-3 608 are virtual APs of the same AP and form VAP set 1). The multi-BSSID element field 2024 includes the non-transmitting BSSID profile of VAP-2 606, which includes at least the SSID information (denoted as "Staff") and another multi-link element 2026 that holds the information of AP MLD1, because VAP-2 corresponds to the non-transmitting BSSID profile and belongs to AP MLD1. The non-transmitting BSSID information 2022 refers to the non-transmitting BSSID profile of this VAP-2 606 (i.e., the non-transmitting BSSID profile of the same VAP set). Since the MLD information is already held in the host frame 2000, the ML element 2026 held in the non-transmitting BSSID profile only holds the MLD MAC address (shown as "0A-20") in the common information field and can use this to reference the ML element 2006 in the host frame. The common control and presence bitmap fields are not shown in the ML elements 2006 and 2026, but it will be understood that the ML element format is the same as the ML element 1500 of FIG. 15.

[0069] 21 shows a diagram of a beacon frame 2100 transmitted by VAP-5 612 of the network shown in FIGS. 6A and 6B according to a first embodiment. The beacon frame 2100 indicates the BSSID MAC address 2102 of VAP-5 604 as "0E-22" and the associated SSID 2104 as "IOT." The multi-BSSID element 2106 provides information for the non-transmitting BSSID VAP-4 610 (because VAP-4 610 and VAP-5 612 are virtual APs of the same AP and form VAP Set 1). The multi-BSSID element field 2106 contains the non-transmitting BSSID profile of VAP-4 610, which includes at least information for the SSID (shown as "Guest") and a multi-link element 2108. Generally, the non-transmitting BSSID profile of a VAP that is part of an AP MLD also contains a multi-link element that holds MLD-related information. In this case, the multi-link element 2108 maintains the MLD-related information of the AP MLD 602 ​​.

[0070] In Tier 2 virtualization, beacon and probe-response frames have the same format as Tier 1, except that all VAPs in an AP MLD advertise the same SSID, and therefore the SSID field is not advertised in the individual link-specific information fields. The SSID field may be advertised in the common information field of the multi-link element, or may be skipped entirely if the value is the same as the SSID advertised by the host beacon or probe-response frame. In Tier 2 virtualization, because VAPs of the same physical AP cannot reside in the same MLD, the untransmitted BSSID information in the link-specific information field cannot be found in the multi-BSSID element of the host frame and must be retrieved from the RNR or neighbor report elements carried in the host frame, or from the multi-BSSID elements carried in the beacon or probe-response frames of other APs. 22, for beacon / probe response frame 2200 for BSSID1, the non-transmit BSSID information in link 2 information field 2204 cannot be found in multi-BSSID element 2202 of host frame 2200 and must be retrieved from multi-BSSID element 2208 carried in beacon / probe response frame 2206 for BSSID2. The transmit BSSID field in the non-transmit BSSID information points to beacon frame 2206 for BSSID2, and the BSSID index is used to find the non-transmit BSSID profile in the multi-BSSID element carried in beacon frame 2206.

[0071] 23 shows a diagram of a beacon frame 2300 transmitted by VAP-1 1008 of the network 1000 shown in FIGS. 10A and 10B according to the first embodiment. The beacon frame 2300 indicates the BSSID MAC address 2302 of VAP-1 1008 as "0A-21" and the associated SSID 2304 as "Staff." The multilink element 2306 indicates the type field 2308 as "Discovery." Under common information, the host link ID 2310 is indicated as "1" and the MLD MAC address 2312 is indicated as "0A-20" (i.e., the MAC address of AP MLD1 1002). The multilink element 2306 also includes two link-specific information fields 2314 and 2316, which represent VAP-3 1012 and VAP-5 1016, respectively. The link-specific information field 2314 provides information about the represented VAP-3 1012, such as the link ID (denoted as "2"), operating channel, and non-transmit BSSID information 2318. The link-specific information field 2316 provides information about the represented VAP-5 1016, such as the link ID (denoted as "3"), operating channel, and non-transmit BSSID information 2320. The non-transmit BSSID information 2320 provides information about the VAP-6 1018, such as the transmit BSSID (denoted as 0D-31), MaxBSSID indicator, and BSSID index.

[0072] The beacon frame 2300 also includes a multi-BSSID element 2322 that provides information for the non-transmitting BSSID VAP-2 1010 (since VAP-1 1008 and VAP-2 1010 form VAP Set 1). The multi-BSSID element 2322 includes the non-transmitting BSSID profile 1 of VAP-2 1010, which includes information for at least an SSID (shown as "Guest") and another multi-link element 2324. The multi-link element 2324 indicates a type field 2326 as "Discovery." Under the common information, the host link ID 2328 is set to "1," indicating the link ID assigned to the host link over which the beacon frame 2300 is transmitted, and the MLD MAC address 2330 is indicated as "0D-20" (i.e., the MAC address of AP MLD2 1004). The multilink element 2324 also includes a link-specific information field 2332 representing VAP-4 1014, which provides information about the represented VAP-4 1014, such as the link ID (denoted as "2"), operating channel, and BSSID (denoted as 0D-21). The common control and presence bitmap fields are not shown in the ML elements 2306 and 2324, although it will be understood that the ML element format is the same as the ML element 1500 of FIG. 15.

[0073] Note that in the ML element 2324 carried within non-transmitting BSSID profile 1 of the multi-BSSID element 2322 in the beacon frame 2300 transmitted by VAP-1 1008, the host link ID field indicates link ID (1) assigned to the VAP corresponding to non-transmitting BSSID profile 1 (i.e., VAP-2 1010). In this example, the link ID happens to be the same as link ID (1) assigned to the VAP transmitting the beacon frame 2300, but they would be different if global link ID allocation were used instead of local link ID allocation. Also, because all links of AP MLD2 advertise the same SSID, an MLD-level SSID may be defined for AP MLD2, and the SSID field is omitted in the link-specific information field of the ML element 2324.

[0074] 24 shows a diagram of a beacon frame 2400 transmitted by VAP-4 1014 of the network 1000 shown in FIGS. 10A and 10B according to a first embodiment. The beacon frame 2400 indicates the BSSID MAC address 2402 of VAP-4 1014 as "0D-21" and the associated SSID 2404 as "Guest." The multilink element 2406 indicates the type field 2408 as "Discovery." Under common information, the host link ID 2410 is indicated as "2" and the MLD MAC address 2412 is indicated as "0D-20." The multilink element 2406 also includes a link-specific information field 2414 representing VAP-2 1010. The link-specific information field 2414 provides information about the represented VAP-2 1010, such as the link ID (denoted as "1"), the operating channel, and non-transmit BSSID information 2416. The non-transmit BSSID information 2416 provides information about VAP-1 1008, such as the transmit BSSID (denoted as 0A-21), the MaxBSSID indicator, and the BSSID index.

[0075] Beacon frame 2400 also includes a multi-BSSID element 2418 that provides information for non-transmitting BSSID VAP-3 1012 (since VAP-3 1012 and VAP-4 1014 form a VAP set). Multi-BSSID element 2418 includes non-transmitting BSSID Profile 1 for VAP-3 1012, which includes at least the SSID information (shown as "Staff") and another multi-link element 2420 that holds the MLD MAC address of AP MLD1 1002 in the common information field. The common control and presence bitmap fields are not shown in ML elements 2406 and 2420, although it will be understood that the ML element format is the same as ML element 1500 of FIG. 15.

[0076] 25 shows a diagram of a beacon frame 2500 transmitted by VAP-6 1018 of the network 1000 shown in FIGS. 10A and 10B according to the first embodiment. The beacon frame 2500 indicates the BSSID MAC address 2502 of VAP-6 1018 as “0D-31” and the associated SSID 2504 as “IOT.” The beacon frame 2500 also includes a multi-BSSID element 2506 that provides information of the non-transmitting BSSID VAP-5 1016 (since VAP-5 1016 and VAP-6 1018 form a VAP set). The multi-BSSID element 2506 includes the non-transmitting BSSID profile 1 of VAP-5 1016, which includes at least information of the SSID (shown as “Staff”) and another multi-link element 2508 that holds the MLD MAC address of AP MLD1 1002 in the common information field.

[0077] A non-AP MLD can request complete information about the AP MLD's other links by sending a probe request frame on any one of the AP MLD's links. Figure 26 shows a diagram of a probe request frame 2600 sent by a non-AP MLD to VAP-1 1008 of the network 1000 shown in Figures 10A and 10B according to a first embodiment. The probe request frame 2600 includes a BSSID field 2602 indicated as "0A-21," i.e., the MAC address of VAP-1 1008, a wildcard SSID 2604, and a multilink element 2606. The multilink element 2606 indicates the type field 2608 as "discovery." Under the common information, the MLD MAC address 2610 is indicated as "10-20," signaling the AP MLD for which information is desired. The multilink element 2606 also includes two link-specific information fields 2612 and 2614, which indicate link ID2 and link ID3, respectively. In other words, the multilink element 2606 indicates the AP MLD and links for which complete information is desired. The link-specific information fields indicate additional links (i.e., other than the link over which the frame is being transmitted) for which more information is desired. If information for all links in the AP MLD is desired, the link-specific information fields may be omitted.

[0078] In response to the probe request frame 2600, the AP MLD sends a unicast probe response frame 2700 carrying complete information about the requested links, i.e., link IDs 1, 2, and 3, as shown in FIG. 27. The probe response frame 2700 is sent from VAP-1 1008 to the non-AP MLD that sent the probe request frame 2600. The probe response frame 2700 indicates the BSSID MAC address 2702 of VAP-1 1008 as "0A-21" and the associated SSID 2704 as "Staff." The multilink element 2706 indicates the type field 2708 as "Discovery." Under common information, the host link ID 2710 is indicated as "1" and the MLD MAC address 2712 is indicated as "0A-20." The multilink element 2706 also includes two link-specific information fields 2714 and 2716, which represent VAP-3 1012 and VAP-5 1016, respectively. The link-specific information field 2714 provides information about the represented VAP-3 1012, such as a link ID (denoted as "2"), operating channel, BSSID, operating parameters, and EDCA parameter set. The link-specific information field 2716 provides information about the represented VAP-5 1016, such as a link ID (denoted as "3"), operating channel, BSSID, operating parameters, and EDCA parameter set. In other words, the multilink element 2706 includes complete information of the requested links, including links corresponding to non-transmitting BSSIDs.

[0079] The probe response frame 2700 also includes a multi-BSSID element 2718 that provides information for the non-transmitting BSSID VAP-2 1010 (since VAP-1 1008 and VAP-2 1010 form a VAP set). The multi-BSSID element 2718 includes the non-transmitting BSSID profile 1 of VAP-2 1010, which includes at least the SSID information (denoted "Guest") and another multi-link element 2720 that holds the MLD MAC address of AP MLD2 1004 in the common information field. The common control and presence bitmap fields are not shown in the ML elements 2706 and 2720, but it will be understood that the ML element format is the same as the ML element 1500 of FIG. 15. If multiple probe requests are received nearly simultaneously or close to the TBTT, a broadcast probe response frame may also be used instead of a unicast probe response frame, and a beacon frame may hold the complete information instead of a probe response frame.

[0080] In a second embodiment, the beacon and probe response frame may contain an RNR element and / or a neighbor report element that contains information about other APs (co-located or non-co-located). These elements also indicate the MLD MAC addresses and link IDs associated with APs that belong to the MLD. Furthermore, non-transmitting BSSIDs whose profiles are included in the multi-BSSID element in the same frame are not included. As seen in the beacon / probe response frame 2800 of FIG. 28, the multi-link element 2802 contains the minimum information (link IDs) of the links already included in the RNR / neighbor report element and contains basic / full information (link IDs, SSIDs, BSSIDs, operating channel, TBTT, etc.) of other links except the host link.

[0081] Taking the network 1000 of Figure 10A as an example, in a beacon frame transmitted by VAP-1 1008, if VAP-2 1010 and VAP-3 1012 are non-transmitting BSSIDs, information about VAP-4 1014, VAP-5 1016, and VAP-6 1018 is held in the condensed neighbor report element, and the multilink element holds the full information of VAP-3 1012 and the minimal information of VAP-5 1016. However, if all VAPs are co-host APs that transmit their own beacons, they may also be included in the condensed neighbor report element. Advantageously, non-AP MLD can receive information about all APs hosted on the same device from a single frame.

[0082] As an example, to provide information about an AP or VAP, a neighbor report element 2900 shown in FIG. 29 may be used, and a multilink element 2902 may be included as an optional subelement. In this case, the neighbor report element 2900 provides information about VAP-2 1010 in FIG. 10A and indicates the BSSID corresponding to VAP-2, which belongs to AP MLD2 1004, as "0A-22." The multilink element 2902 indicates the AP MLD and link ID to which this AP (VAP-2) belongs. For example, the multilink element 2902 indicates the type field 2904 as "Discovery." Under common information, the MLD MAC address 2906 is indicated as "0D-20," i.e., the MLD MAC address of AP MLD2 1004. The multilink element 2902 also includes a link-specific information field 2908, which represents VAP-2 and provides information about the represented VAP-2, such as the link ID (shown as "1").

[0083] As an example, the abbreviated neighbor report element 3000 shown in FIG. 30 may be used to provide information about multiple APs or VAPs. In this case, the abbreviated neighbor report element 3000 provides information about VAP-2 1010 in FIG. 10A, and indicates the BSSID of VAP-2 in the TBTT information set field 3002 belonging to AP MLD2 1004, and indicates VAP-2's short SSID as "32-CRC(Guest)." Two fields are also added to the TBTT information set field 3002. The newly added fields 3004 and 3006 indicate the AP MLD MAC address and link ID to which this AP (VAP-2) belongs, respectively. The "TBTT information field type" subfield 3008, alone or in conjunction with the "TBTT information length" subfield 3010 of the RNR element, indicates the presence of additional MLD information. For example, if the "TBTT information field type" is set to a value other than 0, this indicates that the TBTT information set holds MLD information. For example, if it is set to 1, the Link ID field is retained, if it is set to 2, both the Link ID and MLD MAC address are retained, or if the "TBTT Information Length" is set to 13, the Link ID field is retained, if it is set to 18, the MLD MAC address is retained, and if it is set to 19, both the Link ID and MLD MAC address are retained.

[0084] In the third embodiment, the beacon & probe response frame carries a multi-link element that carries MLD common information (eg, MLD MAC address) as well as information of other links of the MLD.

[0085] The host frame contains an RNR or neighbor report element that holds information about all co-located APs. A link ID is assigned globally to all co-located MLDs. As shown in the beacon / probe response frame 3100 of FIG. 31, the multilink element 3104 holds minimal information about other links (link ID, BSSID), which is used to reference the RNR or neighbor report element 3102 for more information. Advantageously, for legacy compatibility, no changes are made to the RNR or neighbor report element. The BSSID is used to link the information in the RNR or neighbor report element to the multilink element, since the RNR element always holds the BSSID of the reported AP. A non-AP MLD can initiate multilink setup using the information in the multilink element and the RNR or neighbor report element without having to scan other links to gather complete information about the links.

[0086] FIG. 32 shows a diagram of a beacon frame transmitted by VAP-1 1008 of the network 1000 shown in FIGS. 10A and 10B according to the third embodiment. In this example, link ID assignment is global to the co-located AP MLDs, i.e., link IDs of co-located MLDs are not repeated. Example: Link IDs for AP MLD1: 1 (VAP-1), 2 (VAP-3), 3 (VAP-5); Link IDs for AP MLD2: 4 (VAP-2), 5 (VAP-4). The beacon frame 3200 indicates the BSSID MAC address 3202 of VAP-1 1008 as "0A-21" and the associated SSID 3204 as "Staff." The multilink element 3206 holds information about the AP MLD to which VAP-1 1008 belongs, i.e., AP MLD1 1002. The multi-link element 3206 indicates the type field 3208 as "Discovery." Under common information, the host link ID 3210 is set to "1," indicating that VAP-1 1008 operates on the link assigned link ID 1, and the MLD MAC address 3212 is indicated as "0A-20." The multi-link element 3206 also includes two link-specific information fields 3214 and 3216, which represent other APs belonging to the AP MLD1 1002, namely, VAP-3 1012 and VAP-5 1016, respectively. The link-specific information field 3214 provides information about the represented VAP-3 1012, such as the link ID (indicated as "2") and the BSSID (indicated as "0D-22"). The link-specific information field 3216 provides information about the represented VAP-5 1016, such as the link ID (shown as "3") and the BSSID shown as "0A-23."

[0087] The beacon frame 3200 transmitted by VAP-1 1008 also includes a multi-BSSID element 3218 that provides information about the non-transmitting BSSID VAP-2 1010 (because VAP-1 1008 and VAP-2 1010 form a multi-BSSID set and VAP-1 1008 is the transmit BSSID of this multi-BSSID set). The multi-BSSID element 3218 includes the non-transmitting BSSID profile 1 of VAP-2 1010, which includes at least information about the SSID (shown as "Guest") and another multi-link element 3220 that provides information about the AP MLD to which VAP-2 belongs, i.e., AP MLD2 1004. The multi-link element 3220 indicates the type field 3222 as "discovery." Under the common information, the host link ID 3224 is set to "4," indicating that link ID 4 is assigned to the link on which VAP-2 operates, and the MLD MAC address 3226 is indicated as "0D-20." The multilink element 3220 also includes a link-specific information field 3228 that represents VAP-4 1014. The link-specific information field 3228 provides information about the represented VAP-4 1014, such as the link ID (indicated as "5") and the BSSID 3230 (indicated as "0D-21"). For example, the BSSID 3230 is used to link information in the RNR element 3300 of FIG. 33 to the multilink element 3220. The RNR element 3300 includes information about VAP-4 1014 in the TBTT information set field 3302, such as the BSSID (which is used to link information to the multilink element 3220) and the short SSID of SSID: Guest.

[0088] Note that in the multi-link element 3220 held within non-transmitting BSSID profile 1 of the multi-BSSID element 3218 in the beacon frame 3200 transmitted by VAP-1 1008, the host link ID field indicates link ID "4" assigned to the VAP corresponding to non-transmitting BSSID profile 1 (i.e., VAP-2 1010). In this example, link ID "4" differs from link ID "1" assigned to VAP-1 1008 transmitting the beacon frame 3200 because global link ID assignment is used instead of local link ID assignment.

[0089] Figure 34 shows a diagram of a multilink element 3400 for unified signaling according to a fourth embodiment. The link-specific information may be referred to as STA-specific information (as shown in STA-specific information field 3402), and zero or more STA-specific information fields may exist in the multilink element 3400, with each field holding information for one AP in the AP MLD or one STA in the non-AP MLD. The STA-specific information field 3402 also contains information for the host AP transmitting the frame containing the multilink element or the host AP corresponding to the non-transmitting BSSID profile in which the multilink element is included. The transmitting STA field 3404 (e.g., a bit set to 1) in the STA-specific information field 3402 indicates that this STA-specific information field 3402 holds information for the host AP, and the link ID field 3406 indicates the link ID assigned to the link on which the host AP operates. Other fields in the STA-specific information field may be omitted for the host AP. At most, there must be one STA-specific information field for the host AP in the multilink element. If information for some APs or VAPs is already held in some other elements, for example, if information for VAP-5 is also held in the multi-BSSID element or the RNR element, only basic information about the link is provided, allowing the receiving non-AP STA to gather complete information by referring to other elements as described in the previous embodiments. As a variant, instead of a field, each STA information 3402 can also be a sub-element holding its own element ID and length.

[0090] 35 shows a diagram of a beacon frame 3500 transmitted by VAP-1 1008 of the network 1000 shown in FIGS. 10A and 10B according to the fourth embodiment. In this example, the link ID assignment is also global to the co-located AP MLDs, i.e., link IDs of co-located MLDs are not repeated. Example: Link IDs for AP MLD1: 1 (VAP-1), 2 (VAP-3), 3 (VAP-5); Link IDs for AP MLD2: 4 (VAP-2), 5 (VAP-4). In the multilink element 3502 of the beacon frame 3500, there are three STA-specific information fields 3508, 3510, and 3512 that provide information about VAP-1 1008, VAP-3 1012, and VAP-5 1016, respectively. The STA-specific information field 3508 indicates that the VAP it represents (i.e., VAP-1 1008) is the transmitting STA of the beacon frame 3500 by setting the transmitting STA field 3514 to "1." Similarly, the transmitting STA fields 3516 and 3518 indicate that VAP-3 1012 and VAP-5 1016 are not the transmitting STAs of the beacon frame 3500. In the multilink element 3506 held within the non-transmitting BSSID profile 1 of the multi-BSSID element 3504, the transmitting STA field 3524 within the STA-specific information field 3520 is set to "1," indicating that the represented VAP-2 1010 is the VAP represented by the non-transmitting BSSID profile 1. The transmitting STA field 3526 within the STA-specific information field 3522 is set to "0," indicating that the represented VAP-4 1014 is not the VAP represented by the non-transmitting BSSID profile 1. The Transmit STA bit of a multilink element in a non-transmit BSSID profile should not be confused as meaning that the indicated VAP is the transmit BSSID; this bit simply indicates the VAP represented by the non-transmit BSSID profile.Note that in the multi-link element 3506 carried within non-transmitting BSSID profile 1 of the multi-BSSID element 3504 in the beacon frame 3500 transmitted by VAP-1 1008, the transmitting STA field 3524 is set to 1 in the first STA-specific information field, indicating link ID "4" assigned to the VAP corresponding to non-transmitting BSSID profile 1 (i.e., VAP-2 1010). In this example, link ID "4" differs from link ID "1" assigned to VAP-1 1008 transmitting the beacon frame 3500 because global link ID assignment is used instead of local link ID assignment.

[0091] In deployments targeting only EHT devices, neighbor MLD advertisements can be made more efficient by defining a new neighbor MLD report element 3600 as shown in Figure 36. Each neighbor MLD information field 3602 and 3604 holds a multilink element, i.e., multilink elements 3606 and 3608, respectively. The link information can be partial or complete. A bit in each neighbor information field is used to indicate co-located MLDs. For example, VAP-6 1018 in Figure 10A can advertise co-located APs MLD1 and MLD2 by transmitting neighbor MLD report element 3600.

[0092] If information for some APs or VAPs is already carried in some other element, e.g., information for VAP-5 is also carried in the Multi-BSSID element or the RNR element, only basic information about the link is provided, allowing a receiving non-AP STA to gather complete information by referring to other elements as described in the previous embodiments. An exemplary Neighbor MLD Report element 3600 is carried in a frame transmitted in the network 1000 of FIG. 10A by VAP-6 1018, advertising AP MLD1 1002 and AP MLD2 1004. Because VAP-6 1018 is not included in any of the reported AP MLDs, the "transmitting STA" bits in all STA-specific information fields are set to 0 in this case.

[0093] If the AP reported in the RNR element corresponds to a non-transmitting BSSID (indicated by BSS parameter fields: Multi BSSID = 1, Transmit BSSID = 0), the BSSID may be omitted in the RNR element, and instead a non-transmitting BSSID information field is held, which holds the information necessary to identify the transmit BSSID corresponding to the AP, as well as other information necessary to calculate the AP's BSSID. Example signaling is shown in RNR element 3700 of Figure 37, where BSSID field 3702 is omitted because the BSS parameter field 3704 (Multi BSSID = 1, Transmit BSSID = 0) indicates that the RNR element corresponds to a non-transmitting BSSID. Therefore, RNR element 3700 instead holds a non-transmitting BSSID information field 3706 to identify the transmit BSSID corresponding to the AP, as well as other information necessary to calculate the AP's BSSID.

[0094] During a typical multilink setup procedure, a non-AP STA includes the MAC addresses of its links by including them in a multilink element, and if multilink setup is successful, the AP MLD updates the non-AP MLD's records with those MAC addresses. However, in certain deployments, such as an enterprise network, the network may assign the non-AP MLD the MAC addresses of its links. Initially, the non-AP MLD may contain only one global MAC address, which is used not only as the MLD MAC address but also as the link MAC address of any one link at a time for discovery and multilink setup. During multilink setup (see association request frame 3800 in FIG. 38), a non-AP STA may request the MAC addresses of one or more of its links by including one or more FILS HLP container elements 3802 in the multilink setup frame (e.g., in association request frame 3800, the type field 3808 of multilink element 3806 indicates "multilink setup"). The FILS HLP container 3802 may hold a DHCPv6 packet 3804 requesting one or more MAC addresses from a connected DHCP server. In such cases, the non-AP MLD may omit the MAC address field in the multi-link element. For example, the MAC addresses of the non-AP STAs corresponding to the link are not included in the link-specific information field of the multi-link element 3806. The absence of an L2 MAC address and the inclusion of the FILS HLP container 3802 in the association request frame 3800 alerts the AP MLD that the non-AP MLD is requesting an L2 MAC address using a higher layer protocol.The non-AP MLD's MLD MAC address is used as the TA / RA (indicated in the TA field 3810 of the association request frame 3800) in association request / response frames and any other frames for communication with the non-AP MLD until the non-AP MLD obtains and updates its L2 MAC address. The AP MLD then obtains the non-AP MLD's MAC address (e.g., from a DHCP server) and forwards it to the non-AP MLD in the association response frame or subsequent data frame according to the upper layer protocol encapsulation procedures described in the 802.11 specification. Once the MAC address is installed in the non-AP MLD, it can inform the AP of the link MAC address by sending a dedicated frame (e.g., a MAC Address Update Action frame) that holds a multi-link element that holds the MAC address in the link-specific information field, or the non-AP MLD can use a multi-link re-setup frame (e.g., multi-link re-setup frame 3900 of FIG. 39) or any other suitable frame with the type field set to "MAC Address Update" (as shown in type field 3904 of multi-link element 3902) and the link-specific information holding a multi-link element that holds the MAC address of each link. The multi-link re-setup frame 3900 can be a reassociation request frame. Upon receiving the MAC address, the AP MLD can update the non-AP MLD's records and proceed to communicate with the non-AP MLD on all links using the L2 MAC address.

[0095] According to the fifth embodiment, the beacon & probe response frame carries a multi-link element that carries only MLD common information (e.g., MLD MAC address, host link ID) but not information about other links of the MLD. The host frame carries an RNR or neighbor report element that carries information about all co-located APs (i.e., APs housed in the same physical device). An exemplary beacon & probe response frame 4000 is shown in FIG. 40, where information about all co-located APs is carried in the RNR or neighbor report element 4002, and the multi-link element 4004 carries only the MLD MAC address and host link ID. Of course, the MLD MAC address and host link ID could also be carried as fields directly in the beacon / probe response frame instead of being included in the multi-link element.

[0096] The RNR element or neighbor report element according to the fifth embodiment indicates which of the reported APs belong to the same MLD as the AP transmitting the frame. Referring to the RNR element 4100 shown in FIG. 41, if the reported AP is part of a multi-BSSID set, e.g., VAP-2, as shown in the TBTT information set 4102, the BSSID index 4108, together with the BSSID field 4104, indicates the corresponding transmitting BSSID (i.e., VAP-1). Furthermore, one bit in the BSS parameters field 4106 (or the TBTT information header field 4110) indicates whether this AP reported in the RNR element 4100 belongs to the same AP MLD whose MLD MAC address is carried in the frame carrying this RNR element. The RNR element may also include a change sequence number indicating a significant change to the BSS parameters of the AP reported by this TBTT information set. When a non-AP MLD associated with the AP MLD to which this reported AP belongs receives the RNR element, it can compare this change sequence number with its locally stored change sequence number. If they differ, it is alerted to a significant change to the BSS parameters of the reported AP and can proceed to listen for beacon / probe response frames transmitted by the reported AP to retrieve the relevant BSS parameters. Alternatively, the BSSID index 4108 may refer to a unique index assigned to the reported AP among all co-located APs. By comparing the BSSID index with the mapping of BSSID index and co-located AP MLD, the non-AP MLD receiving this RNR element can determine which reported AP belongs to which AP MLD.

[0097] FIG. 42 shows a diagram of a network 4200 according to a sixth embodiment. The network 4200 is similar to the network 500 shown in FIGS. 5A and 5B, but also supports an additional SSID specifically for legacy non-AP STAs. In addition to advertising SSID:Multi-links, AP-1 4204 also advertises SSID:5GHz_Link specifically for legacy non-AP STAs operating in the 5 GHz band, and AP-2 506 also advertises SSID:2.4GHz_Link specifically for legacy non-AP STAs operating in the 2.4 GHz band, such as legacy STA 4220. In this deployment, the existing SSID field of the beacon frame transmitted by the AP retains the SSID assigned for legacy non-AP STAs, but the SSID assigned for non-AP MLD is advertised within the multi-link element. In this way, it is possible to create separate network policies for MLD and legacy STAs.

[0098] FIG. 43A shows a beacon frame 4300 transmitted by, for example, AP-1 4304 of FIG. 42. In the SSID field 4310 of the beacon frame, SSID: 5GHz_link is advertised for legacy non-AP STAs. In the multi-link element 4312, information for AP MLD1 4202 is advertised. Here, the multi-link element 4312 holds basic information for all three APs in AP MLD1 4202. The first STA-specific information field holds information for AP-1 4204, so the "transmitting STA" bit 4320 is set to 1. It also includes an SSID field 4330 set to "Multi-links." Similarly, the second STA-specific information field holds information for AP-2 4206, so the "transmitting STA" bit is set to 0. It also includes an SSID field 4340 set to "Multi-links." Similarly, the third STA-specific information field holds information for AP-3 4208, so the "Transmitting STA" bit is set to 0. It also holds the SSID field 4350 set to "Single-link" because AP-3 4208 supports single-link non-MLD devices. Of course, if AP-3 4208 also supports legacy non-AP STAs, it can advertise other SSIDs for the legacy non-AP STAs, or the same "Single-link" SSID can be used for the legacy non-AP STAs. If all APs belonging to the AP MLD advertise the same SSID for the non-AP MLD on all links, the SSID for the non-AP MLD can be signaled in the common information field, and the SSID field can be omitted in the STA-specific information field. Furthermore, if the SSID advertised by the AP in the AP MLD is the same as the SSID of the legacy STA, the SSID field can be omitted entirely in the multilink element, and non-AP MLDs receiving this beacon (and multilink element) will infer the SSID based on inheritance.

[0099] Instead of (or in addition to) the multi-link element 4312, one or more RNR elements may be used to advertise the SSID:Multi-links of non-AP MLD by including a list of short SSIDs in the RNR element corresponding to one or more overlaid SSIDs. This is shown in FIG. 43B, where the RNR element 4360 advertises the information of AP-1 4204 in FIG. 42. The short SSID field 4370 indicates the short SSIDs of legacy and non-AP STAs, and a new field, Overlaid_SSID_List 4380, is added to the RNR element to advertise one or more short SSIDs corresponding to SSIDs overlaid on the legacy SSID, i.e., other SSIDs that AP-1 4204 supports on the same link. In this example, the Overlaid_SSID_List holds a single short SSID corresponding to the SSID:Multi-links. Upon receiving the RNR element, the non-AP MLD knows that AP-1 4204 also provides access to the network Multi_Links.

[0100] In this deployment, it can be seen that the non-AP MLD SSID (i.e., SSID:Multi-links) is overlaid on both link 1 (AP-1) and link 2 (AP-2). Therefore, the MLME-START.request primitive used when initiating a BSS on AP-1 and AP-2 needs to be modified to also include a parameter Overlaid_SSID_List indicating a list of one or more SSIDs to be overlaid on the legacy SSIDs, e.g., Overlaid_SSID_List includes SSID:Multi-links in the case of AP-1 4204 and AP-2 4206, and SSID:Single-link in the case of AP-3 4208. An example of such an MLME-START.request primitive is as follows: MLME-START.request( SSID, BSSType, …, Overlaid_SSID_List )

[0101] When one or more SSIDs are overlaid on a legacy SSID, one potential issue is that if a physical AP serves both legacy non-AP STAs and non-AP MLDs, the AP transmits broadcast and group address data frames belonging to both SSIDs on the same link (channel). For example, AP-1 4204 transmits a broadcast data frame with SSID:Multi-links on the 5 GHz link (Link 1) to non-AP MLD-1 on the 5 GHz link. However, the legacy non-AP STA 4220, operating on the 5 GHz link, also receives this broadcast data frame. Because the transmitter address (TA) is set to the MAC address of AP-1 and the receiver address (RA) is set to the broadcast MAC address, the legacy non-AP STA 4220 considers this frame to be directed to itself and attempts to decode it. However, since the group security key (GTK) for SSID:Multi-links may be different from the GTK for SSID:5GHz_link, non-AP STAs will not be able to decode the data payload. This problem also occurs in other cases, i.e., broadcast data frames intended for legacy STAs are also unnecessarily decoded by non-AP MLD.

[0102] One way to overcome this challenge is to use the MLD MAC address as the TA (Address 2) of the broadcast data frame (e.g., 4400) shown in Figure 44A. Here, the TA field 4410 is set as the MLD MAC address of AP MLD-1 4202. Because the TA is different from the MAC address of AP-1, legacy non-AP STAs will discard this frame, but the non-AP MLD recognizes the MLD MAC address and correctly receives the broadcast data frame 4400. Similarly, the non-AP MLD can be configured to ignore broadcast data frames that contain the AP's L2 MAC address in the TA field. A similar method can also be used for broadcast management frames intended only for non-AP STAs associated with a particular SSID. However, for management frames, broadcast frames intended for non-AP MLD can be distinguished by using the Address 3 field instead of the Address 2 (TA) field and setting Address 3 as the AP MLD's MAC address instead of the link's BSSID (i.e., the L2 MAC address of the serving AP operating on the link). Referring to the broadcast management frame 4420 in FIG. 44B transmitted by AP-1 4204 in FIG. 42, the TA field 4430 is set as the L2 MAC address (0A-21) of AP-1 4204, while the BSSID field 4432 is set as the MLD MAC address (0A-20) of AP MLD-1 4202. Because the BSSID is different from AP-1's MAC address, legacy non-AP STAs will discard this frame, but the non-AP MLD recognizes the MLD MAC address and therefore correctly receives the broadcast management frame 4420. Similarly, except for certain important broadcast frames (e.g., beacon frames, probe response frames, FILS discovery frames, channel switch announcement frames, etc.), the non-AP MLD can be configured to ignore other types of broadcast management frames that contain the AP's L2 MAC address in the BSSID field.

[0103] While the above two methods can help avoid broadcast storms for specific types of frames, a more general method applicable to all frame types can also be envisioned. Figure 44C shows a generic MAC frame 4440 specifically designed for use in split network cases, such as when interconnecting with VLANs or when two or more SSIDs are overlaid on the same wireless channel. MAC frame 4440 is distinguished from legacy MAC frames by, for example, setting protocol version field 4442 in the frame control field of the MAC header to a previously unused value (e.g., 2). When protocol version field 4442 is set to this new value (e.g., 2) or greater, a new field, VLAN ID 4446, is retained in the MAC frame, for example, immediately before the frame body field. When an AP interconnects a wireless network with a wired network that implements VLANs, VLAN ID field 4446 is set to the corresponding VLAN ID used in the wired network (as shown in Figures 7 and 12). If the AP does not interconnect with a wired VLAN, a unique VLAN ID is assigned to each SSID operating on the link and communicated to non-AP STAs operating on the link, for example, during the association process.

[0104] For example, in the network 4200 of FIG. 42, apart from SSID:Multi-links, another SSID:Multi-links-guest may also be served by both AP-1 4204 and AP-2 4206 on links 1 and 2, respectively. VLAN IDs 1 and 2 may be assigned to SSID:Multi-links and SSID:Multi-links-guest, respectively. In all MAC frames for non-AP MLD or non-AP STAs participating in SSID:Multi-links, the VLAN ID field 4446 is set to 1, and in all MAC frames for non-AP MLD or non-AP STAs participating in SSID:Multi-links-guest, the VLAN ID field 4446 is set to 2. The non-AP MLD or non-AP STAs can then further filter MAC frames based on the VLAN ID field 4446 (in addition to filtering based on the RA / TA / BSSID fields). The TA field 4444 is set to the L2 MAC address of the transmitting STA, according to conventional methods.

[0105] Yet another way to avoid broadcast storms is to introduce a new frame type (e.g., a new data frame type) that is understood only by EHT devices. All data frames intended for EHT devices (MLD or non-MLD) would use the new data frame type. Alternatively, the 11be specification could require that data frames intended for EHT and future enhancement STAs always be kept in EHT PPDUs (rather than legacy PPDUs: 11a, 11n, 11ac, or 11ax). Legacy devices cannot decode EHT PPDUs, so they discard data frames intended only for EHT and future enhancement STAs. These methods can avoid broadcast storms without disrupting which VLANs and VAPs were originally created.

[0106] 45 shows a flow diagram 4500 illustrating a method of communication according to various embodiments. In step 4502, a frame is generated at an AP included in a plurality of APs belonging to an AP MLD, each of the plurality of APs advertising a BSSID and providing a link identified by a link ID, and the frame carries a multilink element containing information about the AP MLD and the plurality of APs. In step 4504, the frame is transmitted on the link, and the multilink element indicates the link ID of the link on which the frame is transmitted.

[0107] 46 shows a schematic, partially sectioned diagram of a communication device 4600 that can be implemented for EHT virtualization according to the first to sixth embodiments. The communication device 4600 can be implemented as a STA or AP included in multiple STAs or APs that belong to an AP MLD or a non-AP MLD according to various embodiments.

[0108] The various functions and operations of the communications device 4600 are arranged in layers according to a hierarchical model, in which lower layers report to and receive instructions from higher layers, in accordance with IEEE specifications. For simplicity, the details of the hierarchical model will not be discussed in this disclosure.

[0109] As shown in FIG. 46, the communications device 4600 may include circuitry 4614, at least one wireless transmitter 4602, at least one wireless receiver 4604, and multiple antennas 4612 (for simplicity, only one antenna is shown in FIG. 46 for illustrative purposes). The circuitry may include at least one controller 4606 for use in software and hardware-assisted execution of tasks it is designed to perform, including controlling communications with one or more other multi-link devices in a MIMO wireless network. The at least one controller 4606 may control at least one transmit signal generator 4608 for generating frames to be transmitted to one or more other STAs, APs, or MLDs via the at least one wireless transmitter 4602, and at least one receive signal processor 4610 for processing frames received from one or more other STAs, APs, or MLDs via the at least one wireless receiver 4604. The at least one transmit signal generator 4608 and the at least one receive signal processor 4610 may be standalone modules of the communication device 4600 that communicate with the at least one controller 4606 for the functions described above. Alternatively, the at least one transmit signal generator 4608 and the at least one receive signal processor 4610 may be included in the at least one controller 4606. Those skilled in the art will appreciate that the arrangement of these functional modules is flexible and may vary according to actual needs and / or requirements. Data processing, storage, and other related control devices may be provided on an appropriate circuit board and / or within a chipset.

[0110] In various embodiments, in operation, the at least one wireless transmitter 4602, the at least one wireless receiver 4604, and the at least one antenna 4612 may be controlled by at least one controller 4606. Furthermore, while only one wireless transmitter 4602 is shown, it will be understood that there may be more than one such transmitter.

[0111] In various embodiments, in operation, the at least one wireless receiver 4604, together with the at least one receive signal processor 4610, form the receiver of the communications device 4600. In operation, the receiver of the communications device 4600 provides the functionality necessary for multi-link communications. While only one wireless receiver 4604 is shown, it will be understood that more than one such receiver may be present.

[0112] In operation, the communications device 4600 provides functionality necessary for EHT virtualization. For example, the communications device 4600 may be an AP included in multiple APs that belong to an AP MLD, where each of the multiple APs advertises a BSSID and provides a link identified by a link identifier (ID). In operation, the circuit 4614 may generate a frame carrying a multilink element that includes information about the AP MLD and the multiple APs. In operation, the transmitter 4602 may transmit a frame on a link, where the multilink element indicates the link ID of the link on which the frame is transmitted.

[0113] The AP may be a member of a multi-BSSID set or a member of a co-host BSSID set, or may not be a member of either a multi-BSSID set or a co-host BSSID set, and the frame may be one of a beacon frame, a probe response frame, a FILS discovery frame, or an association response frame.

[0114] The AP may be a member of a multi-BSSID set, and the circuit 4314 may be further configured to include a multi-BSSID element in the frame, the multi-BSSID element including a non-transmitting BSSID profile holding other multi-link elements, the other multi-link elements including information about other AP MLDs to which the other APs corresponding to the non-transmitting BSSID profile belong and multiple links belonging to the other AP MLDs, and the other multi-link element further indicating a link ID of the link on which the other AP operates. The other multi-link element may further include a type field, a common information field holding a link ID of the link on which the other AP operates, and one or more link-specific information fields, each representing a link among the multiple links belonging to the other AP MLDs excluding the link on which the other AP operates, and each link-specific information field holding a link ID and link-specific information for the represented link, the link-specific information indicating a BSSID and operating channel associated with the represented link. The link-specific information may further indicate an SSID corresponding to the BSSID of the represented link if the SSID is different from that of the link held in the common information field. If the represented link corresponds to a non-transmitting BSSID, the link-specific information may further indicate a transmitting BSSID, a MaxBSSID indicator, and a BSSID index corresponding to the non-transmitting BSSID.

[0115] Each BSSID may be included in multiple BSSIDs belonging to the AP MLD, and the multiple BSSIDs may be mapped to two or more SSIDs, and the multi-link element may further indicate an SSID corresponding to each link. The SSID or one or more BSSIDs mapped to the SSID may be indicated in a MAC data service primitive MA-UNITDATA.request, and the transmitter 4602 may be further configured to transmit a data frame corresponding to the MAC data service primitive MA-UNITDATA.request if the AP supports one or more BSSIDs mapped to the SSID.

[0116] Each BSSID may be included in multiple BSSIDs belonging to the AP MLD, and the multiple BSSIDs may be mapped to a single SSID, and the multilink element may further indicate the SSID. The AP MLD may bridge wireless frames between multiple APs and a network implementing multiple VLANs, such that each SSID of the multiple SSIDs is mapped to a corresponding VLAN. The multilink element may further include a type field, a common information field holding a link ID of the link on which the multilink element is transmitted, and one or more link-specific information fields, each representing a link of multiple APs other than the link on which the multilink element is transmitted, and each link-specific information field holding a link ID and link-specific information of the represented link, where the link-specific information indicates a BSSID and operating channel associated with the represented link. The link-specific information may further indicate an SSID corresponding to the BSSID of the represented link if the SSID is different from that of the link held in the common information field. If the represented link corresponds to a non-transmitting BSSID, the link-specific information may further indicate a transmitting BSSID, a MaxBSSID indicator, and a BSSID index corresponding to the non-transmitting BSSID.

[0117] The circuit 4614 may be further configured to provide information of one or more other APs by including one or more Neighbor Report elements or Condensed Neighbor Report (RNR) elements in the frame. The Multilink element may further indicate the BSSID and operating channel associated with each link of multiple APs that do not correspond to any of the APs included in the Neighbor Report element or RNR element. The Neighbor Report element or RNR element may further indicate the MLD MAC address of the AP MLD if the reported AP belongs to the AP MLD. If the AP indicated in the RNR element corresponds to a non-transmitting BSSID, the RNR element may further indicate the transmit BSSID, MaxBSSID indicator, and BSSID index corresponding to the non-transmitting BSSID.

[0118] The circuit 4614 may be further configured to provide information of one or more other AP MLDs different from the AP MLD to which the AP belongs by including in the frame a Neighbor MLD Report element that holds information of the other one or more AP MLDs. The multilink element may further include a type field, a common information field, and one or more STA-specific information fields, each STA-specific information field representing an AP among the multiple APs, each STA-specific information field holding a link ID and link-specific information for the represented AP, and each STA-specific information field further holding a transmitting STA field that indicates whether the represented AP associated with the STA-specific information field is the AP that transmits the frame that holds the multilink element.

[0119] For example, the communications device 4600 may be a non-AP STA included in multiple non-AP STAs belonging to a non-AP MLD. The circuit 4614, in operation, generates a probe request frame holding a multi-link element including an MLD MAC address of the AP MLD and one or more link IDs of links belonging to the AP MLD. The transmitter 4602, in operation, transmits the probe request frame to request information about the AP MLD and one or more links of the AP MLD. The circuit 4614 may be further configured to generate a frame holding another multi-link element with a type field set to a value indicating a MAC address update, the other multi-link element holding the MLD MAC address of the non-AP MLD and the MAC addresses of one or more links of the non-AP MLD, and the transmitter 4602 may be further configured to transmit the frame to request the AP MLD to update its records of the non-AP MLD with the MAC addresses of the one or more links.

[0120] The present disclosure can be realized by software, hardware, or software cooperating with hardware. Each functional block used in the description of each embodiment above can be partially or completely realized by an LSI such as an integrated circuit, and each process described in each embodiment can be partially or completely controlled by the same LSI or a combination of LSIs. The LSI can be formed as a separate chip, or a single chip can be formed to include some or all of the functional blocks. The LSI can include data inputs and outputs coupled thereto. The LSI referred to herein may be referred to as an IC, system LSI, super LSI, or ultra LSI depending on the level of integration. However, the technology for implementing an integrated circuit is not limited to LSI, and it can be realized using dedicated circuits, general-purpose processors, or dedicated processors. Also, a field programmable gate array (FPGA), which can be programmed after LSI fabrication, or a reconfigurable processor, which can reconfigure the connections and settings of circuit cells arranged within LSI, can be used. The present disclosure can be realized as digital processing or analog processing. If future integrated circuit technology replaces LSI as a result of advances in semiconductor technology or other derivative technologies, the functional blocks can be integrated using future integrated circuit technology. Biotechnology can also be applied.

[0121] The present disclosure may be implemented by any type of apparatus, device or system having communication capabilities, referred to as a communication device.

[0122] A communication device may include a transceiver and processing / control circuitry. The transceiver may include and / or function as a receiver and a transmitter. The transceiver as a transmitter and receiver may include an RF (radio frequency) module, which includes an amplifier, an RF modulator / demodulator, etc., and one or more antennas.

[0123] Some non-limiting examples of such communication devices include telephones (e.g., cellular phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, digital book readers, telehealth / telemedicine (remote health and medicine) devices, and vehicles (e.g., automobiles, airplanes, ships) that provide communication capabilities, and various combinations thereof.

[0124] Communication devices are not limited to being portable or mobile, but may include any type of non-portable or fixed apparatus, device, or system, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "things" in the network of the "Internet of Things" (IoT).

[0125] Communications may include, for example, data exchange via cellular systems, wireless LAN systems, satellite systems, and the like, as well as various combinations thereof.

[0126] A communications device may include a device, such as a controller or sensor, coupled to the communications device to perform the communications functions described in this disclosure. For example, a communications device may include a controller or sensor that generates control or data signals used by the communications device to perform the communications functions of the communications device.

[0127] Communications devices may also include infrastructure facilities such as base stations, access points, and any other apparatus, device, or system that communicates with or controls apparatus such as those in the non-limiting examples above.

[0128] Non-limiting examples of stations may be those included in a first plurality of stations belonging to a multi-link station logical entity (i.e., MLD, etc.), and as part of the first plurality of stations belonging to the multi-link station logical entity, the stations of the first plurality of stations share a common Medium Access Control (MAC) data service interface to upper layers, and the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).

[0129] Thus, it can be seen that embodiments of the present invention provide a communications device and method specifically for EHT virtualization of MLD devices.

[0130] While exemplary embodiments have been presented in the above detailed description of embodiments of the present invention, it should be understood that numerous variations exist. It should be further understood that the exemplary embodiments are examples and are not intended to limit in any way the scope, applicability, operation, or configuration of the present disclosure. Rather, the foregoing detailed description provides those skilled in the art with a convenient road map for implementing the exemplary embodiments, and it should be understood that various changes may be made in the function and arrangement of the steps and methods of operation described in the exemplary embodiments, and in the modules and structure of the devices described in the exemplary embodiments, without departing from the scope of the subject matter set forth in the appended claims.

Claims

1. A non-access point multi-link device (non-AP MLD) to which multiple STAs belong, a receiver for receiving a frame from an access point multilink device (AP MLD) including at least a first virtual access point (AP) and a second virtual AP, the frame including an SSID field indicating a first common SSID (Service Set Identifier), a multilink element for the AP MLD, and a multi-BSSID element for another AP MLD, the multilink element including a MAC address of the AP MLD, and the multi-BSSID element including a non-transmitting BSSID profile of a first non-transmitting BSSID belonging to a first multi-BSSID (Basic Service Set Identifier) ​​set for a first channel; a control unit that, when determining that the non-AP MLD itself is participating in the first common SSID indicated by the SSID field included in the received frame, determines whether or not to associate the non-AP MLD itself with the AP MLD based on the multilink element included in the frame; A non-AP MLD comprising:

2. The multi-link element includes a common information field including a MAC address of the AP MLD and a link-specific information field including link information of the second virtual AP. The non-AP MLD according to claim 1.

3. the frame is one of a beacon frame and a probe response frame; The first virtual AP corresponds to a first BSSID (Basic Service Set Identifier), which is a first transmitting BSSID belonging to a first multi-BSSID set for a first channel; the second virtual AP corresponds to a second BSSID, the second BSSID being one of a second transmitting BSSID and a second non-transmitting BSSID belonging to a second multi-BSSID set for a second channel; the first common SSID is an SSID common to the first BSSID and the second BSSID, and is advertised on the first channel by the first virtual AP; The non-AP MLD according to claim 1.

4. The other AP MLD is: a third virtual AP corresponding to the first non-transmitting BSSID belonging to the first multi-BSSID set for the first channel; a fourth virtual AP corresponding to another BSSID, which is either the second transmitting BSSID or the second non-transmitting BSSID, belonging to the second multi-BSSID set for the second channel; Equipped with If the other BSSID is the second transmitting BSSID, the fourth virtual AP advertises a second common SSID for the first non-transmitting BSSID and the second transmitting BSSID on the second channel. The non-AP MLD according to claim 3.

5. the non-transmitting BSSID profile includes another multi-BSSID element for the other AP MLD that is different from the multi-BSSID element for the AP MLD; The non-AP MLD according to claim 4.

6. the other multi-BSSID elements included in the non-transmitting BSSID profile include information about the third virtual AP and the fourth virtual AP; The non-AP MLD according to claim 5.

7. a plurality of virtual APs corresponding to the first multi-BSSID set operate on the first channel and constitute a first virtual AP set, and a plurality of virtual APs corresponding to the second multi-BSSID set operate on the second channel and constitute a second virtual AP set; The non-AP MLD according to claim 3.

8. The link-specific information field includes a link ID subfield and a non-transmitted BSSID information field. The non-AP MLD according to claim 2.

9. A communication method in a non-access point multi-link device (non-AP MLD) to which multiple STAs belong, comprising: receiving a frame from an access point multilink device (AP MLD) including at least a first virtual access point (AP) and a second virtual AP, the frame including an SSID field indicating a first common SSID (Service Set Identifier), a multilink element for the AP MLD, and a multi-BSSID element for another AP MLD, the multilink element including a MAC address of the AP MLD, and the multi-BSSID element including a non-transmitting BSSID profile of a first non-transmitting BSSID belonging to a first multi-BSSID (Basic Service Set Identifier) ​​set for a first channel; When it is determined that the non-AP MLD itself is participating in the first common SSID indicated by the SSID field included in the received frame, it determines whether or not to associate the non-AP MLD itself with the AP MLD based on the multilink element included in the frame. A communication method, including:

10. The multi-link element includes a common information field including a MAC address of the AP MLD and a link-specific information field including link information of the second virtual AP. The communication method according to claim 9.

11. the frame is one of a beacon frame and a probe response frame; The first virtual AP corresponds to a first BSSID (Basic Service Set Identifier), which is a first transmitting BSSID belonging to a first multi-BSSID set for a first channel; the second virtual AP corresponds to a second BSSID, the second BSSID being one of a second transmitting BSSID and a second non-transmitting BSSID belonging to a second multi-BSSID set for a second channel; the first common SSID is an SSID common to the first BSSID and the second BSSID, and is advertised on the first channel by the first virtual AP; The communication method according to claim 9.

12. The other AP MLD is: a third virtual AP corresponding to the first non-transmitting BSSID belonging to the first multi-BSSID set for the first channel; a fourth virtual AP corresponding to another BSSID, which is either the second transmitting BSSID or the second non-transmitting BSSID, belonging to the second multi-BSSID set for the second channel; Equipped with If the other BSSID is the second transmitting BSSID, the fourth virtual AP advertises a second common SSID for the first non-transmitting BSSID and the second transmitting BSSID on the second channel. The communication method according to claim 11.

13. the non-transmitting BSSID profile includes another multi-BSSID element for the other AP MLD that is different from the multi-BSSID element for the AP MLD; The communication method according to claim 12.

14. a plurality of virtual APs corresponding to the first multi-BSSID set operate on the first channel and constitute a first virtual AP set, and a plurality of virtual APs corresponding to the second multi-BSSID set operate on the second channel and constitute a second virtual AP set; The communication method according to claim 13.

15. a plurality of virtual APs corresponding to the first multi-BSSID set operate on the first channel and constitute a first virtual AP set, and a plurality of virtual APs corresponding to the second multi-BSSID set operate on the second channel and constitute a second virtual AP set; The communication method according to claim 11.

16. The link-specific information field includes a link ID subfield and a non-transmitted BSSID information field. The communication method according to claim 10.

17. An integrated circuit for a non-access point multi-link device (non-AP MLD) to which multiple STAs belong, comprising: receiving a frame from an access point multilink device (AP MLD) including at least a first virtual access point (AP) and a second virtual AP, the frame including an SSID field indicating a first common SSID (Service Set Identifier), a multilink element for the AP MLD, and a multi-BSSID element for another AP MLD, the multilink element including a MAC address of the AP MLD, and the multi-BSSID element including a non-transmitting BSSID profile of a first non-transmitting BSSID belonging to a first multi-BSSID (Basic Service Set Identifier) ​​set for a first channel; a control step of determining whether or not to associate the non-AP MLD itself with the AP MLD based on the multilink element included in the frame when it is determined that the non-AP MLD itself is participating in the first common SSID indicated by the SSID field included in the received frame; An integrated circuit that controls

Images