MFT-MAC: A Duty-Cycle MAC Protocol Using Multiframe Transmission for Wireless Sensor Networks

In many sensor network applications, energy efficiency and latency are major design criteria because battery-operated sensor nodes limit network lifetime. In this paper, we propose a new contention-based duty-cycle MAC protocol using a synchronized approach for use in wireless sensor networks. In the proposed MFT-MAC protocol, we use a control frame that considers the number of DATA frames to be transmitted to the next node in order to improve the energy efficiency and reduce the end-to-end delay. During the SLEEP period, each node transmits multiple DATA frames to the next node through the use of the control frame. The performance of the proposed MAC protocol is confirmed through the use of NS-2 simulator.


Introduction
Wireless sensor networks consist of one or more sinks and a large number of small, low-cost, low-power sensor nodes.These networks are suitable for a variety of applications, such as environmental monitoring, military purposes, and gathering of sensing information [1,2].In many environmental monitoring wireless sensor network applications a sink gathers data from battery-operated sensor nodes spread across a geographical area using a unidirectional multihop chain topology.In these applications the network lifetime is based on the average power consumption and the battery lifetime of the sensor nodes [3,4].Due to these circumstances, energy efficiency is a major concern in the design of the medium access control (MAC) protocols used in these types of sensor networks.
The sensor-MAC (S-MAC) protocol [5], which was proposed on the basis of contention-based protocols such as IEEE 802.11, is a typical energy efficient MAC protocol for wireless sensor networks.In S-MAC, a frame is divided into listen and SLEEP periods.The sensor nodes periodically wake up for a short fixed listen interval and then go back to sleep for most of the frame duration to save energy.The low duty cycle resulting from the ratio of the wake time to the total frame time not only improves the energy efficiency but also may result in a significant latency in the frame delivery, especially in the multihop topology.
B-MAC [6], WiseMAC [7], and X-MAC [8] which use an asynchronous duty cycle have been developed to improve energy efficiency in the idle listening interval.In B-MAC, we use low-power listening and an extended preamble to reduce energy consumption.Nodes have awake and SLEEP periods with an independent schedule.In order to provide synchronization, B-MAC and WiseMAC use a preamble that is slightly longer than the SLEEP period.WiseMAC reduces the preamble length to improve the energy efficiency.B-MAC and WiseMAC are well suited for light traffic loads but have problems in the degradation of throughput, high latencies, and low-power efficiencies due to their relatively longer preamble.
The timeout-MAC (T-MAC) [9], the routing enhanced MAC (R-MAC) [10], the variable load adaptive MAC (VLA-MAC) [11], and the demand wakeup-MAC (DW-MAC) [12] protocols have been proposed to improve energy efficiency through the use of an adaptive duty cycle.In T-MAC, the sensor nodes in the listen mode go to sleep when no activity occurs for a given time interval, called TA.The TA is the minimal amount of idle listening time per frame and so may cause throughput degradation and additional latency.R-MAC has been proposed to reduce the end-to-end delay in multihop topologies.R-MAC uses a PION (pioneer) frame instead of the RTS/CTS frame of the S-MAC in its listening mode.This PION frame supports multihop routing in a single cycle.The DW-MAC protocol can reduce the packet delivery latency for a wide range of traffic loads based on the R-MAC.The DW-MAC protocol schedules to maintain a proportional one-to-one mapping function between a DATA period and SLEEP period.
We propose multiframe transmission MAC (MFT-MAC) for wireless sensor networks.In the proposed MAC protocol, we transmit the multiple DATA frames in a single cycle to improve energy efficiency and to reduce latency.

The MFT-MAC Protocol
In the traditional low-latency MAC protocols [10] a source node sends a DATA frame to the sink node through a multihop procedure in a single cycle.The proposed MFT-MAC protocol is a contention-based MAC protocol for wireless sensor networks.MFT-MAC forwards multiple DATA frames over the multihops in a single duty cycle in order to reduce energy consumption without sacrificing the end-toend delay.MFT-MAC is well suited for data collection applications in which sensor nodes have to report to the sink node through the use of multihops in a chain topology as shown in Figure 1.
Figure 2 shows the MFT-MAC operation.The MFT-MAC protocol consists of SYNC, DATA, and SLEEP periods in a single cycle as those in R-MAC [10].Nodes 0 to 4 synchronize their clocks with the required precision in the SYNC period.In the DATA period, the source node contends with its neighbors and setups a forwarding path using the control frame for sending the DATA frame to the sink node in the SLEEP period.In this paper, we use a control frame similar to the RTS/CTS mechanism to solve the hidden node problem.The control frame is used to request communication in the same manner as a RTS frame and simultaneously confirms the request like a CTS frame.The control frame possesses the multiframe transmission information over multihops.In the SLEEP period, nodes 0 to 3 can transmit DATA frames through the multihops to the sink node 4. The nodes wake up at some specific time in order to receive the multiframes and then go back to sleep after transmitting the multiframes.

The Control Frame.
During the DATA period each node sends a control frame called a PION to the next node in order to setup the forward path to the sink node.The PION acts as the RTS and CTS; it includes all of the RTS and CTS fields.In addition, the PION contains the final destination address, the hop count, and the number of multiframes.The MFT-MAC uses the cross-layer routing information; the final destination address is passed down from the network layer.Each node sets its hop count to the number of hops needed to reach the source node.Each node calculates the number of multiframes to be transmitted to the next node in a single-hop interval.
In Figure 2, the source node 0 waits for a random period from the contention window (CW) and an additional distributed interframe spacing (DIFS) period before sending a PION to node 1. Node 0 transmits a PION to node 1 with the multiframe field number of 1. Node 1 waits for a short interframe spacing (SIFS) period and then sends a PION to node 2 with the multiframe field number of 2 when node 1 has a DATA frame to be transmitted to the sink node 4.This PION frame acts like a CTS as node 0 overhears node 1's PION.Nodes 2 and 3 set their multiframe field numbers to those of the received PION plus 1 when they have DATA to be sent to the sink node 4. The number of DATA frames transmitted in the SLEEP period is determined using the number of PIONs transmitted in the DATA period.In this paper, we set the number of PION frames to 5, the same number used in [10].When the number of nodes is greater than 6 in the chain topology, the transmission should be continued in the next cycle.If the number of nodes is 10, node 5 starts its transmission during the second cycle.In the second cycle, node 5 transmits a PION with a multiframe number of 6 and a hop count of 0 when node 5 has a DATA frame to be transmitted to the sink node 9.The wake-up time of a node is calculated from the hop count and the multiframe number.We describe the calculation of the wake-up time in the following subsection.

The Multiframe Transmission.
After setting up the forwarding path in the DATA period, the nodes transmit the multiple DATA frames during the SLEEP period, as shown in Figure 2.During this period we employ the DATA/ACK mechanism.A node transmits DATA to the next node.The received node waits for a SIFS period and replies with an ACK if the DATA frame is received without errors.After receiving the ACK, the node waits for a SIFS period and transmits the next DATA frame when the node has additional DATA frames to be transmitted to the next node.After receiving the ACK for the final DATA frame, the node goes back into sleep mode.
In Figure 2, the source node 0 transmits a DATA frame to node 1, which then replies with an ACK back to node 0. After receiving the ACK, node 0 goes into sleep mode.Node 2 then wakes up to receive the DATA frames from node 1. Node 1 sends the received DATA frame to node 2, waits for an ACK, and then transmits its own DATA frame.Nodes 3 and 4 wake up to receive their respective multiple DATA frames at their scheduled times.The wake-up time is calculated by where  denotes the hop count and   is the number of frames to be transmitted to the next node.  is the transmission time from DATA to ACK determined by where  DATA and  ACK denote the transmission time of the DATA and ACK frames, respectively.In (1) we set the wakeup time of the first and second nodes, that is,  = 0 and 1, to 0.

Simulation Results and Discussions
We evaluate the performance of the proposed MFT-MAC protocol through the use of a NS-2 simulator.Simulation results have been compared to those found for the R-MAC and DW-MAC protocols.
Table 1 shows the key system parameters used for simulations.We use the default settings in the standard S-MAC simulation module in the NS-2 simulator as those in [10].In simulations, each sensor has an omnidirectional antenna and we use a two-ray radio channel model.We set the transmission range to 250 m and the carrier sensing range to 550 m.We use a constant bit rate (CBR) traffic model.The lengths of the DATA and PION frames were 50 and 14 bytes, respectively.We also set the duty-cycle related parameters as follows: the total cycle time of 4465 ms consisted of a SYNC frame of 55.2 ms, a DATA frame of 168 ms, and a SLEEP frame of 4241.8 ms.
We use three different types of topologies in simulations: a chain topology and 5 × 5-node chain and sink node topologies.Nodes are deployed in equal intervals of 200 m.We perform simulations over 33000 seconds.We use the static routing schemes to eliminate the effects of routing algorithms as those in [12].In the chain topology, each node from 0 to −1 transmits its DATA frames to a sink node  as shown in Figure 1. Figure 3 shows 5 × 5-node grid topologies: a 5-chain scenario and a sink node scenario.In a 5 × 5-node grid topology with 5 straight chains, each chain topology has 5 hops and each sink node is located at the edge of the grid.Each node transmits its DATA frames to each sink node along the path.In the 5 × 5-node grid topology with a sink node, 24 source nodes transmit their DATA frames through the shortest static routes to the sink node located at the bottom right corner of the grid.The source node 0 uses the shortest route {0-6-12-18-24} as shown in Figure 3(b) and the maximum number of hops is 4.
We calculate average power consumption in order to evaluate the energy efficiency of the proposed MFT-MAC protocol.Average power consumption is calculated by dividing the total energy consumed by sensor nodes by the total simulated time as that in [10].Figure 4 shows simulation results of the average power consumption relative to the number of hops in the chain topology.In the proposed MFT-MAC protocol, we transmit multiple DATA frames using only one PION frame, but the R-MAC and DW-MAC protocols transmit only one DATA frame per PION.The number of PION frames of the proposed MFT-MAC protocol is smaller than those of the R-MAC and DW-MAC protocols in end-to-end  transmission for a given traffic load.In the proposed MFT-MAC protocol, energy consumed by nodes is reduced proportional to the reduction of the number of PION frames.Simulation results show that the average power consumption of the MFT-MAC protocol is less than those of the R-MAC and DW-MAC protocols.The average power consumption of the MFT-MAC, DW-MAC, and R-AMC protocols is 69.58, 69.64, and 70.44 mWatts at the rate of 1 bps (one packet per 400 seconds) for 8 hops, respectively.
Figure 5 shows the average power consumption relative to the number of hops in the 5 × 5-node grid topology with 5 chains.In this scenario, retransmissions of PION caused by collisions with neighbors and frame errors by interference signals increase the average power consumption.The average power consumption of the MFT-MAC, DW-MAC, and R-AMC protocols is 71.08, 71.15, and 71.39 mWatts at the rate of 4 bps (one packet per 100 seconds) for 4 hops, respectively.Simulation results show that the proposed MAC protocol has a good performance relative to those of DW-MAC and R-AMC.
Figure 6 shows the average power consumption relative to the number of hops in the 5 × 5-node grid topology with a sink node.In this topology, the proposed MFT-MAC protocol consumes more energy than those in other topologies as retransmissions of PION caused by collisions and frame errors are increased.Simulation results show that the average power consumption of the MFT-MAC, DW-MAC, and R-AMC protocols is 71.1, 71.3, and 72.0 mWatts at the rate of 1 bps for 3 hops, respectively.Figure 8 shows the average end-to-end delay relative to the number of hops from the sink node in the 5 × 5-node grid topology with 5 chains.In this scenario, retransmissions of PION caused by collisions and frame errors increase the number of duty cycles and therefore the average end-to-end delay time is increased.The average end-to-end delay time of the MFT-MAC, DW-MAC, and R-MAC protocols, 10, 39, and 95 sec at the rate of 4 bps for 4 hops, respectively.
Figure 9 shows the average end-to-end delay relative to the number of hops from the sink node in the 5 × 5-node grid topology with a sink node.In this scenario, the average endto-end delay time of the MFT-MAC protocol is larger than those in other scenarios as retransmissions caused by frame collisions and errors are increased.Simulation results show that the average end-to-end delay time of the MFT-MAC, DW-MAC, and R-MAC protocols are 21, 39, and 182 sec at the rate of 1 bps for 3 hops, respectively.
Figure 10 shows throughputs of the proposed MFT-MAC, DW-MAC, and R-MAC protocols in the chain topology.The throughput performance of the MFT-MAC protocol is shown to be superior to those found for the DW-MAC and R-MAC due to the reduction of the average end-to-end delay for a given number of nodes.In R-MAC and DW-MAC,    throughputs are saturated as control frame collisions in the DATA period are increased at a traffic load of 1 bps and 6 bps, respectively.Simulation results show that throughputs of the MFT-MAC, DW-MAC, and R-MAC protocols were 7.98, 5.86, and 0.32 bps at a traffic load of 8 bps, respectively.

Conclusions
In this paper, we proposed the multiframe transmissions-(MFT-) MAC protocol for wireless sensor networks.The proposed MAC protocol is well suited for data collection applications in which sensors have to report to the sink nodes through a multihop topology.We have confirmed the performance of the proposed MAC protocol through NS-2 simulations.The simulation results show that the proposed MAC is superior to the DW-MAC and R-MAC protocols in regard to average power consumption, the average end-to-end delay, and throughput.

Figure 5 :
Figure 5: Average power consumption relative to the number of hops in the 5 × 5-node grid topology with 5 chains.

Figure 6 :
Figure 6: Average power consumption in the 5 × 5-node grid topology with a sink node.
Figure 7 shows simulation results of the average end-to-end delay relative to number of hops in the chain topology.The average end-toend delay time of the MFT-MAC, DW-MAC, and R-MAC protocols is 5.70, 11.28, and 29.41 sec at the rate of 1 bps for 8 hops, respectively.

Figure 7 :
Figure 7: Average end-to-end delay in the chain topology.

Figure 9 : 6 International
Figure 9: Average end-to-end delay in the 5 × 5-grid topology with a sink node.

Figure 10 :
Figure 10: Throughputs relative to the traffic loads in the 5 × 5-grid topology with a sink node.