Embodiments described herein relate generally to apparatus and methods for simultaneous transmit and receive in networks and preferably to simultaneous transmit and receive in IEEE 802.11 networks in full-duplex/half-duplex co-existence scenarios.
Due to recent advances in analogue and digital self-interference cancellation techniques, full-duplex (FD) radios, that can simultaneously transmit and receive, can be practically realised. The FD transceiver differs from its half-duplex (HD) counterpart in that, it uses self-interference cancellation methods to eliminate the interference from the signal it sends, so as to be able to successfully receive simultaneously. The self-interference cancellation technique, however, cannot mitigate interference from other RF sources.
In the following, embodiments will be described with reference to the drawings in which:
According to an embodiment there is provided a method of scheduling data transmission in a communication system. The method comprises receiving at a first network node a request for data transmission to the first network node and scheduling a data transmission originating at first network node so that the end of the data transmission substantially coincides with or is earlier than the expected end of the data transmission to first network node. The first network node is an access point or a station.
In an embodiment the data associated with the requested transmission is received and the data scheduled for transmission is transmitted from the first network node.
The received request may comprise an indication of the time required for completing the requested data transmission.
A data size or MCS or a delay to the start of the data transmission originating from the first network node may be chosen by the first network node so that the ends of the two data transmissions substantially coincide or so that the scheduled data transmission finishes before the data transmission requested to be transmitted to the first network node.
An acknowledgement may be received at the first network node after the end of the data transmissions and an acknowledgement may be transmitted from the first network node after the end of the data transmission.
If the first network node is an access point and the request for a data transmission to the first network node originated at a first STA the scheduled data transmission may be for the first SAT or for a second, different STA.
The second, different STA may be hidden from the first STA.
If the first network node is not an AP, that is if the data exchange has been initiated by and STA, the AP may decide whether BFD or UFD transmission or a simple receipt of data from the requesting STA is to take place.
The control of data transmission can be done dynamically on a frame by frame basis, depending only on the data transmission needs at a given moment.
The method may further comprise determining the end of an acknowledgement timeout period for the data transmitted from the AP on the basis of the expected duration of the data received or to be received at the AP.
Scheduling a data transmission may further comprise determining whether or not a request for data for transmission to another network node has been generated or received at the first network node.
Scheduling a data transmission may comprise scheduling a data transmission to a network node other than the network node from which the request for data transmission has been received. The other network node may be selected on the basis of neighbourhood information available to the first network node so that the selected network node and the network node from which the request for data transmission has been received are partially or fully hidden from each other.
The method may further comprise transmitting data according to the scheduled data transmission and transmitting an indicator identifying that the data transmission is a BFD or UFD data transmission. This puts nodes not participating in the data transmission on notice to allow them to remain quiescent during the data exchange.
According to another embodiment there is provided a method of capability discovery in a wireless network comprising FD capable nodes within the network advertising FD capability to other nodes by setting a flag or capability bit indicative of FD capability in a beacon. RTS control message, PLCP and/or MAC header.
The flag or capability bit may be set in a part of the beacon, RTS control message, PLCP and/or MAC header that is not accessed by network nodes that are not FD capable. This ensures backward compatibility
BFD/UFD data transmissions may be scheduled by an access point on the basis of discovered FD abilities of nodes in the network. The AP may comprise a memory in which data identifying discovered FD abilities are stored.
If the PLCP header is used for the transmission of the flag or capability bit no central control or extra RTS/CTS messages are needed. Reserved bits used in the header may represent the status of the frame and of the node.
The indicator may indicate that the transmission from the first network node is a secondary transmission from a FD AP in a BFD transmission, a secondary transmission from a FD AP in a UFD transmission, a primary transmission originating from a FD AP in a potential FD communication or that the AP wants to initiate a hidden node information collection procedure.
According to another embodiment there is provided a device configured to execute computer program instructions, the computer program instruction such as to configure the device to schedule data transmission in a communication system comprising a FD access point and one or more STAs by receiving at the device a request for data transmission to the device and scheduling a data transmission originating the device so that the end of the data transmission substantially coincides with or is earlier than the expected end of the data transmission to device. Wherein the device is the access point or an STA of the one or more STAs.
According to another embodiment there is provided a FD capable AP configured to discover node capability in a wireless network comprising FD capable nodes by advertising FD capability to other nodes by setting a flag or capability bit indicative of FD capability in a beacon, RTS control message, PLCP and/or MAC header.
According to another embodiment there is provided a FD capable AP configured to support BFD or UFD transmission in a network comprising FD and HD network nodes, the AP configured to generate different headers for indicating type and target of the transmission to the nodes in the network depending on whether the header is to be used in communication with a HD or FD node.
According to another embodiment there is provided a system comprising an FD AP and HD and/or FD capable nodes, wherein the FD AP and/or one or more of the FD capable nodes is a device as described above or wherein the FD AP is a FD AP as described above.
According to another embodiment there is provided a computer program product storing computer executable code configured to, when executed by a processor, cause a device comprising the processor to implement any of the methods described above.
Conventionally, wireless networks have been built on half-duplex (HD) radios which cannot transmit and receive simultaneously due to self-interference, that is interference generated by the transmitted signal on the received signal. Due to recent advances in self-Interference cancellation, full-duplex (FD) radios, that can simultaneously transmit and receive, can be practically realised. To realise simultaneous transmit and receive (STR) mode in IEEE 802.11 networks, two distinct types of wireless links can be created: a) Bi-directional Full-Duplex (BFD) link in which a pair of FD-capable access point (AP) and station (STA) can simultaneously transmit/receive to/from each other, (b) Uni-directional Full-Duplex (UFD) in which the AP can simultaneously transmit to a Full-Duplex/Half-Duplex (HD) STA (i.e. a STA that cannot transmit and receive simultaneously) while receiving from another FD/HD STA. Both these types of links are illustrated in
Enabling STR mode in 802.11 networks creates a number of challenges. FD nodes (APs and STAs) should be able to co-exist with the legacy HD nodes with minimal protocol modifications. FD APs and STAs should be able to discover the FD capabilities while co-existing with the legacy HD nodes. Further, BFD and UFD transmissions should be enabled without modifications to the legacy channel access mechanisms. The unique characteristics of UFD transmission enable two HD nodes to simultaneously transmit/receive to/from the AP. However, not all the nodes within the coverage of the AP can be part of the UFD transmission as nodes that are not hidden from each other are likely to interfere. The proposed invention facilitates coexistence of FD and HD STAs associated to an FD or a legacy (HO) access point.
In legacy 802.11 networks (HD communications), nodes expect an acknowledgement (ACK) after sending a data packet. However, in case of BFD transmission, since the data packets are sent by both nodes simultaneously, it is possible that a node is still busy sending data packages after successful receipt of an incoming data package and cannot consequently send an acknowledgement in a timely fashion. This can lead to ACK timeout. This issue can become particularly challenging for UFD transmission.
Embodiments enable the co-existence of FD and HD STAs, and therefore has some key structural differences from the legacy approach, which are described as follows.
In some but not in all embodiments any FD communication must be preceded by an RTS from the initiating node. Moreover, any FD/HD STA is capable of receiving when the NAV is set.
The following embodiments are described in the context of a single-cell multi-user 802.11 network scenario in which both FD and HD STAs co-exist. Initially, nodes in the network are able to discover the FD capabilities. To facilitate this in the embodiment the AP periodically advertise its FD capability in the beacon frame. STAs in the network learn from the beacon transmission if the AP is FD capable or not. In an embodiment the FD capability of the AP is advertised within the ‘capability information’ field (illustrated in
In an embodiment a FD STA in the network informs the AP of its FD capabilities when sending the association request frame. In the embodiment the FD capability is advertised through a 1 bit change in any of the reserved bits of the 2 byte capability information field within the association request frame.
STA-Initiated Communication Scenario
After discovering the FD capabilities, any FD capable node can engage in a BFD or UFD transmission with the AP. However, not all the STAs in the network can potentially become part of a UFD transmission. In the embodiment it is preferred that the two STAs simultaneously served by the AP are substantially out of the interference range of each other.
In one embodiment the AP learns which nodes are eligible to become part of the UFD transmission through a simple procedure during the network initialization phase. In this procedure neighbourhood information is exchanged between STAs and APs. During the network initialization phase, the AP sends a message (e.g. a RTS) to each STA in turn as shown in
Nodes will at some point engage in an RTS-CTS exchange with the AP in those embodiments that use RTS-CTS messages. In an alternative method all other nodes that can hear a CTS but not an RTS record the destination address in the CTS message and store this. Using the bitmap which the AP maintains and makes available to all STAs in the cell e.g. via beacons or some other messages, the STAs stores the bitmap corresponding to the stored destination id. This enables each STA to report the hidden STA bitmap via a dedicated signalling/data frame or by piggybacking this information on existing messages that it sends to the AP. Once the AP receives this information, it has a list of hidden STAs corresponding to each STA in the cell.
In a yet further method each STA can overhear transmissions on the medium and record the source Id of each such Tx that it can decode. The STA stores the bitmap corresponding to all of the STAs that it can hear and report this to the AP in a similar manner as that described in the preceding paragraph. The AP can then identify a list of hidden STAs of this STA by identifying the ones from its associated STAs list that do not overlap with the list reported by the STA.
In the following the procedure for legacy HD, BFD, and UFD transmissions in case of FD/HD co-existence scenario is detailed. Reference is made to the scenario illustrated in
Case 1: Both STA 1 and AP are HD capable. In this case the legacy procedure (shown in
Case 2: STA 1 is FD capable and AP is HD capable. The legacy procedure is followed in this case as well, as the AP cannot engage in FD data exchange.
Case 3: STA 1 is HD capable and AP is FD capable. In this case there are two possibilities: (i) STA1 and AP engage in a HD transmission using the legacy procedure, and (ii) the AP establishes a UFD transmission with STA 1 and another (eligible) STA.
Case 4: Both STA 1 and AP are FD capable. In this case, there are three possibilities: (i) Both STA 1 and AP can engage in a BFD transmission, (ii) a UFD transmission involving STA 1 and AP an another eligible STA, or (iii) STA 1 and AP can engage in the legacy HD transmission (this can happen if AP does not have data to send to STA1 or other STAs to which AP could transmit whilst receiving data from STA1).
In the following some of the fields in RTS and CTS control messages are discussed. The RTS and CTS (and ACK) messages contain a ‘Duration ID’ field (henceforth referred to as the ‘duration’ field). This field specifies the total transmission time required for the frame that is to be sent. The STAs receiving RTS read the duration field and set their NAV, which is an indicator for the STA on how long it must defer from accessing the medium. For example, the duration field in the RTS message is set to the time needed to transmit data, CTS, and ACK messages with explicitly accounting for the SIFS duration.
The CTS-FD control message employed in a preferred embodiment differs from the legacy control message by 1 bit i.e., any reserved bit in the Frame Control (FC) field, which precedes the duration field, of CTS-FD message is set to 1. Legacy FC field contains two distinct fields: a 2-bit ‘Type’ field and a 4-bit ‘Sub-type’ field. Currently, Type values of ‘00’, ‘01’, and ‘10’ indicate management, control, and data frames, respectively. However, Type value of ‘11’ is reserved. Further, 9 Sub-type values from 0000 to 1001 for the control frame (Type value of 01) are reserved. Therefore, the CTS-FD control message is completely backward compatible with legacy HD STAs and its practical realization is not a challenge.
BFD Transmission
Consider that at time to STA 1 sends a RTS message to the AP as shown in
If the AP has data to send to STA 1, it responds with a CTS-FD message after waiting for SIFS duration. The CTS-FD sent by the AP has the reserved bit of FC field set to 1 to indicate that a FD exchange is started and differs in this respect from a legacy CTS message. The CTS-FD message also includes the destination address of STA 1 to indicate that the FD exchange is a BFD exchange with STA1. The CTS-FD therefore informs STA 1 of a possible BFD transmission.
After waiting for a SIFS duration, STA 1 starts data transmission (at time point t3). Similarly, after sending the CTS-FD message, the AP waits for SIFS duration and sends a data message (with the destination address of STA 1). Therefore, a BFD transmission occurs between STA 1 and the AP. The ACK procedure will be described later. As discussed later, the data transmission from AP to STA 1 needs to end before or at time t4. Time t4 is known to the AP as the RTS message includes information (in the form of duration D0) regarding the time the data transmission requested by STA1 is expected to take. D0 covers the entire time span from t1 to t5, so that D0=3*SIFS+T_CTS+T_Data+T_Ack, T_Data is the time period between t3 and t4 and T_ACK is the time between t4+SIFS and t5. t4 can therefore be calculated as t4=D0−(SIFS+T_Ack).
As can be seen from
Given that STA1 may expect an ACK from the AP shortly after t4, the AP proceeds by selecting one or more of the payload, the MCS (modulation and coding scheme) and the time at which the data transmission is started to ensure that its data transmission to STA1 is completed before or at t4. Once both data transmissions have been completed at time t4 STA1 and the AP are both free to send ACK messages and, in doing so, avoid an ACK time out that, by the legacy protocol is set to occur at time point t4+SIFS+ACKtransmission.
UFD Transmission
At time to STA1 sends an RTS message to the AP, as shown in
Since the CTS-FD message contains destination address of STA1, STA1 starts transmitting data at time t3. Based on D0 and D1, the AP knows when the data transmission from STA1 will end, namely at time point t4. Since STA3 is eligible to take part in the UFD transmission and the AP has data to send to STA3, the AP sends a data message to STA3 at or after time t3.
The neighbouring STAs follow their NAV and remain quiescent after finding out that the data is intended for STA3. Therefore, a UFD transmission is successfully established by the AP. Since STA3 can be a legacy HD node, it is particularly important that the data transmission from AP to STA3 ends at time t4. If the transmission ended before t4 then STA3 may also send ACK before t4, that is whilst the AP is unable to receive the ACK as it is still receives data from STA1. Therefore, the AP is configured to select a packet whose transmission time is less than or equal to t4−(t2+SIFS) such that the chosen MCS can deliver the packet, subject to the aforementioned time constraint. The AP is configured to select the start time of transmission (ts) to STA3 so that, dictated by the payload size and the MCS, data transmission ends at t4. Let, test denote the data transmission time from the AP to STA3, which is the function of payload and MCS. If test=t4−(t2+SIFS) then ts=t2+SIFS. On the other hand, if test<t4−(t2+SIFS) then ts=t4−test.
It will be appreciated that the AP does not need to adjust the start time of transmission for BFD transmission. This is because STA 1 (
The ACK timeout setting procedure and the constraint on the AP for suitably selecting the payload and MCS are discussed with reference to the UFD transmission scenario shown in
Therefore, the minimum ACK timeout for STA 1 and AP is equal to t5, which is the sum of t4, SIFS, and the transmission time for ACK. By setting the ACK time out to t5, the AP does not need to unnecessarily re-transmit if the second transmission finishes before the first transmission. The AP is configured to select the payload and the MCS so that the second transmission finishes before the first transmission.
The ACK timeout setting mechanism of the embodiment (with both STA 1 and AP set the ACK timeout to t5) is equally applicable in case of BFD transmission. The AP is configured to select the payload and the MCS such that the second transmission (from AP to STA 1) finishes before or simultaneously with the first transmission (STA 1 to AP).
The embodiments cover, amongst other scenarios, the following cases with respect to UFD transmission:
In one embodiment, the AP is configured to, if more than two STAs are eligible to take part in the UFD transmission, selects the one with best channel or some other metric (to ensure fairness etc.). One way of making this selection is for the AP to maintain statistics indicating how reliably an STA had during previous data transmissions provided acknowledgement of data receipt and to preferentially select STAs indicated in thus maintained statistics as being more reliable over STA indicated in thus maintained statistics as being less reliable.
AP-Initiated Communication Scenario
The following discussion is based on the scenario shown in
It will be appreciated that the UFD transmission scenario is not feasible in case of AP-initiated communication scenario (whether the AP sends and RTS or not).
CTS-FD Vs CTS Control Message
It is worth pointing out that the proposed protocol to enable STR mode can work with both RTS/CTS-FD handshake and legacy RTS/CTS handshake. The former is a 1-bit modification to the legacy CTS, as described earlier. However, the CTS-FD plays a critical role in mitigating the contention unfairness issue for overhearing nodes, which arises due to BFD and UFD transmissions.
As shown, STA 1 which is FD-capable is engaged in a BFD transmission with the AP. While this BFD transmission is going on, a nearby STA (STA 2) will receive erroneous/corrupted packets due to the interference arising from simultaneous reception of packets from STA 1 and AP. After the completion of BFD transmission, both AP and STA 1 will wait for DIFS duration before next contention. However, STA 2 will wait for EIFS duration before next contention, resulting in unfairness in channel access, since EIFS duration is larger than DIFS duration. In legacy 802.11 networks, EIFS is defined (for a STA to defer its channel access following the reception of corrupted packets) to allow extra time for the intended receiver (who may have received the data correctly) to return an ACK without interference. Contention unfairness issues affect both HD and FD STAs and is present in case of UFD transmission as well. To mitigate this issue FD-capable nodes are, in one embodiment, configured to, on receipt of CTS-FD control message, ignore any corrupted packets received during the NAV period.
In the following yet further embodiments will be described. To practically realise a network comprising of FD and HD capable devices, it is necessary for the communicating entities to exchange capability information. As mentioned earlier, even if the AP and some/all of STA devices are FD capable, it is essential to coordinate transmissions among the devices in the network to enable parallel simultaneous transmissions in such a way that this does not lead to interference among them.
To achieve this, the concept of different types of flags to indicate different modes of operation is introduced. The use of these flags is, again, completely backwards compatible, i.e., legacy devices ignore these fields in the packet header which are set to 0 by default. Before specific flags and the modes of operation they enable are discussed, it is worth examining how these flags could be potentially advertised so as to send appropriate signals to the entities involved in the communication. Following are several different ways in which this is achieved in embodiments. These embodiments are purely for the purpose of illustration and therefore are not meant to limit the scope of protection sought.
In one embodiment the reserved bits in the existing PLCP header is used to signal the flag. This is shown in
In another embodiment the current PLCP header is extended, as, for example, is shown in
In another embodiment the flag is signalled using the reserved bits in the MAC layer header. Similar to the PLCP approach, this is easy to implement and compatible with legacy nodes. Legacy nodes will set the reserved bits as all zeros. The rest of the nodes map the frame status into the flags described later.
If the AP is a legacy device that is only capable of HD communication, then communications between STAs (HD or FD capable) and the AP follows the legacy approach. Therefore the following discussion focuses only on scenarios where the AP is FD capable.
There are four basic FD flags indicating four categories of frames that may exist in a FD enabled wireless network. They are FDFlag0, FDFlag1, FDFlag2, and FDFlag4. To support additional functions such as uni-directional FD, identifying hidden nodes for each node for selection during uni-directional FD, three more flags, FDFlag3, FDFlag5 and FDFlag6, are used in embodiments.
Table 2 highlights the preconditions and objectives associated with the different flags employed in the proposed method to enable FD communications. As evident from the discussion so far, both BFD and UFD can be initiated from either an FD capable AP or STA with the AP being responsible for this decision. However, in embodiments FD transmissions are constrained by the need for the secondary transmission to finish at the same time as the primary/first initiated transmission. In some cases where this may not be possible (e.g. when the secondary transmission is shorter than the primary transmission), transmissions can be staggered, for example by delaying the secondary transmission, so as to enable it to complete at the same time as the primary transmission. When referring to completion of the transmissions at the same time reference is made to completion that is simultaneous to the extent that the above mentioned subsequent acknowledgement signals can be sent and received without triggering an acknowledgement timeout.
This ensures that legacy devices that are receiving the secondary transmission do not need to wait any longer than SIFS before they send an ACK. If the secondary transmission completes before the primary one, the legacy node might ACK immediately after waiting for SIFS and in the case where we want to the legacy terminal to wait until the primary transmission completes, a change will be required on the legacy terminal side. By enforcing that secondary transmissions to legacy devices complete at the same time as primary transmissions, full backwards compatibility with the legacy approach is ensured.
It is worth emphasising that the sequence of embodiments described above are in no particular order. The order of the flags and the way they are implemented can be changed as long as the basic function that each flag is supposed to facilitate is catered for without departing from the spirit of the invention.
It is moreover emphasised that the description of the adjustment of the acknowledgement time period in legacy STAs that is facilitated by the durations reported to the STAs from the AP provided above with reference to the embodiments using the RTS and CTS-FD message exchange also applies to the embodiments using the FDFlags.
This embodiments allow the nodes in a network that are FD capable to exploit opportunities for engaging in FD communications by, where possible, avoiding or at least minimising interference to other nodes in the network. This is achieved without requiring central control. If flags are used RTS/CTS do not have to be used. The embodiments are fully compatible with legacy nodes. The full duplex MAC protocol is realised as backwards compatible extension to the legacy protocol and is compatible with the BSS colouring method.
The first table in
Similarly, the 2nd table in
If the AP is aware of data that it wants to send then it checks in step 340 if the data is for the originally requesting STA and initiates BFD transmission in step 350 if this is the case. If the data is not to be sent to the originally requesting STA then the AP checks if the STA to which the data is to be sent is hidden from the originally requesting STA or at least partially hidden from the originally requesting STA to the extent that UFD transmission is possible. If this is not the case then the method advances to step 330. Otherwise UFD transmission is instigated in step 370.
For the BFD and the UFD transmissions that have alternatively been initiated the MCS, transmission starting point and/or (if possible following the choice of data to be sent) the data length is chosen so that the transmission from the AP to the selected STA finishes before or simultaneously with the transmission from the originally requesting STA to the AP in step 380 as described above and the thus configured data transmission then takes place in step 390.
It will be appreciated that, should it be determined that data to be sent to any particular STA is of a nature/length that does not allow the data transmission for the AP to the STA to be completed before the completion of the data transmission from the originally requesting STA to the AP then a different BFD or UFD data transmission may be made from the AP if such a different data transmission is required.
The above description relating to
If an AP initiates a data transfer to an STA then all STAs in the network are informed (via the indicators discussed herein) of the fact that, at the time of the initiating of the data transfer the AP does not expect to receive data itself. The STAs in the network therefore know that, up to this point, they are free to request data transfers to the AP.
Whilst certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel devices, and methods described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the devices, methods and products described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.
Number | Date | Country | Kind |
---|---|---|---|
1612342.4 | Jul 2016 | GB | national |