1. Introduction
The medium access control (MAC) layer significantly impacts network throughput, as it co-ordinates the channel access between wireless nodes. Despite physical layer advancements, the underlying IEEE 802.11 protocol cannot fully exploit features and support high-performance applications. The IEEE standard [
1] defines multiple channels for communication at the physical layer. IEEE standard 802.11b,g specifies three orthogonal or non-overlapping channels which are 22 MHz wide, and IEEE 802.11a specifies 12 non-overlapping channels: 4 channels of 20 MHz each in the upper, lower, and middle U-NII bands. When orthogonal channels are used, concurrent transmissions can co-exist on multiple channels without causing interference to each other. A transceiver can switch easily between various channels, but IEEE 802.11 is designed only for single-channel operation. With the dense deployment of wireless nodes becoming a reality in the near future, the study of multi-channel protocols to maximize utilization of spectrum resources is an issue of peculiar interest.
A deterrent issue in multi-channel protocols affecting performance is the multi-channel hidden terminal problem wherein the nodes performing data transmission on data channels miss the control packets exchanged on the control channel. Due to missing information on channel status, the pair of nodes may inadvertently choose a busy channel and start data exchange, causing a collision. Of the existing multi-channel MAC protocols, dedicated control channel-based [
2,
3] and time synchronization-based protocols [
4,
5] handle this issue effectively. The dedicated control channel protocols eliminate the multi-channel hidden terminal issue by having two transceivers, one for control signaling, and other for data transfer, and the nodes are aware of the neighbor activities all the time. However, having two transceivers per node increases the cost, energy consumption, and size. In a dense deployment of nodes with no existing power infrastructures, the usage of nodes with expensive hardware and high power consumption is not feasible. Also, dedicating an entire channel for control exchanges decreases the bandwidth available for data transmissions. Moreover, as the density of nodes increases and a large number of data channels are present, the control channel becomes a serious bottleneck. This makes the dedicated control channel protocols with multiple transceivers less attractive. As for time synchronization-based protocols, the time is divided into control and data phases. The contention for channels occurs during the control phase and the nodes that succeed in negotiations are involved in data transfer during the data phase. All nodes listen to each other during the control phase and are aware of the control exchanges; the multi-channel hidden terminal problem is removed. However global synchronization is a difficult task as it involves considerable overhead and complexity. Distributed or asynchronous multi-channel protocols using single antennas are highly susceptible to multi-channel hidden terminal issues. The authors of [
6] proposed a back-off mechanism to overcome this by mandating a waiting time for nodes in successful data transfer before the next contention. Our protocol does include a waiting period but does not mandate a complete data transmission time. In [
7], the authors suggest that a careful channel selection strategy can avoid the hidden terminal problem to a reasonable extent.
Another issue in multi-channel protocols is that the loss of control exchanges due to collisions in request-to-send (RTS) and clear-to-send (CTS); i.e., RTS–RTS or RTS–CTS collisions, can lead to information loss. Due to loss of control exchanges, a node may select a data channel in use and cause a data collision. The authors of [
8] suggest that if a data channel in use is selected inadvertently, the neighbors can issue an invalid signal and stop the on-going negotiation. Avoiding collisions in multi-channel hidden terminals and control handshakes greatly enhances the network throughput. A strategy in multi-channel protocols to increase the throughput is to employ a batch-mode operation wherein multiple data frames are allowed to transmit per handshake [
9] reducing the contention and amortizing the handshake overhead. Keeping the multiple frames allowed per handshake to an optimum number is mandatory in this approach, otherwise other nodes will suffer a high degree of starvation before getting a channel to transmit.
In this paper, a distributed multi-channel MAC protocol using a single transceiver is proposed, which is named the spectrally efficient asynchronous multi-channel (SA-MMAC) protocol. In the proposed protocol, a receiver node, on receiving data successfully, sends data to the sender as a piggy-backed acknowledgment, skipping the control exchanges and reducing the signaling overhead. A full-duplex MAC design was investigated in [
10,
11]. However, the design in [
10] requires an array of physical layer modifications and that in [
11] employs a dedicated control channel. The main contributions of this paper can be summarized as follows:
We propose a novel, simple-to-implement multi-channel MAC protocol to coordinate multiple channel access using a single half-duplex transceiver without the need for time synchronization.
The protocol extends the IEEE 802.11 single-channel back off/contention mechanism and load balances the parallel transmissions to multi-channels.
The protocol increases the spectral efficiency and reduces the signaling overhead by allowing a full-duplex mode of operation in data channels.
The protocol promotes spatial channel re-use by using a control channel for data transmissions and prevents control channel bottlenecks by strict enforcement of half-duplex mode in the control channel.
The deterrent multi-channel hidden terminal problem is addressed by a revamped contention mechanism wherein the success node pair waits additional time in the maximum data frame before starting to contend.
The control signals collisions (RTS–RTS, RTS–CTS) are handled by a jamming signal from receiver after sending the CTS.
The rest of the paper is organized as follows. The operational details of the SA-MMAC protocol are described in
Section 2. In
Section 3, the details of the simulator validation are provided. A performance evaluation is presented in
Section 4 to demonstrate the effectiveness of our proposed protocol. Finally, some conclusions are drawn in
Section 5.
2. The Spectrally Efficient Asynchronous Multi-Channel MAC (SA-MMAC) Protocol
2.1. System Model
In the design of the proposed SA-MMAC protocol, there are two important features:
A distributed network of N nodes, with each node equipped with a half-duplex transceiver. A node can transmit or receive at any given time but not both. A node transmitting on a data channel cannot listen to control signals on the control channel.
K orthogonal channels of equal bandwidth. Simultaneous transmissions can happen on these channels without interfering with each other. One channel is configured for control exchanges and other K-1 channels are configured for data transfer. The control channel is reused for data transfer when possible.
The proposed protocol is a logical extension of IEEE 802.11 and is assumed to have IEEE 802.11-like behavior in other layers of the TCP/IP stack. The channel conditions are assumed to be ideal and error-free and the packets are lost only due to collisions. For the protocol design, we modify the IEEE 802.11 control packets to add some fields. The control frames in SA-MMAC are:
RTS (request-to-send): is sent when a sender has data to send. The RTS is modified to contain additional information such as the available channel list (ACL) and data transfer time.
CTS (clear-to-send): is sent to acknowledge the incoming RTS. The frame is modified to contain the selected channel and data transfer time.
RES (reservation): is sent to confirm neighbors of the on-going transmission. The frame is similar to that of the CTS.
2.2. Operations of the SA-MMAC Protocol
The basic idea of our proposed SA-MMAC protocol consists of four aspects.
(1) Full-duplex mode of operation: the receiver node can operate in a full-duplex mode and skip the control overhead signaling only one successful control handshake.
(2) Re-use of the control channel: the control channel is used for data transmissions but is restricted to half-duplex mode operation so as to obtain balance between reuse of the channel and prevention of a bottle-neck at the control channel.
(3) Contention mechanism: multi-channel problems, such as the hidden terminal, are controlled by additional waiting time for the success node pair after data transmission.
(4) Collision avoidance. Finally, the collisions in control signals (RTS/CTS) are handled by an additional jamming signal from the receiver after sending a CTS.
Spectrally efficient asynchronous multi-channel MAC (SA-MMAC) uses a single transceiver and listens to a commonly assigned control channel by default. When a node is ready to send data, it first issues a request-to-send (RTS) on the control channel which includes a list of available channels on the sender side. The receiver, on getting the RTS, checks its list of free channels and selects a commonly available channel. If no common channel is available, or if the node is busy in data exchange, the RTS request is ignored; otherwise a clear-to-send (CTS) is issued. The receiver then switches to the data channel and gets ready to receive data. The sender, on receiving the CTS, announces the selected data channel and channel release time to its neighbors in a frame called reservation (RES). Then, it switches to the data channel and starts sending data. Once the data transfer is complete, the receiver sends an acknowledgement (ACK). The neighboring nodes which hear the control exchanges freeze their back-off timers and defer from contention for the duration of transmission. Nodes will send the RTS, CTS, and RES on the control channel and switch to the agreed data channel for data transfer. When the process is complete, the sender–receiver switch to the control channel and take cognizance of the control messages exchanged. The contention and back-off mechanism on the control channel follow IEEE 802.11.
The working of the SA-MMAC protocol is illustrated in
Figure 1. Node A has data to send to B and issues a RTS on the control channel (CCH) with the list of available channels. The neighbors of A defer until after the RTS frame + Data Inter-Frame Space (DIFS) time. B, on receiving the RTS, chooses a common channel. Since B has data to send to A, B adds its own data transfer time to the data transfer time of A indicated in the RTS and sends the CTS to A. The neighbors of B defer from contention until the data transfer time, as indicated in the CTS signal. After the Short Inter-Frame Space (SIFS) time, the receiver sends the RES signal again. Nodes which missed the CTS signal due to collisions can hear the RES and become cognizant of the data transfer. Node A, on receiving the CTS, sends the RES to its neighbors. Then, nodes A,B switch to the selected data channel and transfer data. B, on receiving DATA from A, sends back its DATA as a piggy-backed acknowledgement. A on receiving DATA (B) knows that B received its DATA (A) successfully. It then sends acknowledgment (ACK) for DATA (B). The nodes then switch to the control channel and wait for the mandatory time of a maximum data frame and start contending again as per the IEEE 802.11 contention mechanism. When the data transfer of A–B is going on, nodes C and D successfully negotiate and start the data transfer process on channel 2. However, in this case since D does not have any data to send to C, it simply sends an acknowledgment after receiving DATA from C. In the scenario described in
Figure 1, let us assume the data channels are 2. When E wants to send data to F, it sees all the data channels are occupied. Hence, E selects the control channel (CCH) for data transfer and sends the RTS. F also has data to send to E, but it skips its data frame, as control channel is used for data transfer. Hence, the CTS from F just includes the data transfer time for E. Our protocol uses a synchronous mode of operation and has some important features which solve commonly existing problems in multi-channel protocols.
2.3. Issue of Multi-Channel Hidden Terminal and Deafness Due to Use of a Single Radio
The use of single radio results in multi-channel hidden terminal and deafness problems. At any given time, a half-duplex transceiver can only either send or receive on only one channel. A hidden terminal occurs in RTS/CTS as two nodes sending RTS at the same time cause a collision at the third node, or at least one node is deaf to the other RTS. It is also possible that when a node sends the CTS, a neighbor may send a RTS simultaneously. Also, nodes in data transfer are deaf to the exchanges on the control channel and may select a busy channel inadvertently in the next frame exchange. In our protocol, the nodes returning from data transfer wait a mandatory time for the maximum data frame on the control channel before contending again for transfer. By this approach, one node that has just completed data transfer (lets say node A) and is returning to the control channel, and another node which has obtained the data channel at the same time (lets say node Z) can get to know each other. Before node A starts another RTS, node Z will be back to the control channel and will be ready to hear the control exchanges. This additional waiting time, while causing overhead, serves to eliminate the multi-channel hidden terminal and results in a highly collision-free operation.
2.4. Issue of Increased Control Overhead
In order to transfer data, a node has to incur control overhead due to the time spent in back-off, contention, and control signals such as RTS and CTS. For small data frames, more time is spent in sending the control signals. The collisions that happen during the contention lower the spectrum utilization. Nodes that obtain the channel often succeed and the failed nodes starve for a long time. Our protocol has two main overheads apart from contention and back-offs. Nodes returning from data transfer have to wait for one maximum data frame time. Nodes have to wait when control channel is used for data transfer. In order to offset the effect of these overheads, an impartiality is added to the protocol. Once a pair of nodes agrees on data transfer, the receiver can send an extra frame to the sender without the cost of contentions and back-offs. When a receiver needs to respond to an RTS, it checks if it has any data to the sender, adds it to data transfer time, and the CTS is sent. When the first data frame from sender (A) to receiver (B) is complete, receiver (B) sends the second frame (A) to the sender. The transfer of second frame from node B is a piggybacked acknowledgment to node A. Node A knows that the transfer of first frame is successful. Node A then sends the ACK to B to confirm the receipt of second frame. In the absence of a data packet to sender (A), an ordinary ACK packet is sent from receiver (B). Thus, the second frame from node B effectively skips all the contention, waiting, back-off, and RTS–CTS signals. A visible downside of this approach is that other nodes suffer a delay in acquiring the channel due to transfer of two time frames in a single negotiation and the sender also needs to wait for an additional frame time before the next data exchange. This bi-directional approach was first proposed in [
11] but using a dedicated control channel. The ill-effects of dedicated control channel have been previously discussed.
2.5. Comparison of Features
Our protocol uses an asynchronous mode of operation and employs a common agreed-upon channel for control signals. Nodes use distributed random access mechanism as in IEEE 802.11 for contention. This protocol supports broadcasts and does not need any temporal synchronization. However, a moderate channel switching delay is present. A comparison of features of the SA-MMAC protocol with the single-channel IEEE 802.11, the reliable channel-based multi-channel MAC (m-RCR), and the asynchronous multi-channel MAC (AMMAC) protocol is shown in
Table 1.
3. Simulator Validation
The SA-MMAC protocol follows IEEE 802.11 in its underlying back-off and contention mechanism with necessary modifications in control frames and handshakes for multi-channels. A custom-made packet-level simulator is done in python. We validate the simulator by comparing our IEEE 802.11 DCF and RTS/CTS implementation with some of existing seminal works [
12,
13,
14,
15]. The simulation parameters are set as in referred works. The results from our simulator in
Figure 2a–c match with results of [
12] (Figure 6), [
13] (Figure 5), and [
14] (Figure 6), respectively. Similarly, IEEE 802.11 saturation throughput, access delay, frame drop ratio, and Jain’s fairness index (JFI) from the simulation (
Figure 3a–d) accurately match with those of Akeel (refer to IEEE 802.11 graphs in Figure 3, Figure 4, and Figure 6 [
15]). By establishing the accuracy and correctness of back-off and contention mechanism of IEEE 802.11, we establish the correctness of the simulator as the multi-channel protocols share the same IEEE 802.11 contention mechanism with necessary changes as per the demands of the protocol.
4. Simulation Results and Discussion
We detail the underlying assumptions for the performance evaluation. The simulation parameters are listed in
Table 2.
The nodes are in transmission range of each other in a single collision domain.
The channel assignment follows a per-packet basis.
Saturated traffic conditions are assumed, so nodes will have a frame to transmit all the time.
The frames exchanged are: RTS, CTS, ATS, DATA, and ACK. No other frames are considered.
All nodes use the same PHY layer using the direct-sequence spread spectrum (DSSS) at a rate of 1 Mbps.
Both data and control frames are sent at a rate of 1 Mbps. All nodes transmit with the same data rate. Varying data rates at various nodes at the same time are not considered. In case of collision, the frames are discarded. The capture effect is not considered.
All simulations are run for a time of 10,000 data frames. The chosen frame count is validated and found to provide sufficient accuracy in populating the performance measures.
We compare the SA-MMAC with the single-channel IEEE 802.11, and the following multi-channel asynchronous MAC protocols: (1) reliable channel-based multi-channel MAC (m-RCR) [
9] and (2) asynchronous multi-channel MAC (AMMAC) [
6]. The chosen protocols m-RCR and AMMAC belong to the same asynchronous multi-channel category using single half duplex transceiver and exhibit some characteristics of our proposed SA-MMAC. m-RCR reserves multiple steps per successful handshake and transmits RES again over selected intervals to avoid a multi-channel hidden terminal problem. It has one channel reserved for control exchanges and rest of the available channels for data transfer. In the simulations, we keep the m factor of m-RCR to 5 as suggested in [
9]. The AMMAC reuses the control channel and the success node pair wait for a maximum data transfer time before starting contention. The m-RCR nor AMMAC protocols do not need time synchronization and use the IEEE 802.11 contention mechanism.
Figure 4a shows the normalized throughput for a fully connected network using three concurrent channels with increasing network load up to 80 nodes. When the network load is low, all protocols have a similar performance. As the network approaches saturation, SA-MMAC yields a significant performance over all the other protocols. The gain in performance over IEEE 802.11 is mainly due to usage of multiple channel transmissions. The normalized saturated throughput (0.7) is always capped below 1. The m-RCR protocol reserves one channel exclusively for control exchanges, which means one channel less for data transfer. The performance gain of SA-MMAC over AMMAC is due to the fact that the nodes are involved in full duplex transmissions on data channels skipping the control channel negotiations and back-off overhead.
Figure 4b,c shows the results for the same network scenario when using 4 and 12 channels. As we can observe, for high node density of 80 nodes using 12 channels, the saturation throughput of SA-MMAC (7.3740) has about 1245% more throughput than 802.11 (0.5479), 94% more than m-RCR(3.7908), and 18% more than AMMAC (6.2430).
Figure 5a shows the comparison of channel access delay for 3 channels as the node density increases from 5 to 80. As the traffic load increases, the access delay for IEEE 802.11 sharply rises as the collisions happen during channel negotiation and data transfer. All the nodes have to wait until the complete data transfer time as indicated in the RTS or CTS message and then start a contention. In multi-channels, m-RCR has the worst access delay as the nodes that succeed contention occupy a whopping m times data transfer on the data channel. Nodes that lose the contention have to wait for the time of m data frames, not to mention the inherent weakness in contention mechanism of the IEEE 802.11(briefly discussed later). SA-MMAC has similar channel access delay to AMMAC but is marginally better. The similarity is due to the fact SA-MMAC employs a mandatory maximum time frame wait after successful data transfer, similar to that of AMMAC. The waiting period for the control channel in SA-MMAC is reduced to about half of that of AMMAC. Moreover, we need to consider the fact that the data transfer is bi-directional in data channels. Despite a full duplex mode operation in data channels and control channel usage, SA-MMAC still performs comparably to AMMAC. We repeat the experiments for 4 and 12 channels as in
Figure 5b,c and a similar trend is observed. The proposed protocol thus scales well to 12 channels with the same kind of performance.
Figure 6a shows Jain’s fairness index (JFI) versus the number of nodes in the network. As the node traffic increases, the fairness index in IEEE 802.11 drastically reduces due to its poor contention mechanism. The phenomenon of “rich get richer and the poor get poorer” occurs. Nodes that successfully transfer data get an early chance to negotiate as the CW is set to a minimum, whereas the failed nodes have to wait longer and any further collision worsens its chance of getting the channel access. m-RCR is seen to have a better JFI than others. JFI is calculated based on the transmitted packets in a time window and any dropped packets will be excluded. The fact is that m-RCR drops more packets and as a side effect, there is an increase in JFI. This is explained later. AMMAC increases the JFI by a modified contention mechanism. The nodes successful in data transfer must wait the maximum data frame time before they start their next contention. This facilitates the other nodes getting the transmission channel. AMMAC has a better JFI than SA-MMAC (about 25% better) due to the fact there is only one data frame transmission per handshake in AMMAC whereas in SA-MMAC, the receiver can use the same handshake and send an extra data frame, skipping the contention overhead. The reduction of JFI in SA-MMAC is because only the receiver node in successful negotiation gets preferential treatment, skipping the overhead. A similar trend is observed for 4 and 12 multiple channels in
Figure 6a,b.
The adaptability of SA-MMAC for a large density of nodes and high traffic conditions can be observed from the results in
Table 3 and
Table 4.
Table 3 shows the frame drop ratio (FDR) for a network of 100 nodes under three scenarios (3, 4, and 12 channels). IEEE 802.11 has frame drop ratio of (5.31%) irrespective of the number of channels, as it uses only one channel and the remainder of the bandwidth remains unused. All multi-channel protocols have a nil frame drop ratio for 100 nodes.
In a densely populated network of 500 nodes, IEEE 802.11 fares poorly, dropping about 57% of the packets. In m-RCR, packets wait longer and longer due to extended transmissions on the data channels; the re-transmission attempts fail and the packets get dropped rampantly. Hence, m-RCR drops a whopping 64% of the packets. The SA-MMAC outperforms its counterpart AMMAC with a 45% lower frame drop ratio (FDR). By virtue of its watch-and-proceed contention mechanism and neighbors’ better awareness of control exchanges, SA-MMAC results in almost a collision-free operation.
Figure 7 shows the performance of SA-MMAC for four channels for a network of 100 nodes with a varying number of channels. As we can observe, with respect to the performance of a network with the use of multi-channels, as parallel data transmissions occur, the availability of more channels translates to an increase in saturation throughput and a decrease in channel access delay. The fairness index almost remains the same.
Table 5 shows the performance of SA-MMAC for the same scenario of 100 nodes and four channels with different packet payload sizes. We can notice that the trend is similar irrespective of the frame sizes.
We considered another scenario of a populated network of 200 nodes with different number of available channels and compared the protocols. As we can observe in
Figure 8a, the increase in the number of channels does no good to the IEEE 802.11. As the network is heavily loaded, the performance of IEEE 802.11 sharply drops with normalized saturation throughput reduced to 0.4 and access delay increased by more than 1750 s. The m-RCR throughput increases with the increase in number of channels, and does not go beyond half of the spectrum utilization, with a saturation throughput of less than 4 for 8 channels. For AMMAC, the performance is saturated at 10 channels and cannot take advantage of more channels thereafter. This is due to the mandatory waiting time for the nodes returning from data transfer and moreover, the high traffic leads to increase in RTS collisions, more retransmission attempts, and a drop in packets. The saturation throughput of SA-MMAC can be seen as increasing even beyond 10 channels, which confirms its suitability for a higher number of channels without the control channel becoming a bottle-neck. We consider the channel access delay of protocols with varying numbers of channels. This is given in
Figure 8b. The delay characteristics of IEEE 802.11 do not change due to the reasons discussed earlier. The access delay of AMMAC (and also m-RCR to an extent) converges with SA-MMAC at a higher number of channels. However, we need to consider the fact that AMMAC throughput is already saturated and packets are dropped heavily. As for m-RCR, the packet drop is even worse for higher density networks. Thus we can establish that SA-MMAC transmits more packets than other protocols with much less of an access delay.