TMCnet News

Software Techniques for Maximizing Network Functionality in Duty Cycle Restricted ISM Bands [Sensors & Transducers (Canada)]
[April 22, 2014]

Software Techniques for Maximizing Network Functionality in Duty Cycle Restricted ISM Bands [Sensors & Transducers (Canada)]


(Sensors & Transducers (Canada) Via Acquire Media NewsEdge) Abstract: In this paper, a technique is presented which allows users of license free ISM bands to increase functionality of the wireless network while remaining within the maximum legally allowed transmit duty cycle requirements. We show through analytical modeling and empirical evaluation, that traditional MAC and routing techniques result in a significant increase in the overall TX duty cycle when sensor sample frequencies are increased. Specifically, we focus on the 868 MHz ISM band where the maximum allowed legal TX duty cycle must be < 1 %. Two novel techniques are presented that significantly reduce the TX duty cycle. The result of implementing these techniques is a reduction in power consumption and more importantly, an increase in network functionality while remaining within the legal requirements. We show that these techniques allow for sensor readings to be collected far more frequently in multi-hop, receiver duty cycled, wireless sensor networks. Results from a 50 node deployment are also presented to validate the model with empirical results.



Copyright © 2013 IFSA.

Keywords: 868 MHz limitations, Duty Cycle, Low Power, WSN, Multi-Hop.


(ProQuest: ... denotes formulae omitted.) 1. Introduction Considering that the license free bands can be occupied by multiple co-existing wireless networks, sanctions are put in place for users of these bands. These sanctions are placed by the ISM band regulatory authorities [1]. Sanctions are placed on TX duty-cycle and TX transmit power. TX duty-cycle is the percentage of time spent in TX mode at the physical layer. Placing restrictions on TX duty-cycle allows for fairer usage of the band and ensures multiple devices can co-exist in harmony. Operation in the license free 868-868.6 MHz ISM band requires maximum TX duty cycles of <1 % (Class 2) and maximum TX power levels of approximately +14 dBm. Other nearby bands require <0.1 % (Class 1). This specific duty cycle requirement of <1 % translates to a maximum of 36 seconds of TX on-time within one hour and a maximum length of 3.6 seconds for any single transmission (See Table 1).

These restrictions place limitations on the functionality of the network, specifically, they limit the rate at which sensor readings can be reported to the network sink. The higher the sampling rate the greater the network activity. The rate at which sensor readings must be reported from each node in the network is largely an application based requirement. Depending on the application, these regulatory restrictions may impose a limit on the desired sensor report rate and the network engineer will need to be satisfied with a lower sampling rate. To overcome the issues described above, two techniques are implemented to reduce the overall TX duty cycle of the multihop network as a whole. The first technique and the one that has the largest impact on reducing the TX duty cycle, is a neighbor schedule learning system. A custom MAC protocol was designed to facilitate neighbor schedule learning. Nodes are able to leam when neighboring nodes are expected to wake up and they choose the most energy efficient time to begin contacting them. The result of this is a drastic reduction in TX duty cycle, messages can now be transmitted to duty-cycled neighbors in milliseconds compared to 100's of milliseconds using standard MAC techniques.

The second technique is a layer 3 routing optimization, whereby nodes piggyback their sensor readings into packets from upstream nodes within the multi-hop network. When a packet is received which requires forwarding towards the network sink, this triggers the recipient of the packet to carry out a sensor reading. This optimization results in fewer transmissions and more optimal utilization of the maximum payload length of the physical layer itself.

1.1. TX on Time During Transmissions The length of time for which the transceiver is in TX mode during each transmission to a duty cycled neighbor, varies greatly from MAC protocol to protocol. To guarantee reliable communication, nonacknowledge based MAC protocols such as B-MAC and BoX-MAC 1 are required to leave the radio transceiver in TX mode for the full duration of the receive check interval (Tw) [10, 8]. The receive check interval is the time interval between receive check operations in duty cycled WSN nodes. Conversely, acknowledge based protocols such as XMAC and BoX-MAC2 cease transmitting as soon as an ACK is received [2, 8]. On average, this ACK packet will be received half way through the receive check interval. Interestingly, the total length of time for which both of these protocols spend in TX mode during transmissions to duty cycled neighbors, is approximately equal to Tw/4. On average, the overall time the radio is active for during transmissions is indeed Tw/2 . During this time period of Tw/2, the radio spends a share of its time in TX mode sending packets and the rest in RX mode listening for ACK (acknowledge) packets. In the case of BoX-MAC2, the proportions of time spent in RX and TX will vary as the payload length changes. X-MAC on the other hand spends fixed lengths of time in both TX and RX during the contacting phase due to its RTS (Request To Send)/ CTS (Clear To Send) system.

The primary goal of this work is to provide a simple technique to lower TX duty cycle, allowing users of the license free bands to increase network functionality. In Section 2, a detailed description is given into the functionality of both of these techniques and a description of the designed MAC protocol is given. In Section 3, modeled results are presented showing the potential savings in TX duty cycle that can be achieved. In Section 4, the experimental setup is explained, empirical test data is presented and compared against our simulated results. We also present some preliminary results from a deployment of 50 nodes, showing how the proposed system works in a full scale deployment. In Section 4.4, we discuss these important results and their implications. Finally a brief summary of related work is presented in Section 5 and in Section 6 we conclude and suggest a few topics for further expanding this work.

2. Design A custom MAC protocol was developed, tested and implemented on our custom hardware. It is highly customized and suited for use in duty cycled low-rate low-power wireless sensor networks. It consists of a very short packet length RTS/ CTS preamble wakeup stream which contains source and destination address information. Senders interrogate receivers by sending short RTS packets followed by a short period where they wait for a CTS response. A node which receives an RTS packet addressed to itself, responds with a CTS (containing source and destination address) packet to the sender. Upon reception of the CTS packet at the sender, it proceeds by sending the payload data and waits for a payload acknowledge message. At the bit-rate of the transceiver being used, the duration of one send RTS packet and listen for CTS cycle is 2 ms. One cycle consists of approximately 1 ms of TX time and 1 ms of RX time listening for a CTS packet.

Using this technique, short packet based receive check lengths of approximately 2.3 ms are achieved (2 ms for a valid packet + »300 qs receiver startup time). The functionality of the protocol is depicted in Fig. 1.

2.1. Reducing TX On Time Through Neighbor Schedule Learning To reduce the energy required to send data packets, a technique is used to reduce the time spent in TX mode per unicast transmission. This technique is called neighbor schedule learning. Learning schedules involves zero additional synchronization packets. Each node in the network maintains its own wakeup schedule, and simply guarantees that each periodic receive check will occur at an integer multiple of the network wide receive check interval.

As can be seen from Fig. 2, the time-offset between two nodes wakeup schedules will dictate the energy required to send data between them. In a non learn scenario node B must transmit for 5 s before node A wakes. If node B counts the amount of time needed before node A replied, it can learn the timeoffset between their relative wakeup schedules. During the next transmission it applies this learned offset and reduces the time spent in TX mode.

With wakeup scheduling now handled by the aforementioned mechanisms, each node in the network can learn the time offset between its wakeup schedule and those of its neighbors. During the very first interaction between two nodes, the sender stores the number of RTS/CTS cycles it required before the destination responded. This number of attempts is stored in a neighbor specific data structure and is proportional to the time offset between their respective wakeup schedules. One additional byte is required to store the time offset between wakeup schedules, hence the system is scalable.

During the next transmission to a particular neighboring node, the sender now knows reasonably accurately, when the destination will wakeup. The sender then recalls the time offset value from the neighbor specific data structure, and delays accordingly so as to begin performing RTS/CTS cycles a few milliseconds before the destination is expected to wakeup. This time offset is updated during every encounter to account for oscillator drift, explained further in Section II-B. The offset learning process is illustrated in Fig. 2. In Fig. 2, node B first learns the time offset between its wakeup schedule and that of node A, during the next transmission it uses the learned time offset and delays accordingly before contact the destination. Fig. 3 shows the current profile of a node sending a unicast packet to a duty cycled receiver. It wakes up recalls the learned offset to the recipient, delays 350 ms and begins performing RTS/ CTS just before the recipient wakes up. RTS/ CTS is performed at a dynamic TX power level, hence the higher spike for the payload.

2.2. Handling Drift Our protocol also handles drift which can accumulate between nodes receive check schedules. Initial learned time offset values will drift over time depending on the relative inaccuracies of node's clock sources. When relative clock drifts are positive the time-offset increases, when negative the time offset decreases. If the maximum relative oscillator between 2 nodes in a deployment is 20 ppm (some can be -10 ppm others +10 ppm), 1.2 ms/minute of drift can accumulate.

We simulated the total energy to send 100,000 packets at data send intervals increasing from 2 seconds to 2048 seconds and also swept the synchronization period TSync from 4 ms to 100 ms. The energy required to send the 100,000 packets is summated for each simulated data send interval and synchronization period. In Fig. 4, we graph the results. The energy to send the 100,000 packets is summed for each TSync, and the lowest value that works best when averaged across all data send intervals is chosen. This lowest value which occurs at a particular synchronization period is used to normalize all of the other summated values which were obtained from different synchronization periods. This optimum value occurs at a TSync of 24 ms (depicted in Fig. 4). Fig. 4 also shows that when a non TSync period of 10 ms is chosen, the energy required to send 100,000 packets across different data send intervals increases by a factor of 5.5 for relative oscillator drifts of 10 ppm and 20 ppm. On average, nodes in a network will have an equal number of neighbors with whom they experience NRD and PRD. Therefore the optimum value for TSync is, in reality, something between 24 ms and 0 ms.

Obviously, if the accumulated drift is greater than the Tsync interval problems will occur. This will cause the sender to miss the recipient's receive check event and incur a full receive check interval worth of transceiver on-time. This is the phenomena seen in Fig. 4, where the power consumption jumps erratically at certain TSYnc intervals. To prevent this from occurring a number of preventative measures are/ were taken and are listed below: * Tsync interval is proportional to data send rate, forwarding data more often results in a lower Tsync; * High precision 1 % load capacitors were used with the 32.768 kHz crystal; * Nodes were calibrated to reduce maximum inter-node oscillator inaccuracies to approximately +-5 ppm; * Offset is updated during each encounter.

If Tsync is 8 ms (4 RTS/CTS attempts) and a node requires 6 attempts to contact the destination, the sender updates the stored offset for this neighbor by adding 2 (6 (Actual)-4 (Desired)). The opposite applies if the sender requires less attempts than the desired number to contact the destination, here the sender subtracts from the stored offset.

2.3. Piggybacking Data Messages The primary task of each node in the WSN is to report periodic sensor readings to the network's sink. To reach the network sink, nodes at the outer edges of the deployment may have to route through several nodes, depending on the density and RF environment of the deployment.

The underlying idea of our piggybacking optimization is as follows: nodes that happen to lie in a path that has neighboring nodes generating or forwarding data packets will piggyback their sensor readings into messages which are being forwarded. This process is described graphically in Fig. 5. Traditionally, this is done differently and each individual node generates its own periodic data messages.

To accommodate piggybacking, the payload is partitioned into different blocks. Each node which forwards the packet, adds its sensor readings to the payload in a specific position. The position is dependent on the hop number. The leaf node that generated the packet, adds its sensed data to position 0. The next node to interact with and forward the packet adds its sensed data to position 1. In our implementation and application, each node adds a total of 5 bytes to the payload and the length of the variable data packet. Additionally, packets contain a routing header. Forwarding nodes increment a Hop Count value, and add the ID and RSSI of the last hop to the routing header. Packets that originate from nodes which have a direct RF path to the network sink are short. Payload lengths grow linearly as the hop count increases. At the bit rate of the physical layer in use, each byte adds a total of 80 (iS to the length of the payload.

When the network sink receives a unique sensed data packet, it first examines the hop count of the packet in the routing header. Depending on this value, it knows how many nodes have interacted with the packet and included sensor readings. It is also aware of the position in the payload where to find sensor readings from the Nth hop.

3. Simulation To estimate the TX duty cycle across different data send intervals with and without optimizations, the system was modeled in Matlab. The model calculates the overall TX duty cycle resulting in sending data packets at different rates, when one child node is attached and assumes sending to a duty cycled neighbor. The algorithm used is shown in Algorithm 1. Each transmission incurs a total TX time of TSync ms worth of RTS/ CTS attempts, i.e., 4 ms of TX time, plus the length of the payload. A payload length of 24 bytes is 2.4 ms at the bit rate of the physical layer. The simulated experimental length was 2 days. The TX duty cycle is hence the total time spent in TX mode divided by the length of the test. The results are shown in Fig. 6. This graph includes 4 curves, two for neighbor learning enabled and two for neighbor learning disabled. The two curves where neighbor learning is enabled, include piggybacking enabled and disabled. The same applies for the other 2 curves, where neighbor learning is disabled.

Algorithm 1. Model of TX on time during transmissions, neighbor learning enabled.

Initialize Variables repeat Time In TX = 0.004s + Payload Length Accumulated Time += Send Interval until Accumulated Time > 2Days Duty Cycle = Time In TX / 2 Days In the case of neighbor learning and piggybacking being enabled, the simulation predicts a 70 times reduction in TX duty cycle compared to both being disabled. With both optimizations, nodes are capable of achieving 0.72 % TX duty cycle forwarding data packets every 1 second. With both optimizations disabled this time increases to 52 seconds. The results are summarized in Table 2. For each transmission, the node without neighbor learning spends on average half of the receive check interval performing RTS/ CTS, in this scenario that is 0.5 s. Of that 0.5 s half is spent in TX mode, or 0.25 s (as previously discussed in Section II).

In the case of only the piggybacking optimization being enabled, there are two unique scenarios. Firstly, the node under test has piggybacking disabled and it forwards data packets for its child node and also generates its own additional data packets. The simulation shows it is only able to provide < 1 % TX duty cycle when packets are being generated every 52 seconds. When piggybacking alone is enabled, the nodes can report back sensor readings every 26 seconds while remaining < 1 % TX duty cycle. The duty cycles reached by the version of the simulation with both optimizations disabled represents a MAC protocol similar to BoX-MAC2 or X-MAC.

4. Empirical Evaluation 4.1. Testbed The testbed used for this experiment consists of custom devices, comprised of a PIC24F microcontroller and an SX1211 868 MHz radio transceiver. The radio is operated at 100 kbps data rate and a sleep current of 1 pA is achieved for the platform. The hardware platform is pictured in Fig. 7.

4.2. Measuring TX on Time To be able to accurately estimate the overall TX duty cycle of deployed nodes, a counter is implemented in software which keeps track of the total amount of time spent in TX mode. This counter is included in each transmission and allows the network sink to keep track of how much time each node spends in TX mode.

The basic unit of time for this counter is 1 ms, each increment of the 32-bit counter is equal to 1 ms and it overflows after 60 days of constant TX on time. 1 ms is the length of an RTS packet and is hence a convenient unit of time. Each transmission which takes place, results in the counter being incremented by the number of RTS/ CTS attempts required to contact the destination, plus the length of the payload transmission. This technique enables very accurate monitoring of the time spent in TX mode at each node. An example of this counter working is a transmission which requires 100 RTS/ CTS attempts to contact the destination and a payload length of 2 ms. This transmission would results in the counter being incremented by 102, 100 for the RTS transmissions and 2 for the length of the payload.

The network sink which always listens, sends all received data packets to a PC over USB, where the results are logged. Using the technique described above, the TX duty cycle can be easily calculated for each node using Equation 1.

...(1) screen-shot of the printout from the network sink is shown in Table 3. Here nodes 34 and 35 are forwarding packets through node 12 every 5 seconds. The TX duty cycle counter counts the total time spent in TX during transmissions, as can be seen in Table 3, the difference between the two consecutive transmissions is 5 counter units or (5*1 ms) 5 ms. Also included is the RSSI of each hop, -54 dBm from nodes 34 and 35 to node 12, and -44 dBm from node 12 to the network sink. Most importantly from Table 3 the packet counter feature can be seen, node 35 requires 5 packets to send its status message (1395-1390).

4.3. Experimental Setup To validate our modeled results presented in Section III a small micro-benchmark network was deployed using the node pictured in Fig. 7. The node's firmware also contains layer 3 routing protocols and these may cause fractional overheads in terms of TX duty cycle. An example of one of these overheads is a periodic probe message to check if the network sink is in range. The network sink was configured to be in an always listening state. This reduces the TX duty cycle of nodes which can communicate with the network sink because they only ever need 1 RTS/ CTS cycle before the payload data can be sent. All nodes were programmed to perform receive checks once a second and forward data packets at the same rate. The sensor sample interval and hence packet generation intervals were chosen to be 1, 2, 5, 10,20, 30, 40 and 60 seconds.

The first micro-benchmark experiment was devised to measure the difference in TX duty-cycle between nodes with neighbor learning enabled and disabled. For this experiment which was conducted, a total of 17 nodes were deployed in a large office and a maximum of 2 hops was observed. After having deployed the 17 nodes, it was observed that 11 of the nodes were able to communicate directly with the network sink. The remaining 6 were forced to route their messages through the 11 nodes which had a path to the network sink. The nodes of interest were the 6 nodes which did not have a direct RF path to the network sink because they were required to send to duty cycled neighbors. 3 of them were programmed with neighbor learning enabled and 3 without. Tests were conducted for 12 hours and all results were logged on a PC which was connected to the network sink. Of the 6 nodes under test, their TX duty cycles were calculated using Equation 1. 'Packets' represents the software packet counter shown in Table 3 and explained in Section 4.2.

The second micro-benchmark experiment was devised to test the piggybacking and neighbor learning technique combined and a slightly different topology was required. The reason being that in the first experiment the leaf nodes were the only nodes sending to duty cycled neighbors. A controlled 3 hop topology was required because the nodes under test needed to be parent nodes (forwarding upstream packets), and still forward to duty cycled neighbors. The topology is depicted in Fig. 8 and the nodes under test are the yellow nodes (2nd row from right).

4.4. Results The first experiment was devised to solely measure the efficiency of our implemented neighbor schedule learning optimization. The TX duty cycle of a total of 6 leaf nodes was measured over a 1 day period (3 with neighbor learning, 3 without). The results are summarized in Table 4. Each test (i.e., each send interval) was carried out a total of 3 times and the maximum, minimum and overall average TX duty cycles are listed in Table 4. In Fig. 9, simulated and tested results are compared. The empirically tested values are in extremely close agreement with the modeled results. The maximum variation in the predicted vs. the measured duty cycle is 0.044 % when sending packets every 40 seconds. These variations can be explained by the overheads mentioned in Section 4.3.

The second experiment was designed to measure the efficiency of our piggybacking and neighbor learning algorithm combined. The TX duty cycle of 3 parent nodes each with 1 child node a piece, was measured. The experiment was carried out using a number of different configurations. Different combinations of piggybacking/ neighbor learning enabled and disabled were used. The results are presented in Fig. 9. In the case of piggybacking only being disabled, the parent node under test forwards packets for its child and generates its own packet during each data send interval. In the experiment where piggybacking was enabled, the parent node sends only one packet during each data send interval. The difference in TX duty cycle is intuitively approximately 50 %, as the workload of the parent is reduced by a factor of 2 when piggybacking is enabled. The slight increase in the payload length due to piggybacking is insignificant when compared to the amount of time spent in TX mode during the RTS/ CTS phase of the transmission (each byte adds only 80_s compared to almost 1 ms for an RTS/ CTS cycle).

In the case of neighbor learning and piggybacking being enabled we observe a 70 times reduction in TX duty cycle, 0.7 % forwarding every second (9b), when both are disabled this forwarding rate must be increased to almost 50 seconds to achieve < 1 % TX duty cycle (9a). With both optimizations enabled, parents with a single attached child node can forward packets every 8 seconds to comply with the <0.1 % TX duty cycle restrictions (9b), with 2 child nodes attached this figure increases to 16 seconds.

From Fig. 9a, there is very close correlation between experimental and predicted results. With only piggybacking enabled the data send interval can be 26 seconds while still remaining below 1 %, with it disabled, the data send interval must be 52 seconds to comply with the 1 % TX duty cycle restrictions.

Again, the duty cycles reached by the version of the protocol with both optimizations disabled represents a MAC protocol similar to BoX-MAC2 or X-MAC.

4.5. Deployment Results/ L3 Performance At the MAC layer there are clear savings in TX duty cycle to be made by the two previously discussed techniques. To investigate how this system would perform in a full multi-hop protocol stack (which itself induces extra network overhead) and to asses the scalability of the algorithms , a sizable network of 50 nodes was deployed.

Nodes were deployed in an old building spanning 3 stories, 1 single sink node was deployed on the 3rd and top storey. The dimensions of the building are (L:60 m, W:70 m, H:20 m), larger in area than testbeds such as Indriya [4] and Twist [6]. 16 nodes were deployed on the 3rd floor, 18 on the 2nd floor and 15 on the ground floor.

The testbed of 50 nodes plus network sink was deployed for 3 days for each experiment. The sink was in an always listening state and an arbitrary receive check interval of 1 second was used for all other nodes. Nodes were programmed to generate temperature readings every 4 minutes. The TX dutycycle of nodes was tracked in the same manner as previously described. The dynamic traffic patterns of a multihop WSN make it difficult to predict the TX duty cycle of nodes. For example, certain nodes will dynamically need to forward packets for other nodes during certain periods and this dynamic behavior is difficult to predict.

To demonstrate the savings of the techniques discussed in this protocol, two separate experiments were conducted and the same 5 nodes were used for duty cycle comparison in both cases. The 5 nodes which were selected did not have a direct path to the always listening network sink. One experiment had both techniques enabled and the latter had both disabled.

In the case of both techniques being disabled the lowest achievable TX duty-cycle for an acknowledge based MAC is: ...(2) With a Tw of 1 second and a Tsend of 4 minutes, this gives a duty cycle of 0.104 %. In Table 5, duty cycle values are given for both versions of the experiment. Without the controlled topologies of the initial micro-benchmark experiments, the reduction in TX duty cycle is quite varied. Node 60 sees a reduction factor of 21.3 while node 6F sees a reduction factor of 52.3. This can be explained by unpredictable traffic patterns and dynamic link qualities. Also shown in Table 5, is the mean packet forward interval for the nodes. Failure to communicate with a potential parent induces a large amount of time spent in TX mode. These points aside, across 50 nodes there is still a significant average reduction factor of 31.7 in the TX duty cycles.

5. Related Work In terms of the two optimizations and their novelty, there are some similar concepts to be found in the literature. Protocols such as WiseMAC [5] and Hui and Culler's techniques in [7], use similar neighbor schedule learning systems. The differences between WiseMAC and this work are the following: WiseMAC uses an uninterrupted preamble wakeup sequence that doest not contain address information. This work uses an RTS/CTS system which will stop as soon as the destination responds (zero overlistening). WiseMAC requires periodic exchange of scheduling information, this work does not. WiseMAC relies on a Layer 1 receive check, this work uses Layer 2 (i.e., lower power in dense networks due to less overhearing but a slight increase in receive check energy).

WiseMAC is also for infrastructure networks and it only considers down-link traffic (parent to children).

In [7], the authors briefly mention and describe their neighbor schedule learning system. They improve upon WiseMAC's preamble only wakeup stream by adding some address information into the wakeup stream. Receive checks are layer 1 based and nodes which overhear can quickly decide the packet is not destined for them because of the embedded address information. But still overhearing does occur, unlike this work. Schedule information is exchanged by including extra data in acknowledge messages, in this work no extra data is transferred to provide neighbor schedule learning.

Ye et al. in SCP-MAC [12], present a MAC protocol where all nodes are scheduled to wake during the same time window. Transmissions now take place within this window, resulting in a reduced TX duty cycle compared to standard duty cycled MAC techniques. SCP-MAC requires additional scheduling packets to be transmitted and this has an impact on the overall TX duty cycle, it also suffers from high receive check energy and high latency.

The authors in [5, 7] and [12] present results on the reduction in power consumption of their techniques but fail to investigate the potential reduction in TX duty cycle. This work leverages some of these concepts and simplifies/ optimizes them and applies them to industrial applications for the 868 MHz ISM band.

6. Conclusion & Future Work In this paper, two techniques to reduce TX duty cycle are described, simulated and empirically evaluated. WSNs which must report real time sensor readings are considered and data aggregation techniques such as in [11] are not considered. Our techniques improve functionality of WSN deployments by allowing users of license free bands to increase network activity, while still remaining within the legal maximum TX duty cycle requirements. Using both of the aforementioned techniques in a controlled network topology, it is demonstrated that sparse, low-rate networks can provide sensor readings 70 times more frequently to comply with the <0.1 % TX duty cycle requirements of some of the ISM bands. In a 50 node deployment spanning multiple stories, we also demonstrate an average reduction factor of 31.7 in TX duty cycle across 50 deployed nodes.

Specifically, it is shown that using both techniques and having only 1 dependent child, sensor readings can be forwarded every 8 seconds while still complying, and every 16 seconds when 2 child nodes are attached. The result is a far more active network which is able to provide more frequent sensor readings to the end user. Another important byproduct of the drastic reduction in TX duty cycle is the reduction in power consumption and increased lifetime of the battery powered network.

There are a few distinct areas where our work can be improved upon and developed further. For applications where latency is not an issue, large savings in TX duty cycle could be made if nodes which are under a large workload (i.e., multiple child nodes) could queue received data packets and transmit them all in one burst. This would prevent the TX duty cycle from increasing with workload, the disadvantages of this approach would be that sensor readings would no longer be real-time and payload lengths would increase drastically. The performance of the developed techniques in large scale multi-hop deployments is also of interest (100's of nodes). The authors would also like to compare their work against other cross layer approaches such as Dozer and Koala [3], [9].

Acknowledgment The authors would like to acknowledge and thank the support of El Electronics and IRCSET ( Irish Research Council for Science Enterprise and Trade).

References [1] . ETSIEN300 220-1,2012.

[2] . Michael Buettner, Gary V. Yee, Eric Anderson, and Richard Han, Xmac: a short preamble mac protocol for duty-cycled wireless sensor networks, in Proceedings of the 4th International Conference on Embedded Networked Sensor Systems, 2006, pp.307-320.

[3] . Nicolas Burri, Pascal von Rickenbach, and Roger Wattenhofer, Dozer: ultra-low power data gathering in sensor networks, in Proceedings of the 6th International Conference on Information Processing in Sensor Networks, 2007.

[4] . Manjunath Doddavenkatappa and Mun Choon Chan, Aal an experience of building indriya, National University of Singapore, 2009.

[5] . Amre El-Hoiydi and Jean-Dominique Decotignie. Wisemac: An ultra low power mac protocol for multi-hop wireless sensor networks, in Sotiris E. Nikoletseas and Jos D. P. Rohm, editors, Algorithmic Aspects of Wireless Sensor Networks, Lecture Notes in Computer Science, Vol. 3121, 2004, pp. 18-31.

[6] . Vlado Handziski, A. Köpke, Andreas Willig, and Adam Wolisz, Twist: A scalable and reconfigurable wireless sensor network testbed for indoor deployments, TKN Technical Report TKN- 05-008, Technical University Berlin, 2005.

[7] . Jonathan W. Hui and David E. Culler, Ip is dead, long live ip for wireless sensor networks, in Proceedings of the 6th ACM Conference on Embedded Network Sensor Systems, Raleigh, NC, USA, 2008, pp. 15-28.

[8] . D. Moss and P. Levis, Exploiting physical and link layer boundaries in low-power networking, Technical report, Stanford, 2008.

[9] . Razvan Musaloiu-E., Chieh-Jan Mike Liang, and Andreas Terzis, Koala: Ultra-low power data retrieval in wireless sensor networks, in Proceedings of the 7th IEEE International Conference on Information Processing in Sensor Networks, 2008.

[10] . Joseph Polastre, Jason Hill, and David Culler, Versatile low power media access for wireless sensor networks, in Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, SenSys '04, New York, NY, USA, 2004., pp. 95-107 [11] . S. Sivaranjani, S. Radhakrishnan, and C. Thangaraj, Adaptive delay and energy aware data aggregation technique in wireless sensor networks, in Vinu V Das and Yogesh Chaba, eds., Communications in Computer and Information Science, Springer Berlin Heidelberg, Vol. 296, 2013, pp. 41^19.

[12] . Wei Ye, Fabio Silva, and John Heidemann, Ultra-low duty cycle mac with scheduled channel polling, in Proceedings of the 4th International Conference on Embedded Networked Sensor Systems, Boulder, Colorado, USA, 2006, pp. 321-334.

Eoin O'Connell, Victor Cionca, Brendan O'Flynn Tyndall National Institute, University College Cork, Ireland E-mail: [email protected] Received: 23 September 2013 /Accepted: 22 November 2013 /Published: 30 December 2013 (c) 2013 International Frequency Sensor Association

[ Back To TMCnet.com's Homepage ]