Multi-link aggregation architecture and operation

Abstract

A reference architecture for supporting multi-link aggregation (MLA) operations is described. An MLA multiplexer logic layer is provided that provides synchronization functionality to synchronize data transmission over two or more slave air interfaces belonging to an aggregated link.

Description

[0001] Cross-reference to related applications

[0002] The present invention claims priority to U.S. Provisional Patent Application No. 62 / 988,315, filed on March 11, 2020, entitled “MULTI-LINK AGGREGATION ARCHITECTURE AND OPERATIONS,” and U.S. Non-Provisional Patent Application No. 17 / 194,613, filed on March 8, 2021, entitled “MULTI-LINK AGGREGATION ARCHITECTURE AND OPERATIONS,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present invention relates to WiFi communication, and in particular to a method and system for supporting aggregation of multiple air interfaces. Background Art

[0004] IEEE 802.11be is an upcoming WiFi communication standard that defines a technical feature that enables aggregation of multiple air interfaces (also known as multi-link aggregation (MLA)) to support higher throughput, load balancing, and higher reliability. MLA is also interchangeably referred to as multi-link operation (MLO). The present invention mentions MLA, but it should be understood that references to MLA can also be understood to refer to MLO. In order for MLA to be of practical use in WiFi communications, the implementation of MLA should take into account the properties of the air interface (also known as the air or wireless link or interface), for example, the state of the air interface may change or degrade rapidly in quality (for example, due to environmental changes and / or site mobility). The reliability of transmission and the security of transmission are also issues.

[0005] Therefore, a reference architecture needs to be provided to support such MLA operation for the air interface. Summary of the Invention

[0006] In various examples, the present disclosure describes a reference architecture for supporting MLA operations and functions, as well as methods and systems for supporting MLA over the air.

[0007] The examples described herein can make the implementation of MLA more automated and deterministic, ensuring that the expected air interface is ready and in an associated state. The examples described herein can enable relatively rapid reconfiguration of MLA (e.g., using dynamic or near real-time reconfiguration) when the state of the air interface changes. The disclosed examples can provide relatively efficient switching capabilities between converged and non-converged operations. The disclosed examples can implement MLA with relatively high reliability and relatively low risk of transmission duplication and / or missequencing. In addition, using the examples described herein, the security of data frame transmission in MLA can be ensured.

[0008] In some examples, the disclosed reference architecture includes an MLA multiplexer logic layer, which is an abstracted MAC layer that sits on top of multiple air interfaces. The MLA multiplexer can be used to perform MSDU multiplexing and demultiplexing functions. In addition, synchronization functionality can be provided to achieve plesiochronous performance across multiple air interfaces, which can further improve performance.

[0009] Implementing the MLA multiplexer as a logical layer on top of the existing physical layer allows the air interfaces belonging to the aggregated link to still operate independently, including maintaining independent security associations. This provides more stable security for data transmission.

[0010] In some examples, the present invention describes methods for implementing operational states in an MLA multiplexer. State-based operation of the MLA multiplexer enables more efficient switching between converged and non-converged operations. State-based operation enables the MLA multiplexer to easily switch to quasi-periodic maintenance and reconfiguration functionality as needed.

[0011] In some examples, protocols and signaling for enabling various MLA functions on MLA-capable APs and / or STAs are also described. Example frame formats are also described to help ensure that received transmissions are properly demultiplexed.

[0012] In some examples, the present disclosure describes an apparatus for wireless communication. The apparatus includes a network interface supporting multiple air interfaces for wireless communication with at least one network entity, and a processor coupled to the network interface. The processor is configured to execute instructions to implement a multi-link aggregation (MLA) multiplexer (muxer) as a logical layer, the MLA multiplexer providing at least a synchronization function to synchronize data transmissions to the at least one network entity, the transmissions being performed over two or more slave air interfaces belonging to an aggregated link.

[0013] In some examples, the present disclosure describes a method for wireless communication, including implementing a multi-link aggregation (MLA) multiplexer (muxer) as a logical layer, the MLA multiplexer providing at least a synchronization function to synchronize data transmissions to at least one network entity, the transmissions occurring over two or more slave air interfaces belonging to an aggregated link.

[0014] In any of the above examples, the implementation of the MLA multiplexer may include: a data distributor responsible for allocating data to each slave air interface for transmission; a data collector responsible for receiving data from each slave air interface and reassembling the received data; and an MLA manager responsible for providing at least the synchronization function.

[0015] In any of the above examples, each slave air interface may maintain a corresponding independent security association for data transmission.

[0016] In any of the above examples, the MLA multiplexer operates in one of the following states: an unavailable state, in which the multiple air interfaces do not participate in any aggregated link; an initialization state, in which the MLA multiplexer communicates with the at least one network entity to establish the aggregated link using the two or more slave air interfaces; an operating state, in which transmission to the at least one network entity is performed on the aggregated link; or a maintenance state, in which the MLA multiplexer obtains information about the operating status of each slave air interface to ensure that the link established on each slave air interface is able to operate.

[0017] In any of the above examples, the MLA multiplexer transitions from the run state to the maintenance state upon expiration of a timer.

[0018] In any of the above examples, when there is traffic on the aggregated link, the timer may be paused or reset.

[0019] In any of the above examples, the synchronization function may include: obtaining information about a duration of a corresponding contention window from each slave air interface; and configuring each slave air interface to use a new contention window, the new contention window being a maximum value of the corresponding contention window.

[0020] In any of the above examples, the synchronization function may include: for at least one slave air interface, filling transmission on the at least one slave air interface so that data transmission on each slave air interface ends synchronously.

[0021] In any of the above examples, the data transmitted on the aggregated link may be a MAC protocol data unit (MPDU) having a frame format, wherein the frame format may include an address field indicating a logical MAC address associated with the MLA multiplexer to indicate a source of the MPDU.

[0022] In any of the above examples, the frame format may further include a frame control field including a bit value indicating a message type of the MPDU.

[0023] In some examples, the present disclosure describes a non-transitory computer-readable medium encoded with instructions that, when executed by a processor of a device, cause the device to implement any of the above examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Reference will now be made by way of example to the accompanying drawings which show exemplary embodiments of the present application, in which:

[0025] Figure 1A is a schematic diagram of an exemplary system for EDMG communication between a STA and a network;

[0026] Figure 1B is a block diagram of an exemplary device suitable for EDMG communications;

[0027] Figure 2 is a block diagram of an example of a disclosed reference architecture for supporting MLA;

[0028] Figure 3 is used Figure 2 A block diagram of an example of MLA operation of a reference architecture;

[0029] Figure 4 is a state diagram of exemplary states for supporting MLA operations;

[0030] Figure 5 is a state transition table showing the Figure 4 Some exemplary signals for transitions between the states shown;

[0031] Figure 6 is a flow chart of an exemplary method for transitioning from MLA initialization to MLA operation;

[0032] Figure 7 is a flow chart of an exemplary method for transitioning from MLA operations to MLA maintenance;

[0033] Figure 8 is a block diagram of an example of contention window synchronization;

[0034] Figure 9is a timing diagram of an example of MLA synchronization;

[0035] Figure 10 An exemplary MLA MPDU frame format is shown; and

[0036] Figure 11A and Figure 11B Details of an exemplary frame control field for indicating MLA MPDU data transmission are shown.

[0037] The same reference numbers may be used in different drawings to identify the same components. DETAILED DESCRIPTION

[0038] This disclosure describes a reference architecture that supports multi-link aggregation (MLA) for air interfaces. MLA enables multiple air interfaces to serve services together by treating them as a single aggregated link. MLA is also interchangeably referred to as multi-link operation (MLO). This disclosure mentions MLA, but it should be understood that references to MLA can also be understood to refer to MLO. Multiple air interfaces aggregated together in this manner can be referred to as an aggregated link or multilink as a logical shorthand. The interfaces aggregated together in an aggregated link can be referred to as slave interfaces (or slave links). An air interface can also be referred to as an air interface, a wireless interface, a WiFi interface, an air link, a wireless link, or a WiFi link, among other common terms. In various examples, this disclosure also describes protocols and functionality for supporting MLA for air interfaces. Transmissions over an aggregated link can be referred to as MLA transmissions and can involve separate transmissions over each separate slave air interface. The examples disclosed herein can be built on top of and / or compatible with existing IEEE 802.11 layers.

[0039] To help understand the present invention, an exemplary system for supporting wireless communication over an air interface is first described.

[0040] Figure 1A is a schematic diagram of an exemplary system 100 in which the methods described herein may be implemented. Figure 1AThe illustrated system 100 can support a wireless local area network (WLAN) that includes an access point (AP) 102 and multiple stations (STAs) 104 within the coverage area of ​​the AP 102. In the illustrated example, there is only one STA 104 and one AP 102, but there can be multiple STAs 104 and / or multiple APs 102. Each STA 104 can be any suitable device capable of wireless communication, including mobile or fixed devices such as smartphones, laptops, mobile phones, or tablet devices, and the STAs 104 need not be identical to each other. For example, the STAs 104 can also be referred to as terminals, user devices, user equipment (UEs), or clients. The AP 102 can also be referred to as a personal basic service set (PBSS) coordination point (PCP) or a base station. For example, the AP 102 can be implemented as a router. The STAs 104 can access the network 106 through the AP 102.

[0041] The system 100 may support communication between the AP 102 and each STA 104, as well as direct communication (also referred to as device-to-device communication) between the STAs 104. Using multiple antennas, the AP 102 may perform multi-user transmissions (e.g., simultaneous transmissions from the AP 102 to multiple STAs 104) using spatial multiplexing techniques called multi-user multiple-input multiple-output (MU-MIMO). For simplicity, the examples described herein may refer to wireless communication over the air interface between a STA 104 and the AP 102, but it should be understood that the present invention is equally applicable to wireless communication over the air interface between two STAs 104, multi-user communication (e.g., between the AP 102 and multiple STAs 104), or any other wireless communication over the air interface.

[0042] Figure 1B is a block diagram of an exemplary processing unit 150 that may be used to implement the methods and systems disclosed herein, such as AP 102 and / or one or more STAs in STA 104. Other processing units suitable for implementing the present invention may be used, and these processing units may include components different from those described below. Although Figure 1B A single instance of each component is shown, but multiple instances of each component may exist in processing unit 150 .

[0043] The processing unit 150 includes one or more processing devices 152, such as a processor, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a dedicated logic circuit, or a combination thereof. The processing unit 150 may also include one or more input / output (I / O) interfaces 154 that can support connection to one or more suitable input devices 164 and / or output devices 166. The processing unit 150 includes one or more network interfaces 156 for wired or wireless communication with a network 106 (e.g., an intranet, the Internet, a P2P network, a WAN, a LAN, and / or a radio access network (RAN)). The one or more network interfaces 156 may include wired links (e.g., Ethernet cables) and / or wireless links for intra-network and / or inter-network communication. For example, the one or more network interfaces 156 may provide wireless communication via one or more transmitters / receivers or transceiver antennas 168. The antennas 168 may collectively function as an antenna array, in which case each antenna 168 may be referred to as an antenna element or radiating element of the antenna array. There may be multiple such antenna arrays. The processing unit 150 may also include one or more storage units 158, which may include a mass storage unit such as a solid-state drive, a hard disk drive, a magnetic disk drive, and / or an optical disk drive.

[0044] The processing unit 150 may include one or more memories 160, which may include volatile or non-volatile memory (e.g., flash memory, random access memory (RAM), and / or read-only memory (ROM)). The one or more non-volatile memories 160 may store instructions (e.g., in the form of software modules) that are executed by the one or more processing devices 152, for example, to perform the methods described herein. For example, instructions for implementing a logic layer for supporting MLA (as further described below) may be stored in the one or more memories 160.

[0045] The one or more memories 160 may include other software instructions, such as software instructions for implementing an operating system and other applications / functions. In some examples, one or more data sets and / or one or more modules may be provided by an external memory (e.g., an external drive in wired or wireless communication with the processing unit 150) or by a transient or non-transient computer-readable medium. Examples of non-transient computer-readable media include RAM, ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, CD-ROM, or other portable memory.

[0046] A bus 162 may be present to provide communications between components of the processing unit 150, including one or more processing devices 152, one or more I / O interfaces 154, one or more network interfaces 156, one or more storage units 158, and / or one or more memories 160. The bus 162 may be any suitable bus architecture, including, for example, a memory bus, a peripheral bus, or a video bus.

[0047] exist Figure 1B , one or more input devices 164 (e.g., a keyboard, mouse, microphone, touch screen, and / or keypad) and one or more output devices 166 (e.g., a display, speakers, and / or printer) are shown as being external to processing unit 150. In other examples, one or more of input device(s) 164 and / or output device(s) 166 may be included as components of processing unit 150. In other examples, no input devices 164 and output devices 166 may be present, in which case I / O interface(s) 154 may not be required.

[0048] The AP 102 and the STA 104 may each include a plurality of antenna elements 168 forming an antenna array and may perform appropriate beamforming and beam steering control (e.g., using beam steering circuitry and / or a beam steering control module implemented by the processing device 152 and the processing unit 150) to facilitate wireless communication over the air interface.

[0049] Figure 2 An example of a disclosed reference architecture for supporting MLA operations is shown. In this example, a reference architecture for MLA is shown for two air interfaces between two entities, but it should be understood that this is exemplary and not intended to be limiting. For example, more than two air interfaces may be established between the two entities, and / or more than two entities may communicate with each other over one or more corresponding air interfaces.

[0050] In this example, two network entities 204a and 204b communicate with each other over air interface 1 202a and air interface 2 202b (generally referred to as one or more air interfaces 202). Air interfaces 202a and 202b are grouped together using MLA, but operate independently of each other. Each entity 204a and 204b can be any network entity that wirelessly communicates with each other. For example, one entity 204a can be AP 102, and the other entity 204b can be STA 104. It should be understood that air interface 202 can be established between any other network entities and is not necessarily limited to communication between AP 102 and STA 104.

[0051] Both entities 204a and 204b include a physical (PHY) layer 210. Each air interface 202a and 202b is managed on a corresponding instance of the PHY layer 210 at each entity 204a and 204b (for simplicity, only one instance of the PHY layer 210 at each entity 204a and 204b is shown in detail; the shaded areas should be understood to have similar detailed information). The PHY layer 210 can be based on existing standards. In this example, each instance of the PHY layer 210 includes a PHY sublayer; a PHY layer management entity (PLME) connected to the PHY sublayer; and a station management entity (SME) connected to the PHY layer management entity via a PLME_SAP. Robust security network association (RSNA) key management is provided by the SME. It should be noted that each air interface 202 is independently established on a corresponding instance of the PHY layer 210, with independent security and association management.

[0052] On top of the PHY layer is the disclosed MLA multiplexing (or multiplexer) entity 220 (also referred to simply as MLA multiplexer 220 in some examples). Although referred to as an "entity" in some examples, the MLA multiplexer 220 is not a separate hardware entity in the network, but rather a logical entity (or logical layer) instantiated within a physical network entity (e.g., within the AP 102 or STA 104). The MLA multiplexer 220 represents the entire MAC service access point (SAP) layer for performing the operation and management functions of the MLA, which will be described in further detail below. The MLA multiplexer 220 includes a MAC service data unit (MSDU) distributor 222 (or more generally a data distributor), an MSDU collector 224 (or more generally a data collector), and an MLA MAC layer management entity (MLME) - SAP 226 (or more generally an MLA manager). The MSDU distributor 222 is responsible for distributing MSDUs over the transmit MLA air interface 202. The MSDU collector 224 is responsible for receiving and assembling MSDUs over the receive MLA air interface 202. The MLA MLME-SAP 226 performs functions for managing the lifecycle and state machine of the MLA multiplexer 220. The MLA MLME-SAP 226 provides synchronization functions that manage the transmission and reception of MLA data transmissions. The MLA MLME-SAP 226 also provides flow control and load balancing functions. Further details on the MLA multiplexer 220 and its functions are provided below.

[0053] The disclosed exemplary reference architecture can provide greater flexibility because each air interface 202 can be independently established on the existing PHY layer using existing authentication and association procedures (e.g., as defined in existing IEEE 802.11 standards). No changes to the physical interface stack are required. Furthermore, if MLA reconfiguration is required, there is no need to renegotiate link security, which can help reduce latency.

[0054] The disclosed exemplary reference architecture may also provide increased reliability. For example, in the event that the air interface "flips" between states (e.g., due to unstable or rapidly changing conditions), the MLA multiplexer 220 may detect the problem and redistribute traffic with minimal disruption to the traffic.

[0055] The disclosed exemplary reference architecture enables MLA implementation with reduced complexity. As described above, MLA multiplexer 220 does not impact the physical layer or security of air interface 202. Instead, MLA multiplexer 220 processes and manages the distribution and collection of MSDUs and provides some synchronization functionality. Consequently, there is no need to design new algorithms for managing the security and physical layers of interface 202.

[0056] Figure 3 is a block diagram of an example of MLA operation using the reference architecture described above. In this example, a first entity 204a (acting as a sender) is sending an MSDU to a second entity 204b (acting as a receiver). Figure 3 Three air interfaces 202 are shown, which are grouped together by MLA. Each air interface 202 is established by a corresponding independent instance of the PHY layer and the MAC layer and a corresponding independent security association (SA). In this example, a first air interface 202 is established between MAC1a and PHY1a at the first entity 204a and MAC1b and PHY1b at the second entity 204b, and the first air interface 202 has a first SA1. Similarly, a second air interface 202 is established between MAC2a and PHY2a at the first entity 204a and MAC2b and PHY2b at the second entity 204b, and the second air interface 202 has a second SA2; a third air interface 202 is established between MAC3a and PHY3a at the first entity 204a and MAC3b and PHY3b at the second entity 204b, and the third air interface 202 has a third SA3. Each MAC instance is associated with a corresponding MAC address (in Figure 3 The MAC address is associated with the MAC address (shown as MAC_Addr1a, MAC_Addr2a, etc.) in the frame header to correctly route data transmission.

[0057] Each entity 204a, 204b has a respective instance of an MLA multiplexer 220a, 220b that distributes / collects transmitted / received MSDUs, respectively. Each MLA multiplexer 220a, 220b is associated with a respective MAC address (MAC_Addr_Muxer_A and MAC_Addr_Muxer_B, respectively; typically MAC_Addr_Muxer).

[0058] Each air interface 202 maintains independent MAC protocol data unit (MPDU) transmission and a separate, independent security association. This independence helps reduce the impact on chip design and reduces or avoids the added complexity of hardware and software implementation.

[0059] Figure 4 is a state diagram of exemplary states in which the MLA multiplexer 220 may operate. These states may be implemented as a state machine in the MLA multiplexer 220. Four operational states of the disclosed MLA multiplexer 220 are depicted: a multilink unavailable state 402 (also referred to as state 1 or unavailable state); a multilink peer initialization and peer state 404 (also referred to as state 2 or initialization state); a multilink running state 406 (also referred to as state 3 or running state); and a multilink maintenance and reconfiguration state 408 (also referred to as state 4 or maintenance state).

[0060] In the unavailable state 402, the MLA is not in use and the air interface operates as an independent, separate link.

[0061] In the initialization state 404, network entities exchange information to obtain information about individual air interface conditions in order to establish an MLA.

[0062] In the operational state 406 , the MLA has been successfully established, and the aggregated link is used for data transmission and reception between network entities.

[0063] In the maintenance state 408, checks are performed (e.g., by AP 102) to ensure that the established links are still operational (e.g., not congested, not degraded, etc.) If necessary, reconfiguration can be performed to maintain operation of the aggregated links (e.g., dropping poorly performing links from the aggregation and rerouting traffic accordingly).

[0064] It should be noted that the MLA multiplexer 220 can be implemented using only the unavailable state 402, the initialization state 404, and the operational state 406 (i.e., the maintenance state 408 is not required). For example, it can be assumed that once the MLA has been established to aggregate a given set of air interfaces, the aggregated link will be sufficient to operate within the required lifetime of the aggregated link (e.g., when the aggregated link is expected to have a short lifetime, such as for relatively small data units).

[0065] Typically, the MLA multiplexer 220 may also be implemented with a maintenance state 408 to help ensure that the aggregated link operates with adequate quality and to help improve the user experience (eg, reduce the number of failed transmissions and / or retransmissions).

[0066] Figure 4 Also shown are some signals that may trigger a transition from one state to another. It should be understood that the indicated signals are exemplary and not intended to be limiting. Different signals may be used instead of or in addition to the signals shown to cause a transition from one state to the next.

[0067] Figure 5 is a state transition table showing the Figure 4 Some example signals for transitioning between the states shown. In the state transition table shown, the current state is indicated at the top, the next state is indicated on the left, and example signals for transitioning from the current state to the next state are indicated in the table entries. Figure 4 If the state model is not feasible, an entry of "N / A" is shown.

[0068] Figure 5 The figure shows the state transitions and received signaling from the perspective of an MLA multiplexer 220 (implemented in one network entity). That is, each MLA multiplexer 220 can independently transition between states based on received signals. State transition signals can be generated internally by the MLA multiplexer 220 itself or received from another MLA multiplexer 220. Signals between MLA multiplexers 220 can be communicated using control frames; internally generated signals can be generated by the MLME (in the PHY layer 210).

[0069] Each state can be self-looping. Self-looping means that the current state and the next state are the same state. In other words, the state is considered stable. Self-looping is the default state transition used when there is no state transition signal. Figure 5 As shown, in some cases, the self-loop is timed, which means that after the self-loop is executed within a predefined time period, the current state must transition to a different next state. A predefined self-loop timer can be used locally to record the predefined time period.

[0070] When the current state of the MLA multiplexer 220 is state 1 (unavailable state 402), state 1 may self-loop to the same state 1 without any associated timer. In other words, without any state transition signal, the MLA multiplexer 220 may remain in the unavailable state 402 indefinitely. Figure 4 When a remote signal (shown as MLPeering in FIG. 4 ) is received from another MLA multiplexer 220 via a control frame, for example, the MLA multiplexer 220 transitions to State 2 (Initialization State 404). If the MLA multiplexer 220 is the entity initiating multilink, the MLA multiplexer 220 transitions from State 1 to State 2 after determining that its local air interface is ready for MLA. State 1 does not directly transition to State 3 (Operational State 406) or State 4 (Maintenance State 408).

[0071] When the current state of the MLA multiplexer 220 is state 2 (initialization state 404), upon receiving the MLME_peeringMLTimeout signal ( Figure 4 State 2 transitions back to State 1 (Unavailable state 402) when the MLME_PeeringTimeOut signal is received (shown as PeeringTimeOut in the figure), which may be an internally generated signal from the MLME when a peering timer maintained by the MLME expires. This means that initialization and peering are only attempted within a predefined time period, and if peering is not successful within this time period, then the MLA initialization fails. State 2 may loop back to the same State 2 within a predefined time period, which may be the same as or different from the duration of the peering timer described above. A local loopback timer may be started at the start of the MLA peering process and may run until the MLA peering succeeds. If the loopback timer expires, the MLA multiplexer 220 may consider the loopback timer expiration to be equivalent to an MLA attempt failure and may transition back to State 1. The timer for loopback may be used as a fail-safe feature so that the MLA multiplexer 220 does not remain locked in the Initialization state 404 in the event of any error. When the MLME_MLAPeeringSuccess signal is received (in the figure), the MLA multiplexer 220 may transition back to State 1 (Unavailable state 402). Figure 4 When the MLA multiplexer 220 receives an internally generated signal from the MLME when the MLME receives an indication that the MLA was successfully established, the MLA multiplexer 220 transitions to State 3 (Operational State 406). State 2 does not transition directly to State 4 (Maintenance State 408).

[0072] When the current state of the MLA multiplexer 220 is state 3 (operating state 406), upon receiving the MLME_forcedMLDown signal ( Figure 4State 3 transitions directly back to State 1 (Unavailable State 402) when a signal (shown as ForcedMLDown in the figure) is received (this signal may be an internally generated signal from the MLME). MLME_forcedMLDown may be generated internally to force MLA to end at a network entity and may be used in situations where a network entity (e.g., AP 102) determines that MLA should not be used (e.g., if an expected positive acknowledgement is not received, indicating a failure of the remote air interface at the other end of the aggregated link; or if an unavailable or error condition is detected in the local air interface). State 3 does not transition directly to State 2 (Initialization State 404). State 3 may loop back to the same State 3 within a predefined period of time. If no traffic is sent / received on the aggregated link after the timer expires, the MLA multiplexer 220 automatically transitions to State 4 (Maintenance State 408). If traffic is received, the timer is reset. Alternatively, if traffic is received, the timer is paused and resumed when the traffic ends. The local timer used for looping back may be used to ensure that maintenance of the aggregated link is performed quasi-periodically (e.g., approximately every 100 ms). The quasi-periodic nature of the transition to state 4 ensures that the operation of the aggregated link is performed frequently enough, but the transmission / reception of data is not interrupted by the transition to state 4. Figure 4 State 3 also transitions to State 4 when a signal (shown as MLTimedMeasurement in FIG. 1 ) is received (this signal may be a remote signal received, for example, via a control frame from another MLA multiplexer 220). The ML timed measurement signal functions similarly to the loopback timer described above, but depends on a remote timer running on another MLA multiplexer 220 (e.g., at the other end of the aggregated link).

[0073] When the current state of the MLA multiplexer 220 is state 4 (maintenance state 408), upon receiving the MLME_forcedMLDown signal ( Figure 4 4 (shown as ForcedMLDown in the figure) (which may be an internally generated signal from the MLME), state 4 transitions directly back to state 1 (unavailable state 402). MLME_forcedMLDown may be generated internally to force MLA to end at the network entity and may be used in situations where the network entity (e.g., AP 102) determines that MLA should not be used (e.g., if an expected positive acknowledgement is not received, indicating a failure of the remote air interface at the other end of the aggregated link; or if an unavailable or error condition is detected in the local air interface). When the MLA multiplexer 220 is in state 4, measurements of the multi-link operation are performed by the MLME. If the MLME fails to obtain the required measurement results, the MLME generates an internal signal MLME_measurementMLFailure (in the figure). Figure 4 This signal causes the MLA multiplexer 220 to transition from state 4 to state 2 (initialization state 404), which can support the reconfiguration of the aggregated link. If the MLME successfully obtains the required measurement results, the MLME generates an internal signal MLME_measurementMLSuccess (in Figure 4 406 ) which causes the MLA multiplexer 220 to transition from state 4 to state 3 (operational state 406) to continue operation of the currently established aggregated link. State 4 can loop back to the same state 4 within a predefined time period. A local loopback timer can be started when MLA maintenance begins and can run until the MLA maintenance is completed (MLME measurement success or failure). If the loopback timer expires, the MLA multiplexer 220 can consider the loopback timer expiration to be equivalent to the MLME measurement attempt failure and can transition back to state 2. The timer for loopback can be used as a fail-safe feature so that the MLA multiplexer 220 does not remain locked in the maintenance state 408 under any error conditions.

[0074] Some of the state transitions are described in more detail below.

[0075] Figure 6 6 is a flow chart of an exemplary method 600 for transitioning from the initialization state 404 (state 2) to the unavailable state 402 (state 1) or the operational state 406 (state 3). The method 600 may be referred to as a method for initializing MLA (also referred to as initializing multilink peering or simply initializing peering). Typically, MLA is initialized between at least two MLA multiplexers 220 (one at each end of an aggregated link), with a first MLA multiplexer 220 being an MLA initiator (or master node) and a second MLA multiplexer 220 being an MLA responder. The method 600 may be performed by the MLA multiplexer 220 acting as the MLA initiator. Typically, the MLA initiator may be the AP 102, and the MLA responder may be a STA 104 associated with the AP 102. However, in some examples, the MLA initiator may be a STA 104, and the MLA responder may be the AP 102 or another STA 104. For simplicity, the following description may be understood in the context of AP 102 as an MLA initiator and STA 104 as an MLA responder, but it should be understood that this is not intended to be limiting.

[0076] At 602, the first MLA multiplexer 220 (also referred to as the MLA initiator for simplicity) begins MLA initialization in state 2 (initialization state 404). For example, step 602 may occur when the MLA initiator transitions from state 1 (unavailable state 402) to state 2 (e.g., after checking the readiness of its local air interface, such as after checking that the interface is operational and / or has a low error rate).

[0077] At 604, the MLA initiator sends a signal to the second MLA multiplexer 220 (also referred to as the MLA responder for simplicity) indicating a request for multi-link peering. For example, the signal may be in the form of a control frame (or management frame) generated by the MLA initiator and sent to the MLA responder over the air interface. This signal may be referred to as an ML_Peering_Request signal. The ML_Peering_Request signal may include information indicating the availability of the air interface at the MLA initiator, identification information about the available air interface (e.g., the virtual MAC address of the MLA initiator and / or the MAC address of the air interface), and other possible information.

[0078] At the MLA responder, receiving the ML_Peering_Request signal causes the MLA responder to transition from state 1 to state 2. The MLA responder performs operations in state 2 to determine the availability of its own air interface. The MLA responder sends a signal to the MLA initiator to provide information about the availability of the air interface at the MLA responder, as well as identification information about the available air interface (e.g., the virtual MAC address of the MLA responder and / or the MAC address of the air interface), and other possible information. The response signal can be in the form of a management frame and can be called an ML_Peering_Response signal.

[0079] At 606, the MLA initiator waits for a response (e.g., an ML_Peering_Response signal) from the MLA responder. Optionally, the MLA initiator may start a timer (e.g., a peer timer managed at the MLME), and if the timer expires before receiving a response signal from the MLA responder, the MLA initialization may be considered to have failed, the MLA initiator returns to state 1, and the method 600 ends.

[0080] If a response is received from the MLA responder (before the peer timer expires, if used), the response shall include information about the available air interfaces at the MLA responder and their identifiers (eg, MAC addresses).

[0081] The MLA initiator checks whether its local air interface is ready for multi-link peering at 608. This check may include determining the congestion level and / or current traffic load of the local air interface.

[0082] If the MLA initiator determines that its local air interface is not ready, the method 600 proceeds to step 610. At 610, the MLA initiator ends the MLA initialization process and returns to state 1, and the method 600 ends. Optionally, the MLA initiator may also send a signal to the MLA responder to indicate that the MLA initialization has failed, and to cause the MLA responder to return to state 1.

[0083] If the MLA initiator determines that its local air interface is ready, the method 600 proceeds to step 612. At 612, MLA initialization is successful. The MLA initiator transitions to state 3 and begins distribution and collection functions (e.g., using the MSDU distributor 222 and the MSDU collector 224, respectively). Optionally, the MLA initiator may also send a signal to the MLA responder to indicate that MLA initialization was successful and cause the MLA responder to transition to state 3. The method 600 ends.

[0084] Figure 7 FIG2 is a flow chart of an exemplary method 700 for transitioning from the operational state 406 (state 3) to the maintenance state 408 (state 4) and back. The method 700 may be referred to as a method for MLA maintenance. Generally, MLA maintenance may be performed locally by the MLA multiplexer 220 at each end of the aggregated link. For example, the method 700 may be performed by the MLA multiplexer 220 at the AP 102 or the STA 104.

[0085] At 702, the MLA multiplexer 220 is in the operational state 406 (state 3), and MLA is currently being used on multiple slave air interfaces (these slave air interfaces have been designated to serve aggregated traffic on the aggregated link).

[0086] At 704 , the MLA multiplexer 220 monitors the operation of the slave local air interface (ie, the air interface corresponding to the end of the aggregated link local to the MLA multiplexer 220 ).

[0087] If the state of the slave air interface has not changed, then the slave air interface is operating normally. Then, the method 700 proceeds to step 706 to wait until MLA maintenance is required. For example, a self-loop timer can be used to ensure that MLA maintenance is performed quasi-periodically, or a remote signal can be received to transition to state 4 (e.g., as described above with respect to Figure 5 Other techniques may be used to trigger MLA maintenance (eg, other internal or remote signals may trigger MLA maintenance). After waiting for the timer (or other trigger) for MLA maintenance, method 700 proceeds to step 708.

[0088] Returning to step 704 , if the status of one or more dependent air interfaces changes (eg, indicating that one or more dependent air interfaces are no longer operational or have significantly degraded), then maintenance and / or reconfiguration of the aggregated link may be required to keep the MLA operational.

[0089] At 708, the MLA multiplexer 220 transitions to the maintenance state 408 (state 4) and begins the MLA maintenance and reconfiguration process. For example, the MLA maintenance and reconfiguration may include redistributing traffic off the degraded air interface, among other possible functions.

[0090] At 710, the MLA multiplexer 220 determines whether the MLA maintenance is successful. For example, as described above with reference to Figure 5 As described above, the MLA multiplexer 220 may receive a local signal from the MLME indicating whether the multi-link measurement is successful or unsuccessful.

[0091] If the MLA maintenance is unsuccessful (eg, the MLME_measurementMLFailure signal is received), the method 700 proceeds to step 712. At 712, the MLA multiplexer 220 transitions to state 2 for reconfiguration. The method 700 ends.

[0092] If the MLA maintenance is successful (eg, the MLME_measurementMLSuccess signal is received), the method 700 proceeds to step 714. At 714, the MLA multiplexer 220 transitions back to state 3 to continue MLA operation. The method 700 ends.

[0093] As described above, the functionality provided by MLA multiplexer 220 synchronizes data transmission / reception on an aggregated link. The slave air interfaces in an aggregated link operate independently of one another. This means that each slave air interface may have a different contention window and link speed. Therefore, synchronization of data transmission / reception may be necessary so that transmission and reception on the aggregated link start and stop simultaneously on all slave air interfaces. Some exemplary synchronization operations that may be provided by MLA multiplexer 220 (e.g., using MLA MLME-SAP 226) are now described.

[0094] Figure 8 is a block diagram of an example of contention window synchronization that may be performed by the MLA multiplexer 220 using the MLA MLME-SAP 226. For purposes of illustration, Figure 8 Three slave interfaces of the aggregated link are shown. It should be understood that there may be fewer or more slave air interfaces in the aggregated link.

[0095] Contention window synchronization can be performed by the MLA multiplexer 220 at the transmitting end of the aggregated link at the start of an MLA transmission. At the start of an MLA transmission, the MLA multiplexer 220 obtains information from each local slave interface 202a, 202b, 202c to determine the contention window cw1, cw2, cw3 for each slave interface 202a, 202b, 202c, respectively. For example, the MLA multiplexer 220 can use virtual contention (e.g., as defined in the IEEE 802.11 standard) to obtain this information. Using the information fed back from each slave interface 202a, 202b, 202c, the MLA multiplexer 220 sets the contention window (referred to as MLAcw) for the MLA transmission, which is the largest contention window among the slave interfaces 202a, 202b, 202c. This can be expressed mathematically as:

[0096] MLAcw=Max(cw1,cw2,cw3)

[0097] The MLA multiplexer 220 configures all local slave air interfaces 202a, 202b, 202c to use the MLA contention window.

[0098] Figure 9 is a timing diagram of another example of MLA synchronization. In this example, MLA transmission occurs between a transmitting network entity (in this case, AP 102) and a receiving network entity (in this case, STA 104). In other examples, the transmitting network entity may be AP 102 or STA 104, and the receiving network entity may be AP 102 or STA 104. For illustrative purposes, three slave interfaces are shown (Interface 1, Interface 2, and Interface 3 at each of the AP and STA), but it should be understood that the number of slave interfaces used for MLA transmission may be greater or lesser. The slave air interfaces at AP 102 may generally be referred to as AP interfaces (specifically numbered 1, 2, and 3); the slave air interfaces at STA 104 may generally be referred to as STA interfaces (specifically numbered 1, 2, and 3). In this example, the transmitting network entity communicates with one receiving network entity over three aggregated links. However, it should be understood that this is not intended to be limiting. For example, in some cases, each STA interface may represent the entire protocol stack of the corresponding STA.

[0099] exist Figure 9 Prior to transmission as shown, the MLA multiplexer 220 should determine that each air interface is ready for transmission (e.g., Figure 6 608 ) so that transmission can start on all slave interfaces simultaneously.

[0100] As shown, after an arbitrary short interframe space (aSIFS) time 902, all AP interfaces use the same contention window duration 904 (i.e., the aforementioned MLAcw) configured by the MLA multiplexer 220. After the contention window 904 and another short interframe space (SIFS) 906, each AP interface sends a request to send (RTS) frame 908 to the corresponding STA interface. Each STA interface responds to the corresponding AP interface with a clear to send (CTS) frame 910. This process initiates synchronous (or quasi-synchronous) channel access. This can be referred to as "quasi-synchronous" channel access, even though the end result is effective synchronization of transmissions, because synchronization is not based on common timing signaling, but rather relies on having equal contention windows and equal RTS / CTS timing on each interface.

[0101] Relevant data (e.g., corresponding physical protocol data units (PPDUs) 912a, 912b, 912c) are transmitted over each air interface between the AP 102 and the STAs 104. For example, the MLA multiplexer 220 (e.g., using the MSDU distributor 222) can distribute the data to each slave interface for transmission. At the end of the MLA transmission, each STA interface responds with a corresponding positive acknowledgement (ACK) 914 in the reverse direction of the link. The ACK 914 allows the MLA multiplexer 220 at the AP 102 to easily detect the status of each air interface.

[0102] It should be noted that the data 912a, 912b, and 912c transmitted on each air interface can have different sizes, and each air interface can have different link speeds (in other words, there may be uneven transmission on the aggregated link). To ensure load balancing so that reception ends simultaneously on each slave interface, the MLA multiplexer 220 at the transmitting entity (AP 102 in this example) can pad the transmitted data. For example, data transmission on faster links can be padded to balance data transmission on slower links. Any suitable padding algorithm can be used. This data padding can be performed using the flow control and load balancing functions of the MLA multiplexer 220 (e.g., using the MLA MLME-SAP 226).

[0103] This disclosure also describes exemplary frame formats that enable the MLA multiplexer 220 at the receiving end to identify whether a given data transmission is an MLA management frame or a data frame belonging to an MLA data stream, and whether it is a data frame within the MLA data stream to which the data frame belongs. This identification of data frames may be necessary because each individual slave air interface operates independently, and data on different slave interfaces may arrive out of order and / or may be interleaved with data belonging to different data streams. The MLA multiplexer 220 at the receiving end can use this information to correctly collect and reassemble the data (e.g., using the MSDU collector 224).

[0104] Figure 10 An example of an MLA MPDU frame format 1000 is shown, illustrating some example field details. Example frame format 1000 is generally based on an existing MPDU frame format (eg, according to the existing IEEE 802.11 standard), but adapted for MLA transmission, as described below.

[0105] The exemplary frame format 1000 includes a frame control field 1002 that includes an MLAMPDU transmission indication 1100 (described further below). The exemplary frame format 1000 includes a duration / ID field 1004 that indicates duration or association identifier information. The exemplary frame format 1000 also includes an address 1 field 1006 that identifies the receiver (e.g., indicating a receiving address (RA)); an address 2 field 1008 that identifies the transmitter (e.g., indicating a transmitting address (RA)); an address 3 field 1010; and an address 4 field 1012. The address 4 field 1012 can be used, for example, to indicate the logical MAC address of the MLA multiplexer 220 at the transmitter (in the Figure 10 The MLA multiplexer 220 at the transmitter is identified by the MLA address 4 field 1012 (shown as MLA_MUXER_Address in FIG4 ). The information included in the address 4 field 1012 can be used at the receiving MLA multiplexer 220 to check whether the received MPDU is from the same transmitting MLA multiplexer 220 as the current data stream or from a different MLA multiplexer (which may indicate that the MPDU belongs to a different data stream). This allows the receiving MLA multiplexer 220 to correctly collect MPDUs belonging to the same data stream and correctly reassemble the data.

[0106] The exemplary frame format 1000 also includes a quality of service (QoS) control field 1014 , a high throughput (HT) control field 1016 , a frame body 1018 (including data content), and a frame check sequence (FCS) field 1020 .

[0107] Figure 11A and Figure 11B Details of an exemplary frame control field 1002 including an indication of an MLAMPDU data transmission are shown. While these examples illustrate the use of certain bit values ​​in certain fields, it should be understood that these are for illustrative purposes only and are not intended to be limiting.

[0108] Figure 11A The information carried in each bit of an exemplary 2-octet long frame control field 1002 is shown. Specifically, the frame control field 1002 may use a 2-bit type field 1102 and a 4-bit subtype field 1104 as an MLA MPDU transmission indicator 1100. Other bit values ​​in the frame control field 1002 may be similar to existing standard definitions.

[0109] Figure 11B 1 is a table showing exemplary bit values ​​that may be carried in the type field 1102 and the subtype field 1104. For example, a bit value of "00" in the type field 1102 and a bit value of "1111" in the subtype field 1104 may be used to indicate that the MPDU is an MLA management frame transmission; a bit value of "10" in the type field 1102 and a bit value of "1101" in the subtype field 1104 may be used to indicate that the MPDU is an MLAMPDU data transmission.

[0110] In various examples, this disclosure describes a reference architecture for supporting over-the-air MLA. In the disclosed reference architecture, an MLA multiplexer logic layer is provided on top of the existing PHY layer. This added layer allows for relatively easy implementation of MLA functionality without requiring significant changes to existing security procedures. The air interface, in both the ready and associated states, can operate independently while also acting as a slave interface carrying aggregated services.

[0111] An MLA multiplexer can be implemented using a state machine and can include a maintenance state (which is used on a quasi-periodic basis) to enable relatively fast and near real-time maintenance and reconfiguration of aggregated links when air interface states change. An MLA multiplexer can easily transition between states to switch between aggregated and non-aggregated operation. An MLA multiplexer provides synchronization capabilities to manage transmission and reception on multiple air interfaces that otherwise operate independently of each other.

[0112] In some examples, frame formats have been described to support correct identification and demultiplexing (reassembly) of MLA transmissions at a receiver.The disclosed embodiments can help reduce the risk of transmission duplication and / or misordering.

[0113] Since the MLA multiplexer is a logic layer placed on top of the existing PHY layer, the MLA multiplexer does not affect the existing security of the individual interfaces. Existing security protocols can be used to ensure the security of data transmission.

[0114] Although the present invention uses steps in a certain order to describe methods and processes, one or more steps of the methods and processes may be omitted or modified as appropriate. One or more steps may be performed in an order different from the order described as appropriate.

[0115] Although the present invention has been described at least in part in terms of methods, it will be understood by those skilled in the art that the present invention also relates to various components for performing at least some aspects and features of the described methods by hardware components, software, or any combination of the two. Accordingly, the technical solutions of the present invention may be embodied in the form of software products. Suitable software products may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer-readable medium, including, for example, a DVD, CD-ROM, USB flash drive, removable hard disk, or other storage medium. The software product includes instructions stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein.

[0116] The present invention may be embodied in other specific forms without departing from the subject matter of the claims. The described exemplary embodiments are to be considered in all respects as illustrative only and not restrictive. Selected features from one or more of the above-described embodiments may be combined to create alternative embodiments not explicitly described, and features suitable for such combinations are understood to be within the scope of the present invention.

[0117] All values ​​and subranges within the disclosed ranges are also disclosed. In addition, although the systems, devices, and processes disclosed and illustrated herein may include a specific number of elements / assemblies, these systems, devices, and assemblies may be modified to include more or fewer such elements / assemblies. For example, although any disclosed element / assembly may be cited as a single quantity, the embodiments disclosed herein may be modified to include multiple such elements / assemblies. The subject matter described herein is intended to cover and encompass all appropriate technical changes.

Claims

1. A device for wireless communication, characterized in that include: A network interface, the network interface supporting multiple air interfaces for wireless communication with at least one network entity; as well as a processor coupled to the network interface, the processor configured to execute instructions to: A multi-link aggregation (MLA) multiplexer is implemented as a logical layer, the MLA multiplexer providing at least a synchronization function to synchronize data transmission to the at least one network entity, the transmission being performed over two or more slave air interfaces belonging to the aggregated link, wherein the synchronization function comprises: obtaining information about the duration of the corresponding contention window from each of the dependent air interfaces; and Each of the dependent air interfaces is configured to use a new contention window, where the new contention window is a maximum value of the corresponding contention window.

2. The device according to claim 1, characterized in that The MLA multiplexer includes: a data distributor, configured to distribute data to each of the slave air interfaces for transmission; a data collector configured to receive data from each of the slave air interfaces and reassemble the received data; and An MLA manager is configured to at least provide the synchronization function.

3. The device according to claim 1, characterized in that Each of the slave air interfaces maintains a corresponding independent security association for data transmission.

4. The device according to claim 1, characterized in that The MLA multiplexer operates in any of the following states: an unavailable state, in which the multiple air interfaces do not participate in any aggregated link; an initialization state, in which the MLA multiplexer communicates with the at least one network entity to establish the aggregated link using the two or more slave air interfaces; an operational state in which transmission to the at least one network entity occurs over the aggregated link; or A maintenance state, in which the MLA multiplexer obtains information about the operating status of each of the slave air interfaces to ensure that a link established on each of the slave air interfaces can operate.

5. The device according to claim 4, characterized in that The MLA multiplexer transitions from the operational state to the maintenance state after a timer expires.

6. The device according to claim 5, characterized in that When there is service on the aggregated link, the timer is paused or reset.

7. The device according to claim 1, characterized in that The synchronization functions include: For at least one slave air interface, filling transmission is performed on the at least one slave air interface, so that the data transmission on each of the slave air interfaces ends synchronously.

8. The device according to claim 1, characterized in that The data transmitted on the aggregated link is a MAC protocol data unit (MPDU) having a frame format, wherein the frame format includes an address field indicating a logical MAC address associated with the MLA multiplexer, and the address field is used to indicate a source of the MPDU.

9. The device according to claim 8, characterized in that The frame format also includes a frame control field including a bit value indicating a message type of the MPDU.

10. A method for wireless communication, characterized in that: The method comprises: A multi-link aggregation (MLA) multiplexer is implemented as a logical layer, the MLA multiplexer providing at least a synchronization function to synchronize data transmission to at least one network entity, the transmission being performed over two or more slave air interfaces belonging to an aggregated link, wherein the synchronization function comprises: obtaining information about the duration of the corresponding contention window from each of the dependent air interfaces; and Each of the dependent air interfaces is configured to use a new contention window, where the new contention window is a maximum value of the corresponding contention window.

11. The method according to claim 10, characterized in that Implementing the MLA multiplexer includes: a data distributor, configured to distribute data to each of the slave air interfaces for transmission; a data collector configured to receive data from each of the slave air interfaces and reassemble the received data; and An MLA manager is configured to at least provide the synchronization function.

12. The method according to claim 10, characterized in that Each of the slave air interfaces maintains a corresponding independent security association for data transmission.

13. The method according to claim 10, characterized in that The MLA multiplexer operates in any of the following states: an unavailable state, in which the multiple air interfaces do not participate in any aggregated link; an initialization state, in which the MLA multiplexer communicates with the at least one network entity to establish the aggregated link using the two or more slave air interfaces; an operational state in which transmission to the at least one network entity occurs over the aggregated link; or A maintenance state, in which the MLA multiplexer obtains information about the operating status of each of the slave air interfaces to ensure that a link established on each of the slave air interfaces can operate.

14. The method according to claim 13, characterized in that The MLA multiplexer transitions from the operational state to the maintenance state after a timer expires.

15. The method according to claim 14, characterized in that When there is service on the aggregated link, the timer is paused or reset.

16. The method according to claim 10, characterized in that The synchronization functions include: For at least one slave air interface, filling transmission is performed on the at least one slave air interface, so that the data transmission on each slave air interface ends synchronously.

17. The method according to claim 10, wherein: The data transmitted on the aggregated link is a MAC protocol data unit (MPDU) having a frame format, wherein the frame format includes an address field indicating a logical MAC address associated with the MLA multiplexer, and the address field is used to indicate a source of the MPDU.

18. A computer-readable storage medium, characterized in that The device comprises instructions which, when executed by a processor of the device, cause the device to perform the method according to any one of claims 10 to 17.

Images