Multichannel preamble sampling MAC protocol for wireless sensor networks

Abstract

In this article, a multichannel preamble sampling MAC protocol, MCPS, especially tailored for wireless sensor networks, is proposed and thoroughly evaluated. MCPS is a low-power MAC protocol operating on multichannel using carrier sensing for collision avoidance. Specifically, MCPS exploits all the non-overlapping channels provided by IEEE 802.15.4 physical layer. Basically, MCPS uses one dedicated common control channel to wake up an intended receiver using a preamble sampling technique. However, data transmission takes place in a dedicated data channel. Indeed, MCPS allocates to every pair of sensor nodes a unique data channel that aims at being 2-hop conflict free. Hence, the probability of collision is highly reduced and even completely mitigated in some scenarios. Moreover, MCPS allows each sensor node to dynamically adjust its transmission power when sending strobed preamble or periodically generated data. Indeed, for each possible distance separating a pair of communicating nodes, MCPS adapts the appropriate transmission power and selects the appropriate data channel. Using multiple channels, MCPS allows multiple simultaneous data communications along with handshaking on the common control channel, hence reducing the end-to-end delay and improving the throughput while being energy efficient. MCPS has been implemented using OMNET++ simulator under INET framework, on top of the IEEE 802.15.4 physical layer, which was improved to support the multichannel communication. The authors compare the performance of MCPS with McMAC and X-MAC. Simulation results show that MCPS greatly improves the network performance especially in terms of throughput, waiting time, end-to-end delay, and energy per bit.

Introduction

Wireless sensor network (WSN) consists of a large number of sensor nodes that are randomly scattered in a given field. Each sensor node consists of a limited memory, a limited processor, a limited source of energy usually in the form of battery, a sensor unit, and a transceiver for data transmission and reception. Traditionally, the main requirement for WSNs applications was long lifetime as they are mostly deployed in inaccessible places. That is why most of the previously proposed research works focus mainly on the energy efficiency as it is the only solution to improve the network lifespan. Nowadays, besides the fulfillment of the energy conservation requirement, WSNs should provide data transmission with maximum data rate as well as minimum end-to-end delay. This is because WSNs are recently involved in applications such as health examination, target tracking, and critical event detection, which require timely transmission of large amount of data. In fact, achieving high throughput in WSNs that are naturally characterized by low bandwidth is challenging as opposed to ad hoc networks, which support high data rates. For instance, the maximum possible data rate in IEEE 802.15.4 standard is only 250 kbps. ¹ To deal with the previous mentioned challenge, researchers in Soua and Minet ² list three possible solutions. The first solution is the use of adaptive transmission power, which means the sender transmits a packet with the right transmission power to deliver the packet to the destination node. By doing so, nodes can reuse the shared medium in a way that multiple transmissions are accomplished simultaneously without interference or collisions. The second solution is the use of directional antenna, where the transmission power is mainly oriented toward the receiver side. The third solution is the use of multichannel communication. Multichannel communication consists of dividing the available bandwidth into different channels of reduced width; hence, different pairs of nodes in the same neighborhood exchange data packets simultaneously on different channels without interference or collisions instead of a unique pair of node exchanging data on the available shared channel. Consequently, network throughput increases since various data transmissions take place on different data channels simultaneously. Furthermore, the end-to-end delay is expected to decrease because of the decrease in the waiting time to seize the channel especially compared to the single-channel scheme. However, the multichannel communication has its own challenges that should be carefully dealt with when designing a multichannel protocol. The first challenge is the missing receiver problem. The missing receiver problem may occur when a transmitter node sends a packet to a receiver node on a particular channel, where that receiver is not listening to since it is busy communicating with another node on another channel. Consequently, the sender mistakenly supposes that the receiver is not reachable. This may result in a waste of energy as well as it may induce network partitioning. This problem is also called the deafness problem. ³ Figure 1 sketches the missing receiver problem.

Figure 1.

The missing receiver problem.

The second challenge is the hidden node problem that occurs when a node C that is in the transmission range of B, but not in the transmission range of A, misses the control packets exchanged between A and B. Control packets are usually in the form of request to send and clear to send (RTS/CTS) messages. Node C misses the control packet between A and B on one channel because it was busy at that time with another data transmission on another channel. Therefore, a collision might happen at node B when node C tries to send data packet on the channel that was previously chosen by node A and B. ² Figure 2 illustrates the hidden node problem.

Figure 2.

The hidden node problem.

In this research, a multichannel preamble sampling MAC protocol (MCPS) for WSNs is proposed and evaluated. Our ultimate aim is to conceive a low-power MAC protocol especially tailored for WSNs. In fact, MCPS allows communication using variable transmission power on different channels. By doing so, MCPS protocol combines the use of adaptive transmission power and the multichannel communication solutions that are mentioned earlier, to deal with WSN’s challenges. Precisely, MCPS is operating on the multi-non-overlapping channels of the IEEE 802.15.4 standard with one dedicated common control channel (CCC) to wake up an intended receiver using a preamble sampling technique. However, data transmission takes place in the appropriate data channel that corresponds to the distance separating the two communicating nodes. By doing so, a pioneer distance-based channel assignment (DBCA) approach is proposed. The DBCA approach allows a sender node to independently choose the data channel without any overhead that may result from exchanging control packets. For the best of the authors’ knowledge, MCPS is the first multichannel MAC protocol for WSNs that uses DBCA approach as a channel assignment technique.

Related work

WSNs can be classified into single-channel MAC protocols, where the sensor nodes use the same common frequency, and multichannel MAC protocols, where the shared medium is divided into multiple different channels that can be used simultaneously on the same neighborhood without interference or collisions.

Regarding single-channel MAC protocols, authors in literature^4,5 proposed preamble ahead anycast MAC protocol to mitigate the sleeping period by selecting the next hope node from a group of possible nodes called Forwarding Candidate set (FCS) that wakes up earlier instead of fixed next hope.

Regarding WSN multichannel MAC protocols, they can be classified into three categories according to the channel assignment technique: static, semi-dynamic, and dynamic. In the next three sections, authors review existing multichannel MAC protocols related to the focus of each category.

Static channel assignment

In this category, a unique data channel is assigned to every node for possible communication with it.

Enhanced multichannel MAC protocol

Enhanced multichannel MAC protocol (Enhanced HMC-MAC) has three operation phases. ⁶ During the first phase, the node coordinator (NC) broadcasts a TDMA-based schedule on a semaphore channel for node’s beacon propagation management. The beacons include a bitmap of one-hop and two-hop neighbors for that node. By doing so, a three-hop neighbor list is build at each receiver node. The three-hop neighbor list is used to guarantee to the most possible extent a conflict-free channel allocation process. After assigning channels for all the nodes in the network, the second phase starts. Indeed, enhanced HMC-MAC protocol imposes a hierarchical cluster tree topology, where sensor nodes are categorized into two groups. These groups allow nodes during the data transmission phase to be in different states. In other words, when nodes belonging to the first group are in the transmission state, then nodes belonging to the second group will be in the reception state according to the timeslots, and vice versa. After the second phase, nodes sleep for energy conservation. The main disadvantage of this protocol is the use of static channel assignment, as it may result in network partitioning. Furthermore, the control packet is overloaded as it contains the bitmap of 1-hop and 2-hop nodes in the neighborhood. Moreover, collision free data transmission is not guaranteed, as more than one node can share the same channel.

Multichannel cluster tree

Multichannel cluster tree (MCCT) is a multichannel cluster tree-based protocol for WSNs that is built on the top of the IEEE 802.15.4 slotted CSMA-CA. ⁷

Nodes in the network are classified into active coordinators (parents) and passive coordinators (children). Each parent with its children forms a cluster, and a channel is assigned for each cluster. When a node newly joined the network, it listens to the CCC for any incoming Hello messages that are sent by the coordinators. Hello messages contain information such as the channels and timeslots used by the 2-hop nodes in the neighborhood. The newly joined node selects a coordinator with non-null smallest number of children. If all the available active coordinators have a number of children exceeding the proposed threshold, then the newly joined node selects a passive coordinator to form a new cluster. In this case, the passive coordinator becomes an active coordinator, and it selects the least used channel based on its neighbor table as a cluster channel. The main disadvantage of this protocol is the use of static channel assignment, as it may result in network partitioning. Furthermore, increasing the number of leaf nodes in the cluster instead of creating new cluster may result in an increase in the scheduling, which will induce an increase in the end-to-end delay.

Dynamic channel assignment

In this category, a node is assigned a channel possibly before each data transmission. However, precise coordination between the sender and the receiver nodes is required to avoid the missing receiver and the multichannel hidden node problems.

Multichannel medium access control protocol (iQueue)

iQueue protocol, is a hybrid MAC protocol that uses both Carrier-Sense Multiple Access (CSMA) and Time-Division Multiple Access (TDMA) to deal with low traffic load as well as bursty traffic, respectively. ⁸ iQueue was designed with the purpose of taking advantage from both CSMA and TDMA techniques depending on the traffic rate. When a node has a packet to send, it starts with CSMA/CA mechanism to win the access to the medium. This packet contains extra information indicating the number of packets in the queue. Hence, the router node (parent) allocates for sender node (child) an exact number of timeslots based on its queue. When the queue is empty, the router node will not assign any timeslots, and it will work like a low duty-cycle CSMA protocol. The channel assignment process starts from the routers by defining a subset of data channels for each router. Then, the routers update their Channel-Occupancy-Indicator by listening on the CCC for a predefined period of time. After that, the router checks the Channel-Occupancy-Indicator to find a free data channel. If the router fails to find a free data channel, it will randomly choose a channel and broadcast it to other routers. Although the channel assignment mechanism ensures unique channel selection in 1-hop neighborhood, the overhead of selecting and maintaining channels is high.

Efficient multichannel medium access control protocol

Efficient multichannel medium access control protocol (EM-MAC) is a multichannel duty-cycle MAC protocol that allows a node to choose dynamically between a set of channels based on the channel load status. ⁹ Specifically, each node preserves a measure for each channel that indicates whether the channel has a high load or interference, to avoid using that channel. By doing so, it allows for load balancing between the available channels besides the mitigation of probable collisions and retransmissions. EM-MAC protocol is a receiver-initiated protocol, which means the sender has to receive a beacon packet from the receiver to proceed its transmission. To enable a sender meets its receiver, a sender must have the prediction state of the receiver to independently calculate the predicted wake-up time and the wake-up channel of that receiver. To obtain this information, a sender repeatedly waits on each channel for a beacon packet that might be sent by the receiver, to respond with a data packet containing a request for the receiver’s prediction state. However, the sender ultimately finds its receiver, and the time required for rendezvous increases by increasing the number of the available channels.

Predictive-wakeup multichannel MAC protocol for WSNs

Predictive-wakeup multichannel MAC protocol (PW-MMAC) is a duty-cycle asynchronous multichannel MAC protocol that uses dynamic channel assignment mechanism. ¹⁰ It uses probabilistic channel selection approach by allowing each node to anticipate the wake-up time and the selected channel by its receiver using a pseudo-random function called linear congruential generator (LCG). Initially, the sender wakes up slightly before its receiver on the last channel it communicates with that receiver and waits for beacon. Once a beacon is received by the sender from the intended receiver, it will use the pseudo-random function to select a channel for communication. Specifically, the channel assignment is dynamic, which is based on the schedule generated by the pseudo-random function.

In PW-MMAC, there is no guarantee that the selected channel by the sender will be the same one chosen by the receiver since the sender independently calculates the channel for data transmission using the pseudo-random function and without any confirmation from the receiver. Hence, the deafness problem may arise.

Semi-dynamic channel assignment

In this category, each node is statically assigned a channel with possibility of channel switching whether to communicate with other nodes or in response to changes of network conditions.

Multichannel asynchronous scheduled medium access control protocol

Multichannel asynchronous scheduled medium access control protocol (MCAS-MAC) is a multichannel asynchronous scheduled MAC protocol. ¹¹ It is a duty-cycle MAC protocol that is tailored for high-density network by supporting the back-to-back packet transmission. Every node periodically transmits a Hello message on its home channel, which contains information about its wake-up time and its home channel identifier. MCAS-MAC consists of two main phases: the initialization phase and the periodic listening and sleeping phase. During the first phase, the newly incoming node listens on all the available channels for a specific period of time for any possible Hello message. After that, the newly joined node can choose a unique wake-up schedule and a home channel that is the least used one in the neighborhood. Then, it advertises this information on its selected home channel. Immediately after, it enters the periodic listening and sleeping phase. When a node has a packet to transmit, it will wait until the wake-up time of the receiver; then, it switches to the receiver’s home channel for data transmission, which it may result in a long delay.

Multichannel lightweight medium access control protocol

Multichannel lightweight medium access control protocol (MC-LMAC) is a TDMA-based multichannel MAC protocol. ¹² According to MC-LMAC, every sensor node will be allocated a couple of a timeslot and a channel that is supposed to be 2-hop conflict-free. In MC-LMAC, time is divided into frames. Each frame consists of two stages: a control stage and a data transmission stage. Amid the control stage, each node changes to the regular control channel and uses their allocated timeslot to start a communication with the intended receiver. Amid the data transmission period, the intended receiver changes its transceiver to the sender’s data channel for packet exchange. MC-LMAC encounters higher idleness when compared to contention-based protocols. In fact, according to MC-LMAC, when a node has a packet to send, it must sit tight for its timeslot to begin the handshaking. Furthermore, a node needs to wait until finishing the control stage to begin data transmission. In addition, since the data transmission stage lasts for one packet only, a sender node is obliged to experience the control stage again when it has more data packets for the same receiver.

Regret matching-based channel assignment algorithm

Regret matching-based channel assignment algorithm (RMCA) is a multichannel contention-based MAC protocol that uses semi-dynamic approach as a channel assignment mechanism. ¹³ According to RMCA, each node is assigned a channel. After that, a node notifies its neighbors by broadcasting the assigned channel on the CCC. RMCA divides the time into stages. For each stage, a channel is randomly selected by each node. Then, each node calculates a utility function of the selected channel. The utility function is based on two metrics: the valid receiving ratio (VRR) and the average packet transfer delay (ATD). VRR is the ratio of the successfully received packets to the all sensed packets, while the ATD is the ATD of the successfully received packets. The output value from the utility function is used in a modified regret matching (MRM) procedure, which calculates the average regret from the current selected channel to the other channel. When the selected channel of the current stage is different from the next stage, the node broadcasts the newly selected channel on the CCC. Although RMCA requires few control packets exchanged for channel selection, it suffers from idle listening because of always-on receivers. Furthermore, no mechanism is used to abstain from waking up on a busy channel, which may cause the multichannel hidden node problem. In addition, the system is memory-based, where future channel prediction is based on the past knowledge. This may result in consumption of the limited memory and energy resources.

MCPS protocol description

To successfully design a multichannel MAC protocol for WSNs, two issues need to be carefully addressed since they highly affect the performance of the multichannel MAC protocol: (1) how often a given data channel is assigned to the nodes and (2) what are the used criteria to select a channel from the available ones. To address the first issue, the researchers dynamically allocate channels to nodes for communication. In other words, a channel is selected and assigned to communication nodes before each data transmission. To handle the second issue, the researchers allocate data channel for communication based on the distance separating a pair of nodes. To the best of the authors’ knowledge, MCPS is the first MAC protocol that uses DBCA technique.

In this section, a detailed explanation of MCPS protocol operation is conducted. First, the researchers describe the use of adaptive transmission power as a channel assignment mechanism. After that, they thoroughly clarify the MCPS functioning in terms of the sender, the receiver, and the overhearer behaviors. Finally, they discuss the main design aspects of MCPS, which are the use of adaptive power preamble transmission, the use of the more bit feature to adapt MCPS to high traffic load, and the usage of the meeting table to alleviate multichannel challenges.

DBCA technique

MCPS is built on the top of the IEEE 802.15.4 protocol. Accordingly, there are 16 non-overlapping channels in the network, with each channel having equal bandwidth of 2 MHz as defined by IEEE 802.15.4 and shown in Figure 3. The researchers dedicate the first channel in the range, which is channel number 11 as a common default control channel. This channel allows each potential sender to meet and wake up its intended receiver using a preamble sampling technique. Other channels, that is, channels 12–26), are devoted for data transmissions.

Figure 3.

Graphical representation of the IEEE802.15.4 channels.

According to MCPS, A node dynamically selects a data channel based on the distance separating it from the receiver. Let us denote by Ch_data the set of data channels. In MCPS, the researchers suppose that each sensor node is capable of using multiple transmission power levels depending on the distance separating a pair of neighbor nodes. Indeed, for each range of distance separating a pair of nodes, a dedicated transmission power will be used and a dedicated data channel will be selected for data communication. In this work, since MCPS is built on top of IEEE 802.15.4, 15 ranges of distances are defined. For each range of distance, a dedicated transmission power is used and a dedicated data channel is selected. Let us suppose that a pair of sensor nodes, say u and v, that are within a distance d from each other want to communicate. Note that d ⩽ d_max where d_max is the maximum distance that can be reached using the maximum available transmission power, which is defined as 45 m. In particular, the distance d is within one of the 15 defined ranges, say range r_i. Accordingly, u and v will use the corresponding transmission power P_i and the data channel Ch_i to communicate. For clarification purposes, Figure 4 shows the channel assignment mechanism used in MCPS. As depicted in Figure 4, for instance, the distance between S1 and S2 is 9 m, which corresponds to the range r₁ as shown in Table 1. Accordingly, node S1 and S2 will communicate through data channel 12 with a transmission power that corresponds to 10 m. This simple mechanism allows to distributively allocate a data channel for every pair of neighbor nodes without requiring any extra packet exchange. Indeed, MCPS combines both adaptive transmission powers with multiple channels in simple asynchronous manner to assign data channels for every pair of communicating nodes. To the best of our knowledge, no multichannel MAC protocol combines these two approaches to deal with WSN challenges.

Figure 4.

Channel assignment mechanism in MCPS.

Table 1.

The transmission ranges of IEEE 802.15.4 channels.

Channel number	Carrier frequency (GHz)	Transmission range (m)	Transmission power (dBm)
11 (the common control channel)	2.405	r 0 [0–45]	−26.9
12	2.410	r 1 [0–10]	−39.9
13	2.415	r 2 [10–12.5]	−37.9
14	2.420	r 3 [12.5–15]	−36.3
15	2.425	r 4 [15–17.5]	−35
16	2.430	r 5 [17.5–20]	−33.8
17	2.435	r 6 [20–22.5]	−32.8
18	2.440	r 7 [22.5–25]	−31.8
19	2.445	r 8 [25–27.5]	−31
20	2.450	r 9 [27.5–30]	−30.2
21	2.455	r 10 [30–32.5]	−29.5
22	2.460	r 11 [32.5–35]	−28.9
23	2.465	r 12 [35–37.5]	−28.2
24	2.470	r 13 [37.5–40]	−27.6
25	2.475	r 14 [40–42.5]	−27.1
26	2.480	r 15 [42.5–45]	−26.6

In fact, there are 15 ranges of distances corresponding to 15 data channels, where the 15th transmission range corresponds to the maximum transmission range. Table 1 explains the assignment of different transmission ranges to IEEE 802.15.4 available channels. Note that the transmission range starts by 10 m for channel 12 with an increase by 2.5 m for every new range that corresponds to the next defined data channel. In other words, the transmission range starts with 10 m and increases by 2.5 m for each channel until it reaches the maximum, which is 45 m for channel number 26. Note that, in channel number 11, which is the CCC, nodes can use any of the defined transmission ranges based on the distance between the nodes.

Overview of MCPS protocol

MCPS is a low-power medium access control protocol designed for WSNs using a single half-duplex transceiver. MCPS is a contention-based MAC protocol operating on multichannel using preamble sampling technique. Accordingly, there is a CCC and multiple data channels. Nodes use the random access protocol CSMA/CA as medium access technique for both the CCC and the data channels. Accordingly, nodes are competing on the CCC to access the medium in order to send the preamble. However, CSMA/CA is used in the data channels as precaution to avoid any possible collisions. In the CCC, which is the default active channel, all sensor nodes are in the sleep mode. Each sensor node having a data packet to send uses the preamble sampling technique to wake up its intended receiver. It is worth pointing out that, in the common channel, the wake-up preamble is sent using the minimum transmission power. This means that the sender uses the right transmission power that corresponds to the distance between the sender and the receiver. Hence, it uses the minimum power to deliver the preamble to the intended receiver and hence waking it up. Once the destination woke up on the CCC, the sender and the receiver switch to the appropriate data channel to directly send data packet and acknowledgment (ACK). Here again, data exchange is transmitted using the minimum transmission power on the corresponding data channel.

The preamble sampling technique on the CCC is illustrated in Figure 5. It consists in periodically sampling the medium to check for activity. The sampling period is denoted with T_W, where the letter W refers to wake-up. The time during which the received signal strength is measured is denoted with T_L. If a node finds the medium busy, it continues listening until it receives a meaningful packet or until the medium becomes idle again. At the transmitter, a wake-up preamble of a maximum size equal to the sampling period T_W is transmitted ahead of every data packet to ensure that the receiver will be awake in the appropriate data channel when data transmission begins. According to MCPS, the wake-up preamble consists of temporally spaced burst of short packets each including some useful information. Specifically, each short packet contains, most importantly, the destination identifier (ID), thus allowing overhearing nodes to return to sleep for the purpose of reducing the overhearing cost especially in terms of energy. Note that, if a node finds the common channel busy, the average overhearing duration is (3 × T_{short_packet})/2. This value assumes the reception of half short packet in average, followed by the reception of a complete meaningful short packet. The short packet also includes information about the chosen data transmission channel and the estimated end time of communication as shown in Figure 6. As such, the overhearer would not trigger a communication with neither the sender nor the receiver until the estimated end time of communication elapses. Moreover, the researchers suggest inserting a gap between two successive short packets.

Figure 5.

The preamble sampling on the common control channel.

Figure 6.

The format of MCPS short packet.

In order to avoid a receiver going back to sleep in case it wakes up in a gap of the burst, MCPS imposes that the listening period lasts at least the gap period, each time a node wakes up to sample the common channel

$$T_{\mathrm{EA}}+T_{C\_\mathrm{PROP}}⩽T_{\mathrm{gap}}⩽T_L$$

where T_{C_PROP} refers to the maximum propagation time over the maximum transmission distance d_max

$$T_{C\_\mathrm{PROP}}=\frac{d_{\max }}{V_s}$$

where V_s refers to the nominal speed of sound in the air.

According to our MCPS, the wake-up preamble length has to be at least

$$T_W⩾T_{C\_\mathrm{DATA}}+T_{C\_\mathrm{ACK}}+2\times T_{C\_\mathrm{PROP}}$$

where T_{C_DATA} and T_{C_ACK} refer to the data transmission time and acknowledgment transmission time hypothetical in the common channel, respectively.

As shown in Figure 5, the sender switches to the agreed data channel once it receives the early acknowledgment (EACK). An EACK is sent by a node when it receives a short packet that is intended to it. The EACK feature is introduced in MCPS in order to save energy and increase the throughput. Indeed, according to MCPS, whenever a sender node receives an EACK, it will stop sending short packets and thus both communicating nodes will switch to their dedicated data channel to start exchanging data packets. Similarly, the receiver switches to the data channel after sending the EACK. By doing so, the protocol tries to use a reduced preamble length to start data communication. Moreover, as mentioned earlier, the preamble and the EACK are sent using the minimum transmission power that corresponds to the distance separating the two communicating nodes. This alleviates collisions and interference in the CCC and allows simultaneous collision free preamble exchanges by other nodes that are outside the transmission range of the current transmitter node.

Receiver behavior

All nodes in the network sample the medium with the same constant period T_W, but their relative sampling schedule offsets are independents. Having no packet to send, each sensor node sleeps and periodically wakes up on the CCC to sample the medium for T_L period of time. If the channel is idle, the node returns to sleep. Otherwise, the node remains awake until the correct reception of a short packet. Once a short packet is correctly received, first the sensor node verifies if it is the actual target receiver of the short packet. If so, the receiver starts by sending an EACK confirming the chosen data channel ID and the start time of the transmission, T_start. Note that, in such case if the chosen channel is already busy, the receiver updates the T_start to be the estimated end time of current transmission on the chosen channel. Furthermore, the receiver updates the estimated end time of communication proposed by the sender to include the new T_start and send it in the EACK. Then, the receiver returns to sleep until the updated start time of the data transmission, in order to further reduce the energy consumption. At the precise data transmission time T_start, the receiver switches to the chosen data channel to receive the upcoming data packets. However, if the received short packet was intended to another node, the overhearer keeps track of the sender, receiver, and data channel identifier along with the announced estimated value of end of communication time in a table called hereafter the meeting table. Further details regarding the meeting table are discussed later. By doing so, the overhearer avoids waking up a busy node and especially avoids communicating on a busy channel. In other words, if the overhearer, after a while, wants to send a packet to a well-defined node, first it has to check its meeting table. If the node and the chosen data channel are not busy, the overhearer, which is now a sender, will proceed sending a wake-up preamble. Otherwise, it has to defer its preamble transmission until the estimated end time of communication. The estimated end time of communication is to be calculated by the sender and simply reads

$$T_{\mathrm{estm}\_\mathrm{end}}=T_{\mathrm{start}}+T_{C\_\mathrm{DATA}}\times \mathrm{BS}+T_{C\_\mathrm{ACK}}$$

where the T_start is the start time of transmission and the T_{C_DATA} is the transmission time of a data packet. The BS is the number of data packets intended to that receiver in the sender queue. The T_{C_ACK} is the transmission time of data ACK. It is worth pointing out that T_{estm_end} includes the time required to send the entire data packets in the sender’s queue for that receiver, as it includes the burst size, which make it more accurate. T_start is calculated using the following formula

$$T_{\mathrm{start}}=\mathrm{ST}+T_{\mathrm{Short}\_\mathrm{Pkt}}+T_{\mathrm{EACK}}+2\times T_{C\_\mathrm{PROP}}$$

where ST is the current simulation time, T_{Short_P kt} is the transmission time of the short packet, and T_EACK is the transmission time of EACK.

Furthermore, if a node succeeds to correctly receive an EACK during T_L, here again the node has to keep track of the sender, receiver, and data channel identifiers along with an estimated value of end of communication in its meeting table. As a result, such mechanism will participate in further reducing the hidden node effect in a multichannel scheme. Figures 7 and 8 illustrate the receiver behavior on the CCC and on data channel, respectively.

Figure 7.

The receiver behavior on the common control channel.

Figure 8.

The receiver behavior on data channels.

Transmitter behavior

By default, every sensor node in the network periodically samples the common channel. A node having a packet to transmit will precede it with a preamble of maximum length T_W in order to wake up a well-defined receiver at the appropriate time on the corresponding data channel. Recall that the wake-up preamble is a burst of short packets each including the sender identifier, the destination identifier, the estimated end time of data transmission, and the data channel identifier. Before transmitting, a node n₁ first senses the common channel for T_L. Now, on one hand, if the medium is idle, the sender has to check its meeting table. If the potential receiver is busy, then n₁ will defer its transmission until the estimated end time of communication on that channel. In the same way, if the chosen data channel j, corresponding to a transmission over a distance d_j, is busy with a communication between n₂ and n₃ and that n₁ is at most d_j distant from any one of them. Then, here again n₁ will defer its transmission till the estimated end time of communication on channel j. Otherwise, the sender proceeds by sending short packets on the CCC and wait for the EACK for T_gap. On the other hand, if the medium is busy, the sender keeps on listening until the reception of a correct short packet or an EACK. Note that, in such case, the sender will adopt the receiver behavior explained in the previous subsection. In other words, once a short packet not intended to the sender is correctly received, the sender is back to sleep mode for future medium sampling at the next scheduled periodic wake-up time since the CCC is already busy with a wake-up preamble transmission. As discussed later, such mechanism will further alleviate the congestion and hence any possible collision on the CCC will be avoided to the most possible extent. Now, if the transmitter succeeds to send a burst of short packets and that, an EACK is received, the sender first verifies if it is the actual receiver. If so, the sender checks the T_{estm_end} along with the received EACK. If the received T_{estm_end} in the EACK is greater than the T_{estm_end} proposed by the sender in the sent preamble, it means the channel is busy right now; then, the sender sleeps until T_Start proposed by the receiver in the received EACK, which is equal to the estimated end time of current transmission on the chosen data channel. After that, the sender wakes up and switches to the chosen data channel to start data transmission. Figures 9 and 10 demonstrate the sender behavior on the CCC and data channel, respectively.

Figure 9.

The sender behavior on the common control channel.

Figure 10.

The sender behavior on data channels.

Adaptive power preamble transmission

As mentioned earlier, the preamble transmission on the CCC is achieved using the minimum required transmission power to reach a given destination. Using the minimum required transmission power enhances the spatial reuse of the CCC especially compared to the use of the maximum transmission power. Indeed, as the transmission power decreases, closer nodes can transmit simultaneously without any interference as explained in Figure 11. For example, suppose node S₁ is sending preamble to node R₁ using transmission range r_i. Simultaneously, node S₂ can send preamble to node R₂ on the common channel given that both S₂ and R₂ are farther than r_i from S₁ and R₁. Thus, the smaller the transmission range r_i is, the closer the couple (S₁, R₁), (S₂, R₂) are. Thus, more nodes will be able to use the CCC simultaneously without interference, and hence, the spatial reuse is enhanced. By doing so, the congestion and so does the collision on the CCC especially when the traffic rate is high is alleviated. Recall that, using a single CCC scheme on dense network is not preferable because of the bottleneck that may be caused. However, using different transmission ranges on the CCC, in addition to the more bit feature that is explained in more detail in the following section, will considerably limit the bottleneck effect as it allows for more nodes to use the same channel concurrently. Therefore, the use of adaptive transmission power for sending preamble and early acknowledgment on the CCC is foreseen to reduce the end-to-end delay and hence improve the throughput.

Figure 11.

Spatial reuse for the common control channel.

High traffic support

MCPS is an adaptive duty-cycled MAC protocol that depends on the traffic load in the network. According to MCPS, a node is by default in the sleeping mode. It will switch to the active mode only if it detects an activity on the channel or it receives a packet from the application layer. By doing so, when the data generation rate is high or nodes in the network are rather active, nodes will have less sleeping period which will enhance the network throughput and energy efficiency while being adaptive to the network load.

Furthermore, MCPS protocol supports the burst data transmission, which is also found in a number of MAC protocols for sensor networks,^14,15 thanks to the use of the more bit in the header of data packets. When this bit is set to 1, it indicates that more data packets destined to the same sensor node are waiting in the buffer of the transmitting node. When a data packet is received with the more bit set, the receiving sensor node continues listening on the same data channel. Consequently, remaining on the same data channel, the sender will proceed transmitting the following data packet right after having received the acknowledgment, without getting back to the common channel in order to wake up the same previous receiver (see Figure 12). Therefore, the end-to-end delay is decreased and the throughput flowing through a given forwarder is increased. Furthermore, the use of more bit alleviates the congestion since a single handshaking in the CCC will be enough to send burst of data packets. Consequently, the energy consumption is further reduced as nodes do not need to go back again to the CCC for a new handshaking with the same target host.

Figure 12.

The more bit conception.

The meeting table

Recall that each node in the network maintains a meeting table, which contains information retrieved from the short packets that are received during the preamble sampling on the CCC. More precisely, whenever a node overhears a short packet in the CCC, it will add in its meeting table: the MAC address of the source node, the MAC address of the destination node, the channel in which the source and the destination nodes will communicate, and the estimated end time of communication. Based on that, when a node wants to initiate a communication, as shown in Figure 9, it first checks its meeting table to make sure that the intended receiver is not busy with another node. If so, the sender defers the transmission until the estimated end time of communication. However, if the sender after checking its meeting table finds the receiver idle; then, it will proceed sending the preamble. Recall that the preamble will be transmitted as a series of temporally spaced short packets. During the time gap between two successive short packets, the sender will wait for possible EACK from the target receiver. If, however, the sender receives an EACK from the intended receiver that it is destined to another node, which means that the receiver has agreed on a communication with another node, then, in this case, the sender will update its meeting table, stop sending the preamble, and sleep until the estimated end time of communication with that receiver. By doing so, the missing receiver problem is alleviated, which is considered as one of the main multichannel challenges as described in section “Introduction.”

Furthermore, according to MCPS, any sensor node may overhear either a short packet or an early acknowledgment. In this case, the overhearer keeps track of the sender, receiver, and data channel identifiers along with an estimated value of end of communication in its own meeting table, in order to avoid potential hidden node collision. Note that, such mechanism is proposed in order to further mitigate the hidden node effect in any data channel.

In fact, as shown in Figure 13, in order for the hidden node effect to occur on a data channel, the following requirements should be satisfied:

1. A succeeds to wake up B on data channel j.

2. C, at most d_j distant from B, succeeds to wake up its own receiver D on the same data channel j nearly at the same time.

3. C misses the early acknowledgment from B.

Clearly, the combined occurrence of these three events is not very likely. Consequently, the hidden node effect, in MCPS, is naturally reduced in a data channel thanks to the combined use of EACK, the meeting table, and especially the multichannel communication scheme.

Figure 13.

The hidden node effect.

Performance analysis

This section is dedicated to evaluate the performance of MCPS and to assess its efficiency compared to McMAC ¹⁶ and X-MAC ¹⁷ protocols. To do so, different performance metrics will be evaluated, namely, the preamble collision probability, the end-to-end delay, the throughput, and the energy consumption per useful bit.

In fact, the total number of nodes in the network is not a parameter of the study since we conceive and evaluate a MAC protocol that is by design a hop by hop protocol. Therefore, the researchers rather consider and vary the number of 1-hop neighbors for each node. Accordingly, they have implemented three network scenarios to show the effectiveness of the proposed protocol as follows: (1) regular low-density network scenario, where the number of neighbors for each node varies between 4 and 7; (2) regular high-density network scenario, where exactly each node has 15 neighbors; and (3) random network scenario, where each node has a random number of neighbors. Consequently, in order to satisfy the requirements of the three scenarios in terms of number of neighbors, the researchers rather consider an extremely large network where they neglect the border effect, as nodes at the network edges do not satisfy the required number of neighbors. Results show that MCPS outperforms McMAC and X-MAC in terms of end-to-end delay, throughput, and energy conservation.

Overview of OMNET++ simulator

OMNET++ simulator is used to evaluate the performance of MCPS protocol. The researchers choose OMNET++ for the following reasons:

1. It has a variety of built-in protocols and models.

2. OMNET++ has a great flexibility in building network topologies as it has simple GUI.

3. It has simulation libraries implemented in C++ language, which is more suitable for WSN simulation as it provides the hierarchical module implementation.

4. Besides the graphical runtime environment, its running and debugging performance are very efficient as it does not take long time or consume too much memory.

5. It has the capability of dividing the radio spectrum into separate channels, which allow us to modify the physical layer to enable the multichannel communication.

6. It is an open-source software that is managed by active community of developers. ¹⁸

Overview about the result analysis process

The researchers compare the performance of MCPS protocol with X-MAC ¹⁷ and McMAC ¹⁶ protocols. On one hand, X-MAC is a single-channel protocol that uses strobed preamble sampling technique similar to MCPS. According to X-MAC, all nodes compete to access the single shared channel which may increase the waiting time that will result in high end-to-end delay, high energy consumption, and low throughput. Furthermore, a preamble is needed before each data transmission since it does not support data burst traffic, unlike MCPS, where a sender can send burst of data packets with single preamble thanks to the more bit feature. On the other hand, McMAC is a multichannel preamble sampling MAC protocol. McMAC takes advantage of the multichannel support in IEEE 802.15.4 similar to our protocol. However, the channel assignment mechanism of McMAC is based on a hypothetical hash function that equally distributes the number of the available nodes to the number of the available channels in a Round Robin manner. For example, if the number of the available nodes is 64, then four nodes will be assigned the same base channel since there are 16 channels in IEEE 802.15.4 standard. Consequently, there is neither a guarantee of 1-hop conflict-free channel assignment nor the 2-hop conflict-free one, since more than one node in the same neighborhood can simultaneously use the same channel, which may result in hidden node collision, unlike MCPS, where a 2-hop conflict-free channel assignment can be guaranteed for up to 15 neighbors as explained in section “DBCA technique.” Furthermore, MCPS uses the meeting table in order to first avoid the missing receiver problem and second to further mitigate any possible collisions especially in extremely dense network. McMAC uses semi-dynamic channel assignment technique, where all nodes are assigned a fixed channel and when a node wants to communicate with other node, it will switch to the intended receiver home channel. According to McMAC, the sender switches to the receiver’s home channel for communication. When a node has a packet for transmission, it will perform triple clear channel assessment (CCA) before starting preamble transmission to make sure the receiver’s home channel is idle. Note that in McMAC, the triple CCA is proposed to ensure that a sender node is not sensing a channel during the gap between two successive preambles. Compared to MCPS, a more efficient mechanism, which imposes the CCA period to last at least for the duration of this gap, is used, as explained earlier. According to McMAC, if the channel is idle, the transmitter will send preamble and waits for an early ACK. Once an early ACK is received, it will proceed with data transmission.

In MCPS, the default bitrate, which is 250 kbps, is used. The transmission range for McMAC and X-MAC is 45 m. The transmission power for MCPS protocol varies based on the transmission range between the sender and the receiver for a maximum of 45 m. For MCPS and McMAC, they use all the 16 available channels. In order to meticulously and exclusively assess the performance of MCPS protocol, while ignoring the impact of any other layer, the researchers used a single hope scenario (one-to-one) with a queue of size 80 packets. At the beginning, each node wakes up randomly at a time between 0 and 1 s. The preamble short packet, the early ACK, and the data ACK have the size of 80 bits, while the size of data packets is 320 bits. Table 2 summarizes the simulation parameters that are common between all the evaluated protocols. Recall that the slot duration equals the sleeping period, which is the duration between two successive channel sampling times. The check interval, T_L, is the period during which a node is listening to the channel, and T_gap is the time between two successive short packets transmissions.

Table 2.

General simulation parameters.

Slot duration (TW)	1 s
Check interval (TL)	0.01 s
Tgap	0.01 s
Queue size	80
Bit rate	250 kbps
Transmission range	45 m
Control packet length	80 bits
Data packet length	320 bits

It is worth pointing out that in addition to the comparison with McMAC and X-MAC protocols and looking for the best version of MCPS protocol, the researchers assess the performance of three variant versions of MCPS protocol based on the sending mode of the preamble in the CCC. In fact, four basic modes of sending the preamble are possible with MCPS. The first mode is called the ShortPreamble, which means that the transmitter keeps sending the preamble’s short packets until it receives an early acknowledgment EACK. Once the EACK is received, the sender will immediately switch to the data channel and proceed transmitting data. The second mode is called LongPreamble mode where the sender keeps sending preamble for the whole sleeping period even after it receives an EACK in order to inform a maximum number of neighbors about the outgoing communication and hence avoid potential hidden node data collision. The third mode is called the MaxPower, where the preamble is sent using the maximum transmission power that corresponds to the maximum transmission range. Finally, the last possible mode is, the MinPower, which means that the sender will use the right required transmission power that corresponds to the distance between the sender and the receiver. Hence, it uses the minimum power to deliver the preamble to the intended receiver and thus waking it up. Based on these modes, there are three variant implementations of MCPS protocol. These versions are different in the transmission of the preamble sampling technique. The First version is called MCPSShortPreambleMaxPower, which means that the preamble is sent using the maximum transmission power and will stop once the transmitter receives an EACK. The second version is called MCPSShortPreambleMinPower, which means that the preamble is sent using the minimum transmission power and will stop once the transmitter receives an EACK. Finally, the third version is called MCPSLongPreambleMaxPower, which means that the preamble is sent using the maximum transmission power and the transmitter continue sending the preamble for the whole sleeping period even if it receives an EACK. It is worth pointing out that the data, however, are always transmitted using the minimum transmission power in all MCPS versions in order to save energy as it is a unicast communication in a well-dedicated collision-free data channel.

The researchers analyze the performance of our protocol based on the end-to-end delay, the data waiting time before successful transmission, the throughput, the energy per bit, and the probability of preamble collision.

Both McMAC and MCPS implement the more bit feature, which allows a node to send burst of data packets per handshake instead of only one packet per handshake. Accordingly, the researchers investigate an additional performance metric, which is the data burst size that is calculated only for these two protocols.

Three network scenarios will be implemented to evaluate and compare the performance of the abovementioned protocols, namely, regular low- and high-density network scenarios in addition to the random network scenario. The next sections are devoted to assess the performance of the studied protocols according to these three network scenarios.

Regular low-density network scenario

In low-density network scenario as shown in Figure 14, there are 16 nodes that were distributed such that each node has between one and seven neighbors. Specifically, each node has only one neighbor on a given transmission range. Based on that, and according to MCPS, no two neighbors will be assigned the same data channel. Hence, there is no data collision on data channels because every data channel is dedicated for a data communication with a unique neighbor. Similarly, for McMAC, since there are 16 nodes, each node is assigned a unique data channel as a base channel. For simplicity, the researchers rename IEEE802.15.4 channels such that channel 11 will be referred to as channel 0, which is the common channel in MCPS, and channel 12 referred to as channel 1 and so on. For example, as shown in Figure 14, channel 15 assigned for data communication between nodes S7 and S8 corresponds to channel 26 in the standard.

Figure 14.

Regular low-density network topology.

Burst size

Figure 15 shows the effect of data generation rate on the data burst size. Recall that McMAC and MCPS use the more bit feature in order to send all the data packets destined to the same receiver once a pair of nodes succeed the handshaking. Hence, the burst size is the average number of data packets transmitted per handshake. As shown in Figure 15, the burst size of McMAC is increasing with the traffic rate because nodes have more packets on their queues for the same destination.

Figure 15.

The burst size in low-density network scenario.

Note that, similarly for all MCPS versions, the burst size is increasing with the traffic rate not only because nodes have more packets on their queues for the same destination but also because a collision-free data communication is guaranteed since every pair of neighbor nodes have a dedicated data channel, as opposed to McMAC where data communication is prone to collision with preamble transmission. Indeed, McMAC uses parallel rendezvous, which means the handshake, between the sender and the receiver, is accomplished in the receiver’s home channel. Hence, data packets are more likely to collide with preamble transmission on the node’s base channel, which will cause the abortion of the transmission of a burst of data packets. On the contrary, MCPS sends the preamble on the dedicated CCC in addition to the use of the distance-based data channel assignment along with the meeting table to mitigate data collision. Note that MCPS long preamble with maximum power has the highest burst size because each node has to send preamble for the whole sleeping period before starts sending data packets. In other words, the average preamble length is the highest and equals the sleeping period. Hence, more data packets will be accumulated in the queue for every possible destination that will be delivered at once when a given destination is met.

Probability of preamble collisions

Figure 16 shows the probability of preamble collision as function of the data generation rate. The probability of preamble collision refers to the total number of missed early ACK per the total number of transmitted preamble. As explained before, in low-density network scenario, there is no data collision in MCPS because each sender has a unique receiver on every data channel.

Figure 16.

The probability of preamble collision in low-density network scenario.

Generally, as shown in Figure 16, with the increased traffic rate, the probability of preamble collision is increasing for X-MAC while it is decreasing for McMAC and has convex upward behavior for all MCPS versions. The reader may expect that the probability of preamble collision should increase with the traffic rate even for McMAC and MCPS. However, thanks to the use of the more bit property, even with an increasing traffic rate, less handshaking are required since one successful preamble exchange will be enough to send a burst of data packets destined to the same receiver. Specifically for all MCPS versions, the probability of preamble collision has a convex upward behavior. Indeed, the effect of the traffic rate dominates when the traffic rate is less than 0.5 packets/s, causing the probability of preamble collision to increase, while the effect of the burst size takes over after a traffic rate of 0.5 packet/s, leading to a decrease in the probability of preamble collision. Note that MCPS is achieving much less preamble collision for all its versions than X-MAC and McMAC especially for a data generation rate greater or equal to 0.5 packet/s. More precisely, MCPS using short preamble with minimum transmission power achieves the lowest preamble collision probability since it uses a transmission power that rightly corresponds to the transmission range between the sender and the receiver nodes. Consequently, only nodes on that transmission range will receive the preamble and hence less interference between nearly simultaneous preamble transmissions is created. Unlike MCPS using short preamble with maximum power and MCPS using long preamble with maximum power, where both versions use the maximum transmission power to send strobed preamble and early ACK-like X-MAC and McMAC. Thus, farther nodes are receiving any preamble transmission and hence more interference is generated.

Waiting time

Figure 17 shows the average waiting time as function of the traffic generation rate. The waiting time refers to the queuing time till the successful sending of a packet. As expected and as shown in Figure 17(a), X-MAC has the worst waiting time because it is mainly a single-channel protocol. Packets will wait in the queue in order to have a chance to be send. More specifically, it starts with a constant delay because the traffic is still low and nodes mostly are sleepy; then, it starts decreasing when the data generation rate reaches one because the average waiting time is calculated relative to the successfully received packets. Indeed, increasing the data generation rate will decrease the total number of successfully received packets due to high collision as shown in Figure 16 and hence the average waiting time of the successfully received data packets will decrease. For clarification purposes, in Figure 17(b), we zoom in the multichannel protocols; namely; MCPS (with all its versions) and McMAC. As shown in Figure 17(b), the waiting time for McMAC is decreasing with the increased traffic rate thanks to the more bit, which allows a node to send burst of packets for the same destination instead of one data packet per handshake. Besides the more bit effect, the probability of preamble collision for McMAC as depicted in Figure 16 is decreasing with the traffic rate, which leads to a decrease in the waiting time too.

Figure 17.

The waiting time in low-density network scenario.

For clarification purposes, Figure 18 shows the waiting time for only the three versions of our protocol. As shown in Figure 18, the average waiting time shows a convex upward behavior due to two opposite main factors. On one hand, increasing the traffic generation rate will naturally increase the probability of preamble collision, which will increase the average waiting time. Moreover, the use of the meeting table by MCPS will contribute increasing the average waiting time. Indeed, according to MCPS protocol, when a node has a packet to send, it will start by checking its meeting table in order to avoid triggering a communication with a busy receiver. Besides, if the sending node senses a busy common channel, it will sleep for the whole sleeping period in order to alleviate the traffic on the common channel. On the other hand, raising the traffic generation rate will increase the data burst size as shown in Figure 15 thanks to the use of the more bit. Indeed, once a pair of nodes meet on their dedicated data channel after a successful handshaking, the sending node will deliver all the data packets in its queue destined to that neighbor thanks to the use of the more bit. Therefore, the waiting time is a compromise between the probability of preamble collision and the average burst size.

Figure 18.

The waiting time for MCPS MAC protocol.

As shown in Figure 17, all MCPS versions are achieving in average lower waiting time than X-MAC and McMAC while the lowest value is achieved by the MCPS version using short preamble with minimum power. Note, however, that the waiting time for the MCPS version using long preamble with maximum power has the highest value between all MCPS versions as shown in Figure 18 because it has the most accurate meeting table since any preamble exchange will be received by all the nodes in the neighborhood. In addition, it has the longest average preamble length, as it equals 1.

End-to-end delay

Figure 19 demonstrates the end-to-end delay as a function of the data generation rate. The end-to-end delay is the amount of time from the generation time of a packet until the successful reception of data ACK. Indeed, the end-to-end delay is affected mainly by the average waiting time. In fact, the end-to-end delay and the waiting time are completely correlated as depicted in Figure 20. Hence, they have similar behaviors.

Figure 19.

The end-to-end delay in low-density network scenario.

Figure 20.

Correlation between the waiting time and the end-to-end delay in low-density network scenario.

As a recap, comparing all the MCPS versions with X-MAC and McMAC, we can state that all MCPS versions are achieving lower end-to-end delay while the lowest values are accomplished with the MCPS version using short preamble with minimum transmission power.

Throughput

The Throughput refers to the total number of successfully received packets by all nodes during the simulation time. Figure 21 depicts the throughput of all the studied protocols as function of the traffic rate. Generally, the throughput of all protocols increases with the traffic rate except for X-MAC, which starts by normally increasing and then it decreases especially when the traffic rate reaches 0.5 packet/s. Indeed, for high traffic rate, the nodes are much competing for the channel access and hence the total number of preamble collisions will increase which will end up decreasing the X-MAC throughput.

Figure 21.

The throughput in low-density network scenario.

However, dealing with McMAC and MCPS protocols, the throughput is always increasing with the traffic rate thanks to the increase of the data burst size due to the more bit effect. It is worth pointing out that our protocol MCPS achieves the highest values of throughput, while the maximum is reached by the MCPS version using short preamble with minimum transmission power.

Energy per bit

Figure 22 shows the average energy per bit (EpB) consumed by each protocol. The energy per bit is the total consumed energy by all the nodes during the network lifetime divided by the total number of successfully received data packets. Generally, the energy consumption of MCPS and McMAC protocols decreases with the traffic rate while it increases for X-MAC. The main two factors that affect the energy consumption are the preamble collision and the data burst size. Since the preamble collision for X-MAC increases with the traffic rate, the total consumed energy is increasing too. In addition, X-MAC does not implement the more bit feature, so a preamble is needed to be sent before every data packet, which will highly increase the total energy consumption. On the other hand, the energy consumption per successful bit for McMAC and MCPS protocols is decreasing with the traffic rate thanks to the use of the more bit feature. Consequently, for these protocols, one preamble handshaking is enough to send a burst of data packets, which will decrease the total consumed energy per successful bit.

Figure 22.

The energy per bit in low-density network scenario.

Note that the MCPS version using short preamble with minimum power achieves the lowest energy consumption since it uses the right needed power to reach a given receiver. Thus, MCPS is the most energy efficient protocol.

Regular high-density network scenario

In this scenario, we want to test the protocol on high-density network in order to investigate the maximum achievable performance gain for MCPS protocol when it uses all the available 16 channels. The total number of nodes in this scenario is 61 nodes where 16 among them have each 15 neighbors. For MCPS protocol, the nodes are distributed such that each node has at most 15 neighbors on different 15 data channels. The 16th channel is used as a common channel. For McMAC protocol, their channel assignment technique is based on a virtual hash function that distributes the nodes equally on the available channels. Consequently, with 61 nodes in the network, three to four nodes are sharing the same data channel. Figure 23 shows the topology of high-density network scenario. As depicted in the figure, for instance according to MCPS, node S1 has 15 neighbors each on different data channel.

Figure 23.

High-density network topology.

Burst size

Similar to the low-density network scenario, as shown in Figure 24, the burst size of McMAC and MCPS are increasing with the traffic rate thanks to the more bit feature, which allows the transmission of a burst of data packets to the same destination instead of one packet per communication. When the data generation rate increases, there will be more packets to the same destination that are waiting in the queue. For MCPS, there is no data collisions on data channels, hence the burst size will increase with the traffic rate because the nodes will proceed sending all the packets in the queue without abortion due to collisions. MCPS long preamble with maximum power has the highest burst size as expected because each node has to send preamble for the whole sleeping period before starting data transmission.

Figure 24.

The burst size in high-density network scenario.

Preamble collision

Figure 25 shows the preamble collision as function of the data generation rate. Unlike the low-density network scenario, the preamble collision has convex upward behavior for X-MAC. It increases from 0.1 to 0.5 packets/s and then it tends to have a little decrease after 0.5 packets/s. The reader may expect the preamble collision probability to increase with the traffic rate for X-MAC in a high-density network scenario as it is a single-channel protocol, where more nodes compete to access a common shared medium. Indeed, according to X-MAC operation, if a node has a packet to send, it first checks the channel activity. If the channel was busy, the node sleeps for the whole sleeping period to alleviate traffic. Therefore, although in high-density network the number of nodes is higher than in low-density network, much more nodes are sleepy with the increased traffic rate since the channel is busier due to the higher density of the network. As a result, packets will wait much more in the queue than in low-density network scenario. Therefore, for high traffic generation rate, the preamble collision will decrease due to nodes inactivity, as more nodes are sleepy due to a more active medium.

Figure 25.

Preamble collision probability in high-density network scenario.

Similar to the low-density network scenario, the preamble collision for McMAC is decreasing with the traffic rate due to the increase in the burst size. Similarly, the preamble collision for MCPS using long preamble with maximum transmission power is decreasing with the traffic rate thanks to the use of the more bit feature which will increase the data burst size. Similar to the low-density network scenario, in MCPS version using short preamble with maximum transmission power and MCPS version using short preamble with minimum transmission power the probability of preamble collision has a convex upward behavior. As explained in the low-density network scenario, the effect of the traffic rate dominates for a traffic rate between 0.1 and 0.5 packets/s, causing the probability of preamble collision to increase, while the effect of the burst size takes over when the traffic rate exceeds 0.5 packet/s, which leads to a decrease in the probability of preamble collision. The MCPS version using short preamble with maximum transmission power achieves lower preamble collision probability than MCPS version using long preamble with maximum transmission power since the preamble transmitter stops sending preamble as soon as it receives an early ACK. Hence, using short preamble will inevitably reduce collision compared to the use of long preamble, especially for high dense network. Moreover, the MCPS version using short preamble with minimum transmission power further reduces the preamble collision probability since it is not only using short preamble but also accompanied by the use of less transmission power which will create less interference. Thus, the MCPS version using short preamble with minimum transmission power is achieving the lowest preamble collision probability.

Waiting time

Figure 26 shows the waiting time as function of the data generation rate. As mentioned earlier, the waiting time is affected mainly by the preamble collision and the data burst size. When the data burst size increases, the waiting time decreases, and when the preamble collision increases, the waiting time will also increase. As shown in Figure 26(a), X-MAC has the highest waiting time, although it has a very low preamble collision as shown in Figure 25, which is supposed to result in a low waiting time too. As we mentioned in the previous subsection, although the number of nodes in this scenario is high compared to the low-density network scenario, for X-MAC, the number of active nodes in high-density scenario is much less than the one in low-density scenario due to higher nodes’ activities. As a result, the number of data packets that are waiting in the queue increases with the traffic rate because the majority of nodes are sleepy. As shown in Figure 26(b), similar to the low- density network scenario, the waiting time for McMAC is decreasing because of the increase in the burst size. The waiting time of the MCPS version using long preamble with maximum transmission power is decreasing with the traffic rate similar to McMAC thanks to the increase in the data burst size and the decrease of the preamble collision. Similar to the low-density network scenario, the MCPS version using short preamble with maximum transmission power and the MCPS version using short preamble with minimum transmission power have a convex upward behavior due to the preamble collision and the burst size. Indeed, the waiting time starts increasing due to the increase in the preamble collision and then it decreases when the data generation rate exceeds 0.5 packet/s due to the increase in the burst size.

Figure 26.

The waiting time in high-density network scenario.

End-to-end delay

Figure 27 shows the end-to-end delay in high-density network scenario as function of the data generation rate. As shown in Figure 28, the end-to-end delay has a full correlation (equals to 1) with the waiting time. Therefore, the behavior of the end-to-end delay as function of the traffic is well justified by the waiting time behavior.

Figure 27.

End-to-end delay in high-density network scenario.

Figure 28.

The correlation between the waiting time and the end-to-end delay in high-density network scenario: (a) X-MAC and (b) McMAC and MCPS.

Throughput

Figure 29 shows the throughput as function of the data generation rate. Recall that the throughput is mainly affected by the burst size and the preamble collision. It increases with increased burst size and decreases with the increased preamble collision. Although the preamble collision of X-MAC is very low as shown in Figure 25, which is supposed to result in high throughput, the throughput of X-MAC is the lowest because of the node’s inactivity as explained in the previous sections. Similar to the low-density network scenario, the throughput of McMAC and all the MCPS versions are increasing with the traffic rate due to the increased burst size. It is worth pointing out that the MCPS version using short preamble with minimum transmission power achieves the maximum throughput.

Figure 29.

The throughput in high-density network scenario.

Energy per bit

Figure 30 shows the average energy per bit (EpB) consumed by each protocol. Similar to the low-density network scenario, the average consumed energy per successful bit is decreasing with the traffic rate for McMAC and all the MCPS versions thanks to the increased burst size. Indeed, as the data burst size increases, the energy efficiency of these protocols will further increase since one successful preamble transmission will be enough to send more and more data packets. Unlike X-MAC in low-density network scenario, the energy consumption is decreasing in high-density network scenario due to the increase in the number of inactive node. Indeed, when the traffic rate increases, the number of inactive nodes are larger than the number of active nodes, which results in low energy consumption. In fact, the effectiveness of X-MAC protocol decreases with the increased traffic rate, as most of the time nodes are sleepy. This is proven by the high waiting time of X-MAC as shown in Figure 26(a).

Figure 30.

Energy consumption in high-density network scenario.

Similar to the low-density network scenario and as shown in Figure 30, the MCPS version using short preamble with minimum transmission power achieves the lowest energy consumption because it sends the preamble and the EACK with the minimum transmission power. Thus, MCPS is the most energy-efficient protocol even in high-density network scenario.

Random network scenario

In random network scenario, 60 nodes are scattered randomly in the sensor field. Among them, 28 nodes are sending to a number of neighbors from one to five. The purpose of this topology is to test the performance of MCPS on random topology, which is the common case on WSN. Figure 31 shows the topology of the studied random network scenario.

Figure 31.

The topology of random network scenario.

Burst size

Figure 32 shows the burst size as function of the data generation rate in random network scenario. Similar to the low-density and high-density network scenarios, the burst size of MCPS and McMAC increases with the traffic rate thanks to the use of the more bit, which allows sending burst of data packets to the same destination after one successful handshaking instead of one packet per handshake. As shown in Figure 32, the MCPS version using long preamble with maximum transmission power has the highest burst size because nodes send preamble for the whole sleeping period before starting data transmission. Hence, more data packets are buffered in the node’s queue.

Figure 32.

Burst size in random network scenario.

Preamble collision

Figure 33 shows the preamble collision probability as function of the data generation rate in the random network scenario. Similar to the low-density network scenario, the preamble collision for X-MAC increases with the traffic rate, while it decreases for McMAC and has a convex upward behavior for MCPS. As we mentioned earlier, X-MAC does not support the burst transmission, while McMAC and MCPS do by using the more bit feature. Therefore, X-MAC needs to precede each packet with a preamble transmission, which results in an increasing preamble collision especially when the traffic rate increases. As depicted in Figure 33, MCPS is achieving much less preamble collision for all its versions especially when the data generation rate exceeds 1 packet/s. Specifically, the MCPS version using short preamble with minimum transmission power is achieving the lowest preamble collision probability. Therefore, MCPS achieves the lowest preamble collision probability even in random network scenario.

Figure 33.

Preamble collision in random network scenario.

Waiting time

Figure 34 shows the average waiting time as function of the data generation rate in random network scenario. Similar to low-density and high-density network scenarios, X-MAC has the worst waiting time, as shown in Figure 34(a) because it is mainly a single-channel protocol. More specifically, it starts increasing for traffic rates between 0.1 and 1 packet/s because of the increase in the preamble collision and then it decreases when the data generation rate reaches 1 packet/s since the average waiting time is calculated relative to the successfully received packets. Therefore, increasing the data generation rate will decrease the total number of successfully received packets due to high collisions and hence the average waiting time of the successfully received data packets will decrease. For clarification purposes, in Figure 34(b), we zoom in the multichannel protocols, namely, MCPS (with all its versions) and McMAC.

Figure 34.

The waiting time in random network scenario.

Similar to the low- and high-density network scenarios, the waiting time for McMAC is decreasing with the increased traffic rate thanks to the more bit, which allows a node to send burst of data packets for the same destination instead of one data packet per handshake. Figure 35 shows the average waiting time for all the MCPS versions. Similar to the low-density and high-density network scenarios, the waiting time shows a convex upward behavior due to two opposite factors. On one hand, increasing the traffic generation rate will naturally increase the probability of preamble collision, which will increase the average waiting time. On the other hand, raising the traffic generation rate will increase the data burst size, which will decrease the average waiting time.

Figure 35.

The waiting time for MCPS protocol in random network scenario.

To sum up, all MCPS versions are achieving in average lower waiting time than X-MAC and McMAC while the lowest value is achieved by the MCPS version using short preamble with minimum transmission power.

End-to-end delay

Figure 36 shows the end-to-end delay in random network scenario as function of the data generation rate. Similar to the low-density and high-density network scenarios, and as shown in Figure 37, the end-to-end delay has a full correlation (equals to 1) with the waiting time. Therefore, the behavior of the end-to-end delay as function of the traffic is well justified by the waiting time behavior.

Figure 36.

The end-to-end delay in random network scenario.

Figure 37.

The correlation between the end-to-end delay and the waiting time in random network scenario.

Throughput

Figure 38 depicts the throughput of all the studied protocols as a function of the traffic rate. Similar to the low-density and high-density network scenarios, the throughput of all protocols are increasing with the traffic rate except for X-MAC, which starts by normally increasing; then, it decreases especially when the traffic rate reaches one packet/s. Recall that, for high traffic rate, the nodes are much competing for the channel access and hence the total number of preamble collisions will increase which will end up decreasing the X-MAC throughput. However, dealing with McMAC and MCPS protocols, the throughput is always increasing with the traffic rate thanks to the increase of the data burst size due to the more bit effect. It is worth pointing out that our MCPS protocol achieves the highest throughput values, while the maximum is reached by the MCPS version using short preamble with minimum transmission power because of the unique DBCA mechanism used by MCPS, the more bit, and the meeting table.

Figure 38.

The throughput in random network scenario.

Energy per bit

Figure 39 depicts the average consumed energy per successfully received bit. Similar to the low-density and high-density network scenarios, the energy consumption of MCPS and McMAC protocols decreases with the traffic rate while it increases for X-MAC as in low-density network scenario. As we mentioned earlier, the main two factors that affect the energy consumption are the preamble collision and the data burst size. The total consumed energy for X-MAC is increasing because the preamble collision is increasing with the traffic rate. In addition, X-MAC does not support data burst transmission, so a preamble is needed to be sent before every data packet, which will highly increase the total energy consumption. On the other hand, the energy consumption per successful bit for McMAC and MCPS protocols is decreasing with the traffic rate thanks to the use of the more bit feature. Consequently, for these protocols, one preamble handshaking is enough to send a burst of data packets which will reduce the total consumed energy per successful bit. As shown in Figure 39, the MCPS version using short preamble with minimum transmission power achieves the lowest energy consumption since it uses the right needed power to reach a given receiver. Thus, MCPS is the most energy-efficient protocol even in random network scenario.

Figure 39.

The energy consumption in random network scenario.

Summary

It is worth pointing out that in general, all MCPS versions outperform McMAC and X-MAC in terms of end-to-end delay, throughput, preamble collision, and energy conservation. Specifically, the MCPS version using short preamble with minimum transmission power achieves the lowest preamble collision, the highest throughput, and the highest energy efficiency. For instance, in random network scenario, which is the usual case of sensor networks, the end-to-end delay of the MCPS version using short preamble with minimum power is less than McMAC by 90.33% and less than X-MAC by 99.84%. The throughput of MCPS is better than McMAC by 9.20% and better than X-MAC by 45.80%. MCPS achieves an energy conservation of 52.34% and 17.72% compared to McMAC and X-MAC, respectively.

Indeed, MCPS is outperforming the existing multichannel MAC protocols thanks to three key features. First, the pioneer distance-based channel assignment allows MCPS a 2-hop conflict-free channel assignment for every pair of neighbors without requiring any extra packets exchange for negotiation. Thus, further energy saving is achieved and the throughput is improved. Second, the use of the more bit feature allows MCPS to highly reduce the energy and time cost as only one preamble exchange will be enough to send more than one data packet in the data channel, as opposed to X-MAC where a new preamble exchange is required for each data packet which highly consumes energy and time. However, McMAC is also using the more bit feature, but since the channel assignment strategy of McMAC is neither completely 1-hop conflict free nor 2-hop conflict free then data transmissions are more prone to collisions. Third, MCPS is using the meeting table in order to avoid the missing receiver problem and to further mitigate the hidden node collisions. Indeed, the meeting table will help a sender node to check the intended receiver availability before initiating the preamble transmission on the CCC which will help saving time and energy. Moreover, thanks to the meeting table, a sender node will check the availability of the data channel in case a neighbor or a hidden neighbor has been assigned the same data channel especially if the network density is so high. Consequently, the meeting table is considered as a double check technique to avoid the missing receiver problem and to further mitigate data collisions especially in high-density network scenario. Note that the aforementioned three techniques are the success keys of MCPS that allows the improvement of the network throughput as well as the energy efficiency.

Conclusion

Nowadays, WSNs applications require high data rates and timely data transmission with minimum energy consumption. One possible solution to satisfy such requirements is by using multichannel communication scheme. In this article, we propose a multichannel preamble sampling MAC protocol, MCPS, especially tailored for WSNs. MCPS uses DBCA mechanism, which is, to the best of our knowledge, the first multichannel MAC protocol that uses such assignment mechanism. By doing so, the channel assignment procedure is achieved in a simple, asynchronous way without requiring any extra packet exchange or any complex calculation which further improves the energy efficiency. MCPS uses adaptive power transmission for preamble/EACK transmissions on the CCC as well as for data/ACK packets on corresponding data channels. By doing so, in addition to the energy conservation achievement, MCPS reduces the common channel bottleneck as the use of the adaptive transmission power on the CCC allows for different pair of nodes on the same vicinity to accomplish simultaneous handshaking. Furthermore, according to MCPS, one successful handshaking on the CCC is enough to send all the data packets on the sender’s queue to that receiver thanks to the use of the more bit feature. This will further alleviate the traffic on the CCC, which results in low preamble collision. Consequently, the waiting time and the end-to-end delay decrease while the throughput increases. Simulation results show that significant improvement is achieved by our MAC protocol, MCPS, compared to the single-channel X-MAC protocol and multichannel McMAC protocol. Moreover, MCPS outperforms McMAC and X-MAC in terms of end-to-end delay, throughput, and energy conservation.