Multi-link device operation

Abstract

Embodiments herein describe various configurations of UMAC and LMAC in a multi-link operating architecture. Wherein some embodiments allow for multi-link operation using a variety of different wired and wireless connections. These embodiments also describe configurations that allow for physical separation of UMAC and LMAC components.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 489,688, filed on March 10, 2023, entitled “Multi-Link Device Operation,” the entire contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates to wireless communications and, more particularly, to multi-link device (MLD) operations. Background Art

[0004] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard includes protocols for implementing wireless local area network (WLAN) communications, including Wi-Fi. In the IEEE standard, the medium access control (MAC) layer provides control abstraction of the physical (PHY) layer, making the complexity of physical link control invisible to upper layers of the network stack.

[0005] The subject matter claimed in this disclosure is not limited to implementations that solve any disadvantages or that operate only in those environments described above. Rather, this background is provided merely to illustrate one example technology area where some embodiments described in this disclosure may be practiced. Summary of the Invention

[0006] Various embodiments related to multi-link device operation are described. In some embodiments, various upper MAC (UMAC) and lower MAC (LMAC) components or devices may be separated to achieve various improvements.

[0007] The present invention describes a multi-link device (MLD) architecture comprising: a common memory; an upper layer MAC (UMAC) device; and a plurality of lower layer MAC (LMAC) devices, the plurality of lower layer MAC (LMAC) devices being physically separated from each other and from the UMAC device, wherein the UMAC device and the plurality of LMAC devices are capable of accessing the common memory.

[0008] The present invention discloses another MLD architecture, comprising: an upper layer MAC (UMAC); and multiple lower layer MACs (LMACs) communicating with the UMAC. The multiple LMACs include: a first LMAC configured to manage a Wi-Fi transceiver; and a second LMAC configured to manage a non-Wi-Fi link. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Further features and details of the exemplary embodiments are described and explained by means of the accompanying drawings, in which:

[0010] Figure 1A system architecture showing an MLD model that can be implemented at a point where a single data stream is multiplexed by an upper MAC (UMAC) for processing by individual lower MACs is shown;

[0011] Figure 2 A configuration showing UMAC and LMAC physically separated is shown;

[0012] Figure 3 An example architecture including an access point device and a repeater device is shown;

[0013] Figure 4 Another example architecture including a STA emulator is shown;

[0014] Figure 5 An example machine in the form of a computing device within which a set of instructions can be executed causing it to perform any one or more of the operations discussed herein is shown; and

[0015] Figure 6 A flowchart showing an example method of providing MLD operations is shown. DETAILED DESCRIPTION

[0016] Prior to IEEE 802.11be (Wi-Fi 7), Wi-Fi networks were built on wireless channels with bandwidths between 20 MHz and 160 MHz. Transmissions could use all or part of the channel bandwidth. In implementing multiple basic service sets (BSSs), a single device could establish multiple such networks, but these networks were effectively independent. Functionally, a conventional multi-BSS device was equivalent to multiple independent access points (APs) housed in a single device. As used herein, the term Wi-Fi is generally used as an example type of wireless communication. It should be understood that where the term Wi-Fi is used herein, it can be replaced with “wireless” or any other type of wireless communication, as the present disclosure is applicable to all types of communication and related protocols, not just Wi-Fi.

[0017] In the presently disclosed multi-link operation (MLO), a single device uses multiple links (e.g., wireless channels), but data streams transmitted over multiple links can be aggregated at higher layers. A multi-link device (MLD) has one traffic interface and distributes that traffic over two or more links. Functionally, an MLD acts as a single AP toward higher layers, but includes multiple subordinate APs operating on different channels toward lower layers.

[0018] Some advantages of the present disclosure can provide improvements to MLO and MLDs, including: increased throughput through channel aggregation, resulting in higher total bandwidth; enhanced robustness due to additional redundancy; and additional flexibility and adaptability in allocating and prioritizing traffic.

[0019] Figure 1 An example system architecture 100 for an MLD is shown. Some MAC processing is common for all data packets (e.g., “upper MAC processing” - UMAC) and does not perform specific functions tied to individual links. UMAC tasks typically include combining smaller data packets into larger data packets for efficient transmission and breaking received larger data packets into smaller data packets suitable for individual links. UMAC can also typically assign unique sequence identifiers or numbers (e.g., traffic identifiers “TIDs”) to data packets to ensure proper order during reassembly at the receiving end. Other MAC processing can be specific to the link over which data is transmitted (e.g., “lower MAC processing” - LMAC). Figure 1 Each link from 1 to n is also shown as being associated with its own discrete physical layer (PHY), which typically takes the form of a discrete transmitter / receiver, which can be discrete hardware or virtual hardware (e.g., virtualized transmitter and / or receiver).

[0020] The current IEEE 802.11be standard revision defines MLD operation that assumes all links are wireless (e.g., 802.11be) and that all links originate from the same device (and they all terminate at another single device). This can act as a constraint, and extending this constraint can reduce the limitations imposed by the current version of the 802.11be standard.

[0021] For example, some improvements to the basic MLD reference framework provided herein can include: (i) an MLD with multiple wireless links, but one or more LMACs (and layers below) located in separate devices that can be in different locations; (ii) an MLD device with multiple links, where some of the links are not wireless; and / or (iii) a combination of (i) and (ii), meaning that some or all LMACs can reside in separate devices, and these non-collocated devices can use different PHY technologies. In some examples, an MLD can have a UMAC and multiple links (wireless and / or wired), but each LMAC (and layers below) can be located in separate devices that can be in different locations. Additionally, or alternatively, an MLD can have a UMAC and multiple links, where at least one LMAC is associated with a physical link of the MLD, while another physical link is associated with a second device.

[0022] Figure 1A system architecture 100 is shown that can include a MLD model implemented at the point where a single data stream is multiplexed by an upper MAC (UMAC) for processing by various lower MACs (LMACs). In some MLD implementations where the UMAC and LMAC are co-located, the interface between the UMAC and LMAC can not be explicitly defined (or standardized) because the two blocks are co-located. Moreover, certain implementations can not need to follow the exact flow shown as long as the equivalent output is produced procedurally at the interface defined by the 802.11 standard (e.g., the MAC / PHY interface or the PHY / medium interface). Figure 1 The exact flow shown.

[0023] Non-collocated LMAC (split MAC) architecture

[0024] To provide better coverage or a more seamless roaming experience, the system can include a single device containing a UMAC that is connected to several different devices containing independent LMACs. In some embodiments, this can be built on top of a mesh topology, but the entire mesh network is contained in the context of the MLD.

[0025] In systems where the UMAC and LMAC are not co-located, a communication protocol can be established between the two blocks. This communication protocol can run over any medium that connects the UMAC and one or more LMACs. This medium can be wired (coaxial cable, copper cable, fiber, optical cable, etc.) or wireless (Wi-Fi, Bluetooth, etc.).

[0026] Figure 2 A configuration is shown where the UMAC and LMAC are physically separated (e.g., not co-located). In this example configuration, the UMAC and LMAC are connected by wired links 202a, 202b. The wired links 202a, 202b connect the Ethernet termination 214x of the UMAC device 220 and the Ethernet terminations 214a and 214b of the LMAC devices (e.g., remote AP devices 222a, 222b). However, a wireless link can also be used to connect the UMAC device 220 and the LMAC devices 222a, 222b. Alternatively, the wired connection can take the form of a coaxial cable or fiber optic connection, or any other type of wired connection (e.g., power line communication (PLC)). The UMAC device 220 can be connected to the LMAC devices 222a, 222b through a logical link 224. This logical link 224 can run over the logical link control (LLC) layer to provide coordination between the UMAC and LMAC and allow for concurrent transmission and reception of data in multiple channels spanning a single or multiple frequency bands (e.g., 2.4 GHz, 5 GHz, and 6 GHz).

[0027] When the UMAC and LMAC are separated, there can be several types of communication to and from them to maintain MLD operation:

[0028] 1. Data packet. These data packets can be different from the MAC protocol data units (MPDUs) defined in the 802.11 standard. One reason is that, according to traditional MLD operation, the actual MPDUs can be created by the LMAC, and thus the MPDUs can not be created in the same way as the traditional MLD operation for the non-collocated LMAC. The data format at the UMAC / LMAC interface can be referred to as UMAC / LMAC frames.

[0029] 2. Configuration data for configuring LMAC and PHY states. Since these two blocks are no longer collocated with the UMAC device (e.g., “master device”), these messages can also be carried over the medium (e.g., links 202a, 202b or logical link 224) connecting the UMAC and LMAC.

[0030] 3. Acknowledgement (ACK). Some network standards or network operations require the reception of MPDUs to be acknowledged between the transmitter and the receiver. In Figure 2 In, a wireless link 204 is depicted between the PHY 206 and the STA 208. In some embodiments, the PHY 206 can take the form of a Wi-Fi transceiver. In the case of UMAC and LMAC separation, the “LMAC device” (e.g., 222a, 222b) can be the receiver of the ACK. This ACK can be further propagated in some form from the LMAC 210 to the UMAC 212. In the case of not receiving the ACK, the UMAC 212 can decide to retransmit in the same link or try another link with better channel conditions. While Figure 2 In, only two AP devices 222a, 222b are depicted, but it should be understood that 3, 4, 5 or more remote AP devices can be incorporated in the described architecture. Also, while the LMAC devices 222a, 222b are labeled as remote AP devices, the LMAC devices 222 do not have to be AP devices, but can be any type of device, including a repeater, a drone, a user device, a station, etc.

[0031] 4. Control frame. These are Wi-Fi data packets that do not carry data, and can help with various aspects, e.g., medium reservation, etc. The LMAC 210 can follow the instructions of the UMAC 212 to decide which frames to send and when to send.

[0032] In some embodiments, a single protocol can carry each type of data packet / message over the UMAC / LMAC interface, and an indication within that protocol can identify the nature and destination of the data packet / message. This indication can be carried in a header that can be read by the receiving device. Upon receipt, the receiving UMAC 212 or LMAC 210 can decapsulate the communication and route it to the correct functional block for further processing. In embodiments where a single protocol is transmitted wirelessly, the transmission can be purposefully formatted and / or encrypted to prevent inadvertent interception by other legacy wireless devices over the frequency and / or protocol.

[0033] As noted above, some implementations can not follow the standardized MLD system. Certain implementations that are optimized for performance can choose to organize the transmit and receive streams differently. For example, the actual bit processing of some or all of the data can be deferred until the moment that the MPDU or aggregated MPDU (A-MPDU) is created (the last step in the system architecture 100). Prior to this, the data packets can be identified by reference. At the last moment, these data packets are retrieved from memory and all necessary bit processing (e.g., encryption) is performed. In such a system, the standardized model can not be strictly followed, and there can be no actual data packet exchange between the UMAC and LMAC. Figure 1

[0034] In some embodiments, MLD architectures where the UMAC and LMAC devices are not co-located can also include features that enable co-located operation (whether fully co-located or partially co-located). For example, the UMAC and LMAC devices can include one or more mounting points to allow for the establishment of a conductive path, enabling the MLD architecture to operate in a manner that is closer to the existing 802.11be standard.

[0035] To accommodate such implementations, some example implementations can include:

[0036] 1. An architecture where all LMAC devices have access to a common memory 216, and the UMAC / LMAC interface exchange is not a bit-based data packet, but a data packet reference to one or more memory locations. The individual LMACs can then access the actual data packets in memory 216 and perform the necessary processing to create A-MPDUs. This directly extends the above-described architecture to non-co-located MLOs.

[0037] 2. An architecture that maintains any existing optimizations, but has a hardware engine that is configurable to produce either A-MPDUs or UMAC / LMAC frame streams, or a combination of both A-MPDUs and UMAC / LMAC frames. Given the similarity of the two types of operations, it should be possible to reuse, allowing for an efficient implementation of this multi-mode hardware block.​

[0038] Heterogeneous architecture

[0039] In many deployments, the wireless medium can not be the only medium through which data can be shared. By considering multiplexing traffic over all available mediums, not just multiple Wi-Fi channels, some or all of the advantages of MLO (aggregation, robustness, adaptability, etc.) can be extended. The links can also be non-WiFi wireless links (e.g., cellular, 5G, millimeter wave, Bluetooth, etc.).

[0040] Some embodiments can include multi-link devices where one or more links are non-wireless or non-WiFi. This can be implemented in a manner that is transparent to the UMAC. The UMAC can communicate through the UMAC / LMAC interface without having to be aware of the heterogeneous nature of some links. This can require non-wireless or non-WiFi links to emulate the behavior of wireless LMACs to the UMAC (in both transmit (Tx) and receive (Rx) directions). Several architectures can be considered, including using virtualization, including: (a) a UMAC / LMAC adapter (as further described in connection with Figure 3 Figure 4 Further described in connection with (b) a STA emulator (as further described in connection with). The UMAC / LMAC adapter can be a separate device configured to act as a bridge or interface between the UMAC and LMAC. The STA emulator can be, for example, a virtualized STA.

[0041] Figure 3 An example architecture 300 is shown, including an access point device 302 and a repeater device 304. The access point device 302 and the repeater device 304 are each depicted as having two links through which data can be received and / or transmitted (designated as LI and L2). But it should be understood that three or more links are also possible and are considered within the scope of the present disclosure.

[0042] ​The access point device 302 includes an upper layer MAC (UMAC) 306, a first lower layer MAC (LMAC) 308-1, and a second LMAC 308-2, which are incorporated into an 802.11 MLD encapsulator 310. The LMAC 308-1, together with a PHY 309, which can take the form of a Wi-Fi transceiver, which communicates with another Wi-Fi transceiver in the device 304 over a Wi-Fi network 315, forms part of an L1 link. The access point device 302 also includes an L2 link, which includes the 802.11 MLD encapsulator 310, which has an 802.11 translator / encapsulator 312 configured to receive information that does not follow the protocols normally used with LMACs and convert that information into a format that can be operated on by the AP LMAC 308. The 802.11 MLD encapsulator 310 includes an interface block labeled translator / encapsulator 312, which converts data packets from the UMAC / LMAC interface into a format that can be handled by a non-MLD interface 314 (i.e., a non-WiFi link). The translator / encapsulator 312 can, for example, act as a UMAC / LMAC adapter. The non-WiFi interface can be at the PHY level, the MAC level, or higher. The non-WiFi medium 316 connects a non-WiFi device. At the receiving end of the repeater device 304, the output of the non-WiFi interface is again converted into a format that can be handled by the UMAC. The non-MLD or non-WiFi interface can include any type of device or interface, including cellular, Ethernet, fiber optic, and coaxial communication interfaces.

[0043] Figure 4 Another example architecture 400 is shown, which includes a STA emulator 410. As with the previous embodiment, the L1 link of the AP MLD 402 can be a conventional MLD link that transmits data over Wi-Fi. In this embodiment, the STA associated with the STA MLD 404 is co-located with the AP MLD 402 and acts as a repeater toward the heterogeneous device (AP MLD 402). The STA co-located with the AP MLD 402 includes a STA UMAC 403 and a STA LMAC 405. Specifically, the STA co-located with the AP MLD 402 is part of a STA MLD emulator 410. The STA MLD emulator 410 can be linked and communicatively connected with the upper layer MAC 411 of the STA MLD 404 by way of a wired or wireless connection 413. This configuration combines the flexibility of a non-co-located UMAC and LMAC architecture with a heterogeneous MLD.

[0044] The STA MLD is configured to operate a non-MLD interface (non-WiFi link) 406 that is managed by an upper layer network stack 408 that is not directly part of the STA MLD 404. While the AP MLD 402 maintains a native attached AP (see AP lower MAC 412), it internally creates a STA MLD emulator for managing the non-WiFi interface from the AP MLD. The STA MLD emulator 410 implements the full logic so that the AP MLD sees another attached AP associated with a virtual remote STA MLD. From the perspective of the AP MLD 402, it sees two MLD links, one of which is physically based on a non-WiFi link, but to the AP MLD 402, the non-WiFi link appears as a WiFi link and can be managed as a WiFi link. In this case, traffic aggregation is done at a higher layer.

[0045] Figure 5 An example machine is shown in the form of a computing device 500, within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. The computing device 500 can include a rack-mounted server, a router computer, a server computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, or any computing device having at least one processor, etc., including a set of instructions that cause the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine can be connected (e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The machine can operate in the capacity of a server machine in a client-server network environment. In addition, while only a single machine is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0046] The example computing device 500 includes a processing device (e.g., a processor) 502, a main memory 504 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory (e.g., flash memory, static random access memory (SRAM)), and a data storage device 516, which communicate with each other via a bus 508.

[0047] The processing device 502 represents one or more processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device 502 can include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 502 can also include one or more special-purpose processing devices, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 502 is configured to execute the instructions 526 to perform the operations and steps discussed herein.

[0048] The computing device 500 can further include a network interface device 522 that can communicate with a network 518. The computing device 500 also can include a display device 510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 512 (e.g., a keyboard), a cursor control device 514 (e.g., a mouse), and a signal generation device 520 (e.g., a speaker). In at least one embodiment, the display device 510, the alphanumeric input device 512, and the cursor control device 514 can be combined into a single component or device (e.g., an LCD touch screen).

[0049] The data storage device 516 can include a computer-readable storage medium 524 on which is stored one or more sets of instructions 526 embodying any one or more of the methodologies or functions described herein. The instructions 526 can also reside, completely or at least partially, within the main memory 504 and / or within the processing device 502 during execution thereof by the computing device 500, the main memory 504 and the processing device 502 also constituting computer-readable media. The instructions can further be transmitted or received over the network 518 via the network interface device 522.

[0050] While the computer-readable storage medium 526 is shown in an example embodiment to be a single medium, the term "computer-readable storage medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also include any medium that is capable of storing or encoding a set of instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

[0051] Figure 6A flow diagram of an example method 600 of MLD operation in accordance with at least one embodiment of the present disclosure is shown. The method 600 can be performed by processing logic that can comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a computer system or a dedicated machine), or a combination of both, which can be included in Figures 1-5 any computer system or device of

[0052] For simplicity of explanation, the methods herein are depicted and described as a series of acts. However, acts in accordance with this disclosure can occur in various orders and / or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts can be required to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate the context of the methods disclosed in this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methods to computing devices. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media. Each of the various blocks can be added, omitted, combined, and / or modified, as desired.

[0053] At block 602, the processing logic provides a multi-link device (MLD) architecture including an upper media access control (UMAC) layer.

[0054] At block 604, the processing logic causes the UMAC to send a message to a lower media access control (LMAC) that is not co-located with the UMAC on the same device.

[0055] Another example method can include providing a plurality of LMAC devices that are physically separate from each other and from a UMAC device, wherein the UMAC device and the plurality of LMAC devices have access to a common memory.

[0056] Another example method can include providing a MLD architecture including a UMAC layer. The method can include sending a message from the UMAC to a first LMAC and a second LMAC. The first LMAC can be co-located with the UMAC, and the second LMAC can be located on a different device from the UMAC.

[0057] Another example method can include providing an MLD architecture including a UMAC layer. The method can include sending a message from the UMAC to an MLD encapsulator. The MLD encapsulator can include an AP LMAC and a translator / encapsulator. The MLD encapsulator can be communicatively connected with a non-MLD device through a non-MLD interface. The non-MLD device can have a same or similar MLD encapsulator to receive, decode, translate, etc. the message before it reaches the non-MLD device UMAC. In this way, the non-MLD device can act as an MLD device.

[0058] Another example method can include providing an MLD architecture including a UMAC layer. The method can include sending a message from the UMAC to an STA MLD emulator. The STA MLD emulator can include one or more of an AP LMAC, a STA LMAC, a STA UMAC, and a translator bridge. The STA MLD emulator can or can not be co-located with the UMAC. The STA UMAC can also be linked and communicatively connected to a physical STA device (e.g., through a STA UMAC that resides on the physical STA device). The STA UMAC that resides on the physical STA device can share memory space with the STA UMAC associated with the STA MLD emulator.

[0059] Another example method can include providing an MLD architecture for a non-MLD device including a UMAC layer. The method can include receiving a message at an LMAC, the LMAC including a translator / encapsulator to translate the message in a manner that can be processed by the UMAC layer. The translated message is passed to the UMAC layer for further processing.

[0060] Another example method can include providing an MLD architecture including a UMAC layer. The method can include receiving a message from the UMAC through an LMAC that is not co-located with the UMAC.

[0061] Modifications, additions, or omissions can be made to the methods described without departing from the scope of the disclosure. In another example, the designation of differing elements to the described manner is intended to help describe concepts rather than to limit. Additionally, these methods can include any number of other elements, or can be implemented in other systems or contexts, apart from those described.

[0062] Several implementations have been described. However, it will be apparent that many modifications can be made without departing from the scope and spirit of the disclosure. Therefore, other implementations are within the scope of the following claims.

[0063] In accordance with common practice, the various features illustrated in the drawings can not be drawn to scale. The illustrations presented in the present disclosure are intended to be idealized representations (e.g., of devices, systems, etc.) or methods of the present disclosure and are merely intended for use in describing various embodiments of the present disclosure. As such, the dimensions of the various features can be arbitrarily expanded or reduced for the sake of clarity. In addition, some of the drawings can be simplified for the sake of clarity. Thus, the drawings can not depict all of the components of a given device (e.g., apparatus) or every operation of a particular method.

[0064] The terms used herein, particularly in the appended claims (e.g., in the body of the appended claims), are generally intended as “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.).

[0065] Furthermore, if a specific number of claim technical features is intended to be introduced, such an intent will be explicitly recited in the claims, and if not explicitly recited, no such intent exists. For example, to aid in understanding, the appended claims can contain introductory phrases such as “at least one” and “one or more” to introduce claim technical features. However, even if the same claim includes an introductory phrase of “one or more” or “at least one” and an indefinite article such as “a” or “an” (e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more”), the use of such phrases should not be interpreted as implying that the claim technical feature introduced by the indefinite article “a” or “an” limits any particular claim to only contain an embodiment of such technical feature that contains only one of such technical features. The same applies to the use of a definite article to introduce a claim technical feature.

[0066] Furthermore, even if a specific number of introduced claim technical features is explicitly recited, those skilled in the art will recognize that such technical features should be interpreted to mean at least that number of such technical features (e.g., a simple recitation of “two technical features” without further modification means at least two of such technical features, or two or more of such technical features). Moreover, where structures similar to “at least one of A, B, and C” or “one or more of A, B, and C” are used, generally, such structures are intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc.

[0067] Furthermore, any disjunctive word or term, for example, containing "in the alternative," "one or the other of," or "one, the other, or both," should be understood to express the possibilities of the items individually or in some combination of them. For example, a phrase "A or B" should be understood as indicating at least one of "A" or "B" or some combination of the two.

[0068] Furthermore, the use of the terms "first," "second," "third," etc. do not necessarily imply a particular order or sequence. Generally, the terms "first," "second," "third," etc. are used to distinguish different elements, but the use of these terms is not meant to imply a particular order or sequence, unless otherwise indicated by the context. Moreover, the use of the terms "first," "second," "third," etc. does not imply a specific number of elements, unless otherwise indicated by the context. For example, a first component can be described as having a first side, and a second component can be described as having a second side. The use of the term "second side" in relation to the second component can be used to distinguish this side of the second component from the "first side" of the first component, and not to imply that the second component has two sides.

[0069] All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the present disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although embodiments of the present disclosure have been described in detail, various modifications, alterations, and adaptations thereof will become apparent to the reader.

Claims

1. A multi-link device (MLD) architecture, comprising: public storage; Upper layer media access control UMAC device; as well as a plurality of lower layer media access control (LMAC) devices, the plurality of LMAC devices being physically separated from each other and from the UMAC device; The UMAC device and the multiple LMAC devices can access the public memory.

2. The MLD architecture according to claim 1, wherein: The UMAC device and the LMAC device are connected wirelessly or via a wired / optical medium.

3. The MLD architecture according to claim 1, wherein: Communications between the UMAC device and the plurality of LMAC devices include UMAC / LMAC frames containing packet references rather than bit-based packets.

4. The MLD architecture according to claim 3, wherein: The MLD architecture is multi-mode and is configured to output only bit-based data packets when the UMAC device and the plurality of LMAC devices are co-located.

5. The MLD architecture according to claim 4, wherein: The UMAC device and the plurality of LMAC devices each include a connector for connecting the UMAC device and the LMAC device together.

6. The MLD architecture according to claim 1, wherein: The UMAC is a first UMAC and the plurality of LMACs are a first plurality of LMACs, wherein the first UMAC and the first plurality of LMACs are associated with an access point MLD, and wherein the MLD architecture further comprises a STA MLD device comprising a second UMAC and a second plurality of LMACs in communication with the second UMAC.

7. The MLD architecture according to claim 6, wherein: A first LMAC in the second plurality of LMACs manages a non-WiFi link in communication with the access point MLD.

8. The MLD architecture according to claim 7, wherein: A second LMAC in the second plurality of LMACs manages a WiFi link in communication with the access point MLD.

9. A multi-link device (MLD) architecture, comprising: Upper layer media access control UMAC; as well as a plurality of lower layer media access control LMACs communicating with the UMAC, the plurality of LMACs comprising: a first LMAC configured to manage a Wi-Fi transceiver; as well as A second LMAC is configured to manage a non-Wi-Fi link.

10. The MLD architecture according to claim 9, wherein: The non-Wi-Fi link is a cellular link.

11. The MLD architecture according to claim 10, wherein: The UMAC is not co-located with the plurality of LMACs.

12. The MLD architecture according to claim 11, wherein: The UMAC communicates with the LMAC via a wired connection using packet references rather than bit-based packets.

13. The MLD architecture according to claim 9, wherein: The second LMAC is contained in a simulator, and the simulator includes a STA MLD simulator.

14. The MLD architecture according to claim 9, wherein: Traffic on the link is directed to the STA MLD emulator, which acts as a virtual STA device configured to provide bridging for the non-WiFi link.

15. The MLD architecture according to claim 9, wherein: The non-WiFi link is an Ethernet link.

16. The MLD architecture according to claim 9, wherein: The plurality of LMACs include at least three LMACs.

17. A method comprising: A multi-link device (MLD) architecture is provided, wherein the MLD architecture includes an upper media access control (UMAC) layer; The UMAC is caused to send a message to a lower layer medium access control LMAC that is not co-located with the UMAC on the same device.

18. The method according to claim 17, wherein The LMAC is associated with a non-MLD device.

19. The method according to claim 17, wherein The message is provided from the UMAC to the LMAC via an encapsulator.

20. The method according to claim 17, wherein The message is provided from the UMAC to the LMAC via a station STA emulator.

Images