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

Prof. Kameswari Chebrolu January 12, 2009 Abstract

connected to other nodes placed about 25-30 km apart using long distance links established by directional antennas. These tier two nodes will then be connected with other such nodes and so on, forming a tree topology. At the last level, user devices are connected with a local omni directional antenna which in turn are connected to the FRACTEL tree at some node. Transmission and reception of data by these nodes in the tree topology is subject to a schedule disseminated by the root node. Since the areas where this project is to be deployed are devoid of any wifi activity, we do not need a contention based protocol. The root node is supposed to create the schedule such that nodes do not have to contend for the channel; it is supposed to create a TDMA schedule. Figure 1 shows an example of the FRACTEL system.

The FRACTEL project makes use of long distance wireless links to connect rural and inaccessible areas to a nearby city providing internet, voice and video connectivity. We shall use high gain directional antennas and sectorized antennas for long distance communication over off-the-shelf WiFi hardware. Shorter distance links extend this connectivity to nearby locations. To support long distance links and quality of service requirements, we shall run a TDMA schedule over the FRACTEL infrastructure. In this project, we look at the issues of node synchronization which is critical for correct working of the TDMA schedule. Since FRACTEL has a tree topology, we can perform synchronization between two levels at a time and finally get the entire network to know the global clock time. Another aspect of this project is to optimize the power utilization of the nodes. We shall use a proxy based wakeup mechanism to let the main devices sleep while another low power device stays awake and listens for any wakeup calls. When it receives such a signal, it wakes up the main board. In this report, we discuss the steps taken so far in these aspects and the path ahead.

1

Introduction

The FRACTEL project [5] is envisioned to provide internet connectivity to remote and inaccessible areas. It is very difficult and cost prohibitive to provide wired connectivity to these areas. We shall use long distance wireless links as the backhaul and shorter distance links for last mile access. In addition to data connectivity, we also envision to provide voice and video conferencing abilities using this infrastructure. This provisioning of quality of service and the long distance links make it necessary to modify the standard 802.11 protocol. We plan to use the license free 2.4GHz frequency band with commodity 802.11 WiFi hardware and the open source madwifi driver [1]. We shall have a root node connected to an ISP through some wired connection. This root node is most likely to be placed at a location in a nearby city or town. It shall be

Figure 1: An example deployment The project needs to solve many issues in the domains of scheduling, node synchronization, MAC layer modifications, routing, and experimentations with long distance links. This thesis primarily deals with synchronization of nodes and power saving. In a tree topology, and when we wish to run 1

layer. The hardware, before transmitting the packet on the air alters the packet by stamping a sequence number. Setting the Retry flag in the second byte of the packet disables hardware sequence number stamping. Also, a MAC CRC is appended to the packet. On the receiving side, the packet has to be altered back to get the correct packet. This is then passed up to the network layer without adding any new headers. This effort had started in the first stage and became successful in the first few weeks of the second stage. In the next section, we describe various approaches to the issues of synchronization and power optimization. This section is copied from the Stage One report without any major modifications and is included here for completeness.

a TDMA schedule over it, we need to synchronize the clocks of all the nodes. Also, when parts of the tree are not participating in an ongoing communication, these nodes may be put to sleep. In the rest of this report, we shall discuss the approaches we are taking for solving the time synchronization and the power optimization issue. We start by defining the problem statement for this project and then look at what aspects were dealt with in the first stage of the project. We then move towards the work done in this stage. It involves quantification of the clock drifts between different cards, and the mechanism for synchronizing nodes in the topology. The TDMA MAC protocol was designed in this stage, and as a result we have a working schedule structure in place. On the power optimization aspect, we have started investigating the possibility of using a mote for waking up the main Soekris boards. After discussing the current status in this regard, we chalk out an outline for the work to be done in the third stage.

4

Related Work

The synchronization problem we face in our network is very similar to that faced in wireless sensor networks. We wish to use the synchronized nodes to transmit and receive in accordance with a TDMA schedule instead of the usual CSMA. We 2 Problem Statement therefore require to synchronize nodes at microsecond accuIn this project, we focus on time synchronization of various racy and maintain this synchronization. We will first look at nodes in a tree topology network. Each node should be able to the uncertainties in the critical path and then discuss few syncorrectly predict the global clock value by the use of its own chronization protocols used in wireless sensor networks. local clock and other timing information that it keeps receiving repeatedly from the root node. The schedule will consist of 4.1 Uncertainties in synchronization various slots dictating who is to transmit at what time. It is The reason that synchronization is so difficult is because of a the responsibility of the synchronization routine to maintain a number of uncertainties in the time required for activities in global notion of time and minimize the use of guard bands. the critical path [13]. After we timestamp a packet in softAnother aspect of this project is to minimize the time for ware, the packet queues in the hardware to get transmitted. which the nodes are awake and thus to optimize the energy re- When its turn comes, it requires some time to actually go on quirements of the network. For this we shall be using a mote to air called the transmit time. The packet then takes some time keep listening to WiFi signals at all times and cause the wake to travel from the transmitting node to the receiving node. This up of a sleeping Soekris board only on receiving a specific sig- is called the propagation delay. If the nodes are fixed, the nature pattern. The mote will thus act as a proxy for the main propagation delay is constant baring significant environmenboard while the main board is sleeping. tal changes. When the receiver receives the packet, it causes an interrupt and then the interrupt service routine (ISR) is in3 Stage One Recap voked. The ISR is the earliest place on the receiver side where We are working on single board computers from Soekris [3] we may record the receive time. and using Atheros AR5212 wireless cards. The Atheros card With a timestamp exchange protocol, the clock skew beworks using madwifi open source drivers and the Soekris tween two clocks can be adjusted for. However, there is an board is capable of running Linux kernels. We invested some additional uncertainty with clocks. Two clocks once adjusted time in configuring the hardware and getting it running. We for skew will not continue to run synchronously due to clock ported a previous work for monitoring per packet RSSI values drifts. Two clocks may run at slightly different speed dependto madwifi 0.9.4. This enabled us to understand the transmit ing on their manufacturing precision, crystal properties, and and the receive path of a packet inside the madwifi code. environmental conditions. The drift shown by a clock may itAfter understanding the flow of the packets inside the self keep changing and therefore usually requires sophisticated driver, we created a simple TDMA like scheme by buffering regression models for adjustments. packets at the MAC layer and allowed them to get transmitWe will now briefly look at a few synchronization techted only when desired. We used a trigger packet to initiate niques for sensor networks but also applicable to our setting. the TDMA working. This alteration in the code was done 4.2 Reference Broadcast Synchronization in the adhoc mode. Our next step was to introduce a similar mechanism in the monitor mode. In the monitor mode, the We may be able to increase the accuracy of time synchroniza802.11 frame headers are not applied to the packet as it fol- tion if we eliminate some of the uncertainties in the critical lows a different path from the network layer to the physical path. The RBS protocol [6] achieves this by using a novel 2

technique. A reference node periodically broadcasts synchronization beacons and all the receivers who receive this beacon record their local time and then exchange the recorded time with each others. In this protocol, all the receivers of the beacon are synchronized with each other. The sender of the beacon is not synchronized with the receivers. Therefore, the beacon itself need not contain any timing information. With the sender’s uncertainties eliminated from the critical path, significant timing accuracy can be gained. However, every receiver may have to store an offset with respect to all other receivers. This can be a significant overhead particularly if the nodes are resource constrained. Moreover, we require a reference broadcaster to remain outside of the time synchronization since it cannot be synchronized in this mechanism. This also implies that its broadcast must be visible to each receiver present in the network. It is, therefore, not suitable for hierarchical topology and non-omni directional links. 4.3

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. 4.5

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 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.

Timing-sync Protocol for Sensor Networks

This is a sender–receiver synchronization protocol [7]. The working of the protocol is divided into two phases. The first phase essentially creates a spanning tree of the mesh network. This tree structure is used by the second phase for a pair-wise exchange of timing information. The child and the parent 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. 4.4

Clock Synchronization Protocol for 802.11 Networks

4.6

Wake on WLAN

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 [10], 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.

5

The Flooding Time Synchronization Protocol

Work Done in This Stage

We have dealt with both the aspects of node synchronization and power optimization in this stage. Some important achievements of this stage are hardware level timestamping of packets, creation of packets in the MAC layer, quantification of the clock drift between nodes, and quantification of the energy detection ability of the mote. In this section, we will look at all these aspects in more detail.

This protocol acheives sender-receiver synchronization by broadcasting timestamped messages to all possible receivers [9]. 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

5.1

Hardware Timestamp

When a packet is enabled for sending by the madwifi driver, it does not immediately leave the card. We need the exact 3

time when a packet was sent for proper node synchronization. Details of node synchronization are given in Section 5.3. To get a packet timestamped by the hardware, we have to fool the hardware into believing that the packet being sent is a beacon packet. Beacons are timestamped with a 64-bit clock value at byte 24-30. This mechanism can be exploited by calling the ath hal setuptxdesc() function with the value HAL PKT TYPE BEACON ORed with the flag parameter. We require only the schedule packets to be timestamped by the hardware. We create and send these special packets from the MAC layer itself, and hence could alter the flag without affecting non-schedule packets. All other packets coming from the network layer come through the function ath hardstart() where we append a data header to these packets. The schedule packet is prepared at the MAC layer using a function fractel ath mgtstart() which is very similar to the ath mgtstart() function. We append the schedule header before we reach the ath tx startraw() function and thus, can always treat data packets differently from the schedule packets. We have disabled hardware sequence numbering by carefully choosing the value of the second byte of the packet structure. Only a few values of this byte disable the sequence numbering which otherwise modifies the byte 23-24 of all packets. 5.2

Figure 3: After the SWBA interrupt, a packet gets created and sent on air in about 415µs. The one-shot timer is of acute interest to us because we shall need it to implement different slot sizes. We can specify this timer to fire at a granularity of 125µs. However, its behaviour is not yet completely clear. The intended use of the one-shot timer was to start the first beacon. When a node in AP mode or in adhoc mode comes up, it initiates the beacon sending mechanism. All but the first beacon are sent after the SWBA interrupt occurs due to the periodic timer. However, the first beacon is sent after the one-shot timer expires. The one-shot timer requires the reset of the internal clock to start counting down. Thus, the timer was never intended to be set more than once. We are yet to find out how to tweak its behaviour to get it working the way we need.

Working with the Timers

The Soekris board runs the entire Linux kernel. Hence we already have access to software timers even within the madwifi driver. In addition to this, we also have the Atheros hardware clock which is accurate at a microsecond granularity. The hardware provides us with two important timers–one periodic and the other one-shot. The use of these timers is critical to the accuracy of TDMA scheduling. When set to fire at a fixed interval, the periodic timer causes an SWBA interrupt continuously at that interval. This clock can be set to fire at millisecond granularity and is accurate within a few microseconds at 90 percentile as shown by the Figure 2. Another interesting observation is the time required to send a packet after an interrupt has occurred. Figure 3 shows that the time required to start sending a packet is about 415µs after the SWBA interrupt occurs.

5.3

Time Synchronization

In the first stage, we had decided to use the Timesync protocol for Sensor Networks [7] for synchronizing nodes in our setting. This protocol requires two messages to be exchanged between the nodes to be synchronized. By the exchange of two messages, it can measure the propagation delay between the nodes in addition to the clock offset. If, however, the propagation delay is negligible, already predictable, or if it can be compensated through some other means such as the use of guard bands, then we may use only a single message to determine the clock offset between two nodes. Currently, we are planning to go ahead with this single message approach and determine only the clock offset. In our setting, all nodes must be synchronized with the root node. The root node sends the schedule to all its children in the form of a scheduling packet. It consists of a schedule header and any number of scheduling elements. Each scheduling element contains information about a time slot. This schedule packet will be hardware timestamped while transmission. The root will also include a “root timestamp” which is the time at which it starts all timing calculations for the scheduling elements in that schedule. Thus, the “root timestamp” is the time when it intended to begin the schedule and the hardware timestamp is the time at which the packet was actually sent. When other nodes receive this schedule, they calcuFigure 2: The periodic timer is so accurate that the SWBA late their clock offset from the root node by subtracting their interrupt occurs within a margin of 5µs for most instances. own receive timestamp from the transmit timestamp inside the packet. When it is positive, the receiver’s clock is running be4

not. The schedule header includes the timestamp information that we discussed above and the ID of the transmitting node. Each scheduling element contains the information about when it starts relative to the “root timestamp”, its duration, the transmitter node, the receiver node and the flowID. The structure of the schedule header and a scheduling element is shown in Figure 5.

hind that of the sender and when the offset is negative, the receiver’s clock is running ahead of the sender’s. When these tier-two nodes disseminate the schedule ahead, they do not change the “root timestamp” but also include their own offset with the root node. Thus a schedule header contains three timing information chunks. It contains the time at which the root starts calculating the relative time for all scheduling elements (the “root timestamp”), the time at which this packet was transmitted (the hardware transmit timestamp) and the clock offset of the transmitting node from the root node. The Figure 4 shows the use of these timestamps. The numbers under the double line are offsets calculated by that node. The Node R is assumed to be the root node, the Node A is its child and the Node B is A’s child. Node A shall send the schedule to Node B as part of a slot indicated by a scheduling element.

2000

1000

1000

1000

2000

5050 5000

8000

10000

Node R 0 10950 Node A 7000

7950

9950

11950

­1950 Node B 2000

5000

8000

4000

Figure 5: The structure of the schedule header and a scheduling element

Offset = TX Timestamp + Offset in Packet – RX Timestamp

Figure 4: Time synchronization at work

5.4

Drift Calculation

As described above, the nodes get synchronized at every schedule frame interval. The duration of this interval depends on the workload of the system. However, an upper bound on this interval is indicated by the fact that the clocks of different nodes do not run at precisely the same pace. Ideally, once we calculate the offset between two clocks, it should remain the same for all times in the future. However, since clocks do not precisely run at the same speed, this offset between the clocks changes by time. The rate of this change is not fixed and depends on the hardware used and environmental conditions. We call this change in offset as clock drift. Periodic resynchronization is necessary to prevent clocks from getting completely out of synchronization. To get a ballpark estimate of the clock drift, we sent packets periodically from one node to another and calculated the offset between the receiver and the sender’s clock. The difference between consecutive such offsets is the drift. We observed that the drift varies between 1µs/s to about 15µs/s depending on the card pair used. We also observed that the clock drift remains fairly constant over time. Hence, it is predictable and can be accounted for with simple linear adjustments, if needed.

Using this information present inside the received packet, a node calculates the relative time for each scheduling element. As the schedule percolates down the tree, it may contain some scheduling elements which should have occurred in the past. This can happen because the schedule is disseminated when indicated by some scheduling element itself. For a receiving node, such a scheduling element and any element earlier than that in time is always in the past. The existence of the three time information chunks in the packet enables the node to discard all such scheduling elements by calculating the exact current time for the root node. While broadcasting a schedule, every node can eliminate those scheduling elements from it which should have occurred in the past, but currently, we send the entire schedule without any modification. As stated above, the schedule packet consists of a schedule header and any number of scheduling elements following it. The number of scheduling elements present in a schedule are given in the header and are bounded by the maximum packet size that can go over the channel without getting fragmented. We enforce this requirement so that when a node receives a packet, it can easily check if it is a schedule packet or 5

Card Pair 1-5 1-6 1-3 6-3 5-3 Average -2.78 9.72 4.07 -1.41 13.24 Std Dev 0.42 0.47 1.03 0.5 1.51 Table 1: Drift between clocks of different card pairs. Negative values only indicate that the difference between the offset keeps on decreasing.

Bytes 1Mbps 6Mbps 11Mbps 18Mbps Sent 1 11.66 19.01 -4.04 NA 100 6 -1.5 5.4 5.25 200 23 9.02 17.98 18 500 11 15.55 -5.28 28.5 1000 3 6 0.5 7 Table 1 shows the average drift and the standard deviation for 1400 38 -3 9 -1 different card pairs. Table 2: Difference in transmit time of a packet as shown by the power meter and that reported by the mote in µs. 5.5 Power Optimization so that it detects the channel activity for both 802.15.4 frames as well as 802.11 frames. We can poll this pin to know if the channel is busy or not. We wrote a TinyOS [4] application that continuously polls the CCA pin and returns the time during which the channel was sensed busy. We verified the values returned by the mote with those given by a power meter. The mote cannot sense faster than one tick (approximately 30.5µs). The readings returned by the mote match those returned by the power meter within this tolerance. The Table 2 gives the difference between the length of packets as shown by the power meter and those reported by the mote. We observe that these readings are always within the 30.5µs granularity of the mote’s timer. We do not have a reading from 1 byte packet sent at 18Mbps. The first column in the table is the payload size of a UDP packet. When packets are sent very fast through the 802.11 card, we observed that the mote fails to tell two packets apart. After careful experimentation, we found that the card was sending packets too fast, waiting only about 17.5µs between packets. Quantification of the exact time between two packets such that the mote will never fail to detect two packets apart still remains to be done.

Having a TDMA schedule based scheme means that the nodes continuously exchange the scheduling information even if there is no data flow in a part of the network to keep nodes synchronized. Considering the possible usage pattern of our network, it is highly possible that there will be large periods when there is no data exchange. During this time, it must be possible for the nodes to go to sleep and then wake up and synchronize as and when required. We may employ a scheme similar to that used in the Power Save Mode (PSM) in IEEE 802.11 where the nodes wake up only for reception of a schedule and go to sleep if it need not participate in any scheduling element. This can be further improved using the technique of bounded slowdown as discussed in [8]. Another method is to let the node sleep whenever it detects an idle period and then wake up only when some other node requires to communicate with it. This approach is taken in [10]. Considering our usage pattern where the nodes may remain idle for a long time, the approach in [10] appears the most effective mechanism for conserving energy. A sleeping node may easily detect activity at its own end and wake up. However, if a remote host wishes to wake up another node, it needs to send a signal to the sleeping node and cause its wake up. This is straightforward to implement if we have a low power listening circuitry. However, the hardware we are using is not capable of entering sleep states and hence we should investigate some other mechanisms. We have another hardware component called the mote [2] which uses very little power and can act as a proxy for waking up the main wireless node. The mote works on 802.15.4 Zigbee standard and cannot decipher 802.11 signals. If we plan to use the mote as a proxy device, we will need to use some signature pattern with the 802.11 packets to signal the wake up of a particular node. This signature pattern could be different lengths of packets or different energy levels. Another way is to use motes at both the sender’s as well as the receiver’s end and send 802.15.4 signals as a wake up call. This requires investigating if the 802.15.4 signals can also be sent through a directional antenna like the 802.11 signals and reach equally long distances. We performed certain preliminary experiments to investigate the feasibility of the first method. The length of the received packet may be used as a signature pattern. The mote detects activity on the air using its carrier sensing abilities. The Clear Channel Assessment (CCA) pin can be set in a configuration

5.6

Fitting in the Big Picture

Both the modules of synchronization and power optimization are essential portions of the envisioned system. The use of TDMA based access mechanism is required to provide quality of service guarantees for voice and video communication. And for TDMA to function, a notion of global clock is required. Synchronization of nodes makes it feasible to run the TDMA schedule over the infrastructure. However, synchronization itself is not enough. The root node must create a schedule that caters to the bandwidth requirements of all the nodes in the network. Mechanisms are needed to allow new nodes to join the network, to allow nodes to leave the system and to make bandwidth requests. The root node needs to know the interference map of the entire region so that it can keep the most effective routes as part of the tree and replace those which are no longer the best ones by others. It should decide upon a schedule that does not allow any collision of packets to occur still satisfying bandwidth requests in the most optimal way possibly using different channels for different data flows. The locations where this system is to be deployed are low 6

shown this to be possible if the wifi cards leave a sufficient gap between packets. We shall quantify this shortly and move towards the hardware implementation of a method to automatically put the Soekirs boards to sleep and wake them up when the mote detects a signature.

on resources and this includes electricity. It may very well be possible that the system is required to work off battery power. Also, even if electricity had been plentiful, it does not give us the rights to waste any bit of it. Therefore, whenever not required, the nodes must be able to shut down and conserve power. Nevertheless, when their services are needed, they must be available without much delay. Hence the power optimization module also plays an important role in making the project feasible.

6

References [1] Madwifi website. http://madwifi.org. [2] Mote website. http://www.moteiv.com/.

Looking Ahead

[3] Soekris website. http://www.soekris.com/.

One of the first things to be done in the third stage is to quantify the time between two packets such that the mote can tell them apart. We then need to study the usage pattern of usual mesh wireless networks. We may use the length of a packet for encoding the wake-up signal only if packets of some specific length are rarely used in wireless mesh networks. Once we are successful in doing this, we must build the hardware necessary to switch on the Soekris board after receiving a trigger from the mote. The authors of [10] have already implemented such a circuit and we do not expect much problems in implementing the circuitry. On the synchronization front, we have to use the one-shot timer for accurate working of the TDMA schedule. After this issue is sorted out, the synchronization mechanism must be checked over a multihop topology. We will need to add guard bands to each slot and account for the fact that when we have many nodes in the network, they may get slightly unsynchronized for some time. Timers with granularity less than 125µs are not available, but they can be emulated through busy wait cycles checking the hardware clock value continuously. the synchronization module must provide a clean interface for plugging the TDMA module on top of it.

7

[4] Tinyos website. http://www.tinyos.net/. [5] 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. [6] 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. [7] Saurabh Ganeriwal, Ram Kumar, and Mani B. Srivastava. Timing-sync Protocol for Sensor Networks. SenSys ’03. [8] Ronny Krashinsky and Hari Balakrishnan. Minimizing energy for wireless web access with bounded slowdown. MOBICOMM’02, 2002. [9] Mikls Marti, Branislav Kusy, Gyula Simon, and kos Ldeczi. The Flooding Time Synchronization Protocol. SenSys ’04.

Concluding Remarks

In this stage, we prepared the TDMA MAC protocol detailing most aspects of scheduling, node join procedure and bandwidth request procedure. We implemented parts of the TDMA MAC protocol and quantified some aspects of synchronization. We now know that the clock drift between cards is negligible and we have a running prototype of the synchronization mechanism by which each node knows the accurate value of the global time and can follow the TDMA schedule given by the root node. The one-shot timer continues to evade us, but once we understand its behaviour, we will use this timer instead of the software timers currently used in our implementation. In the days to come, we shall complete the synchronization aspect by verifying its proper working on a multihop topology. The use of motes as a proxy for waking up the main board to save energy was investigated. We may be able to use the length of a transmitted packet as a wake up signal if the mote can always disambiguously capture the length of a packet. Our experiments with the mote and the power meter so far have

[10] Nilesh Mishra, Kameswari Chebrolu, Bhaskaran Raman, and Abhinav Pathak. Wake-on-WLAN. WWW 2006, May 23-26, 2006, Edinburgh, Scotland. [11] Randolph Nelson and Leonard Kleinrock. Spatial TDMA: A Collision-Free Multihop Channel Access Protocol. IEEE 1985. [12] Ananth Rao and Ion Stocia. An Overlay MAC Layer for 802.11 Networks. [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. 7

[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