Business & Finance

Multi-hop Time Synchronization and Power Saving Mechanisms for FRACTEL

Description
Multi-hop Time Synchronization and Power Saving Mechanisms for FRACTEL
Published
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Transcript
  Multi-hop Time Synchronization and Power Saving Mechanisms forFRACTEL Ashutosh Dhekne Department of Computer Science and Engineering,IIT Bombay, IndiaUnder the guidance of  Prof. Kameswari ChebroluJanuary 12, 2009 Abstract The FRACTEL project makes use of long distance wirelesslinks to connect rural and inaccessible areas to a nearby cityproviding internet, voice and video connectivity. We shalluse high gain directional antennas and sectorized antennas forlong distance communication over off-the-shelf WiFi hard-ware. Shorter distance links extend this connectivity to nearbylocations. To support long distance links and quality of servicerequirements, we shall run a TDMA schedule over the FRAC-TEL 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, wecan perform synchronization between two levels at a time andfinally get the entire network to know the global clock time.Another aspect of this project is to optimize the power utiliza-tion of the nodes. We shall use a proxy based wakeup mech-anism to let the main devices sleep while another low powerdevice stays awake and listens for any wakeup calls. When itreceives such a signal, it wakes up the main board. In this re-port, we discuss the steps taken so far in these aspects and thepath ahead. 1 Introduction The FRACTEL project [5] is envisioned to provide internetconnectivity to remote and inaccessible areas. It is very diffi-cult and cost prohibitive to provide wired connectivity to theseareas. We shall use long distance wireless links as the back-haul and shorter distance links for last mile access. In addi-tion to data connectivity, we also envision to provide voiceand video conferencing abilities using this infrastructure. Thisprovisioning of quality of service and the long distance linksmake it necessary to modify the standard 802.11 protocol.We plan to use the license free 2.4GHz frequency band withcommodity 802.11 WiFi hardware and the open source mad-wifi driver [1]. We shall have a root node connected to an ISPthrough some wired connection. This root node is most likelyto be placed at a location in a nearby city or town. It shall beconnected to other nodes placed about 25-30 km apart usinglong distance links established by directional antennas. Thesetier two nodes will then be connected with other such nodesand so on, forming a tree topology. At the last level, userdevices are connected with a local omni directional antennawhich in turn are connected to the FRACTEL tree at somenode. Transmission and reception of data by these nodes inthe tree topology is subject to a schedule disseminated by theroot node. Since the areas where this project is to be deployedare devoid of any wifi activity, we do not need a contentionbased protocol. The root node is supposed to create the sched-ule such that nodes do not have to contend for the channel; itis supposed to create a TDMA schedule. Figure 1 shows anexample of the FRACTEL system.Figure 1: An example deploymentThe project needs to solve many issues in the domainsof scheduling, node synchronization, MAC layer modifica-tions, routing, and experimentations with long distance links.This thesis primarily deals with synchronization of nodes andpower saving. In a tree topology, and when we wish to run1  a TDMA schedule over it, we need to synchronize the clocksof all the nodes. Also, when parts of the tree are not partici-pating in an ongoing communication, these nodes may be putto sleep. In the rest of this report, we shall discuss the ap-proaches we are taking for solving the time synchronizationand the power optimization issue.We start by defining the problem statement for this projectand then look at what aspects were dealt with in the first stageof the project. We then move towards the work done in thisstage. It involves quantification of the clock drifts betweendifferent cards, and the mechanism for synchronizing nodes inthe topology. The TDMA MAC protocol was designed in thisstage, and as a result we have a working schedule structurein place. On the power optimization aspect, we have startedinvestigating the possibility of using a mote for waking up themain Soekris boards. After discussing the current status in thisregard, we chalk out an outline for the work to be done in thethird stage. 2 Problem Statement In this project, we focus on time synchronization of variousnodes in a tree topology network. Each node should be able tocorrectly predict the global clock value by the use of its ownlocal clock and other timing information that it keeps receivingrepeatedly from the root node. The schedule will consist of various slots dictating who is to transmit at what time. It isthe responsibility of the synchronization routine to maintain aglobal notion of time and minimize the use of guard bands.Another aspect of this project is to minimize the time forwhich the nodes are awake and thus to optimize the energy re-quirements of the network. For this we shall be using a mote tokeep listening to WiFi signals at all times and cause the wakeup of a sleeping Soekris board only on receiving a specific sig-nature pattern. The mote will thus act as a proxy for the mainboard while the main board is sleeping. 3 Stage One Recap We are working on single board computers from Soekris [3]and using Atheros AR5212 wireless cards. The Atheros cardworks using madwifi open source drivers and the Soekrisboard is capable of running Linux kernels. We invested sometime in configuring the hardware and getting it running. Weported a previous work for monitoring per packet RSSI valuesto madwifi 0.9.4. This enabled us to understand the transmitand the receive path of a packet inside the madwifi code.After understanding the flow of the packets inside thedriver, we created a simple TDMA like scheme by bufferingpackets at the MAC layer and allowed them to get transmit-ted only when desired. We used a trigger packet to initiatethe TDMA working. This alteration in the code was donein the adhoc mode. Our next step was to introduce a simi-lar mechanism in the monitor mode. In the monitor mode, the802.11 frame headers are not applied to the packet as it fol-lows a different path from the network layer to the physicallayer. The hardware, before transmitting the packet on the airalters the packet by stamping a sequence number. Setting theRetry flag in the second byte of the packet disables hardwaresequence number stamping. Also, a MAC CRC is appendedto the packet. On the receiving side, the packet has to be al-tered back to get the correct packet. This is then passed up tothe network layer without adding any new headers. This efforthad started in the first stage and became successful in the firstfew weeks of the second stage.In the next section, we describe various approaches to theissues of synchronization and power optimization. This sec-tion is copied from the Stage One report without any majormodifications and is included here for completeness. 4 Related Work The synchronization problem we face in our network is verysimilar to that faced in wireless sensor networks. We wish touse the synchronized nodes to transmit and receive in accor-dance with a TDMA schedule instead of the usual CSMA. Wetherefore require to synchronize nodes at microsecond accu-racy and maintain this synchronization. We will first look atthe uncertainties in the critical path and then discuss few syn-chronization protocols used in wireless sensor networks. 4.1 Uncertainties in synchronization The reason that synchronization is so difficult is because of anumber of uncertainties in the time required for activities inthe critical path [13]. After we timestamp a packet in soft-ware, the packet queues in the hardware to get transmitted.When its turn comes, it requires some time to actually go onair called the transmit time. The packet then takes some timeto travel from the transmitting node to the receiving node. Thisis called the propagation delay. If the nodes are fixed, thepropagation delay is constant baring significant environmen-tal changes. When the receiver receives the packet, it causesan interrupt and then the interrupt service routine (ISR) is in-voked. The ISR is the earliest place on the receiver side wherewe may record the receive time.With a timestamp exchange protocol, the clock skew be-tween two clocks can be adjusted for. However, there is anadditional uncertainty with clocks. Two clocks once adjustedfor skew will not continue to run synchronously due to clock drifts. Two clocks may run at slightly different speed depend-ing on their manufacturing precision, crystal properties, andenvironmental conditions. The drift shown by a clock may it-self keepchanging and thereforeusually requiressophisticatedregression models for adjustments.We will now briefly look at a few synchronization tech-niques for sensor networks but also applicable to our setting. 4.2 Reference Broadcast Synchronization We may be able to increase the accuracy of time synchroniza-tion if we eliminate some of the uncertainties in the criticalpath. The RBS protocol [6] achieves this by using a novel2  technique. A reference node periodically broadcasts synchro-nization beacons and all the receivers who receive this bea-con record their local time and then exchange the recordedtime with each others. In this protocol, all the receivers of thebeacon are synchronized with each other. The sender of thebeacon is not synchronized with the receivers. Therefore, thebeacon itself need not contain any timing information.With the sender’s uncertainties eliminated from the criti-cal path, significant timing accuracy can be gained. However,every receiver may have to store an offset with respect to allother receivers. This can be a significant overhead particularlyif the nodes are resource constrained. Moreover, we require areference broadcaster to remain outside of the time synchro-nization since it cannot be synchronized in this mechanism.This also implies that its broadcast must be visible to each re-ceiver present in the network. It is, therefore, not suitable forhierarchical topology and non-omni directional links. 4.3 Timing-sync Protocol for Sensor Networks This is a sender–receiver synchronization protocol [7]. Theworking of the protocol is divided into two phases. The firstphase essentially creates a spanning tree of the mesh network.This tree structure is used by the second phase for a pair-wiseexchange of timing information. The child and the parentnode know each other from the first phase. The parent sendsa time sync packet to the child node. The child node respondswith a timestamped packet (time = T1) and sends it to theparent. The parent node records its own local time when itreceived this packet (time = T2) and responds with anothertimestamped packet at time T3 which also includes the timesT1 and T2. The child again records the time it received thisresponse packet (time = T4).The child now knows the time difference between T1 andT2 which corresponds to the clock skew between the two plusthe propagation delay. Taking an average of the differencebetween T2-T1 and T4-T3 gives better estimate of the clock skew. An advantage of this protocol over RBS is that it is in-herently multi-hop. However, each pair of nodes in the treestructure must exchange two messages to be synchronized.Also, this process has to start from the root node, by issueof a time sync packet, and continue to the leaf nodes. It is asequential process and may be time consuming. 4.4 The Flooding Time Synchronization Protocol This protocol acheives sender-receiver synchronization bybroadcasting timestamped messages to all possible re-ceivers [9]. It uses a preamble and few sync bytes which canbe continuously used by the receiver to estimate the clock dif-ference between the sender and the receivers. It reduces the jitter in interrupt handling time by averaging multiple times-tamps taken at each byte boundary. Only the final averagetimestamp is embedded into the packet. This protocol alsoincludes linear regression to predict the clock drift. The pa-per mentions that the clock drift in the Mica motes is about40 µs . We need to check the clock drift in our equipment, butnonetheless, compensatingforclockdriftmightbenefitourap-plication too. This protocol also deals with changing the rootnode periodically. Due to our natural tree topology, we do notrequire this feature. 4.5 Clock Synchronization Protocol for 802.11 Networks This protocol deals specifically with the problem of synchro-nizing 802.11 nodes in a multihop adhoc network. [15]. Thepaper describes how the number of stations sending the bea-con can be reduced by designating some stations as more “im-portant” for beaconing than others in a mesh network. Thisreduces beacon collisions. It requires creation of dominatingsets of nodes which helps in deciding which nodes are moreimportant. It also does frequency adjustments to get all clocksto have about the same accuracy. It deals with general meshad-hoc networks and not with tree topology we have in our ap-plication. The paper, however, describes a very useful mecha-nism already present in 802.11. The beacon frames sent in ad-hoc networks themselves contain a timestamp which is gener-ated to be that time of the local clock when the first bit of thetimestamp hits the wireless interface. Added to propagationdelay this gives an error of  ± 5 µs . The finding that the bea-con actually contains a very precise time can go a long way inperforming synchronization. We may be able to send beaconswhenever we want to synchronize a pair of nodes with moreaccurate sender’s timing than mere MAC layer timestampingof packets. 4.6 Wake on WLAN In order to conserve energy, it is advisable to switch off themain wireless device when not needed and wake it up on de-mand. It must be possible to wake up devices remotely. Inthe Wake on WLAN paper [10], the authors have used a lowpower consuming mote that listens to the wireless channel andwakes up the main board (Soekris) when it senses increasedenergy on the channel. In this paper, the entire main board isturned off, and therefore, it incurs a large delay in booting upthe main device. However, if we put some of its componentsto sleep instead of completely switching off the main board,we may achieve faster wakeups. 5 Work Done in This Stage We have dealt with both the aspects of node synchronizationand power optimization in this stage. Some important achieve-ments of this stage are hardware level timestamping of pack-ets, creation of packets in the MAC layer, quantification of theclock drift between nodes, and quantification of the energy de-tection ability of the mote. In this section, we will look at allthese aspects in more detail. 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 exact3  time when a packet was sent for proper node synchroniza-tion. Details of node synchronization are given in Section 5.3.To get a packet timestamped by the hardware, we have tofool the hardware into believing that the packet being sentis a beacon packet. Beacons are timestamped with a 64-bitclock value at byte 24-30. This mechanism can be exploitedby calling the ath hal setuptxdesc() function with the valueHAL PKT TYPE BEACON ORed with the flag parameter.We require only the schedule packets to be timestamped bythe hardware. We create and send these special packets fromthe MAC layer itself, and hence could alter the flag without af-fecting non-schedule packets. All other packets coming fromthe network layer come through the function ath hardstart()where we append a data header to these packets. The schedulepacket is prepared at the MAC layer using a function frac-tel ath mgtstart() which is very similar to the ath mgtstart()function. We append the schedule header before we reach theath tx startraw() function and thus, can always treat data pack-ets differently from the schedule packets. We have disabledhardware sequence numbering by carefully choosing the valueof the second byte of the packet structure. Only a few valuesof this byte disable the sequence numbering which otherwisemodifies the byte 23-24 of all packets. 5.2 Working with the Timers The Soekris board runs the entire Linux kernel. Hence wealready have access to software timers even within the mad-wifi driver. In addition to this, we also have the Atheros hard-wareclockwhichisaccurateatamicrosecondgranularity. Thehardware provides us with two important timers–one periodicand the other one-shot. The use of these timers is critical tothe accuracy of TDMA scheduling. When set to fire at a fixedinterval, the periodic timer causes an SWBA interrupt contin-uously at that interval. This clock can be set to fire at millisec-ond granularity and is accurate within a few microseconds at90 percentile as shown by the Figure 2. Another interestingobservation is the time required to send a packet after an in-terrupt has occurred. Figure 3 shows that the time required tostart sending a packet is about 415 µ s after the SWBA interruptoccurs.Figure 2: The periodic timer is so accurate that the SWBAinterrupt occurs within a margin of 5 µ s for most instances.Figure 3: After the SWBA interrupt, a packet gets created andsent on air in about 415 µ s.The one-shot timer is of acute interest to us because weshall need it to implement different slot sizes. We can specifythis timer to fire at a granularity of 125 µ s. However, its be-haviour is not yet completely clear. The intended use of theone-shot timer was to start the first beacon. When a node inAP mode or in adhoc mode comes up, it initiates the beaconsending mechanism. All but the first beacon are sent after theSWBA interrupt occurs due to the periodic timer. However,the first beacon is sent after the one-shot timer expires. Theone-shot timer requires the reset of the internal clock to startcounting down. Thus, the timer was never intended to be setmore than once. We are yet to find out how to tweak its be-haviour to get it working the way we need. 5.3 Time Synchronization In the first stage, we had decided to use the Timesync proto-col for Sensor Networks [7] for synchronizing nodes in oursetting. This protocol requires two messages to be exchangedbetween the nodes to be synchronized. By the exchange of two messages, it can measure the propagation delay betweenthe nodes in addition to the clock offset. If, however, the prop-agation delay is negligible, already predictable, or if it can becompensated through some other means such as the use of guard bands, then we may use only a single message to de-termine the clock offset between two nodes. Currently, we areplanning to go ahead with this single message approach anddetermine only the clock offset.In our setting, all nodes must be synchronized with the rootnode. The root node sends the schedule to all its children in theform of a scheduling packet. It consists of a schedule headerand any number of scheduling elements. Each scheduling el-ement contains information about a time slot. This schedulepacket will be hardware timestamped while transmission. Theroot will also include a “root timestamp” which is the timeat which it starts all timing calculations for the scheduling el-ements in that schedule. Thus, the “root timestamp” is thetime when it intended to begin the schedule and the hard-ware timestamp is the time at which the packet was actuallysent. When other nodes receive this schedule, they calcu-late their clock offset from the root node by subtracting theirown receive timestamp from the transmit timestamp inside thepacket. When it is positive, the receiver’s clock is running be-4  hind that of the sender and when the offset is negative, the re-ceiver’s clock is running ahead of the sender’s. When thesetier-two nodes disseminate the schedule ahead, they do notchange the “root timestamp” but also include their own offsetwith the root node. Thus a schedule header contains three tim-ing information chunks. It contains the time at which the rootstarts calculating the relative time for all scheduling elements(the“roottimestamp”), thetimeatwhichthispacketwastrans-mitted (the hardware transmit timestamp) and the clock offsetof the transmitting node from the root node. The Figure 4shows the use of these timestamps. The numbers under thedouble line are offsets calculated by that node. The Node R isassumed to be the root node, the Node A is its child and theNode B is A’s child. Node A shall send the schedule to NodeB as part of a slot indicated by a scheduling element. 50005050 2000 1000700020007950-19504000   1000 80009950 1000 5000 2000 109501195010000Offset = TX Timestamp + Offset in Packet – RX Timestamp08000Node RNode ANode B Figure 4: Time synchronization at work Using this information present inside the received packet, anode calculates the relative time for each scheduling element.As the schedule percolates down the tree, it may contain somescheduling elements which should have occurred in the past.This can happen because the schedule is disseminated whenindicated by some scheduling element itself. For a receivingnode, such a scheduling element and any element earlier thanthat in time is always in the past. The existence of the threetime information chunks in the packet enables the node to dis-card all such scheduling elements by calculating the exact cur-rent time for the root node. While broadcasting a schedule,every node can eliminate those scheduling elements from itwhich should have occurred in the past, but currently, we sendthe entire schedule without any modification.As stated above, the schedule packet consists of a sched-ule header and any number of scheduling elements followingit. The number of scheduling elements present in a sched-ule are given in the header and are bounded by the maximumpacket size that can go over the channel without getting frag-mented. We enforce this requirement so that when a node re-ceives a packet, it can easily check if it is a schedule packet ornot. The schedule header includes the timestamp informationthat we discussed above and the ID of the transmitting node.Each scheduling element contains the information about whenit starts relative to the “root timestamp”, its duration, the trans-mitter node, the receiver node and the flowID. The structure of the schedule header and a scheduling element is shown in Fig-ure 5.Figure 5: The structure of the schedule header and a schedul-ing element 5.4 Drift Calculation As described above, the nodes get synchronized at everyschedule frame interval. The duration of this interval dependson the workload of the system. However, an upper bound onthis interval is indicated by the fact that the clocks of differ-ent nodes do not run at precisely the same pace. Ideally, oncewe calculate the offset between two clocks, it should remainthe same for all times in the future. However, since clocks donot precisely run at the same speed, this offset between theclocks changes by time. The rate of this change is not fixedand depends on the hardware used and environmental condi-tions. We call this change in offset as clock drift. Periodicresynchronization is necessary to prevent clocks from gettingcompletely out of synchronization.To get a ballpark estimate of the clock drift, we sent packetsperiodically from one node to another and calculated the offsetbetween the receiver and the sender’s clock. The differencebetween consecutive such offsets is the drift. We observedthat the drift varies between 1 µ s/s to about 15 µ s/s dependingon the card pair used. We also observed that the clock driftremains fairly constant over time. Hence, it is predictable andcanbeaccountedforwithsimplelinearadjustments, ifneeded.5
Search
Similar documents
View more...
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x