PRIMARY AND SECONDARY ACCESS POINTS
BACKGROUND
FIELD OF THE DISCLOSURE
[0001] The present disclosure relates to primary and secondary access points.
DESCRIPTION OF RELATED ART
[0002] It is desired to have connectivity to at least two access points (APs), which reside at physically distant locations. Thus, a station (STA), also commonly known as communication device, may be served via several links (e.g. at different carrier frequencies) by several APs. Applications include improved/high reliability connectivity in which STAs can be seamlessly served from several APs. Hence, if one link deteriorates, the other link may serve as a backup. Another application is improved roaming for STAs with high mobility requirements. Hence, a STA can connect to several APs (e.g., a serving and a target AP) during a transition time before getting connected to a single AP (e.g., a target AP) again. Connectivity to multiple distant APs is, however, challenging.
[0003] The “background” description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventor(s), to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
SUMMARY
[0004] It is an object to improve the connectivity, in particular with respect to reliability and seamless roaming. It is a further object to provide a corresponding method as well as a corresponding computer program and a non-transitory computer-readable recording medium that stores therein a computer program product for implementing said method.
[0005] According to an aspect there is provided a primary access point, AP, configured to be connected to two or more secondary, physically separated, interconnected APs, each being configured to communicate with one or more communication devices via separate links and each comprising an upper AP unit and a lower AP unit providing different functionalities for the communication, the primary AP comprising circuitry configured to: connect to the upper AP unit of a first secondary AP of the two or more secondary AP that holds context information configured for use by the upper AP unit of said first secondary AP to communicate with a communication device; and forward one or more data units to be transmitted to said upper AP unit to which it has been connected and/or receive one or more data units from said upper AP unit to which it has been connected.
[0006] According to a further aspect there is provided a secondary access point, AP, configured to be connected to a primary AP that is configured to be connected to two or more secondary, physically separated, interconnected APs, the secondary AP being configured to communicate with one or more communication devices via separate links and comprising an upper AP unit and a lower AP unit providing different functionalities for the communication, the secondary AP comprising circuitry configured to: hold context information in its upper AP unit configured for use by said secondary AP to communicate with a communication device; switch to its lower AP unit and/or the lower AP unit of another secondary AP; receive one or more data units to be transmitted from the primary AP, process the received one or more data units in its upper AP unit, and forward the processed one or more data units according to the switching to either its lower AP unit or the lower AP unit of the other secondary AP and/or receive one or more data units according to the switching from either its lower AP unit or the lower AP unit of the other secondary AP, process the received one or more data units in its upper AP unit, and forward the processed one or more data units to the primary AP.
[0007] According to still further aspects corresponding methods, a computer program comprising program means for causing a computer to carry out the steps of the method disclosed herein, when said computer program is carried out on a computer, as well as a non-transi- tory computer-readable recording medium that stores therein a computer program product, which, when executed by a processor, causes the method disclosed herein to be performed are provided.
[0008] Embodiments are defined in the dependent claims. It shall be understood that the disclosed methods, the disclosed computer program and the disclosed computer-readable recording medium have similar and/or identical further embodiments as the claimed devices and as defined in the dependent claims and/or disclosed herein.
[0009] One of the aspects of the disclosure is to make use of an architecture of multiple distant (physically separated) APs, hereinafter referred to as secondary APs, which are interconnected to serve a communication device (e.g., a STA or non-AP multi-link device (MLD)) via multiple links seamlessly. The secondary APs are connected to an overarching AP (oaAP), hereinafter referred to as primary AP, and each comprise an upper AP unit (or circuitry) and a lower AP unit (or circuitry) that provide different functionalities with respect to the intended communication with the communication device. In such an architecture, the connectivity is improved, in particular with respect to reliability and seamless roaming.
[0010] The foregoing paragraphs have been provided by way of general introduction and are not intended to limit the scope of the following claims. The described embodiments, together with further advantages, will be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWING
[0011] A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:
Fig. 1 shows a first embodiment of the considered architecture.
Fig. 2 shows a second embodiment of the considered architecture.
Fig. 3 shows a third embodiment of the considered architecture.
Fig. 4 shows a schematic diagram of the architecture of the APs according to the present disclosure.
Fig. 5 shows a more detailed schematic diagram of the architecture of the APs according to the present disclosure.
Fig. 6 shows an embodiment of a unit 91 for implementing a wired backhaul.
Fig. 7 shows an embodiment of a unit 93 for implementing a wireless backhaul. Fig. 8 shows an embodiment of the implementation of the backhaul using dedicated WLAN devices.
Fig. 9 shows an embodiment of the implementation of the backhaul using frame creators.
Fig. 10 shows the routing of a backhaul data frame in the implementation of the back- haul depicted in Fig. 9.
Fig. 11 A shows a diagram illustrating the situation before the process of setup or after termination.
Fig. 11 B shows a diagram illustrating the situation after the process of setup or before termination.
Fig. 12 shows a schematic diagram illustrating link reconfiguration driven by a non-AP MLD.
Fig. 13 shows a schematic diagram illustrating link reconfiguration driven by an oaAP.
Fig. 14 shows a diagram of a first embodiment of a downlink transmission.
Fig. 15 shows a diagram of a second embodiment of a downlink transmission with more MSDlls.
Fig. 16 shows a diagram of a third embodiment of a downlink transmission with delayed transmission.
Fig. 17 shows a diagram of a fourth embodiment of a downlink transmission via a different AP. Fig. 18 shows a diagram of a fifth embodiment of a downlink transmission of several APs.
Fig. 19 shows a diagram of a first embodiment uplink transmission using triggered uplink via downlink functionality.
Fig. 20 shows a diagram of a second embodiment uplink transmission.
Fig. 21 shows a diagram of a third embodiment uplink transmission with prevention of a frame exchange.
Fig. 22 shows a diagram of a fourth embodiment uplink transmission.
Fig. 23 shows a diagram of a context transfer process.
Fig. 24 shows a diagram of an embodiment of emptying transmit and receiver queue of an AP before context transfer.
Fig. 25 shows a diagram of an embodiment of the operation with EMLSR in downlink.
Fig. 26 shows a flow chart of an embodiment of a first communication method of a primary AP.
Fig. 27 shows a flow chart of an embodiment of a second communication method of a secondary AP.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0012] It is desired to have connectivity to at least two APs which reside at physically distant locations. Thus, a STA, also referred to as communication device herein, may be served via several links (e.g., at different carrier frequencies) by several APs. The applications include improved or high reliability connectivity in which STAs can be seamlessly served from several APs. Hence, if one link deteriorates, the other link may serve as a backup. Another application is improved roaming for STAs with high mobility requirements. Hence, a STA can connect to several APs (e.g., a serving and a target AP) during a transition time before getting connected to a single AP (e.g., a target AP) again. The difference of both applications lies in the transitory or non-transitory nature of multiple connectivity.
[0013] Two embodiments of the considered architecture are shown in Figs. 1 and 2. Two APs are connected to an overarching AP entity (oaAP) 10 and both APs 20, 30 establish links (link 1 and link 2) to STAs 40, 50 (STA1 and STA2). Both STAs 40, 50 are organized in a non- AP multi-link device (MLD) 60. The non-AP MLD 60 converges the traffic flows of the two STAs 40, 50 within a device, whereas the oaAP 10 converges traffic flows from distant APs 20, 30; hence, in case of the oaAP 10 the connection between APs 20, 30 and oaAP 10 is implemented via a wired (e.g. Ethernet) and/or wireless (e.g. WLAN) backhaul connection. Due to the delays and/or bandwidth limitations that can occur in those connections, an oaAP 10 cannot be an AP MLD as will be outlined in the following. Figs. 1 and 2 show two different implementation examples in terms of the physical separation. In the embodiment of Fig. 1 , the oaAP 10 and the two APs 20, 30 are physically separated, meaning each is in a separate device, whereas in the embodiment of Fig. 2, the oaAP 10 and AP1 20 are implemented in the same device, but AP2 30 is physically separated in a different device. The oaAP 10 may also be implemented together with AP2 30, but AP1 20 is physically separated.
[0014] According to Figs. 1 and 2, both APs 20, 30 create one link each. However, it can be envisioned that an AP is an AP MLD with multiple affiliated APs; hence, creating multiple links as shown in Fig. 3 depicting a third embodiment of the considered architecture in which the non-AP MLD 60 is connected via two links to both AP MLDs 70, 80, each connected to two APs (AP1 20 and AP325 for AP MLD 70 and AP2 30 and AP4 35 for AP MLD 80). The remaining links can be used for other purposes or for the case when the non-AP MLD 60 is connected via two links to a single AP MLD 70 or 80. [0015] Connectivity to multiple distant APs is challenging because various items (referred to as “context” in the following, i.e., “context” comprises one or more of these items) should be synchronized among APs:
Encryption of data units: An AP uses a temporal key (TK) and an increasing packet number (PN). At a receiving STA, the PN is tracked and if it is not in increasing order, the related packet(s) will be discarded. Therefore, the PN needs to be strictly monotonically increasing even if packets are transmitted from different APs. Same is true for TK which is determined during association of a STA. The TK should be the same for all encrypting APs, otherwise the peer STA cannot decrypt.
Sequence numbers: An AP uses a sequence number (SN) to index packets to be transmitted. It is important that the SN does not repeat within a sufficiently large time interval. Furthermore, the SN controls the retransmission and duplication avoidance; a packet from same source and same traffic (TID) is considered as a retransmission and may be either used (if earlier packet was erroneous) or dropped (if earlier packet arrived already).
Association/capability data: Once a STA associates to an AP, capabilities of PHY and MAC are exchanged such that each device understands what the other side is capable of and such that any transmission to the peer device respects the supported features.
Negotiated agreements: Once a STA is associated to an AP, it may negotiate parameters of several features such as BlockAck (BAck), Target Wake Time (TWT), QoS Characteristics, and/or traffic streams (TS or SCS).
Receiver buffer and scoreboard contents: At a receiving AP, packets may be buffered for the sake of order keeping. For example, if a packet with lower SN was received in error, a packet with higher SN will be buffered but not forwarded to higher layer to keep the packet order. Thus, the packet itself as well as the reception status (erroneous or not) needs to be stored. Also, the reception status is part ofaAcknowl- edgement frames sent back from receiver to transmitter.
T ransmitter buffer: At a transmitting AP, packets may be buffered because they have not been able to be transmitted yet, for example because the channel was busy, or another packet may have had transmission priority, or successful packet delivery was not reported by the receiver via an acknowledgement. The last item (transmitter buffer) is closely related to the fact that multiple APs should have a single entry or exit point for data to be transmitted or for data to be received, respectively. Thus, it is completely transparent for the user which link was used for data transfer.
[0016] Depending on the implementation, the context may be partly present at oaAP and partly at an AP. For example, the transmit buffer context may be at an AP, whereas the negotiated agreement context may be at the oaAP. The context of the oaAP can either stay with the oaAP all the time (e.g., in the architecture of Fig. 1) or it may move with the context of the AP (e.g., in the architecture of Fig. 2).
[0017] According to the present disclosure context synchronization problems are addressed. An architecture with oaAP and APs is used. Each AP comprises an upper AP unit (also called “upper AP instance”, “upper AP circuitry” or simply “upper AP”) and a lower AP unit (also called “lower AP instance”, “lower AP circuitry” or simply “lower AP”). Generally, just one instance of an upper AP unit is active within an oaAP and any frame that is transmitted via a lower AP unit is preprocessed by the single upper AP unit. A frame exchange in downlink or uplink involves no more than one AP at a time. The AP can be an AP MLD if the APs are colocated. The upper AP unit may change its physical location by a context transfer. Setup and teardown of oaAP connectivity may be performed. Enhanced Multi-link Single Radio (EMLSR) operation mode as a variant to ensure the single connectivity as described above.
[0018] Fig. 4 shows a more detailed schematic diagram of the architecture of the APs according to the present disclosure. As shown on the right-hand side, each AP 20, 30 is broken down into an upper AP unit 21 , 31 and a lower AP unit 22, 32. Both upper AP units 21 , 31 are logically interconnected, preferably via a backhaul 90 (also referred to as “backhaul link” or “backhaul connection”). In this context, “interconnection” shall be understood such that the interconnected units or components are able to exchange information, e.g., to transmit and receive information, wherein the interconnection may be implemented via a wireless connection (e.g., via Wi-Fi, mobile radio, Bluetooth, etc.) or a wired connection (e.g., via LAN, cable, etc.). Both wireless and wired connection may be implemented by dedicated communication interfaces or by communication interfaces that are anyway present and used for actual data exchange.
[0019] The upper and lower AP units, into which an AP is split, shall be understood as separate physical or logical entities, that together fulfill the task of an AP, wherein each of them fulfills different functionalities of the AP. The terminology upper and lower may refer to their orientation in the open systems interconnection (OSI) model in which the upper AP’s functionalities are closer to the layer above the AP’s MAC layer, whereas the lower AP’s functionalities are closer to the layer below the AP’s MAC layer. In an embodiment, the lower AP may include the PHY layer of the AP. The upper AP unit and the lower AP unit of the same AP can operate independently of each other, but it is assumed that only one upper AP unit is operational at all times for connectivity to a non-AP MLD. The upper AP unit that holds the context is the operating upper AP unit, whereas the other upper AP units (of other APs) are not present or disabled. This avoids context synchronization issues among multiple upper AP units.
[0020] A lower AP unit can, for example, contend for channel access, transmit encrypted MPDlls and receive reception status information from the peer non-AP MLD. Based on this information, it may also retransmit erroneously transmitted MPDlls as indicated by peer non- AP MLD. Similarly, for reception, a lower AP unit can receive data units and provide a reception status information to the peer non-AP MLD. Correctly received data units are subsequently forwarded to the upper AP unit holding the context including a context update, as will be explained below.
[0021] In more detail, splitting the AP functionality into an upper and lower entity according to the present disclosure provides that in case of a transmission, a data packet goes first through the upper AP unit and subsequently through the lower AP unit, whereas in case of a reception it is vice versa. The reason for the splitting is a separation of the functionality.
[0022] The upper AP unit holds MAC functionality that requires common unique states for processing of data (e.g. in a memory such as numbers, keys, scoreboards, and/or buffered data packets). Therefore, for transmission, the upper AP unit holds one or more of the functionalities of queuing for power safe which requires packets to be stored for later transmission, encryption which requires the temporal key, packet number assignment which requires the previous packet number used, and sequence number assignment which requires the previous sequence numbers. For reception, the upper AP unit holds one or more of the functionalities of BAck scoreboarding which requires the status of previous receptions (erroneous or not), duplicate detection which requires the sequence numbers of previously received packets, decryption which requires the temporal key, BAck buffer and reordering which requires the status of previous receptions and receptions that could not be further processed due to a previous erroneous data packets, and replay detection which evaluates the packet number if in increasing order.
[0023] The lower AP unit holds functionality that runs independently of previous operations.
Hence after being configured, it executes various steps regardless of previous states (with the exception of link specific states, see below). It also holds the PHY layer. The lower AP unit can be seen as a “contract worker”. Therefore, for transmission, the lower AP unit holds one or more of the functionalities of MPDll header and CRC computation which is essentially a function of input parameters such as data units, A-MPDll aggregation which may combine multiple encrypted MPDlls into an aggregated MPDll by inserting delimiters, and PHY transmission. For reception, the lower AP unit holds one or more of the functionalities of PHY reception, A-MPDll deaggregation which disassembles an aggregated MPDll into MPDUs based on delimiters, MPDU header and CRC validation which is essentially a function of the receive data unit, address 1 filtering which filters the MPDUs for the address contained within it (to sort out MPDUs that are not intended for the particular STA), and BAck scoreboarding which is to evaluate the current reception state (in upper AP unit, it is the global reception state) to be included into response frames to a reception. The lower AP unit holds also the functionality of channel contention which holds the state of the number of previously failed transmissions as an exception as it is a link specific state. Any state that is obtained within a lower AP (e.g. BAck scoreboard) is forwarded to the upper AP unit during the “context update” but will not be stored at the lower AP unit for next frame exchange.
[0024] Fig. 5 shows an even more detailed schematic diagram of the architecture of the APs according to the present disclosure. In this embodiment it is assumed that the upper AP1 unit 21 holds the context. In addition to the building blocks (functionalities) that are existing in known PHY and MAC layers according to IEEE 802.11 , switching units (also called “switching instances” or “switching circuitries”, “switching devices”, “connection devices” or simply “switches”) are newly added according to the present disclosure. The switching unit 13 (called “switching device A” in Fig. 5) at the oaAP 10 is switched to the upper AP1 unit 21 holding the context 100. Hence, every data packet after “A-MSDll Aggregation (Tx) and De-aggregation (Rx)” is forwarded to or received from this upper AP1 unit 21. The switch 13 only changes when the context 100 is moved to a different AP. The setting of this switch 100 is also STA dependent, as the context for different STAs may reside at different upper AP units. Switch 13 may hold a memory to store MSDlls while no upper AP unit is connected to the oaAP 10 as explained below.
[0025] In the lower end of the upper AP1 unit 21 , a switching unit 23 (called “switching device B” in Fig. 5) resides after the “MPDll Encryption” for transmission or before the “Block Ack scoreboarding” for reception. This switch 23 controls which lower AP unit is used for transmission and/or reception. Conceptually, the switch 23 moves automatically to the lower AP unit forwarding received packets as will be detailed below. Thus, it is possible that the position of the switch 23 is to both APs 20, 30 while waiting for an Rx notice from one of the APs (see below).
[0026] The switch 23 can be placed either such that the lower AP1 unit 22 that is colocated with the upper AP1 unit 21 holding the context 100 performs further steps and is finally transmitting or receiving the data packets, or such that a distant lower AP2 unit 22 is finally transmitting or receiving the data packets. In the latter case, the data packets are transmitted and/or received via a wireless or wired backhaul connection 90 to another switching unit 33 (called “switching device C” in Fig. 5) at the distant AP2 30 which re- ceives/transmits the data packets via backhaul 100 and forwards them to the colocated lower AP2 unit 32 which finally transmits or receives the data packets.
[0027] The switch 33 may hold a memory which stores the data packets until the lower AP2 unit 32 can further process (e.g. due to a channel busy condition). The upper AP units that do not have the context 100 are still present, for example to serve other STAs that are associated to those APs as the context is always STA or non-AP MLD specific. For this reason, the upper AP2 unit 31 may have functionality for other STAs or non-AP MLDs for which it holds the context. For the same reason switch 33 is provided as it is only directed towards the backhaul 90 for the considered non-AP MLD unless there was a context handover; otherwise it connects the upper AP2 unit 31 with lower AP2 unit 32.
[0028] It should be noted that the allocation of functional units to oaAP 10, upper AP units 21 , 31 and lower AP units 22, 32 is exemplary. Different allocations may be possible and some functional units may be dropped without changing functionality of the respective units and the whole scheme.
[0029] Depending on different variants of the implementation described below, the switches and/or upper AP units may operate STA or non-AP MLD specific and/or even traffic identifier (TID) specific. Hence, the upper AP unit holding the context may be different for different STAs or non-AP MLDs and/or even for different traffics for/of the same STAs or non- AP MLDs.
[0030] The backhaul connection 90 provided according to the present disclosure as shown in Figs. 4 and 5 connects the two upper AP units 21 , 31 logically. A backhaul data packet may include encrypted MPDUs, context content, context update, release notifications, Rx notices, etc. The backhaul connection 90 can be implemented in different ways. Fig. 6 shows an embodiment of a unit 91 for implementing a wired backhaul and Fig. 7 shows an embodiment of a unit 93 for implementing a wireless backhaul.
[0031] According to both embodiments, at the entry and/or exit point at the upper AP unit, there is a frame creator 92, 94 attached, which processes the backhaul data and related control information (e.g., to identify the type of backhaul data). This data is embedded into either an Ethernet frame structure using the frame creator 94 for Ethernet (as shown in Fig. 7) or a WLAN frame structure using the frame creator 92 for (as shown in Fig. 6) and given to a dedicated radio or a distribution system.
[0032] Fig. 8 shows another embodiment of the implementation of the backhaul using dedicated WLAN devices 24, 34. The dedicated radio may thus be a WLAN radio that is colocated to the respective upper AP units 21 , 31. Its peer device is the other upper AP unit. Whenever there is backhaul data to transmit from an upper AP unit, the dedicated WLAN radios (i.e., the WLAN devices 24, 34) take care of the delivery to the other upper AP unit. A distribution system 110 is shown that distributes data units according to their source and destination address. It may include wired and/or wireless connections. The distribution system 110 may route a frame to be conveyed via any favorable route to the destination.
[0033] An embodiment of the implementation of the backhaul using frame creators 25, 35 and a distribution system 111 is shown in Fig. 9. The interface to the distribution system 111 is a frame creator 25, 35, either for WLAN (see also Fig. 6) or Ethernet (see also Fig. 7). Both distribution systems 110, 111 can be the same, which means that user data and backhaul may use the same network or different networks (meaning that separate networks exist for backhaul and user data).
[0034] In this context, it is even possible that a backhaul data frame created at the upper AP1 unit 21 goes via the distribution system 111 to the oaAP 10 and passes through the upper and lower AP1 units 21 , 22 to the lower and upper AP2 units 32, 31 , where it exits the oaAP 10 and the distribution systems 110, 111 route it to its destination, which is the upper AP2 unit 31. This is illustrated in Fig. 10 showing this routing 120 of a backhaul data frame in the implementation of the backhaul depicted in Fig. 9. Thus, the same APs are used for connectivity to the non-AP MLD and to the physically separated APs. The operation may be in time-division duplex (TDD) and/or frequency division duplex (FDD). Hence, delays may be expected in this setup until the backhaul data arrives at the upper AP2 unit 31 which may finally serve the non-AP MLD.
[0035] This entire operation may be determined and defined by appropriate settings of source and destination addresses. If there is a non-AP MLD connected to the oaAP 10 and the upper AP1 unit 21 and the upper AP2 unit 31 share data, the user data has source address “oaAP” and destination address “non-AP MLD”. The upper AP1 unit 21 creates the backhaul data for the upper AP2 unit 22 based on user data. The backhaul data packet has source address “upper AP1” and destination address “upper AP2”. [0036] In summary, as shown in Figs. 6 to 10, there are different implementation of a backhaul. A wireless backhaul may be implemented with another WLAN device which is colocated with the upper AP unit (it may even form a multi-link device with the other AP). The data packets to be transmitted via backhaul (e.g. an encrypted MPDll to be transmitted or a received MPDll after BAck Scoreboarding or status information such as BAck scoreboard or context update information) are then encapsulated with control information and forwarded as user data to the colocated WLAN device with address information of the peer device (that is the WLAN device colocated with the distant AP) as well as parameters such as priority and routing information. A wired backhaul may be implemented similarly to the wireless backhaul, however the encapsulated data is embedded in an Ethernet frame with a subtype (e.g. 0x890D Ethertype) and address information.
[0037] Fig. 11 shows a diagram illustrating the process of setup or termination, i.e., the transition to or from a connectivity to multiple distant APs, respectively. Fig. 11 A shows the situation before setup or after termination. Fig. 11 B shows the situation after setup or before termination. All involved entities should perform a capability exchange before to see if connection to multiple distant APs is supported. Initially (Fig. 11 A), the non-AP MLD 60 is connected to a single AP (not shown) or a single AP MLD 70, which belongs to or can join an oaAP entity 10. The non-AP MLD 60, as schematically shown as an embodiment in Fig. 12, or the oaAP 10, as schematically shown as an embodiment in Fig. 13, or the active AP decides to connect to two APs at distant location which belong to the oaAP 10 or may belong to an oaAP. The entity which decides to connect to two distant APs creates a link reconfiguration request frame 200 (optionally followed by an Ack 201) that indicates to the peer device which links should be used subject to confirmation by the oaAP 10. If the non- AP MLD 60 decides to connect to two APs at distant locations, the peer device is the oaAP 10 or the active AP (the one the non-AP MLD is currently connected to, i.e., a single AP or the AP MLD1 70)). If the oaAP 10 or the active AP decides to connect to two APs at distant locations, the peer device is the non-AP MLD 60.
[0038] Thereby at least one link (here link 1) stays as it was to avoid connectivity loss. The request frame 200 is transmitted via any active link, e.g., depending on channel business, and the peer device responds to this frame (e.g. with an Ack) and informs related devices. Once oaAP 10 or non-AP MLD 60 is ready for link reconfiguration it transmits a confirmation 202, followed by an Ack 203 from the peer device. Afterwards, both links can be used. This mechanism is required because “inform oaAP and other APs (optionally)” may take time for setup due to the backhaul connection. The situation after the setup is shown in Fig. 11B.
[0039] Termination works in the same way, but “inform oaAP and other APs (optionally)” includes flushing a buffer and transmitting remaining encrypted MPDlls on the link that is to be terminated as will be detailed below.
[0040] The issue for downlink communication, i.e. , from oaAP 10 to non-AP MLD 60, is that a data packet being transmitted via the AP not holding the context (AP2 30 in Fig. 5), may suffer a delay due to backhaul transmission, which may cause the AP holding the context (AP1 20 in Fig. 5) to transmit earlier although the other AP (AP2 30 in Fig. 5) was supposed to transmit data units earlier. This is an issue for any number associated to a data unit such as SN or PN, because of the following: The receiver may drop the data unit, because the PN of a later transmitted packet by AP2 30 is lower than expected because AP1 20 transmitted a higher PN earlier. This is because the non-AP MLD 60 detects those data packets erroneously as being transmitted by a man-in-the-middle attacker. Further, the receiver may not be able to forward data units to higher layers, because the SN of an earlier transmitted packet (by AP1 20) is higher than what has been received before. This is because the non-AP MLD 60 must keep the order of the packets when forwarding to higher layers. Furthermore, when AP2 30 performs a transmission, a context update for AP1 20 is needed. For example, AP2 30 needs to indicate to AP1 20 which of the transmitted data units have been acknowledged by the peer non-AP MLD 60 as correctly or erroneously received.
[0041] To solve this issue, it is proposed in an embodiment of the present disclosure to have no more than one link active at a time. Thus, if the oaAP 10 decides to transmit on link 1, link 2 is blocked for communication with the same STA and vice versa. In case of an AP being an AP MLD, multiple links may be active if the links belong to the same AP MLD, i.e., APs are residing in one device. [0042] Fig. 14 shows a schematic diagram of a downlink transmission via AP1 and link 1. It illustrates the blocking behavior for link 2 when the lower AP1 unit 22 transmits data packets. In this case, the upper AP1 unit 21 avoids transmitting any data via backhaul to AP2 30 by setting the switch 23 to AP1 20 unless AP1 20 finished the transmission and the lower AP1 unit 22 provided a context update and switch release.
[0043] Fig. 15 shows a schematic diagram of a downlink transmission via AP1 and link 1 for multiple MPDlls. It illustrates the implication of the switch 23 of the upper AP unit 1 being switched to lower AP1 unit 22. As soon as data packets arrive at oaAP 10, it forwards those to the upper AP1 unit 21 which forwards them to lower AP1 unit 22 to include them in an upcoming transmission or to perform another channel access and frame exchange with the non-AP MLD 60 via link 1.
[0044] Fig. 16 shows an embodiment of downlink transmission via AP1 20 and AP2 30 with delayed transmission by AP2 30. The upper AP1 unit 21 may transmit data via backhaul to AP2 30 but instruct AP2 30 to wait for a trigger by AP1 20 via the backhaul before contending for channel access and transmission.
[0045] Fig. 17 shows an embodiment of downlink transmission via AP2 30 that illustrates the blocking behavior for link 1 when the lower AP2 unit 32 should transmit data packets. In this case, the upper AP1 unit 21 shall not forward any packets to the lower AP1 unit 22 once it started to transmit data packets for transmission to AP2 30. The upper AP1 unit 21 may forward packets to the lower AP1 unit 22, once AP2 30 informed AP1 20 about context update (e.g. BAck scoreboard) and confirmed the end of the transmission. Alternatively, similar to the embodiment shown in Fig. 16 and if the lower AP1 unit 22 has a buffer or memory functionality, the upper AP1 unit 21 may in the meantime forward data units to the lower AP1 unit 22, but the upper AP1 unit 21 shall not instruct the lower AP1 unit 22 to transmit before the switch 23 release and context update have been provided by AP2 30. Since this forwarding is not going over the backhaul but via an internal link, benefits are limited. [0046] The switch 23 may operate traffic identifier (TID) specific, meaning that MSDlls targeted for the same STA or non-AP MLD may be further differentiated by their traffic identifier or priority type. The context is designed such that it is TID independent. Therefore, an upper AP unit can generate encrypted MPDll(s) for two or more TIDs and forward them to AP1 20 and AP2 30 simultaneously as illustrated in Fig. 18 showing downlink transmission of several APs separated by TID.
[0047] After an AP finished transmission, it indicates the context update to the AP holding the context and informs the oaAP or the AP holding the context about the release of the fixed switch 23 setting.
[0048] The context update may include at least the reception status of the transmitted MPDlls, i.e., which of the transmitted MPDlls (after one or more attempt) have been acknowledged from the peer non-AP MLD. Furthermore, any other information provided by the peer non-AP MLD that refers to the context (update of negotiated agreements, e.g. BAck agreement) may be forwarded to the AP holding the context or to the oaAP. Depending on the implementation, if the upper AP1 unit 21 does not have a buffer functionality to store the forwarded data units to AP2 30, the context update by AP2 30 may also include non- successfully transmitted encrypted MPDUs. Those MPDUs are then propagated back to AP1 20 for later transmission, e.g., via a different link.
[0049] Generally, the uplink can be implemented by downlink functionality. In this case and as illustrated in Fig. 19 showing an embodiment of triggered uplink via downlink functionality, an AP may transmit a trigger frame to solicit uplink data packets from the non-AP MLD to be transmitted a short interframe spacing (SIFS) after the trigger frame. Nonetheless, it is desired to have a mechanism for a non-AP MLD to access the channel directly, i.e., without a trigger frame being transmitted by an AP, for example, if urgent data is to be transmitted.
[0050] In uplink, a non-AP MLD shall not use more than one link at a time belonging to distant APs. If more than one link at a time were used, it may happen that duplicated MPDUs are forwarded to higher layer and/or that MPDlls are discarded because of their PN not being increasing.
[0051] Fig. 20 shows an embodiment of uplink transmission to AP1 over link 1 . Initially, switch 23 is switched to both lower AP units 22, 32 for receiving an “Rx notice” which indicates to the upper AP1 unit 21 to switch to lower AP1 unit 22 for data reception. The “Rx notice” may optionally be acknowledged by the upper AP1 unit 21 to the lower AP1 unit 22 and/or to AP2 30. Subsequently, the lower AP1 unit 22 forwards received encrypted MPDlls to the upper AP1 unit 21 for decoding. The upper AP1 unit 21 may forward related MSDll to the oaAP 10, which forwards them in turn to the higher layers. Once the frame exchange on link 1 ends, the lower AP1 unit 22 gives a context update and a “Rx notice end” to the upper AP1 unit 21. Once the upper AP1 unit 21 has updated all context, it may switch back switch 23 to both APs 20, 30 for receiving a new “Rx notice” and it may optionally acknowledge the “Rx notice end” to the lower AP1 unit 21 and/or to AP2 30. The context update may include encrypted MPDlls that have been received but could not have been forwarded to higher layer due to out-of-order delivery issues.
[0052] Fig. 21 shows an embodiment of uplink transmission with prevention of a frame exchange. While switch 23 is in position of the lower AP1 unit 21 , any request from AP2 30 is ignored by “Rx notice” being ignored by the upper AP1 or not acknowledged as shown in Fig. 21. In case the “Rx notice” or “Rx notice end” acknowledgement is implemented, AP2 30 readily knows if it can accept a frame exchange or not. AP2 30 may for example not respond to an initiation of a frame exchange by e.g. RTS-CTS or by not responding to an initial control frame or by transmitting a special control frame as shown conceptually shown in Fig. 22 showing another embodiment of uplink transmission. Since the non-AP MLD 60 is aware of the frame exchange on link 1 , it would naturally not try to initiate a frame exchange on link 2 for data that belongs to same TID (if this option is implemented) or for any TID (if the previous option is not implemented). However, when the backhaul provides a significant delay, it may happen that the non-AP MLD tries to establish another frame exchange although context is not updated for example. The RTS (ready-to-send) in the embodiment of Fig. 22 may need to carry TID information for AP2 30 to decide if it should respond or not (if this option is implemented). [0053] The embodiments shown in Figs. 20 and 21 assume that all MPDlls have been correctly and in order received. If this is not the case, a break in the stream of consecutively forwarded encrypted MPDll(s) may appear followed by a bunch of multiple encrypted MPDll(s) being forwarded simultaneously once an erroneous MPDll has been correctly received. The same is true for the MSDll forwarding, as those MSDlls are obtained from the encrypted MPDlls. This implies a received buffer at the lower AP units 22, 32, which may be alternatively implemented at upper AP1 unit 21. In the latter case, the lower AP units 22, 32 would forward any received encrypted MPDll and the upper AP1 unit 21 performs the buffering and reordering.
[0054] The AP holding the context (e.g. AP1 20 in Fig. 5) may perform duplicate detection, i.e. , may filter already received encrypted MPDlls and avoid decrypting these MPDUs and forwarding them to higher layers.
[0055] Similar to the embodiment shown in Fig. 18 for the downlink case, the switch 23 may be TID specific in another embodiment for the uplink case. Hence concurrent frame exchanges on both links with different TIDs are possible. In this context, the “Rx notice” may include a TID specification as well as the related Ack if implemented.
[0056] If the link of the AP not holding the context is excessively used, it makes sense to transfer the context to this AP to reduce or even avoid backhaul load. The context transfer is essential for the use case of seamless roaming.
[0057] Fig. 23 shows a diagram of the context transfer process in which the context is transferred from upper AP1 unit 21 to upper AP2 unit 31. The transfer is initiated at AP2 30, which requests at AP1 20 the transfer. Subsequently, AP1 20 prepares the context transfer by emptying the MSDUs contained in its transmitter queues. Essentially, this means that all stored MSDUs are transmitted, thereby it does not matter if lower AP1 or lower AP2 or both successively transmit those packets. This step is required to lower the amount of data being transferred via backhaul during context transfer. However, any remaining MSDUs in the transmitter or receiver queue can be also transferred during the context transfer. The receive queue of upper AP1 unit 21 may also contain received MPDUs that cannot be forwarded due to out-of-order delivery issue, e.g., because an MPDll with low sequence number was erroneous. Therefore, the mechanism shown in Fig. 24 showing a diagram of an embodiment of emptying transmit and receiver queue of AP1 20 before context transfer may be used. According to this process the upper AP1 unit 21 can request MPDlls with particular SN being transmitted subsequently by the non-AP MLD 60.
[0058] As shown in Fig. 23, once AP1 20 is prepared for context handover, it informs oaAP 10 to move switch 13 to open such that no new MSDlls arrive at AP1 20. After an optional Ack, the context transfer can start which in turn can be acknowledged again by AP2 30. After successful context transfer, AP1 20 instructs the oaAP 10 to move switch 13 to AP2 30, which can be followed by an optional Ack of oaAP 10.
[0059] While the switch 13 is in open position, the oaAP 10 may buffer incoming MSDlls and forward them to the respective upper AP unit once the switch 13 has switched. During the context transfer or during the time while switch 13 is in open position, nothing should be received. Otherwise, it may be discarded. In such cases, APs may not respond as shown in 22, or alternatively, the SN request frame shown in Fig. 24 can indicate a context transfer delay to the non-AP MLD 60 during which time it should not attempt a TXOP initiation with either of the APs. The context can also be transferred step-by-step, e.g., per TID and depending on queue status. In such a case switch 13 operates TID specific.
[0060] The above operations in both downlink and uplink can be implemented with EMLSR operation, because in EMLSR operation the data exchange happens in one link only. In this operation mode, a STA or AP features a radio which supports two modes: Full operation mode (also called data transfer mode herein) in which all PHY resources are focused to a single link and partial operation mode (also called listening mode herein) in which PHY resources are split among at least two links. The partial operation mode has reduced transmit and/or receive capabilities (supported modulation coding schemes, number of spatial streams, supported MAC frames) compared to the full operation mode. Furthermore, a delay may occur when switching between both modes and different delays may apply for switching from partial to full operation mode or vice versa. [0061] Fig. 25 shows a diagram of an embodiment of the operation with EMLSR in downlink. The “contention and frame exchange” block in, e.g., Fig. 14, is disclosed here in more detail. The lower AP1 unit 22 starts EMLSR operation by transmitting an initial EMLSR control frame to STA1 40 of the non-AP MLD 60. Upon detecting this frame, the non-AP MLD 60, initially in partial mode on link 1 and link 2, switches to full operation mode on link 1 and turns off link 2. When full operation mode is active, the frame exchange takes place, and after it is finalized, both links transition to partial mode again.
[0062] Fig. 26 shows a flow chart of an embodiment of a first communication method 300 of a primary AP (e.g. the oaAP 10). In a first step 301 , the primary AP connects (switches) to the upper AP unit of a first secondary AP (e.g. AP1 20) of the two or more secondary AP (e.g. AP1 20 and AP2 30) that holds context information configured for use by the upper AP unit of said first secondary AP to communicate with a communication device (e.g. STA1 40 and/or STA2 50). In a second step 302, the primary AP forwards one or more data units to be transmitted to said upper AP unit to which it has been connected (switched) and/or receive one or more data units from said upper AP unit to which it has been connected (switched).
[0063] Fig. 27 shows a flow chart of an embodiment of a second communication method 400 of a secondary AP (e.g. AP1 20 or AP2 30). In a first step 401 , the secondary AP holds context information in its upper AP unit configured for use by said secondary AP to communicate with a communication device (e.g. STA1 40 and/or STA2 50). In a second step 402, the secondary AP switches (connects) to its lower AP unit and/or the lower AP unit of another secondary AP (i.e., a secondary AP that does not hold the context). In a third step 403, the secondary AP receives one or more data units to be transmitted from the primary AP, processes the received one or more data units in its upper AP unit, and forwards the processed one or more data units according to the switching to either its lower AP unit or the lower AP unit of the other secondary AP and/or receives one or more data units according to the switching from either its lower AP unit or the lower AP unit of the other secondary AP, processes the received one or more data units in its upper AP unit, and forwards the processed one or more data units to the primary AP. [0064] In summary, the present disclosure presents an architecture of multiple distant (physically separated) APs being interconnected to serve a communication device (STA or non-AP multi-link device (MLD)) via multiple links seamlessly. Context synchronization among APs and solutions for downlink (AP to STA) as well as for uplink (STA to AP) connectivity are discussed. Furthermore, it is described how the context at one AP can be handed over to another AP which is important for the application of seamless roaming between APs. Moreover, setup and termination of links to distant APs are addressed as well as the suitability of ELSMR operation in the considered context.
[0065] The device may be implemented by respective units or circuitry, e.g. a processor, processing circuitry, a computer, dedicated hardware, etc., that carries out the functions of the device. Alternatively, a common unit or circuitry, e.g. a common processor or computer, may implement the various functions of the device, or separate units or elements may be used that together represent the circuitry.
[0066] Thus, the foregoing discussion discloses and describes merely exemplary embodiments of the present disclosure. As will be understood by those skilled in the art, the present disclosure may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present disclosure is intended to be illustrative, but not limiting of the scope of the disclosure, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive subject matter is dedicated to the public.
[0067] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
[0068] In so far as embodiments of the disclosure have been described as being implemented, at least in part, by software-controlled data processing apparatus, it will be appreciated that a non-transitory machine-readable medium carrying such software, such as an optical disk, a magnetic disk, semiconductor memory or the like, is also considered to represent an embodiment of the present disclosure. Further, such a software may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.
[0069] The elements of the disclosed devices, apparatus and systems may be implemented by corresponding hardware and/or software elements, for instance appropriate circuits or circuitry. A circuit is a structural assemblage of electronic components including conventional circuit elements, integrated circuits including application specific integrated circuits, standard integrated circuits, application specific standard products, and field programmable gate arrays. Further, a circuit includes central processing units, graphics processing units, and microprocessors which are programmed or configured according to software code. A circuit does not include pure software, although a circuit includes the above-described hardware executing software. A circuit or circuitry may be implemented by a single device or unit or multiple devices or units, or chipset(s), or processor(s).
[0070] It follows a list of further embodiments of the disclosed subject matter:
1. Primary access point, AP, configured to be connected to two or more secondary, physically separated, interconnected APs, each being configured to communicate with one or more communication devices via separate links and each comprising an upper AP unit and a lower AP unit providing different functionalities for the communication, the primary AP comprising circuitry configured to: connect to the upper AP unit of a first secondary AP of the two or more secondary AP that holds context information configured for use by the upper AP unit of said first secondary AP to communicate with a communication device; and forward one or more data units to be transmitted to said upper AP unit to which it has been connected and/or receive one or more data units from said upper AP unit to which it has been connected.
2. Primary AP according to embodiment 1 , wherein the circuitry is configured to determine which of the two or more secondary APs holds the context information and/or to which of the two or more secondary APs to connect by evaluating a device identifier and/or a traffic identifier within a transmitted or received data unit.
3. Primary AP according to embodiment 1 or 2, wherein the circuitry is configured to communicate at a time with only a single secondary AP of the secondary APs serving the same communication device.
4. Primary AP according to any preceding embodiment, wherein the circuitry is configured to transmit, if the primary AP desires to connect to two or more secondary APs and/or disconnect from one or more secondary APs, an instruction to a secondary AP to transmit a link reconfiguration message to the one or more communication devices and/or other secondary APs indicating to them the desired configuration of the links between the secondary APs and the one or more communication devices and/or the desired disconnection.
5. Primary AP according to any preceding embodiment, wherein the circuitry is configured to switch to none of the upper AP units in response to a context handover start instruction from the first secondary AP; and/or switch to the upper AP unit of a second secondary AP in response to a handover end instruction from the first secondary AP.
6. Secondary access point, AP, configured to be connected to a primary AP that is configured to be connected to two or more secondary, physically separated, interconnected APs, the secondary AP being configured to communicate with one or more communication devices via separate links and comprising an upper AP unit and a lower AP unit providing different functionalities for the communication, the secondary AP comprising circuitry configured to: hold context information in its upper AP unit configured for use by said secondary AP to communicate with a communication device; switch to its lower AP unit and/or the lower AP unit of another secondary AP; receive one or more data units to be transmitted from the primary AP, process the received one or more data units in its upper AP unit, and forward the processed one or more data units according to the switching to either its lower AP unit or the lower AP unit of the other secondary AP and/or receive one or more data units according to the switching from either its lower AP unit or the lower AP unit of the other secondary AP, process the received one or more data units in its upper AP unit, and forward the processed one or more data units to the primary AP.
7. Secondary AP according to embodiment 6, wherein the circuitry is configured to forward the one or more data units to the lower AP unit of the other secondary AP and/or receive the one or more data units from the lower AP unit of the other secondary AP via a backhaul link between the secondary AP and the other secondary AP, in particular via one or more of a wireless backhaul link, a wired backhaul link, a direct backhaul link between a switching unit of the secondary AP and a switching unit of the other secondary AP, or an indirect backhaul link from the secondary AP through the primary AP and/or a distribution system to the other secondary AP.
8. Secondary AP according to embodiment 6 or 7, wherein the circuitry is configured to switch to the lower AP unit of another secondary AP if the link between its own lower AP unit and the communication device communicating with the secondary AP is busy and/or has insufficient throughput and/or has insufficient latency and/or has insufficient quality and to switch to its own lower AP unit if the link between the lower AP unit of the other secondary AP and the communication device communicating with the other secondary AP is busy and/or has insufficient throughput and/or has insufficient latency and/or has insufficient quality.
9. Secondary AP according to any one of embodiments 6 to 8, wherein only one of the secondary APs serving the same communication device holds the context information required to communicate with said communication device.
10. Secondary AP according to any one of embodiments 6 to 9, wherein the circuitry is configured to provide a context information update to its upper AP unit once the data transfer via its lower AP unit ended and/or to provide a context information update to the upper AP unit of the other secondary AP once the data transfer via its lower AP unit ended, the context information update including at least a scoreboard update of the data units that the lower AP unit received for transmission.
11. Secondary AP according to any one of embodiments 6 to 10, wherein the circuitry is configured to release the switching from the secondary AP once the data transfer via its lower AP unit ended.
12. Secondary AP according to any one of embodiments 6 to 11 , wherein the circuity is configured to keep the switching unchanged once a data unit has been forwarded to a lower AP unit and until a release indication has been received from the secondary AP to which it has been switched.
13. Secondary AP according to any one of embodiments 6 to 12, wherein the circuitry is configured to hand over the context information to the other secondary AP in response to a handover request from the other secondary AP and/or in response to a request from the primary AP and/or the communication device.
14. Secondary AP according to any one of embodiments 6 to 13, wherein the context information comprises one or more of: encryption information for encrypting and/or decrypting data units; packet numbers for labeling encrypted data units sequence numbers for indexing data units; capability information of the secondary AP and the communication device; one or more communication parameters; negotiated agreements between secondary AP and communication device; and transmit buffer and/or receive buffer and/or scoreboard contents.
15. Secondary AP according to any one of embodiments 6 to 14, wherein the circuitry is configured to store one or more data units received from the other secondary AP for transmission via its lower AP unit until its lower AP unit is able to transmit said one or more data units. 16. Secondary AP according to any one of embodiments 6 to 15, wherein the circuitry is configured to forward one or more data units to the lower AP unit of the other secondary AP with the instruction to wait for a trigger before transmitting the one or more data units to a communication device; and/or trigger the other secondary AP to transmit the one or more data units to the communication device once the secondary AP has switched to the lower AP unit of the other secondary AP; and/or switch to its lower AP unit or the lower AP unit of the other secondary AP dependent on priority of a data unit.
17. Secondary AP according to any one of embodiments 6 to 16, wherein the context information for a communication device can be split among multiple secondary APs if the context information for a traffic identifier is unique among the multiple secondary APs.
18. Secondary AP according to any one of embodiments 6 to 17, wherein the circuitry is configured to initially switch to its lower AP unit and the lower AP unit of the other secondary AP and listen to a reception start notice from one of them indicating that one or more data units are received and shall be forwarded to the upper AP unit of the secondary AP; switch to the lower AP unit from which a reception start notice has been received; and switch back to its lower AP unit and the lower AP unit of the other secondary AP upon receipt of a reception end notice from the lower AP unit from which a reception start notice had been received, the reception end notice indicating that reception of data units has ended.
19. Secondary AP according to any one of embodiments 6 to 18, wherein the circuitry is configured to transmit a handover start instruction to the primary AP to switch to none secondary AP; hand over the context information to the upper AP unit of the other secondary AP; and transmit a handover end instruction to the primary AP instructing it to switch to the upper AP unit of the other secondary AP.
20. Secondary AP according to any one of embodiments 6 to 19, wherein the circuity is configured, before the context information is handed over to the other secondary AP, to transmit remaining data units in its transmit buffer to the communication device, and/or solicit previously erroneously received data units to be retransmitted from the communication device.
21 . Secondary AP according to any one of embodiments 6 to 20, wherein the circuity is configured not to participate in a frame exchange while the switch is switched to the other secondary AP as a result of receiving a reception start notice.
22. Secondary AP according to any one of embodiments 6 to 21 , wherein the circuitry is configured to transmit an initiation frame to the communication device via its lower AP unit to initiate a data transfer with the communication device, the initiation frame causing the communication device to transition from a listening mode to a data transfer mode on the link served by its lower AP unit.
23. First communication method of a primary access point, AP, configured to be connected to two or more secondary, physically separated, interconnected APs, each being configured to communicate with one or more communication devices via separate links and each comprising an upper AP unit and a lower AP unit providing different functionalities for the communication, the first communication method comprising: connecting to the upper AP unit of a first secondary AP of the two or more secondary AP that holds context information configured for use by the upper AP unit of said first secondary AP to communicate with a communication device; and forwarding one or more data units to be transmitted to said upper AP unit to which it has been connected and/or receive one or more data units from said upper AP unit to which it has been connected.
24. Second communication method of a secondary access point, AP, configured to be connected to a primary AP that is configured to be connected to two or more secondary, physically separated, interconnected APs, the secondary AP being configured to communicate with one or more communication devices via separate links and comprising an upper AP unit and a lower AP unit providing different functionalities for the communication, the second communication method comprising: holding context information in its upper AP unit configured for use by said secondary AP to communicate with a communication device; switching to its lower AP unit and/or the lower AP unit of another secondary AP; receiving one or more data units to be transmitted from the primary AP, processing the received one or more data units in its upper AP unit, and forwarding the processed one or more data units according to the switching to either its lower AP unit or the lower AP unit of the other secondary AP and/or receiving one or more data units according to the switching from either its lower AP unit or the lower AP unit of the other secondary AP, processing the received one or more data units in its upper AP unit, and forwarding the processed one or more data units to the primary AP.
25. A non-transitory computer-readable recording medium that stores therein a computer program product, which, when executed by a processor, causes the method according to embodiment 23 or 24 to be performed.
26. A computer program comprising program code means for causing a computer to perform the steps of said method according to embodiment 23 or 24 when said computer program is carried out on a computer.