1 Introduction

Wireless sensor network “WSN” is one of the hottest topics in today’s research field. Its importance comes from its versatility and the various research fields and applications related to it. Health care, precision agriculture, military, industrial automation and home automation are some examples among other WSN applications; those can use this technology and take benefit from its various advantages. However, this versatility nature, if combined with the constrained wireless sensor network nodes, makes the design of any of its components very difficult and hard to meet different applications requirements. In this work we focus on communication protocols for WSN. More specifically, we are interested in MAC ‘Medium Access Control’ protocols. The latter can be considered as the first source of delay since it’s responsible for managing the access to the shared wireless channel. Most of the first proposed MAC protocols for WSN networks have the pre-occupation to minimize the energy consumption of the node [1] that is mainly consumed by the radio module [2]. However, these approaches increase the node life time at the expense of the delay and the other QoS metrics. The IEEE 802.15.4 [3] propose a flexible MAC sub-layer that can extend the node’s lifetime thanks to the duty cycle mechanism in addition to the delay and bandwidth guarantee by using the GTS mechanism. Nevertheless, this standard has several limitations to provide different application requirements. Many MAC protocols were proposed to solve to solve these issues using prioritization built upon the CSMA-CA random algorithms either by using the backoff exponent [4, 5] or the contention window [6–8]. Other researchers prefer to use a deterministic schedule to guarantee the required QoS [9–12]. Our FF-MAC protocol proposed in [13] belongs to the latter category and provide a deterministic end-to-end delay for delay sensitive applications.

The purpose of this study is to evaluate the performance of this protocol, which is introduced as an improvement of the IEEE 802.15.4 standard medium access protocol ‘MAC’ sub-layer, for application with real-time requirements. In our previous work, the performance evaluation was carried out using the WPAN [14] model in NS-2 [15] simulation tool. The obtained results proved the expected enhancements against the standard protocol. However, in order to evaluate the behavior of this protocol in real world environment, we propose in this paper a set of experiments carried out using real test-bed.

The rest of this paper is organized as follow; in Sect. 2, we review the proposed algorithm and discuss its improvements. Section 3 presents the performance evaluation methodology and tools used to test and validate both the implementation and the performance of the protocol against the GTS mechanism of the IEEE 802.15.4 standard. While in Sect. 4, we present and analyze the obtained results. We finish this paper by a conclusion and some perspectives for our future works.

2 Related Works and Proposed Algorithm

As described in [13], FF-MAC protocol is introduced as an enhancement of the IEEE 802.15.4 standard for application with heterogeneous traffic; real-time and best effort traffics. We know that in star topology, the communications between end devices have to pass through the coordinator and may be delivered at least in the next superframe. This rule is also applied to all the exchanges in the contention free period (CFP period) where communication is supposed to be real-time. This mode of communication has an important impact on energy efficiency, since the node wakes up only to transmit data or to receive the beacon and, if any, receive pending data from its coordinator. The network nodes can spend the rest of the time in sleep mode. On the other hand, this gain in energy efficiency is offset by a negative impact on the end-to-end delay, because of the indirect communication from the coordinator to the end device. In multi-source multi-sink communication model [16], the network nodes exchange data with each other and not only with a single sink node. Moreover, according to the IEEE 802.15.4 standard, the communication in the GTS must be done between the GTS owner and its coordinator. This forces the coordinator to keep the frame in its queue till the next superframe. However, delaying the transmission to the next superframe increase considerably the delay in low DC (duty cycle) networks, which is, in typical applications, anticipated to be less than 1 % according to the IEEE 802.15.4 standard specification. The IEEE 802.15.4 standard controls the Duty Cycle “DC” using the BO “Beacon Order” and SO “Superframe Order” parameters according to the following formula:

$$\begin{aligned} \text {Duty Cycle}=\frac{\text {SD}}{\text {BI}}=2^{\mathrm{SO-BO}}\text {(Symbols)} \end{aligned}$$
(1)

where, SD and BI denote the Superframe Duration and the Beacon Interval respectively.

The FF-MAC protocol is designed to solve this energy/delay trade-off by the guarantee of a deterministic end-to-end data delivery inside the same superframe. The enhancements, introduced in the superframe structure illustrated in Fig. 1, first propose a reordering of the contention access period (CAP) and the contention free period (CFP) periods. The reason behind this change is to give the coordinator the ability to forward time critical data, received in the CFP period, in the following CAP period. The results in [17] show that this modification in the superframe provides a better average delay performance than the standard MAC protocol. However, the delay is still influenced by the node density. And this is related to the nature of the CSMA-CA algorithm used in the CAP period.

Fig. 1
figure 1

Superframe structure according to FF-MAC protocol

Full size image

To solve this problem, we proposed in FF-MAC another improvement of the superframe by introducing the dynamic-contention free period (D-CFP) period located between CFP and CAP. The goal is to provide one or more timeslots called dynamically allocated guaranteed time slot (D-GTS) forming the D-CFP, that are used only to receive, from the coordinator, the pending real-time data transmitted in the foregoing CFP of the same superframe. In fact, at the end of the CFP, the coordinator lookup the pending real-time data in its queue and broadcast a new frame named pending real-time packets advertisement (PRTPA), indicating the scheduling of the new D-CFP or the start of the CAP period if no real-time pending data is available.

Fig. 2
figure 2

Example of wireless sensor network nodes and development kit used in this work

Full size image

This process allows a fast retransmission of the pending real-time data without need to wait until the next superframe. And therefore, the sleep time should have no influence on the end-to-end delay.

The performance evaluation were carried out by using NS-2 simulator and shown that our FF-MAC protocol outperforms the GTS mechanism defined in the IEEE 802.15.4 standard. However, in our applied research field, we need to confirm these results by using real world experiments. The latter allows us to test our protocol by introducing the sensors constraints and the real wireless media impairments.

3 Performance Evaluation Tools

The usage of real wireless sensor network nodes has an important impact on the experiments results, since all the simplification and inaccuracy introduced in the simulation model are replaced by the real environment. Hence the results are more realistic and prove the possibility to run our protocol and improve the real-time performance in real world applications.

In this performance evaluation, we used a set of tools to implement, validate and evaluate our approach against the standard.

3.1 Hardware

We used in the hardware side several sensors based on Atmel’s platforms, namely; iLive Nodes [18], Atmega128RFA1 and Meshbean2 boards. These different sensor boards were used in order to make sure that the obtained results don’t depend on any particular sensor platform. An example of sensors and development kit used in this work are illustrated in Fig. 2 and their characteristics are listed in Table 1.

Table 1 Characteristics of the test-bed platforms used in our experiments
Full size table

3.2 Software

In our experiments, we used two software for the implementation and measurement phases. Our FF-MAC protocol was implemented using the Atmel Open MAC (formally named Atmel MAC Software for IEEE 802.15.4 transceivers [19]). This is an open source implementation of the IEEE 802.15.4-2006 standard developed by Atmel [20]. It supports different Atmel microcontrollers and platforms/boards and also different IEEE 802.15.4 based transceivers and single chips. It can also support the wireless sensor network nodes based on these platforms (e.g. iLive, iLive2). Our choice for this software is due to two reasons. First, most of the wireless sensor network nodes we use in our laboratory are compatible with it. Second, this software offers most of the IEEE 802.15.4 features, such as the support of star network and peer-to-peer communication in addition to the non-beacon and beacon-enabled MAC modes. In our study, the latter mode is very important since the GTS mechanism is only available in the beacon-enabled networks. However, the source code doesn’t provide any implementation of the GTS mechanism so far (version 2.8.0). Hence, part of our work was to complete the stack with this feature before implementing our own FF-MAC protocol.

In the measurement phase, we developed a Java software that we named “JSensorsMonitor”. This software can be connected to these sensors using serial communication ports and collect data, process them and show the results (e.g. measure the delay, show topology and more features out of the scope of this paper).

3.3 Methodology

In our measurements, we implemented the GTS mechanism and our FF-MAC protocol inside the Atmel Open MAC Stack. This firmware was used in our sensors to run both the GTS mechanism and FF-MAC in separated scenarios.

One way to get the end-to-end delay is to measure the duration between a packet transmission and the reception of its acknowledgement, which is sent back from the final destination. The delay in this case is considered as the half of this duration. However, this method is not adapted to our scenarios, since the communication behavior is not symmetrical. Hence, In order to collect data and get accurate measurements of the performance evaluation metrics, we utilized the “JSensorsMonitor” software in the computer side. We connected both the sender and receiver to the computer using serial communication in order to notify the JSensorsMonitor application about any sent or received packet by these connected sensors as described in Fig. 3.

Fig. 3
figure 3

Measurement schema

Full size image

Each packet is tagged by a 32-bits sequence number inserted in the application layer payload to easily identify them by the JSensorsMonitor application. Hence, the software can get the saved data from the database and calculate different performance metrics.

The Java application calculations is based the system clock, with a resolution of 1 ms (we used the method “System.currentTimeMillis()” to get system time). This means that we may have an actual time maximum rounding error of 0.5 ms.

4 Results and Discussions

In this section, we analyze and discuss different results collected from the real world experiments. These experiments were carried out to prove both the correctness of our implementation and the improvements provided by our FF-MAC protocol.

In all these experiments, the sensors operate in the 2.4 GHz frequency band with a bit rate of 250 kbps. Each node transmits one 12 bytes packet (application data only) every Beacon Interval duration. The measured delay represents the time that separates the packet creation in the application layer and its reception by the final destination’s application layer (end-to-end). This delay includes the Medium Access Delay, the propagation delay and the processing latency in the intermediate nodes (Coordinator in our case). The test environment is close to an indoor application (inside the laboratory’s building) with fix obstacles like computers and chairs, and arbitrary obstacles that are mainly human. For reliability, we enabled the MAC layer acknowledgement to be able to retransmit the erroneous received frames.

Table 2 shows the sensor’s memory occupation by the firmware program and data. The program is stored in the flash memory while the data is stored in the RAM. We calculated these values using the “avr-size” tool from the “avr-gnu-toolchain”. We applied this command to the implementation of both the IEEE 802.15.4 standard and the FF-MAC protocol. We also made a distinction between different sensors’ roles (Coordinator and end-device). This table shows first that the Coordinator in both protocols uses more memory resources than the end-device. This result comes from the additional mechanisms and processing done by the coordinator. It also shows that the new FF-MAC’s mechanisms consume very few amount of memory. The implementation of FF-MAC protocol increased the memory used by 0.8 % for the program and 1.1 % for data in the coordinator, and 1.1 % for the program and 0.3 % for data in the end-devices.

Table 2 Sensor’s memory usage by the protocols’ implementations (device: atmega128rfa1)
Full size table

We show in Fig. 4 the new superframe structure as described in FF-MAC (see Fig. 1) captured using a signal analyzer (Tektronix digital serial analyzer DSA71604). We can see that the superframe is in accordance with the theoretical design and shows all periods including D-CFP. If we analyze this figure, we can notice the importance of using an accurate slot size based on available number of packets in the coordinator queue. If compared to the CFP, we can see that the D-CFP occupy a smaller slot than CFP. In this example, we have only one pending packet for the corresponding node. So the coordinator reserved enough space for only the packets and its acknowledgement. The CAP period is located right after D-CFP period, and used to transmit packets without bandwidth or real-time requirements. The PRTPA packet introduced by the FF-MAC protocol is sent by the coordinator at the end of the CFP.

Figure 4 illustrates the problem discussed in Sect. 2 and shows the performance of our new protocol. In this scenario we compare the performances of the FF-MAC protocol against the CSMA-CA algorithm. We can clearly see that when using CSMA-CA, the delay is at least around the superframe size because of the problem described in Sect. 2. That delay can increase to two or more times if those packets where not successfully transmitted in the next superframes. However, The FF-MAC has solved this issue since the end-to-end communication is guaranteed to be accomplished inside the same superframe. Our approach provides a very low delay that can be neglected if compared to the other algorithm’s one.

Fig. 4
figure 4

The real superframe structure according to FF-MAC protocol

Full size image
Fig. 5
figure 5

End-to-end delay distribution for different packets

Full size image

In the next scenarios, we changed the size of the superframe (without including sleep time) for different SO values, where \(\hbox {BO}=\hbox {SO}\). We compared in Fig. 6 the standard GTS mechanism defined in the IEEE 802.15.4 standard and our FF-MAC protocol. The theoretical curve represents a delay reference of the time between the beginning of the superframe and the GTS slot time. We suppose that we have only one GTS that occupies one slot. We notice that this duration increase proportionally with SO since the slot size depends on this parameter according to the following equation:

$$\begin{aligned} \hbox {Slot duration} = \hbox {aBaseSlotDuration} \times 2^{\mathrm{so}}\hbox {(Symbol)} \end{aligned}$$
(2)

In the rest of the results, we used a logarithmic scale (log2) in the vertical abscise in order to distinguish these results and to be able to see clearly the small and the high delay values in the same figures.

The delay shown in Fig. 6 is measured for the first half of the communication (i.e. from the source to the coordinator). If we look at the measured delay using the IEEE 802.15.4 standard GTS, we can clearly see that it’s nearly the same compared to the theoretical curve. This result was expected since the GTS is located at the end of the active portion of the superframe.

On the other hand, the FF-MAC shows an important improvement since the transmission is done at the beginning of the superframe. The first GTS (GTS 0) is an exception since it’s sent right after the beacon reception and, then, it doesn’t depend on the slot size. For the rest of the slots (e.g. GTS 1), they depend on the latter but less than the standard, because the packets are sent at the first slots rather than the last ones.

These results show the advantage of changing the order of the CAP and the CFP in the superframe. However, there is a possibility to have the same results using the standard and FF-MAC protocol. This can be done by adjusting the transmission time to the GTS slot at the application layer. But this way of managements has many disadvantages; the first one is the dependency between the MAC and the application layer because the application layer will depend on the MAC layer operation and break the OSI model abstraction law, since it has to know exactly when the GTS slot starts. The second one is related to the resource since we need one extra timer to adjust the transmission time and track the GTS slot beginning. However, if we use the FF-MAC protocol, the node will wait only for the beacon; the application layer will be notified by using the “MLME_BEACON_NOTIFY_INDICATION” standard primitive. Then the application layer may start its transmission.

The hardware node used as a coordinator has to fix the packet queue size to a limited value. In fact, unlike in simulation, the amount of data memory of a real sensor is very limited (163,84 bytes in our case). Hence, the received packets may be more than the maximum number of packets allowed by this coordinator. Then, when this limit is reached, the latter will automatically apply tail drop mechanism. However, in order to protect time critical data from being dropped, we propose the use of a dedicated virtual real time data queue. This queue is, in fact, part of the main queue used for all types of data packets. It reserves the required number of packet buffers from that main queue according to the existing GTS receive slots (similar to the priority queuing mechanism). For instance, if we have one GTS receive slot reserved with a sensing frequency equal to BI, the virtual queue will need only one packet buffer. Even with a small virtual queue size, FF-MAC protocol can still protect these real-time data because this virtual queue is freed up very quickly before receiving any new real-time packet thanks to the fast forwarding ability. The size can be dynamically updated according to the network changes.

Fig. 6
figure 6

One hop delay for different SO values (\(\hbox {DC} = 100\,\%\))

Full size image

In Fig. 7, we evaluate the end-to-end delay for a communication between two end devices in the same star network. We can see that the measured delay for GTS mechanism of the standard MAC increase proportionally with the sleep time length even when the size of the active portion is unchanged (SO fixed to 4). The additional delay is due to the sleep time that is doubled in each scenario (BO increased by one). On the other hand the delay using FF-MAC protocol stays stable around the same value (average delay: 23.5 ms). These results prove that our approach doesn’t depend on the sleep time length due to its ability to forward the data to their destination inside the same superframe.

Fig. 7
figure 7

End-to-end delay versus sleep time

Full size image

In Fig. 8, we would like to evaluate the influence of the slot size on the end-to-end delay for both the IEEE 802.15.4 standard and FF-MAC protocol. Hence, we remove the sleep time (\(\hbox {BO}=\hbox {SO}\)) and we changed the SO parameter to stretch the slot size. The curves show that the standard still have the same problem since the size of the whole superframe increases, while our protocol offer a very low delay even that it’s slightly influenced by the SO changes. This influence comes from the fact that the CFP period size also increases with SO parameter. However, since the forwarding process is done in the D-CFP (right after the CFP), the wait time is still very low.

Fig. 8
figure 8

Delay for different superframe sizes (no sleep time, \(\hbox {DC} = 100\,\%\))

Full size image

If we look at this problem according to different duty cycle values, we can clearly see in Fig. 9 that a combination of BO and SO variations has an influence on the end-to-end delay for the IEEE standard, mainly in low duty cycles scenarios. FF-MAC still keeps its stability and a very low delay in all these scenarios.

Fig. 9
figure 9

Delay for various duty cycles

Full size image

In the following scenario, we traced the behavior of the measured delay for different node densities while the superframe parameters are fixed (\(\hbox {BO}=7\), \(\hbox {SO}=4\)). Figure 10 shows that when using the IEEE 802.15.4 for low densities (less than 11 nodes in this example), the measured delay stays fixed around 2000 ms (nearly the size of the superframe) because the contention is low and all the packets can be successfully forwarded to their final destinations in the next superframe. However, above that threshold, the contentions due to the CSMA-CA used to manage the medium access became ruder, and cause the average delay to increase. The randomness of this algorithm may delay some packets to other superframes, same as it was illustrated in Fig. 5. The FF-MAC, as expected, is not affected by the node density thanks to the deterministic end-to-end transmission in CFP and D-CFP.

Fig. 10
figure 10

Delay for different node densities (\(\hbox {DC} = 12.5\,\%\))

Full size image

In Fig. 11, we show how the usage of an additional period (D-CFP) impacts the performance of the best effort nodes. We can see that the performance of the CSMA-CA algorithm in the CAP period using the IEEE 802.15.4 standard is better than those using the FF-MAC protocol. The reason behind this is that D-CFP period used by the FF-MAC protocol is created from the mandatory CAP period, as it is the case of the CFP period. Hence, the non proprietary nodes have shorter period to use for their transmission and the contention to access the channel become ruder.

Fig. 11
figure 11

Comparison of CAP period nodes’ the performance (CSMA-CA) when using FF-MAC and IEEE 802.15.4 standard (DC = 100 %)

Full size image

The last figure (Fig. 12) shows the bandwidth utilization when using the GTS mechanism of IEEE 802.15.4 standard and the deterministic mechanism of the FF-MAC protocol. All the nodes send one packet in each Beacon Interval (the sensing frequency). The first observation is that the FF-MAC protocol uses the bandwidth more efficiently than the GTS mechanism. This behavior comes from ability of FF-MAC to guarantee the transmission of the time critical data in uplink (source node to coordinator) and downlink (coordinator to destination node), while the GTS mechanism guarantee only the uplink communication. We notice that the transmission errors are corrected thanks to the retransmission mechanism in the MAC level. The second observation is the throughput stability in FF-MAC against a negative impact of the node density on the bandwidth usage in case of the GTS mechanism. That’s because of the CSMA-CA used for downlink communication in the latter against the deterministic D-GTS proposed by the FF-MAC.

Fig. 12
figure 12

Throughput for different nodes densities (\(\hbox {DC}=12.5\,\%\))

Full size image

5 Conclusions and Outlook

In this paper, we presented the FF-MAC protocol as an enhancement to the IEEE 802.15.4-2006 MAC protocol. The improvements were proved by both simulation and real world test-bed implementation and shown a better performance against the GTS mechanism of the IEEE 802.15.4 standard, when transmitting time critical data, in all studied scenarios. The delay performance of the CSMA-CA algorithm in the CAP period is better using the standard. However, those of the FF-MAC protocol are acceptable for ‘Best Effort’ data. The real world experiments also confirm that the proposed protocol can run in real environment, and outperform the standard one for the transmission of the critical data in the presented scenarios.

The use of real sensor nodes introduces many real world imperfections. These constraints may have an influence on the obtained results that can be different from simulation. We’ve discussed the example of the memory limitation and how this can cause problems to the real world networks.

The obtained results are encouraging and open many research perspectives. In our future works, we aim to adapt our protocol to use the IEEE 802.15.4e standard’s new features, particularly, the DSME multi-superframe. We also tend to extend our protocol to support multi-hop networks in cluster tree topology.