Multi-hop Time Synchronization and Power Saving Mechanisms for FRACTEL Ashutosh Dhekne Department of Computer Science and Engineering, IIT Bombay, India Under guidance of

Prof. Kameswari Chebrolu July 16, 2008 Abstract

has not been designed for long distance communication and hence requires considerable amount of modifications to suit our needs. We shall use high gain directional antenna for enabling links up to few tens of kilometers. We shall use sectorized antenna for smaller distances and when nodes are spread around the location of the antenna. The use of directional antenna give a tree structure to the network topology. At any level, most of the communication is expected between a parent node and its child node. This requirement also supports having a tree structure instead of a mesh. The envisioned topology in FRACTEL is shown in [2] and has been reproduced in Figure 1 for completeness.

In FRACTEL, we make use of wireless links to connect rural areas to a nearby city, providing internet, voice and video conferencing capabilities to these areas. We shall be using a combination of high gain directional antenna and lower gain sectorized antenna for long distance wireless communication. Shorter distance links extend this connectivity to nearby locations, typically, within a radius of half a kilometer. In this study, we shall look at time synchronization issues required to run a TDMA schedule over the FRACTEL infrastructure. We modify an appropriate sensor network algorithm for time synchronization to suit our purpose. Since FRACTEL has a natural tree topology, we perform pairwise synchronization between parent and child nodes in the tree. Once nodes are synchronized, we can reduce their power requirement by allowing nodes to sleep while they do not expect to send or receive messages. We describe how the entire system will function after both the synchronization and the power saving mechanisms are in place. After the overview of the entire system, we discuss the steps taken so far in achieving this end goal and the path ahead.

1

Introduction

The FRACTEL project [2] is envisioned to provide internet connectivity to rural areas using a combination of long distance and short distance links. The system must support voice and video traffic in addition to data traffic to enable a phonelike interface and video conferencing capabilities for educational purposes. Laying down physical links to connect these rural areas is not economically viable. However, if we can provide connectivity using wireless technology, we may be able to achieve enough bandwidth at a reasonable setup and operational cost. Two main wireless technologies exist that may be used in this scenario–Wifi and WiMAX. WiMAX equipment is much costlier than Wifi equipment and hence we have decided to use Wifi for this project. However, the 802.11 protocol for WiFi

Figure 1: An example deployment When we use directional antenna, it is unlikely that other transmissions will interfere with its operation. In the shorter range local access links, interference is possible, but since it is a rural setting we expect such interference to be low. Also, to support a voice or video based application on top of FRACTEL, we would need quality of service (QoS) guarantees. With standard CSMA protocol, it is difficult to provide timing guarantees to such applications. Since we expect low interference, we may use a TDMA schedule and eliminate the random backoffs, RTS-CTS and ACK mechanisms present in 1

3.1

CSMA. A fundamental requirement for proper functioning of a TDMA schedule based communication is that the nodes are synchronized with each other. Also, since the nodes are placed at places where we cannot guarantee continuous power supply, conserving battery power is another important concern in these networks. Synchronization facilitates putting nodes into a sleep-wakeup cycle since the slot when the node can receive or transmit is known. Synchronization issues and power optimization are the main focus of this study. Further in this report, we first define the problem statement of this project and then look at related previous work in the field of node synchronization. We discuss about protocols such as Reference Broadcast Synchronization and Time-Sync Protocol in Sensor Networks. We then discuss how we intend to incorporate one of these algorithms into FRACTEL and propose modifications for our specific needs. Then, we use this synchronization and the knowledge of the TDMA schedule to save power by putting nodes to sleep when they will not be required for some time in the future. We also discuss mechanisms to wake up a remote host when another node wishes to communicate with it.

Uncertainties in synchronization

The reason that synchronization is so difficult is because of a number of uncertainties in the time required for activities in the critical path [13]. After we timestamp a packet in software, the packet queues in the hardware to get transmitted. When its turn comes, it requires some time to actually go on air called the transmit time. The packet then takes some time to travel from the transmitting node to the receiving node. This is called the propagation delay. If the nodes are fixed, the propagation delay is constant baring significant environmental changes. When the receiver receives the packet, it causes an interrupt and then the interrupt service routine (ISR) is invoked. The ISR is the earliest place on the receiver side where we may record the receive time. With a timestamp exchange protocol, the clock skew between two clocks can be adjusted for. However, there is an additional uncertainty with clocks. Two clocks once adjusted for skew will not continue to run synchronously due to clock drifts. Two clocks may run at slightly different speed depending on their manufacturing precision, crystal properties, and environmental conditions. The drift shown by a clock may itself keep changing and therefore usually requires sophisticated 2 Problem Statement regression models for adjustments. We will now briefly look at a few synchronization techIn this project, we focus on time synchronization of various nodes in the FRACTEL system and on minimising their en- niques for sensor networks but also applicable to our setting. ergy requirements. We intend to decide on what synchroniza- 3.2 Reference Broadcast Synchronization tion mechanism to use to so that the overhead incurred by the system will be minimum, still maintaining node synchroniza- We may be able to increase the accuracy of time synchronization to the required degree. Since FRACTEL uses long dis- tion if we eliminate some of the uncertainties in the critical tance links, propagation delay may not remain negligible. We path. The RBS protocol [5] achieves this by using a novel need to study how to incorporate this delay in the synchroniza- technique. A reference node periodically broadcasts synchrotion mechanism. Also, any messages exchanged as a part of nization beacons and all the receivers who receive this beasynchronization, must also use the same TDMA schedule. We con record their local time and then exchange the recorded need to address this requirement of fitting synchronization on time with each others. In this protocol, all the receivers of the beacon are synchronized with each other. The sender of the top of TDMA scheduling. beacon is not synchronized with the receivers. Therefore, the For efficient usage of power at each of the devices, we need beacon itself need not contain any timing information. a mechanism to dynamically switch on and switch off wireless With the sender’s uncertainties eliminated from the critidevices. Any mechanism implemented must provide maxical path, significant timing accuracy can be gained. However, mum power savings still keeping delay in communication to every receiver may have to store an offset with respect to all a minimum. We study how the nodes can effectively dutyother receivers. This can be a significant overhead particularly cycle while active to minimize energy consumption. We need if the nodes are resource constrained. Moreover, we require a to study how inactive nodes can be woken up by remote nodes reference broadcaster to remain outside of the time synchroto start communicating with them. nization since it cannot be synchronized in this mechanism. This also implies that its broadcast must be visible to each re3 Related Work ceiver present in the network. It is, therefore, not suitable for The synchronization problem we face in our network is very hierarchical topology and non-omni directional links. similar to that faced in wireless sensor networks. We wish to use the synchronized nodes to transmit and receive in accor- 3.3 Timing-sync Protocol for Sensor Networks dance with a TDMA schedule instead of the usual CSMA. We This is a sender–receiver synchronization protocol [6]. The therefore require to synchronize nodes at microsecond accu- working of the protocol is divided into two phases. The first racy and maintain this synchronization. We will first look at phase essentially creates a spanning tree of the mesh network. the uncertainties in the critical path and then discuss few syn- This tree structure is used by the second phase for a pair-wise exchange of timing information. The child and the parent chronization protocols used in wireless sensor networks. 2

performing synchronization. We may be able to send beacons whenever we want to synchronize a pair of nodes with more accurate sender’s timing than mere MAC layer timestamping of packets.

node know each other from the first phase. The parent sends a time sync packet to the child node. The child node responds with a timestamped packet (time = T1) and sends it to the parent. The parent node records its own local time when it received this packet (time = T2) and responds with another timestamped packet at time T3 which also includes the times T1 and T2. The child again records the time it received this response packet (time = T4). The child now knows the time difference between T1 and T2 which corresponds to the clock skew between the two plus the propagation delay. Taking an average of the difference between T2-T1 and T4-T3 gives better estimate of the clock skew. An advantage of this protocol over RBS is that it is inherently multi-hop. However, each pair of nodes in the tree structure must exchange two messages to be synchronized. Also, this process has to start from the root node, by issue of a time sync packet, and continue to the leaf nodes. It is a sequential process and may be time consuming. 3.4

3.6

In order to conserve energy, it is advisable to switch off the main wireless device when not needed and wake it up on demand. It must be possible to wake up devices remotely. In the Wake on WLAN paper [8], the authors have used a low power consuming mote that listens to the wireless channel and wakes up the main board (Soekris) when it senses increased energy on the channel. In this paper, the entire main board is turned off, and therefore, it incurs a large delay in booting up the main device. However, if we put some of its components to sleep instead of completely switching off the main board, we may achieve faster wakeups.

4

The Flooding Time Synchronization Protocol

Our Approach

In this project we will look at two related aspects in the FRACTEL system. We will be first concerned with accurate node synchronization. Once the nodes are synchronized, a TDMA schedule can be safely implemented over it. The second aspect is to use this synchronization and the knowledge of the schedule for power savings in the network.

This protocol acheives sender-receiver synchronization by broadcasting timestamped messages to all possible receivers [7]. It uses a preamble and few sync bytes which can be continuously used by the receiver to estimate the clock difference between the sender and the receivers. It reduces the jitter in interrupt handling time by averaging multiple timestamps taken at each byte boundary. Only the final average timestamp is embedded into the packet. This protocol also includes linear regression to predict the clock drift. The paper mentions that the clock drift in the Mica motes is about 40µs. We need to check the clock drift in our equipment, but nonetheless, compensating for clock drift might benefit our application too. This protocol also deals with changing the root node periodically. Due to our natural tree topology, we do not require this feature. 3.5

Wake on WLAN

4.1

Synchronization

We propose to use the Timing-sync Protocol for Sensor Networks (TPSN) algorithm for our setting since it is the most natural one for the tree topology that we already have. In addition we may like to incorporate a linear regression mechanism to estimate the drift between clocks. We require to tackle the problem of how to incorporate the synchronization scheme in the TDMA working. One possible way is to have all nodes in the network start as normal wifi devices and wait for a time sync message. We assume that the topology is known or already discovered. The root node sends the time sync packet to each of its children nodes. The children then synchronize with the root and continue to propagate the time sync message to their next level nodes. In case the parent does not receive a response, it may send the time sync message multiple times to counter possible message losses. After a fixed number of tries, the parent assumes that the child node has failed. After the entire tree has been synchronized, the TDMA schedule may be disseminated. In a random topology it would have been difficult to predict when the entire network has been synchronized, but since we already know the topology, we have a fair estimate of the time this will take. As a second check, each of the leaf nodes may send a sync finished message back to its parent node. A higher level node will pass on a similar message to its parent when it receives the sync finished messages from all its children. This would ensure that we do not clutter the root with too many messages and still have a reliable way of predicting when all

Clock Synchronization Protocol for 802.11 Networks

This protocol deals specifically with the problem of synchronizing 802.11 nodes in a multihop adhoc network. [15]. The paper describes how the number of stations sending the beacon can be reduced by designating some stations as more “important” for beaconing than others in a mesh network. This reduces beacon collisions. It requires creation of dominating sets of nodes which helps in deciding which nodes are more important. It also does frequency adjustments to get all clocks to have about the same accuracy. It deals with general mesh ad-hoc networks and not with tree topology we have in our application. The paper, however, describes a very useful mechanism already present in 802.11. The beacon frames sent in adhoc networks themselves contain a timestamp which is generated to be that time of the local clock when the first bit of the timestamp hits the wireless interface. Added to propagation delay this gives an error of ±5µs. The finding that the beacon actually contains a very precise time can go a long way in 3

ate communication with a child node. A typical scenario is when a user in one part of the network places a call to another user. The destination node may be sleeping since it was inactive for a long time. Then the parent must be able to wake up the destination node and place a call through. Another possible scenario when this mechanism will be required is when a multicast message is to be issued. An effective solution to this problem is given in the Wake on WLAN paper [8] where the authors use a zigbee mote to turn on the main device after sensing a particular signature signal on air. Though the paper speaks of using 802.11 signals identified by motes as only energy variations, we may also investigate the use of high power 802.15.4 transmitters. This way, we can send decipherable packets to the proxy mote and reduce erroneous switching on of the main device. When a node is instructed to switch on by its parent, it may still require to be re-synchronized with the parent and then know its slot details. Communication may then proceed between the two users that wish to talk to each other. In a multicast case, we may buffer information at intermediate parents while the children wake up. This way, whenever the root decides to multicast it could just wait for its own children to properly wakeup before starting to send the data. Data will be buffered at each intermediate node while its children are ordered to wake up. The actual multicast may have started much before the last node sees it. This can be acceptable because communication in this case is uni-directional. We must remember that this can be annoying for interactive sessions. They are bidirectional though the viewers might be asking questions only a fraction of the time! We intend to use Soekris boards for communication. These boards use the AMD Geode SC1100 processor that provides support for ACPI module [3]. Thus, if we can properly tune the operating system to make use of these mechanisms, we may be able to save a lot of power by just incorporating the ACPI module in the kernel installation and setting the correct parameters for idle state detection and throttling of the CPU.

the nodes are synchronized. Synchronization, unfortunately, is not a one-off procedure. It needs to be conducted periodically, lest all clocks might drift apart so much that TDMA schedule may become impossible to implement. Hence, we propose to have some mechanism for synchronization while the TDMA schedule is being used. We remember, however, that if we want to effectively use a bidirectional message exchange algorithm for synchronization, we should not impose TDMA restrictions on the nodes while this synchronization is being done. When a parent sends a time sync packet, its child must not wait for its slot for transmitting the first timing message. This requirement may be dealt with in a couple of ways. We may modify the receive MAC code such that whenever the time sync packet arrives, its replies are made immediately without waiting for a transmit slot. Alternatively, we may reserve a slot which follows standard CSMA and responds immediately (after resolving contention) to any packet sent to it during this time. A possible problem with reserving slot is that if the clocks have been already drifted too much, the child node may not see the time sync message while in its CSMA slot. On the other hand, having a CSMA slot may be useful in communicating other status information with nodes. This may include congestion information, sending a new schedule or waking up sleeping nodes. 4.2

Power Saving

There are quite a few ways through which we may save energy in the network. The first way is to put nodes to sleep when they have no data to send or receive. The second is to use energy efficient protocols at all layers so that there is minimum wastage of energy. Another way is to use more efficient hardware and employ power savings at the network card, the microprocessor and the motherboard level whenever possible. Being able to selectively turn off components and guaranteeing service level performance in spite of nodes sleeping regularly can help in extending the battery life for wireless components. A leaf node may sleep when no one is using the device and the device does not expect to receive any communication from the parent node. To decide whether someone is using the device, we may use an inactivity threshold beyond which we automatically turn off the device. When we detect activity from a user at the machine, we turn it on and wait for a synchronization slot. We must remember that we need some method to tell the parent that the child is waiting for it if we use the time sync packet method and not incorporate a CSMA slot. Proceeding further, the child node gets synchronized and then receives slots to transmit and receive. The wireless interface is thus required to be active only at the exact times when either transmission or reception is going to take place. It may sleep at other times. This requires us to account for startup and shutdown times of the wireless card and its energy requirements at those times. There might be times when a parent would like to initi-

4.3

The Whole Picture

We will now look at how the whole system works with the power savings and synchronization in place. We will first assume that the system is all up and running and look at how it performs its operations. Later, we will see how the system is initially setup. As shown in Figure 2, we define a slot to be the smallest time interval for which a station can be in transmit or receive mode in the TDMA schedule. Multiple such slots, allocated to possibly different nodes, comprise the entire TDMA schedule. This schedule is repeated over and over again for a fixed number of times before a (re-)synchronization phase is performed. The sync phase is guarded by guard times on both sides so that no node misses the time sync requests from its parent. This sync phase allows immediate bidirectional data transfer. It is envisioned that in the sync phase, a parent will try to poll all its children and get them to sync with itself. Thus, the sync phase 4

may require different time for each level and corresponding nodes will have to know about their own level as well as their sync phase time. The schematics of this is shown in Figure 2.

Figure 2: TDMA schedule and sync phase. As said above, a parent node tries to sync a child with itself in the sync phase. However, if the child is sleeping, it will ignore the parent’s time sync messages and not acknowledge to the parent. Thus, lack of an acknowledgement acts as an implicit indication to the parent that the child is sleeping and is not interested in being allocated slots in the next schedule. Such children will not be allocated time slots in the next schedule. A topology where all nodes are active will look like the example topology in Figure 3.

Figure 4: A child node is inactive. up is because some other node in the network wishes to communicate with it. In such a case, the appropriate parent will send a special signature pattern to the low-power proxy that will cause a wake up of the node. A parent may send such a pattern only when it enters the sync phase. Wakeup calls will be, however, given priority over time sync messages. A node takes some time to come to full consciousness and we may have to wait till the next sync phase to get this node synchronized and allocate slots to it. In cases where the node has not gone into deep sleep, it may be possible to sync it in the current sync phase, and hence we give priority to the wakeup calls. In any case, the node will be eventually granted slots and it will participate in the communication with the other node. When none of the child nodes have any activity and all of them sleep, there will be no responses to the time sync messages sent by the parent. When a parent identifies such a situation, it can go to sleep, disconnecting the entire sub-tree from the network. It will not participate in the sync phase of its parent and actually behaves very similar to the leaf nodes. This condition is depicted in Figure 5. The only difference for an intermediate node is that it can be woken up by any of its child as well as by its parent. When a previously sleeping child node detects activity at its end and wakes up, it waits for the sync phase to start. Since each node knows the maximum time between two sync phases, this child can safely conclude that its parent is asleep when it does not hear a time sync within that time. In that case, it wakes up the parent using exactly the same mechanism that the parent would have used (sending a signature signal to the low-power proxy of the parent). The parent wakes up and recursively performs this procedure till the required node is awake. Communication then proceeds as usual. Delay between request to communicate by the user to the commencement of the actual communication is not fixed in this case, though it does have a (very large) worst case time.

Figure 3: The FRACTEL topology with all nodes active. A leaf node goes to sleep when it detects inactivity for enough time as configured through some power management features. Such a node does not participate in sync and when the parent distributes a new schedule, the network will look similar to Figure 4. Such a sleeping node may be woken up in two ways. First, a user activity may be detected at the node and the node wakes up through the power management module. Such a node will wait for a time sync poll to occur from its parent and then acknowledge to the parent so that it is now included in the next schedule. It also synchronizes with the parent. The effective delay from the node waking up to it starting to do useful work is equal to the time till the next sync phase plus the time to its allocation slot. The second reason why a node may wake 5

or something similar and also a synchronization phase as described in Section 4.1. If the route is static and is embedded in each node, we can even assume that all nodes are asleep to start with. Following the above mentioned protocols, communication can be started by any node and it will ensure that the required part of the network wakes up and participates in the communication. We note one possible problem in this protocol. We have no error tolerance for sync packets and their acknowledgements. If an ack is lost, that node will be assumed to be asleep and will not be included in the next schedule. Similarly, if a node misses a time sync message from its parent, it will never respond and, again, will be assumed to be asleep. A similar loss while the TDMA schedule is in progress may either be tolerable (in voice or video traffic where a few frames dropped may Figure 5: An entire sub-tree sleeps when no data transfer is re- not cause drastic harm) or may be corrected for (through TCP quired through it. N0 is still active since N2 may be connected retransmissions). The sync phase, however, does not have such to the internet through the landline node. liberties. Since the nodes know about the topology below them and their own parents, it is possible that the root node is asleep 5 Work done so far while there are multiple short-distance communications in Before any of the proposed solution can be applied, it is imperprogress. Any parent node that receives a request for com- ative that we understand the working of the underlying driver munication with another node, first checks if it can satisfy this so that we can make the changes we wish to make in the requirement without passing the request up to is parent. This different components of the MAC layer. We have chosen to occurs when two nodes in a sub-tree wish to communicate use Atheros chipset cards and use the open source madwifi with each other. Such a communication is termed as a short- drivers [1] to build our system. Madwifi drivers are made distance communication. The network layer mechanism for for the standard 802.11 wifi protocol and hence involve all this functionality may easily borrow from routers that main- CSMA/CA capabilities. tain a next hop destination based on network addresses. When We want to modify these drivers in such a way that we can an intermediate parent node detects that it did not use any of run a TDMA based code on this platform. For this, we needed the downstream or upstream slots with its parent, it may de- to use the wireless card in monitor mode as is also done in cide not to participate in the next sync phase. Thus, though a [12], [10], [4] that automatically turned off the beacons, acsub-tree is buzzing with traffic, the root node may go to sleep. knowledgments and RTS-CTS messages. Figure 6 illustrates this case. We have modified the driver to allow actual sending of packets only when its own transmission slot is underway. How to determine which slot is currently going on is a question of the synchronization module. Currently, we have been able to buffer packets at the MAC layer till our transmission slot occurs. We then send the buffered packets serially but ensure that we do not encroach into another slot. Using current transmission rate, we estimate how much time a particular packet will take to leave the card and then decide if we have enough time to allow such a transmission. Since we use a simple queue, the order of frames is not changed. This also implies that we lose the opportunity of transmitting a smaller packet when a larger packet ahead of it in the queue cannot be accommodated in the current slot’s remaining time. We are able to send a particular “magic” packet from a standalone C program. When such a packet arrives at the madwifi driver, it is timestamped and immediately put on air. We do this timestamping at the very last possible place in the code Figure 6: The Root sees no traffic. It may sleep. so as to minimize sender uncertainties. The packet may still queue in the hardware and cause variable delay. On the reAt the very beginning, we may have a route discovery phase ceiver side, we have modified the interrupt service routine to 6

testbed. We then need to use low power motes to wake up the Soekris boards when it receives the appropriate signature signal. This is not trivial, but since it has been implemented in the Wake on WLAN paper, we expect this part to be easier than what it would have been had we started implementing it from scratch. We will proceed with the wake up procedure in incremental steps. We shall first setup a two node network with the motes attached and make the following observations.

timestamp any arriving packet. Later, we check if the newly arrived packet is a magic packet, and if so, calculate an offset using the difference between the timestamp embedded in the packet and that stamped on reception. We conducted some rudimentary experiments to calculate the clock drift in the Soekris boards. However, we are still searching for a good method of measuring such small time delays. Our rough estimate is that the drift is few tens of microsecond per second. We cannot yet quantify this due to the limited accuracy of our measurements. As for now, we have got a two node system that obeys TDMA slots and sends data only in its slot time. We do not yet use the offset calculated from the magic packet. We are currently using Adhoc mode since monitor mode would require us to construct the 802.11 frame format by hand. Commands like ping and scp work well over the TDMA schedule we imposed. We have turned off acknowledgments, but have kept beacons on. Beacons may be currently interfering with our TDMA slots, but we have ignored them since we shall soon work in the monitor mode.

6

1. Time required to put a node to sleep at various sleep levels. 2. Time required to wake up the node after the mote receives the signature signal. 3. Check if any additional energy is expended in wakeup or sleep procedures. 4. Possibility of a scheduled wake up by a mote at some time in the future; clock drift of the mote may be a concern in this case.

Time line for Stage 2

Within the next few months, we propose to complete building the system as described in Section 4. We plan to proceed in the following manner. The first step towards our goal will be to synchronize a couple of nodes and maintain their synchronization. We need to perform the following experiments to get estimates of how often the sync phase should be run and how much guard time should be left around the sync-phase.

Once these steps provide us with satisfactory results, we will incorporate this feature in our testbed. The most difficult and challenging part of the project is to actually deploy nodes at site and get them working properly. When we use long distance directional antenna, we have to align them properly in “line of sight”, otherwise, they will not communicate with each other.

7

1. Synchronize two Soekris boards once and then check the progressive drift between their clocks over time.

Concluding Remarks

The mechanisms and protocols we discussed above are still on the drawing board. They may change considerably as we learn more about the system we are building. Important experiments need to be performed to quantify our requirements about slot intervals, synchronization accuracy and power savings obtained at different sleep modes. However, the purpose of the system and the directions in which we will be working for the rest of the duration of this project have been laid. A significant achievement of this stage of the project has been a fair acquaintance with the driver code.

2. Check how the predictability of the drift changes in short term and long term. 3. Devise a linear regression mechanism to correct for this drift. 4. Check the variation in the throughput of different types of flows as a function of drift. This last experiment will give us a tolerance limit which will also dictate when to resynchronize and the size of the guard bands. We then plan to implement this over multiple hops keeping the tree structure. We shall repeat some of the above experiments to analyse the effect of such a topology on the clock estimation errors and resultant throughput reduction. We may need to tune some parameter like the guard time and the sync periodicity to get better results. The topology discovery and schedule dissemination work is expected to go on concurrently with the time synchronization work. Therefore, we will be in a position to incorporate the node sleep and wake up module to create a more realistic

References [1] Madwifi website. http://madwifi.org. [2] Kameswari Chebrolu and Bhaskaran Raman. Fractel: A fresh perspective on (rural) mesh networks. ACM SIGCOMM Workshop on Networked Systems for Developing Regions (NSDR’07), A Workshop in SIGCOMM 2007, Aug 2007, Kyoto, Japan. [3] Advanced Micro Devices. AMD Geode SC1100 Processor Data Book, January 2004. 7

[4] Christian Doerr, Michael Neufeld, Jeff Fifield, Troy Weingart, Douglas C. Sicker, and Dirk Grunwald. MultiMAC - An adaptive MAC Framework for Dynamic Radio Networking. IEEE, 2005. [5] J. Elson, L. Girod, and D. Estrin. Fine-Grained Time Synchronization using Reference Broadcasts. Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI 2002), Boston, MA, December 2002. [6] Saurabh Ganeriwal, Ram Kumar, and Mani B. Srivastava. Timing-sync Protocol for Sensor Networks. SenSys ’03. [7] Mikls Marti, Branislav Kusy, Gyula Simon, and kos Ldeczi. The Flooding Time Synchronization Protocol. SenSys ’04. [8] Nilesh Mishra, Kameswari Chebrolu, Bhaskaran Raman, and Abhinav Pathak. Wake-on-WLAN. WWW 2006, May 23-26, 2006, Edinburgh, Scotland. [9] Randolph Nelson and Leonard Kleinrock. Spatial TDMA: A Collision-Free Multihop Channel Access Protocol. IEEE 1985. [10] Michael Neufeld, Jeff Fifield, Christian Doerr, Anmol Sheth, and Dirk Grunwald. SoftMAC - Flexible Wireless Research Platform. [11] Ananth Rao and Ion Stocia. An Overlay MAC Layer for 802.11 Networks. [12] Ashish Sharma, Mohit Tiwari, and Haitao Zheng. MadMAC: Building a Reconfigurable Radio Testbed using Commodity 802.11 Hardware. [13] Fikret Sivrikaya and Bulent Yener. Time Synchronization in Sensor Networks: A Survey. 2003. [14] Qing Ye, Yuecheng Zhang, and Liang Cheng. A study on the optimal time synchronization accuracy in wireless sensor networks. Computer Networks 48 (2005) 549– 566, 2004. [15] Dong Zhou and Ten H. Lai. An Accurate and Scalable Clock Synchronization Protocol for IEEE 802.11-based Multihop Ad Hoc Networks. IEEE Transactions on Parallel and Distributer Systems, 2007.

8