Borrowed Channel Relaying: A Novel Method to Improve Infrastructure Network Throughput
© A. Jow and C. Schurgers. 2009
Received: 30 April 2009
Accepted: 25 November 2009
Published: 10 January 2010
From a networking perspective, the chief impediment to throughput enhancement in infrastructure networks such as IEEE802.11 is the access point bottleneck: all traffic to, through, and from the network has to pass through this access point. When some clients experience poor channel conditions and therefore communicate at a lower data rate, this severely impacts the throughput of all clients in the network. Recently, multihop relaying in combination with leveraging multiple data rates was proposed to alleviate this problem. However, our experiments indicate that gains from these techniques are very small with realistic positioning of clients. Instead, we propose a novel scheme that combines relaying and multiple data rate capabilities with the concept of channel borrowing. Our protocol, BCR (Borrowed Channel Relaying), utilizes unused capacity from neighboring access points and is able to achieve network throughput gains of 20% to 60% depending on the scenario. Although we use 802.11 style networks to illustrate this concept, this general principle can be applied to any infrastructure network with receivers capable of tuning to more than one channel.
However, we have also discovered that relaying can be much more effective if cleverly combined with channel borrowing between access points. The idea is that if one Basic Service Set (BSS), a group of nodes consisting of an AP and its clients, is lightly loaded, the channel assigned to it could be used by a neighboring BSS to significantly improve the performance of relaying. This will alleviate the transmission bottleneck around the access point, which was found to be the main obstacle to throughput enhancement. In this paper, we will introduce this novel concept of relaying with channel borrowing, propose a practical protocol solution, and demonstrate its ability to achieve significant overall throughput performance enhancement.
Before getting to the details of our relaying with channel borrowing, we will take a small step back to list some of the different concepts related to relaying and rate diversity that have been proposed to enhance throughput in 802.11-type networks. One of the first ideas was to leverage multihopping for spatial reuse. In a wireless network, using multiple short hops can increase the number of simultaneous transmissions if combined with power control (note that this work assumed that all nodes have a fixed data rate, so it does not exploit rate diversity) . However, it was also observed that if most traffic goes to and from an access point, spatial reuse alone does not lead to an increase in network throughput . The reason is that the access point remains the bottleneck, and each path is basically contending for the same resources, much the same way direct transmissions would. The first main point to realize is that infrastructure networks thus behave fundamentally differently than mesh networks: the access point is the true bottleneck and spatial reuse by itself does not alleviate this problem!
It was realized that another motivation for using multihop routes is to overcome bad channel conditions . This could be thought of as a generalization of range-extension. Since in a typical wireless local area network (WLAN) scenario, devices support multiple data rates; the best rate can be chosen on each link. With such use of rate diversity, a succession of multiple fast hops can free up time on the channel compared to one slow hop. In a scenario where traffic flows to and from an access point, this approach can alleviate the observed bottleneck there, which is the throughput limiting factor in these types of networks. Specific protocols, called rDCF (relay distributed coordination function) and rPCF (relay point coordination function), have been proposed to take advantage of this situation [2, 3]. They are modifications of the 802.11 standard to include such relaying in combination with rate diversity, and basically explore the use of a single relay in a 2-hop path as was illustrated in Figure 2. However, we have found through experimental testing that while these protocols can increase network throughput in carefully constructed scenarios, the amount of throughput gain realized in a network with random node placement is low. The reason is that the probability of having two fast hops to replace a much slower one is small, given the specific dependence of rate versus distance for typical 802.11 devices. We will further illustrate this in Section 4.
The main problem with the relaying setup in rDCF and rPCF is that of the two hops in the path (AP-relay and relay-client ), only one of them can be active at the same time. As such, the combination of both hops, in terms of time-on-the-channel, has to outperform the direct link ( ). For example, in Figure 2, if both and are slow, relaying will not be beneficial, even if link from the AP is fast. Since the access point is the actual bottleneck, ideally one would hope to be able to exploit the fast link r1 from the AP. Basically, due to its bottleneck status, any throughput gain for the AP translates into similar benefits to the network. The problem with rDCF and rPCF is that the second hop forces the AP to sit idle, thereby wasting valuable resources. In this paper, we solve this problem by leveraging yet another degree of freedom in 802.11 networks: the channel assignment. Current 802.11 infrastructure networks are frequency planned with static partitioning of spectrum. The total of spectrum available to the network as a whole is split up in channels. For example, there are 3 nonoverlapping channels for 802.11b in the United States. Other variants of 802.11, such as 802.11a in the 5 GHz band, have 12 nonoverlapping channels, which is even more beneficial for our protocol as we will see in this paper. Each BSS is typically assigned just one channel, so a heavily used AP can have its single channel nearly maxed out while a nonoverlapping channel assigned to a neighbor BSS sits idle. By allowing a single BSS to use more than one channel, more than one transmission can occur simultaneously, therefore improving throughput. This is the basis of the novel approach we propose in this paper: relaying and rate diversity combined with borrowing channels between BSS'. Each node (AP, relay or client) still only uses one channel at a time. However, the AP-relay links and relay-client links operate on different channels through careful coordination. In certain common scenarios, such as an AP in a busy hotel conference room next to lightly used APs in hallways and guest rooms, our protocol is likely to work well because the probability that additional channels will be available at any given time is high. In , some of our colleagues monitored the load on 4 APs providing service to attendees of an ACM conference at UC San Diego. They found that most of the long sessions (devices associated with an AP for greater than 10 minutes) have very low average data rates, which they conclude to be machines of users who associate with an AP and then remain idle as they pay attention to the conference sessions. They also found that load distribution at the APs was very bursty and uneven and was governed mostly by individual users and workloads rather than the number of users associated at any given time. We would like to point out that putting two transceivers on the AP, although also directly attacking the bottleneck in these systems, is not an option. The reason is that self jamming will occur if one transceiver is transmitting while the other is receiving . Though they would use different channels, they operate in the same band, very close in frequency. The transmitter can easily be 50 dB or more above the received signal and even the best filters cannot handle this type of interference almost directly adjacent to the received channel. This is in contrast to systems that are designed to transmit and receive at the same time, like cellular base stations. Unlike 802.11, these systems have the benefit of operating in paired spectrum, where transmit and receive frequencies are separated by a guard band relatively large compared to the channel size to prevent self jamming. Our usage of relay nodes essentially provides the means to do more than one simultaneous transmission without special hardware, within the existing frequency band structure, while avoiding self jamming.
3. Related Work
Besides 802.11 networks, the idea of using relays to improve throughput has also been proposed for cellular networks. Most 2G cellular networks are frequency planned systems just like 802.11, with a static set of channels allocated to each cell. If one cell is heavily loaded while neighbor cells have light traffic, spectrum is not being used efficiently. Methods by which one cell can borrow unused spectrum from neighboring cells have been developed [9, 10]. Later works have looked at the use of relays to improve throughput in 3G networks, which are all based on CDMA. The general idea is to use relays to forward packets to clients with poor channel quality . Mobile devices with more than one interface can be used as relay stations and the relayed data can be sent between the mobile devices and the relay stations as either an in-band (licensed) transmission or an out-of-band (unlicensed) transmission. Cooperative diversity techniques, which can take advantage of the same types of diversity that MIMO uses but do not require more than one antenna on each node, can be used. In , the authors argue that using more than two hops results in only marginal throughput improvement but greatly increases the complexity of the routing algorithms, and found no reason to investigate algorithms with 3 or more hops in detail. They also found that two of the relay protocols can approximately double the throughput of 3G networks. It should be noted that [6, 11] rely on having more than one wireless interface per node, while our work assumes only one interface per node.
In 802.11, each node has an equal opportunity to gain access to the channel in any interframe space between packets, which translates to equal throughput if the packet size used by all nodes is fixed and each transmits as fast as possible. Some protocols, however, such as the Opportunistic Auto Rate (OAR) , attempt to redefine fairness as each node receiving a throughput proportional to the data rate, which roughly translates to an equal amount of time on (rather than opportunity to access) the channel. However, the AP remains a system bottleneck and all the time it spends transmitting to or receiving from nodes with a slow connection is still spent sending relatively few bits per unit time.
Work has also been published about the capacity of wireless networks using multiple channels [13–15]. People have created MAC layers for 802.11 networks that use more than one channel . In their simulations, traffic patterns did not necessarily reflect those of typical infrastructure networks with most of the traffic originating or terminating at a single node, and rate diversity was not considered. Mobile Ad Hoc Network (MANET) systems with multiple channels have been explored . Another idea proposed is allowing traffic to pass through neighboring APs by having nodes explicitly switch channels since many nodes are in the transmission range of more than one AP . This protocol was extended by allowing clients to relay and switch between various BSSes . Rate diversity was not considered in either. The work in  takes rate diversity into account and uses a network of mesh routers to connect end users to gateways. Time is divided into superframes and each mesh node has a designated receive channel in each receive timeslot, with the remaining slots reserved for transmission. The receive pattern of each node is known to its neighbors, and a node wishing to relay a packet through a mesh node needs to transmit on the designated channel in a receive timeslot for the destination node. To help avoid conflicts, part of each superframe is reserved for downlink traffic and part for uplink traffic. Although this protocol outperformed the single channel network by up to 100%, it relies on the assumption that traffic loads across the network are steady over time. This is not the case in real networks, where bursty traffic might generate flows that are not optimal for the superframes, and the system would operate inefficiently until it could have time to adapt to the new traffic flows. Also, this protocol relies a reservation MAC, unlike our protocol which relies on the far more prevalent random backoff MAC and is therefore more suited for typical wireless networks and traffic patterns. We should emphasize that the major difference between our work and other multichannel MAC protocols is that while they focus on mesh networks with randomly generated one-to-one traffic, we focus on WiFi infrastructure networks with very different traffic patterns and a distinct bottleneck at the access point.
Other protocols require each device to have two transceivers . This is the case in the vast majority of multichannel protocols. In , nodes are equipped with as many radios as necessary to make optimal use of the channels. The authors found that in general, nodes closer to the gateways need more radios (as they will be relaying more packets than nodes at the fringes of the networks). Besides the problem that this protocol requires special hardware, it is simply not practical to expect the nodes with the greatest number of radios to be located near the gateways in networks with mobile nodes.
Finally in , nodes can be equipped with as many radios as needed to optimize use of the available channels (at which point the number of simultaneous transmissions is limited by interference). Although throughput can be improved by as much as 4 to 7 times that of a single channel network, this required each node to be equipped with an average of 4 radios!
While using multiple radio interfaces works in theory, in practice the antenna location, channels used, and filters must be carefully controlled to avoid self jamming, and it is not practical because it both adds to the cost of the hardware and is not compatible with preexisting infrastructure.
Our method improves upon the rDCF and rPCF [2, 3] protocols by reducing the amount of time the AP's channel is occupied during the relay process. Since the AP is the bottleneck, the worst thing we can do is force it to sit idle, which is precisely what happens in rDCF and rPCF when packets are being relayed, because each BSS in rDCF and rPCF is allowed to use only one channel. Unlike many other multichannel MAC protocols, we assume that each node has only one transceiver, which makes our protocol possible to implement on existing hardware and does not increase the cost of the equipment required to use it.
4.1. General Concept
As mentioned earlier, the typical large 802.11 network is a frequency planned system, and is installed in such a way that adjacent access points do not use overlapping channels to avoid interference. Our protocol uses the idea that a BSS can temporarily borrow an underused channel from a neighbor for the purposes of relaying packets. This allows relaying to be accomplished without forcing the AP to sit idle while the relay node is communicating with the client node. To do this, one AP would ask its neighbor permission to use the channel over the wired infrastructure. Since this process does not use the wireless channel, it introduces no wireless overhead. Because most internet traffic is in the downstream direction, we focus on relaying packets going from the AP to its clients. Since changing channels can impose a time overhead of up to 200 microseconds , we keep the AP tuned to its own channel at all times and require both the relay and the destination nodes to change channels so that this time overhead does not affect the bottleneck node.
4.2. Step by Step: Relaying a Packet
The AP sends a Relay Data (RDATA) frame to the chosen relay. This packet contains a field that allows the AP to tell the relay node which channel to use when it forwards the packet.
The relay sends a Request-to-send, Borrowed Channel (RTSBC) frame to the destination node, indicating that it intends to send a relayed packet on another channel and therefore the destination node should retune its transceiver to that channel. The RTSBC is also overheard by the AP, and serves as the acknowledgement for the RDATA frame (indicated by the dotted line in the figure). As such, the RTSBC is sent an SIFS interval after the RDATA frame. When the AP receives the RTSBC frame, it knows that the relay is in progress and adds both the relay and destination nodes to its forbidden list (this is intended to prevent the AP from attempting to transmit to nodes that cannot hear it and is described in Section 4.4). The AP also sets a Forbidden List Timer for an amount of time longer than the relay is expected to take. If the AP does not receive a Relay ACK (RACK) within this time interval, it assumes that the relay has failed and removes both nodes from the forbidden list.
The destination node sends a Clear-to-send, Borrowed Channel (CTSBC) frame back to the relay node, acknowledging receipt of the RTSBC frame. Upon sending this packet, the destination node begins tuning its transceiver to the borrowed channel. As soon as it receives the CTSBC, the relay node also begins retuning. Similar to what happens in RTS/CTS exchanges, the CTSBC is sent out an SIFS interval after the RTSBC frame. Both the relay node and the destination node set a (Borrowed) Channel Timer when they finish retuning, for a time interval longer than the second hop is expected to take. If the second hop is not completed when this timer expires, both nodes tune back to the primary channel.
As soon as it completes the process of tuning to the borrowed channel, the relay node waits a PIFS and then sends an RTSBC frame to the destination node. This is done because any nodes using the borrowed channel (e.g., in another BSS) might be unaware that the channel has been reserved, and the RTSBC/CTSBC exchange prevents collisions. The reason we wait a PIFS is that we do not want to clobber any acknowledgements that might be sent in response to transmissions already in progress, but we want priority access to the channel after any transmissions finish (since the channel has, after all, been reserved).
The destination node sends a CTSBC frame back to the relay node on the borrowed channel after an SIFS.
The relay node proceeds with the second hop transmission, sending the RDATA frame to the destination node an SIFS after receiving the CTSBC.
The destination node sends an ACK back to the relay node an SIFS after receiving the RDATA frame. As soon as it does, it begins tuning back to the primary channel.
The relay node, after receiving the ACK, also begins tuning its transceiver back to the primary channel.
As soon as it has tuned back to the primary channel, the relay node waits a PIFS and then sends a Relay ACK (RACK) back to the AP. This prevents the relay node from causing a collision with any existing transmission or its acknowledgement frame, but also gives it priority access over any new transmission.
When the AP receives the RACK frame, it knows that both nodes are tuned to the primary channel again and removes both nodes from its forbidden list.
RDATA (Relay Data): like a DATA frame, the Address 1 field contains the address of the receiver, the Address 2 field contains the address of the sender, and the Address 3 field contains the BSSID. On the first hop, for example, Address 1 holds the address of the relay and Address 2 holds the address of the AP. Likewise on the second hop, Address 1 holds the address of the relay and Address 2 holds the address of the destination node. The Address 4 field, not used in regular DATA frames unless the To DS and From DS bits are both set, is used in RDATA to hold the address of the destination node for both hops.
RTSBC (Request-to-send, borrowed channel): serves the same function as a traditional RTS frame in addition to acting as a signal for the relay and client to switch channels, or to begin the second RDATA transmission. This frame has an extra field indicating the next channel the node should tune its receiver to. All nodes listen for RTSBC packets and set their NAV timers in the same way they do upon receiving an RTS frame, to avoid collisions. Note that the duration indicated in the frame on the main channel will be short, while on the secondary channel it will be long (effectively reserving the channel long enough for the RDATA frame and ACK to be sent).
CTSBC (Clear-to-send, borrowed channel): contains the same information as a traditional CTS frame with the added field indicating the channel the node should tune its radio to.
RACK (Relay ACK): acknowledgement frame to let the AP know that the relay was successful.
4.3. Choosing a Relay
Is there a relay in progress? If there is, the borrowed channel is already being used and therefore is not available to relay the packet, so the packet is sent directly. If not, go on to the next step.
Is the direct link fast enough? If the direct link is slow enough that we can benefit from using a relay, go on to the next step.
- (iii)Is there a suitable relay node? A node must exist that has a faster connection to the AP than the destination node, which means that sending a packet to the relay instead of directly to the destination node would take less of the AP's time. In the case more than one suitable relay node is found, the following procedure is used to select among them.
Any relay node with a faster connection to the AP (first hop rate) takes priority over potential relay nodes with slower first hop rates. This is because the AP is the bottleneck, and by choosing the fastest first hop rate, we are minimizing the time the AP spends transmitting the packet.
If there is a tie between nodes chosen in the previous stage, the node with the fastest second hop rate takes priority. This reduces the amount of time the borrowed channel must be used for relaying.
Any nodes tied after the previous steps are selected randomly with a uniform probability among each of them.
4.4. Forbidden Lists
Once the relay node is chosen, the AP begins the process of telling both the relay and client nodes to transmit the second hop packet on the borrowed channel. This poses a problem for the 802.11 protocol. Recall that if a transmission to a node goes unanswered, the 802.11 protocol assumes that the packet loss was due to network congestion and interference, and therefore increases the size of the contention window and then sets its backoff timer.
The problem is that when the relay and destination nodes are tuned to the borrowed channel, they are effectively out of range of the AP. Should a packet destined for one of these nodes reach the head of the AP's transmit queue, it will receive no response because neither of the nodes will be able to hear the transmission. The AP would incorrectly assume that the channel is congested, set its backoff timer, and hurt overall throughput.
To avoid this issue, we have the AP maintain a list of forbidden destinations. This list contains nodes that are unable to communicate with the AP because they are tuned to another channel, for example, the relay and destination nodes while they are tuned to the borrowed channel.
The transmit queue examines the forbidden list whenever a packet reaches the head of the queue. If the destination of the packet is not forbidden, the queue passes the packet to the AP for transmission. Any packets destined for forbidden destinations are ignored but maintain their position in the queue so that any packet that reached the head of the queue but was blocked receives the first priority as soon as its destination is cleared from the forbidden list.
4.5. Handling Dropped Packets
Dropped RDATA frame from AP to relay: the relay will not send an RTSBC frame to the destination node. The RDATA frame will be treated like any unACKed packet, and the AP will backoff, then send the frame again.
Dropped RTSBC frame from relay to AP: the AP will not add the relay and destination nodes to its forbidden list, and may try to transmit to either node while they are tuned to the other channel. This scenario, fortunately, is unlikely because the RTSBC is sent out an SIFS after the RDATA frame.
Dropped RTSBC frame from relay to destination (primary channel): the frame is retransmitted until a maximum number of retries is reached, then the relay is aborted.
Dropped CTSBC frame from destination to relay (primary channel): the relay node would never receive the CTSBC and would just abort the relay process. The destination node, having sent the CTSBC, would tune to the secondary channel, but would never receive the second RTSBC or the RDATA. Eventually, the destination node's borrowed channel timer will expire, causing it to tune back to the primary channel.
Dropped frames on secondary channel for second hop: if packets are dropped on the secondary channel for any reason, the borrowed channel timers will eventually expire, causing the nodes to tune back to the main channel.
Dropped RACK from relay to AP: if the RACK is dropped, the AP will eventually remove both the relay and destination nodes from its forbidden list when its timer expires.
It is important to note that our protocol relays one packet at a time. While this minimizes latency, since the channel switching time is 200 microseconds , this can be a rather large penalty to pay twice for each packet relayed (for switching the radios on the relay and destination nodes to and from the borrowed channel). Each transmission also incurs the overheads associated with the RTSBC/CTSBC/RACK exchange with the AP, as well as the associated interframe spacings. The overhead as a percentage of the total amount of data sent can be reduced, particularly for large data transfers, by relaying more than one packet at a time. This can be done by sending data packets back to back in groups, separated by an SIFS interval, as is done in the OAR protocol .
CalRadio experiment data rates versus distances.
Maximum distance (m)
One way to evaluate our protocol, assuming the vast majority of the traffic is downstream as it is in most networks (from the AP to the clients), is as a flow problem where the flow of data is from the AP "source" to the client "sinks", both directly and through intermediate nodes (the relays). In order to be able to cast this scenario as a flow problem that can be solved with linear programming, we split each client node into two virtual nodes: a sink node, and a relay node. Each of the links between any nodes and has two values associated with it: , the maximum data rate between nodes and , and , the amount of time and communicate. is a real number between 0 (meaning the link is not used at all) and 1 (meaning the link is used 100% of the time). The objective is to maximize the flow from the source (AP) to the sink nodes, while still satisfying other constraints.
triangle constraint: sum of edges between any three nodes cannot exceed 1.
We can see what the problem is by looking at the picture in a different way. Look at the triangle formed by the AP, relay, and client 2. If we consider these three nodes in isolation, it becomes clear that at any given moment in time, only two can be active (one transmitting, one receiving, and a third node that must sit idle because the other two nodes are busy). Since only one transmission (edge) can be active at any given time, in no event can the sum of the edges in any triangle add up to more than 1.0. Because this constraint applies to any three nodes that form a triangle, we call it the Triangle Constraint.
Packet lengths. All packets include 192 bit PLCP preamble and header, 32 bit FCS, and variable MAC header sent at 1 Mbps. Payload bit rates are variable.
MAC header (bits)
To simulate the overhead associated with using our protocol, the Matlab simulation was rerun with the data rate on the links reduced to an effective rate that takes into account the length of time it takes to transmit all of our control frames as well as the time consumed by interframe spacings and channel switching times. The results are shown in the bottom line of Figure 8. As expected, the gains were lower than those when overhead is neglected, but still amount to about 50%–75% for 7 or more nodes in the BSS.
In order to further investigate our protocol, we implemented a full network level simulation of BCR in the NS-2 network simulator.
In each run of the simulation, we randomly placed a specified number of client nodes in the range of the AP with a uniform distribution over area, then ran both the traditional 802.11 protocol and our channel borrowing and relaying protocol, measuring the difference in total network throughput between the two. It is assumed that the AP always has access to a secondary channel from one of its neighbors whenever one is requested.
NS2 Throughput Improvements for scenario shown in Figure 11.
We found that large numbers of packets being dropped, especially during the relay process, has an adverse effect on the gain because of the large overhead associated with sending relay packets (if a packet is dropped, we use up a lot of time on both the primary and secondary channels only to have the relay process fail). In addition, the relatively large number of packets required to accomplish a relayed transmission (7, compared to just 2 for a direct transmission) makes it more likely that something will go wrong during the process. However, as the results show, we can design our protocol to choose sufficiently conservative power thresholds for each data rate so that the probability of packets being dropped is low enough that it does not adversely affect our results.
Finally, we compared the differences between the Matlab and the NS2 results. One possible explanation for the differences is that even though we did account for overhead in Matlab, we were unable to model some types of overhead, such as the random amount of time a node backs off after a successful transmission, because linear programs require fixed amounts of flow on each link. Instead, we assumed that the channels only sit idle for the minimum amount of interframe space time between transmissions when we calculated the effective data rate on each of the links. This is not the case in NS-2. After the AP finishes transmitting a packet, 802.11's binary exponential backoff (BEB) mechanism requires that the transceiver sit idle in order to give other nodes a chance to access the channel. Upon receiving either an RTSBC or an RACK frame, the AP counts this as a successful transmission, and must give other nodes a chance to transmit before it sends its next packet. Since we underestimated the overhead, the improvement in throughput seen in reality will be lower than that calculated by Matlab, which does match with our results.
802.11 networks are frequency planned systems, which result in inefficiencies from static partitioning of spectrum. Existing work had addressed how to improve throughput using multiple channels and relaying with rate diversity, but we realized that these protocols may not work well if there is random node placement. Also, many existing protocols designed for multichannel MACs assume that each node can have more than one transceiver, making them incompatible with existing hardware. Building on an idea from cellular networks, we introduced a new protocol that leverages channel borrowing and relaying in combination with rate diversity to further improve throughput without custom hardware.
We used our customizable 802.11b research platform, CalRadio, to obtain data on the data rate versus distance tradeoffs in 802.11b, and used these results as inputs to our simulations. We simulated our protocol in both Matlab and NS-2. In NS-2, we saw average gains of 20–30% for random placement, and 60% for ideal placement. We believe we can do even better. Our protocol is not limited to the 802.11 family, but will work with any protocol that provides a tradeoff between signal strength and data rate. The new 802.11n protocol, for example, provides even greater rate diversity with varying signal strength, so the potential gains are even greater. Unfortunately, while our protocol cannot be used with channel bonding in the 2.4 GHz band because there is not enough spectrum to borrow even one extra 40 MHz channel pair, it is an excellent candidate to use with 802.11n in the 5 GHz band, which provides 12 nonoverlapping channels instead of just 3. Another possible improvement comes from the fact that 802.11 transceivers are generally not designed to change channels frequently because in normal operation, switching channels is an infrequent event. If this time can be cut down significantly by designing the hardware to have the ability to rapidly change channels, even more throughput gains can be made. Our transceiver in CalRadio, for example, takes 200 microseconds to tune between channels , and since it contains a typical 802.11 physical layer implementation, we used this channel switching overhead time as an input to our simulations. If we used radios designed to switch channels much faster, our protocol would yield even larger throughput gains. Such a task is possible, as some ultra wideband (UWB) radios can switch channels in a few nanoseconds .
- Heusse M, Rousseau F, Berger-Sabbatel G, Duda A: Performance anomaly of 802.11b. Proceedings of the 22nd Annual Joint Conference on the IEEE Computer and Communications Societies (INFOCOM '03), March-April 2003, San Francisco, Calif, USA 2: 836-843.Google Scholar
- Zhu H, Cao G: RDCF: a relay-enabled medium access control protocol for wireless ad hoc networks. Proceedings of the 24th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '05), March 2005, Miami, Fla, USA 1: 12-22.View ArticleGoogle Scholar
- Zhu H, Cao G: On improving the performance of IEEE 802.11 with relay-enabled PCF. Mobile Networks and Applications 2004, 9(4):423-434.View ArticleGoogle Scholar
- Jow A, Schurgers C, Palmer D: CalRadio: a portable, flexible 802.11 wireless research platform. Proceedings of the 1st International Workshop on System Evaluation for Mobile Platforms (MobiEval '07), June 2007, San Juan, Puerto Rico 49-54.View ArticleGoogle Scholar
- Hsieh H-Y, Sivakumar R: On using peer-to-peer communication in cellular wireless data networks. IEEE Transactions on Mobile Computing 2004, 3(1):57-72. 10.1109/TMC.2004.1261817View ArticleGoogle Scholar
- Luo H, Ramjee R, Sinha P, Li L, Lu S: UCAN: a unified cellular and ad-hoc network architecture. Proceedings of the 9th Annual International Conference on Mobile Computing and Networking (MOBICOM '03), September 2003, San Diego, Calif, USA 353-367.View ArticleGoogle Scholar
- Balachandran A, Voelker GM, Bahl P, Rangan PV: Characterizing user behavior and network performance in a public wireless LAN. Proceedings of the International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS '02), June 2002, Marina del Rey, Calif, USA 195-205.Google Scholar
- Pickholtz RL, Milstein LB, Schilling DL: Spread spectrum for mobile communications. IEEE Transactions on Vehicular Technology 1991, 40(2):313-322. 10.1109/25.289412View ArticleGoogle Scholar
- Favalli L: Sectorized channel borrowing scheme with resource pooling. Proceedings of the 50th IEEE Vehicular Technology Conference (VTC '99), September 1999, Amsterdam, The Netherlands 5: 3019-3023.Google Scholar
- Wille V, Multimaki H, Irons S: A practical approach to "channel borrowing" for microcells in GSM systems. Proceedings of the 48th IEEE Vehicular Technology Conference (VTC '98), May 1998, Ottawa, Canada 1: 144-148.Google Scholar
- Le L, Hossain E: Multihop cellular networks: potential gains, research challenges, and a resource allocation framework. IEEE Communications Magazine 2007, 45(9):66-73.View ArticleGoogle Scholar
- Sadeghi B, Kanodia V, Sabharwal A, Knightly E: Opportunistic media access for multirate ad hoc networks. Proceedings of the 8ht Annual International Conference on Mobile Computing and Networking (MOBICOM '02), September 2002, Atlanta, Ga, USA 24-35.View ArticleGoogle Scholar
- Kyasanur P, Vaidya NH: Capacity of multi-channel wireless networks: impact of number of channels and interfaces. University of Illinois at Urbana-Champaign; 2005.View ArticleGoogle Scholar
- Hung W, Law K, Leon-Garcia A: A dynamic multi-channel MAC for ad hoc LAN. Proceedings of the 21st Biennial Symposium on Communications, April 2002Google Scholar
- Jain N, Das SR, Nasipuri A: A multichannel CSMA MAC protocol with receiver-based channelselection for multihop wireless networks. Proceedings of the 10th International Conference on Computer Communications and Networks, 2001, Scottsdale, Ariz, USA 432-439.Google Scholar
- So J, Vaidya N: Multi-channel MAC for ad hoc networks: handling multi-channel hidden terminals using a single transceiver. Proceedings of the 5th International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '04), May 2004, Tokyo, Japan 222-233.View ArticleGoogle Scholar
- Wu S-L, Lin C-Y, Tseng Y-C, Sheu J-L: A new multi-channel MAC protocol with on-demand channel assignment for multi-hop mobile ad hoc networks. Proceedings of the International Symposium on Parallel Architectures, Algorithms, and Networks, 2000, Dallas, Tex, USA 232-237.Google Scholar
- Balachandran A, Bahl P, Voelker GM: Hot-spot congestion relief in public-area wireless networks. Proceedings of the 4th IEEE Workshop on Mobile Computing Systems and Applications, 2002 70-80.View ArticleGoogle Scholar
- So J, Vaidya NH: Routing and channel assignment in multichannel multi-hop wireless networks with single-nic devices. Computer Science Department, University of Illinois at Urbana-Champaign; 2004.Google Scholar
- Tam W-H, Tseng Y-C: Joint multi-channel link layer and multi-path routing design for wireless mesh networks. Proceedings of the 26th IEEE International Conference on Computer Communications (INFOCOM '07), May 2007, Anchorage, Alaska, USA 2081-2089.Google Scholar
- Raniwala A, Gopalan K, Chiueh T-C: Centralized channel assignment and routing algorithms for multi-channel wireless mesh networks. Mobile Computing and Communications Review 2004, 8(2):50-65. 10.1145/997122.997130View ArticleGoogle Scholar
- Lin T-Y, Tam W-H, Fan K-L, Tseng Y-C: Resource planning and packet forwarding in multi-radio, multi-mode, multi-channel, multi-rate (M4) wireless mesh networks. Computer Communications 2008, 31(7):1329-1342. 10.1016/j.comcom.2008.01.059View ArticleGoogle Scholar
- Wang X, Garcia-Luna-Aceves JJ: Distributed joint channel assignment, routing and scheduling for wireless mesh networks. Computer Communications 2008, 31(7):1436-1446. 10.1016/j.comcom.2008.01.018View ArticleGoogle Scholar
- Maxim 2.4ghz 802.11b zero-if transceiversGoogle Scholar
- Williams LI, Wu D, Staggs E, Yen A: Ultra-wideband radio design for multi-band OFDM 480 Mb/s wireless USB. DesignCon Symposium Digest, January 2005, Santa Clara, Calif, USAGoogle Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.