high throughput broadcast bursts in embedded networks
TRANSCRIPT
High Throughput BroadcastBursts in Embedded Networks
John VidlerB.Sc Computer Science
March 20, 2009
I certify that the material contained in this dissertation is my own work anddoes not contain unreferenced or unacknowledged material. I also warrant thatthe above statement applies to the implementation of the project and allassociated documentation. Regarding the electronically submitted version ofthis submitted work, I consent to this being stored electronically and copiedfor assessment purposes, including the Department’s use of plagiarismdetection systems in order to check the integrity of assessed work.I agree to my dissertation being placed in the public domain, with my nameexplicitly included as the author of the work.
Date:
Signed:
1
Abstract
The increasing speed of sensor motes has allowed developers to design systemsrequiring large bursts of data, such as localization in the “Countersniper Sys-tem for Urban Warfare” and seismic monitoring networks. This has left a gapbetween the developer’s transmission requirements and the ability of the radiostacks and protocols currently in use, forcing protocols designed for infreqentlow-bandwidth transmission to send at high speed. To help alleviate the prob-lem, this project attempts to produce a method of sending large bursts of dataover a wireless network to a number of nodes monitoring the same acoustic space,whilst at the same time leaving capacity for normal low-speed communication.
Contents
1 Introduction 1
2 Related Work 2
3 High Speed Protocol 43.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1 Announcements . . . . . . . . . . . . . . . . . . . . . . . . 73.2.2 Control Messages . . . . . . . . . . . . . . . . . . . . . . . 73.2.3 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 83.2.4 Re-requests . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Platform 114.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 CC2420 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Specification . . . . . . . . . . . . . . . . . . . . . . . . . 11Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.1 TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
AMStandard . . . . . . . . . . . . . . . . . . . . . . . . . 13DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Hardware Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.1 Software Acknowlegements . . . . . . . . . . . . . . . . . 16
Data Rates for Standard TinyOS . . . . . . . . . . . . . . 16Data Rate with Increased Clock Speed . . . . . . . . . . . 17The Relationship between Data Rate and Payload Size . . 18
4.3.2 No Software Acknowlegements . . . . . . . . . . . . . . . 19Data Rates for Standard TinyOS . . . . . . . . . . . . . . 19Data Rate with Increased Clock Speed . . . . . . . . . . . 20The Relationship between Data Rate and Payload Size . . 21
5 High Speed Network Link Experimentation 235.1 Burst Length in Relation to Fragment MTU . . . . . . . . . . . . 235.2 Fragment Rerequests . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Channel Switching . . . . . . . . . . . . . . . . . . . . . . . . . . 25
i
6 Conclusion 27
Bibliography 28
A Proposal: Embedded Networking for High Data Rate Multi-Source Applications 29A.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.3 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.4 The Proposed Project . . . . . . . . . . . . . . . . . . . . . . . . 30
A.4.1 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . 30A.4.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 31
Accurate Measurement . . . . . . . . . . . . . . . . . . . . 31A.4.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.5 Programme of Work . . . . . . . . . . . . . . . . . . . . . . . . . 32A.6 Resources Required . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
B Lab Book 34B.1 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
B.1.1 7 October - Ubuntu TinyOS Install . . . . . . . . . . . . . 34B.1.2 9 October . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
NesC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35The ’Wasabi’ Tools . . . . . . . . . . . . . . . . . . . . . . 35
B.1.3 12 October - Package Conversion . . . . . . . . . . . . . . 35B.1.4 13 October - Fixing Build Errors . . . . . . . . . . . . . . 35B.1.5 16 October . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Superframe Structure . . . . . . . . . . . . . . . . . . . . 35Guaranteed Time Slots (GTS) . . . . . . . . . . . . . . . 36Data Transfer to a Coordinator . . . . . . . . . . . . . . . 36Data Tranfer to a Device . . . . . . . . . . . . . . . . . . 36The Beacon Frame . . . . . . . . . . . . . . . . . . . . . . 37
B.1.6 19 October . . . . . . . . . . . . . . . . . . . . . . . . . . 37B-MAC - CSMA for low powered wireless networks . . . . 37Channel Sampling [CCA] . . . . . . . . . . . . . . . . . . 37
B.1.7 20 October - Meeting . . . . . . . . . . . . . . . . . . . . 37B.1.8 21 October . . . . . . . . . . . . . . . . . . . . . . . . . . 38
JTAG - Write Sequence . . . . . . . . . . . . . . . . . . . 38B.1.9 23 October . . . . . . . . . . . . . . . . . . . . . . . . . . 39
TinyOS - NesC programming . . . . . . . . . . . . . . . . 39B.1.10 27 October - NesC Code . . . . . . . . . . . . . . . . . . . 39B.1.11 21 November - CntToLedsAndRfm & RfmToLeds . . . . . 40B.1.12 25 November . . . . . . . . . . . . . . . . . . . . . . . . . 40
TinyOS Modules . . . . . . . . . . . . . . . . . . . . . . . 40Providing Functionality . . . . . . . . . . . . . . . . . . . 40
B.1.13 25 November . . . . . . . . . . . . . . . . . . . . . . . . . 41Radio Communication - Confirmed Working . . . . . . . . 41
B.1.14 25 November . . . . . . . . . . . . . . . . . . . . . . . . . 41Blue Shell Integration (BLuSH) - Confirmed Working . . 41Radio Power - Confirmed Working . . . . . . . . . . . . . 42
ii
B.1.15 26 Nov26 November . . . . . . . . . . . . . . . . . . . . . 42Imote Speeds . . . . . . . . . . . . . . . . . . . . . . . . . 42Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 42ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.1.16 28 November . . . . . . . . . . . . . . . . . . . . . . . . . 42B.1.17 1 December . . . . . . . . . . . . . . . . . . . . . . . . . . 43B.1.18 2 December . . . . . . . . . . . . . . . . . . . . . . . . . . 43B.1.19 3 December . . . . . . . . . . . . . . . . . . . . . . . . . . 43B.1.20 CC2420 Calculations . . . . . . . . . . . . . . . . . . . . . 43B.1.21 4 December . . . . . . . . . . . . . . . . . . . . . . . . . . 43
More CC2420 Calculations . . . . . . . . . . . . . . . . . 44B.1.22 19 December - Using AMStandard for Broadcasts . . . . 45
B.2 2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45B.2.1 6 January . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Active Messages . . . . . . . . . . . . . . . . . . . . . . . 45Default AM Flow . . . . . . . . . . . . . . . . . . . . . . . 46Internal Call Sequence for Extended Sends . . . . . . . . 49Calling Send . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.2.2 15 January . . . . . . . . . . . . . . . . . . . . . . . . . . 50Recombination . . . . . . . . . . . . . . . . . . . . . . . . 50
B.2.3 17 January - Re-doing Speed Tests . . . . . . . . . . . . . 52B.2.4 21 January . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.2.5 23 January . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.2.6 9 February - HighSpeedNetworkLink . . . . . . . . . . . . 53
iii
Chapter 1
Introduction
As sensor networks get progressively more complex, the data transmission re-quirements change, ususally requiring larger payloads or higher transmissionspeed. The protocol schema described in this document attempts to addressthis issue.
In sensor networks requiring any kind of multilateration, it is often requiredthat motes send data to their neighbours in an effort to coordinate localizationmethods and provide more accurate results. This usually means that broadcastmessages are sent to all motes in range of the transmitter.
While this is fine for most applications as the payloads being sent are fairlysmall and will fit in single packets, but when it comes to multilateration of ana-logue sources, such as audio, it is often advantageous to send the entire signal tothe neighbouring nodes, as this would allow a more accurate comparison thana compressed or discretized representations of the same signal. This proves aproblem, however, as many protocols for reliable multi-packet payload trans-mission are designed for applications which send to only one receiver. Doingthis would mean that the transmitter would have to send data to each of itsneighbours in turn, leading to the motes having to store data for longer periodsof time and taking longer to reach results.
The protocol described here solves this problem by providing semi-reliablebursts of high-speed communication to all receivers in range. In security mon-itoring applications, transmission is not as straightforward as merely sendingdata to the nearest nodes, as while nodes that are physically close may not belogicly co-located, as is the case where nodes are on either side of the samewall. In this case some form of grouping would be required to prevent nodeswhich are unlikely to get the same signal from receiving unnecessary data, aswell as processing time from doing multilateration or comparison operations onsurpurfluous data. This leads to additional requirements for mote grouping, asit is unacceptable for all motes to recieve bursts and then decide if they need todiscard the data or pass it to the application module.
These requirements, (grouping for co-location, semi-reliable broadcast, min-imized contention, backward compatability) are all addressed in this schema.
1
Chapter 2
Related Work
Many protocols fail to take advantage of the number of channels available to thehardware in newer motes, but even recently described protocols which make useof the additional bandwidth by using ”channel hopping” techniques such as inY-MAC[10], or “Le’s multi-channel protocol”[6], are only really geared towardslower bandwidth infrequent packet flow.
Le[6] attempts to free bandwidth by moving motes to other channels whenthe ’home frequency’ becomes too congested to send data at the required ratein an effort to spread the load across all available channels. Each node in thenetwork calculates the probability of communication and switches if the successprobability is low. To maintain links with other nodes, a mote may bring severalothers with it when it performs a switch. While this is acceptable for mediumto low throughput networks, if a mote were to occupy a frequency completelyduring a burst, it would force the other motes to attempt a channel switch, andwould therefore interfere with the burst, increasing its duration, or at worst,cause it to fail entirely. Ignoring the effect on the burst from attempting toswitch several motes to another channel, there is the possibility that motes wouldmiss the switch messages due to the burst messages contending with them, andconnectivity would suffer accordingly. Additionally, this short, high-throughputburst would cause the probability calculations to vary wildly. However, usingthis method it has been shown to increase throughput by up to 50
Y-MAC [10] appears to attempt to create an environment where every trans-mission is shifted to another channel, such that contention is minimised. Fixed-length frames are used to divide time into unicast and broadcast periods, whereeach mote has a receive period in the unicast section. Initially, the motes are allon a ’base channe’ into which requests to send data are posted, causing the re-cipient to start to switch channels along its ’hopping sequence’ allowing messagecomponents to move across the full range of channels. This allows for motesto contend in one channel, only to move away allowing transmission to resume.Unfortunately, if this were to be used for high speed communication, it could notacheive the same throughput as with motes on one channel for the entire burst,as some component of time transmitting is spent moving to another channel.
McMAC [5] is described as a “parallel rendez-vous protocol” as each nodeuses its MAC address to generate a pseudo-random hopping pattern throughthe available channels, and any other mote wanting to transmit to any othermust generate this same sequence of channel hops, and “follow” the receiver
2
as it switches. This is done for much the same reasons as Y-MAC - to reducethe possibility of contented packets in an effort to increase overall throughput.But, also in a manner similar to Y-MAC, because McMAC motes spend a non-insignifigant amount of time channel switching while transmitting data, it wouldsuffer from the same issue - a lowered upper bound for throughput.
Acousitc multilateration applications where digital signatures of sounds needto be transferred to surrounding nodes for comparison require a higher through-put that these protocols can deliver, especially in large networks where severalgrouops of motes may need to communicate high-rate data at once. An exampleof this is the Self-Calibrating Distributed Acoustic Sensing Platform [8], whereseveral sound sources are used in concert to produce a vague direction and signaldescription, which are both sent to neighbours to perform comparisons prior tothe multilateration stage. The network described uses all nodes within radiorange are required to help locate the sound source with any accuracy, as thenumber of nodes used is directly proportional to the accuracy available.
But even the speed of communication here pales in comparison to the re-quired data rate for the “Countersniper System for Urban Warfare”[11] whereeach node timestamps a sound that may be a gunshot n-sound, and transmitsboth the timestamp and the sound data to its neighbours for distributed multi-lateration calculations. Considering the speed of sound, whole swathes of motesin approximately the same area may require high speed communication almostat the same instant, causing a great deal of contention in a very short time.
The protocol devised for this report attempts to solve situations such as theone described here by using the additional channels available on newer motesas a method of communicating in a parallel fasion with very high throughput.
3
Chapter 3
High Speed Protocol
3.1 Overview
In a manner similar to “Le’s protocol” [6], the protocol proposed here uses theadditional channels to prevent contention with other messages in the network,but instead of monitoring the channel and determining if switching is required,motes simply switch to the next available channel and transmit. This meansthat the channel is guaranteed to be free allowing the transmitter to utilisethe channel almost entirely for data, giving throughputs higher than normalnetwork traffic.
Additionally the motes are required to monitor all channel change announce-ments, as to maintain a table of channel states.
3.2 Detail
Normally in TinyOS, application modules would be required to manage theirown radio communications, or to use an existing MAC implementation to controlhow packets are handled before being transmitted or after reception. Assumingthat no MAC layer is required for a sensor mote, and the application is handlingall the small, single packet messages itself, the application wiring would be asshown in Figure: 3.2.0.1.
4
Figure 3.2.0.1: Normal Wireless Network Wiring
However, to maintain control over how messages are handled for high-speedbursts, the HighSpeedNetworkLink module is attached on an additional pair of’types’ (aka. ports) and the BulkSend interface used to send bursts (See Figure:3.2.0.2).
Figure 3.2.0.2: High Speed Network Module Wiring
The HighSpeedNetworkLink module marshals the sequence of events shownin Figure: 3.2.0.3, and describes in general terms the actions taken for bursttransmision from a source (transmitter) to a group of two sinks (receivers).
5
Figure 3.2.0.3: Basic Sequence Diagram for the Protocol
The complete sequence is as follows;
1. Initially, all motes reside on the announce channel (in this implementation,this is channel 11, but could be any channel)
2. The source transmits its intent to send a burst as a Channel Switch An-nouncement as a broadcast to all motes in range containing the channelit will use for the burst and the number of fragments required, then im-mediately switches to said channel.
3. The source then waits a predetermined amount of time (based on thespeed of the radios being used, this may vary as enough time to receive,process and switch channel is required for all the receivers)
4. The sinks receive the Channel Switch Announce and immediately switchto the channel specified in the broadcast and wait for data.
5. The source then sends the complete set of fragments sequentially as ahigh-speed burst.
6. The sinks receive the fragments and attempt reconstruct the message,recording which fragments have been received in a byte vector.
6
7. Once the source has sent the complete data, it waits for a second predeter-mined time (dependant on the loss experienced in the network) and waitsfor retransmission requests.
8. If at this stage, a sink has completed the packet, it returns to the announcechannel. Otherwise, it unicasts a rebroadcast message after a randomdelay, causing the source to resend the fragment specified.
9. if any sync receives any fragment in the redelivery stage, it attempts toadd it to the message, allowing motes which have yet to request a missingfragment use the fragment from another rerequest.
10. Eventually the source will either run out of rerequest attempts (255, asthe highest number of fragments is 255, any more than this is worse thana whole new attempt as a burst) or time out waiting for any more requeststo be made, and will drop back to the announce channel and broadcast achannel free announcement.
Additionally, if a channel is seen to be in use for longer than is possible, (afterat least enough time to send a complete burst twice) then the motes should resetthe usage flag for that channel, so that missed channel free announcements donot mean that channels are never freed.
As an aside, a synchronisation stage would be useful here as a provision toallow motes joining the network late or any that miss packets frequently to beupdated. A protocol such as B-MAC could be used to route synchronisationpackets to keep the network up to date. However, this is outside the scope ofthe work here.
3.2.1 Announcements
Announcements are only sent while in the announce channel, and contain datafor a whole group.
An announcement of type CHANNEL SWITCH CMD Signifies a mote wishesto switch a group to a channel, contains the channel offset, group identifier, andnumber of fragments to expect. All motes should receive this message as theyuse the channel offset to maintain their channel allocation bitvector.
An announcement of type CHANNEL FREE CMD Signifies that a grouphas finished with a channel, and other motes can clear its usage bit in thechannel allocation bit vector.
3.2.2 Control Messages
Control messages are used when in a burst stage, and are used to request ad-ditional data from the fragment source if required. They simply contain afragment identifier for the fragment source to rebroadcast to the group.
3.2.3 Bursts
Bursts are used to transmit the extended payload data over the wireless linkas fast as possible. They consist of a postable task in TinyOS which containsall the management code for generating and sending a fragment. This task is
7
‘posted’ (put on the scheduler’s queue) every time the radio signals a completedtransmission, thus keeps the radio at near-peak usage until the complete burstis sent.
Fragmentation
Fragments are generated by splitting the payload data into discrete chunks ofsize FRAGMENT MTU, where FRAGMENT MTU is the TOSH AM DATALEN-1 (as defined in AM.h for your platform, in this case the IMote2).
In this implementation, 100 bytes of payload data were used for each radiomessage, allowing for a FRAGMENT MTU of 99 bytes.
3.2.4 Re-requests
Occasionally a mote may require a fragment to be sent again after the sendphase to complete an extended payload. This may be due to environmentalissues (radio inteferrance) or mote-specific issues (mote was busy during a send).While the mote-specific issues cannot be easily turned into an advantage, theenvironmental issues usually affect a group of motes, rather than just a singledevice. This means that when re-transmitting data fragments, in a traditionalscheme, the data would have to be send ’n’ times, (where ’n’ is the number ofmotes requiring the data). This is unacceptable in a high-speed network, as itplaces a huge load on the transmitter, and wastes radio messages almost everytime a mote requires a re-transmision.
In the protocol described here, any fragments requiring a re-transmission toany mote are send using broadcast messages, this allows other motes to capturethe fragment re-transmissions and use the data themselves.
Figure 3.2.4.1: Stage 1; Two motes missing a fragment, shown in red, transmit-ter is yellow.
This allows motes that would otherwise have to request all of their missedfragments to ‘leech’ re-transmissions from other motes in the group, drastically
8
cutting down the number of packets sent in the re-transmission phase. Thediagram in Figure 3.2.4.1 shows a 4 mote group immediately after a send phase,and two of the receivers (marked in red) are missing fragment #5 in a sequenceof 6.
Figure 3.2.4.2: Stage 2; Two motes still missing a fragment, with one unicastinga request for fragment #5
Figure 3.2.4.2 shows one of the motes requesting fragment #5 from thetransmitter. The acual mote that transmits the request is irrelevant and non-deterministicly selected. The transmitter then re-broadcasts fragment #5 (as isshown in Figure 3.2.4.3) allowing both motes with missing fragments to capturethe data and finish their extended payloads.
Figure 3.2.4.3: Stage 3; Fragment #5 rebroadcast to all motes in the group
In normal operation, the mote that had already completed its data would
9
have moved back to the announce channel as soon as it had captured the lastfragment.
The number of re-requests is capped at 255 to prevent motes with highpacket loss from continually re-requesting data from the transmitter causing itto occupy the channel indefinitely. Likewise, motes which have not received areply to their requests after a predefined time (Compiled in, application specific)should simply return to the announce channel to prevent data corruption aschannels are re-used.
3.3 Limitations
The number of channels available to the hardware limits the number of concur-rent burst transmissions. If a mote misses the initial channel switch message,it will miss the entire extended payload, and additionally will not mark thechannel as used, so if the mote sends data before the rest of the group returnsto the announce channel, there is the potential for the unsynchronized mote toattempt to use the already used channel. This may cause the entire packet tobe corrupt.
However, the application module should implement some form of checksumfor the extended payloads to counter this, but this itself would mean that theentire packet would be wasted if the checksums did not match.
10
Chapter 4
Platform
4.1 Hardware
Intel IMote2[2] sensor motes were supplied for the implementation section of thisproject, although any mote running TinyOS and using the CC2420[4] radio chipor similar could be used for this method of high-speed data transfer. The moteswere programmed using a JTAG daughter board attached to the high-speed sideof the IMote2 and were controlled by OpenOCD[12] for both programming anddebugging purposes, which was in turn controlled by JFlash[13] to help auto-mate the build/write process . This allowed GDB[1] to be used for debugging,including runtime breakpoints on the IMote2.
4.1.1 CC2420
Specification
The CC2420 radio chips on the iMote2 have the following specification (Takendirectly from the CC2420 datasheet - page 7. Only the most relevant items areshown)
• 2400 - 2483.5 Mhz RF Transceiver
– 250kbps data rate, 2MChip/s chip rate.– High Sensativity (-94 dBm)– Programmable output power
• Seperate transmit and receive FIFOs
– 128 byte transmit data FIFO– 128 byte receove data FIFO
• 802.15.4 MAC hardware support
– Automatic preamble generator– Synchronisation word insersion/detection– CRC-16 computation and checking over the MAC payload– Clear Channel Assessment (CCA)– Full automatic MAC security (CTR, CBC-MAC, CCM)
11
Max theoretical speed: 31.25kBps = 32,000BpsPacket size: 110BPackets/second: ~290.91 packets/secData throughput: ~29,091Bps = 28.41kBps
Limitations
Because the CC2420 chips only have 128 byte buffers for both incoming andoutgoing packets it provides a hard limit on the amount of data that can betransmitted as a single packet. Theoretically, this maximum is 118 bytes, asTinyOS requires a 10 byte header, however, the internals of the CC2420 preventthis entire buffer from being used. When the buffer is completely filled, the chipfires a buffer overflow interrupt signal to the (XScale) processor (on the iMote2,a Pxa270[9]), this has the effect of locking TinyOS into a live loop, as it would bewaiting for a sendDone signal which never fires. As a consequence of this, andthrough experimentation, I determined that a payload data length of 100 bytesgave enough speed, whilst not causing livelock. Any more than 100 bytes seemedto cause problems for the radio, as packets were missed or dropped. Ignoring anyother factors, however, there is a hard limit on the number of bytes that can besent in a second; 31.25kBps ( 250kbps
8 , see CC2420 spec ). This in turn is limitedby the enforced headers, bringing the total useful throughput to 28.41kBps.
4.2 Software
The implementation of this protocol was developed on Ubuntu Linuxs using theTinyOS toolchain and the Intel compiler binaries for linux. OpenOCD was usedto manage a parallel port JTAG programmer which in turn communicated withthe IMote2s via the Crossbow JTAG programming daughter board.
However, the version of OpenOCD available at the time had major glitchessuch that a seperate program - JFlash, was written to manage OpenOCD, andadditionally automate the write process and simplify some of the more com-monly used commands for OpenOCD.
4.2.1 TinyOS
TinyOS is an operating framework designed for use in wireless sensor networks,originally for the Mica and Mica2 sensor motes, but has been expanded to sup-port several platforms, including the iMote2. The NesC compiler[7] is employedto build code for TinyOS, and is essentially a very complex precompiler, tak-ing ’wirings’ (See Figure: 4.2.1.1 for an example of a ‘wiring configuration’ andFigure: 4.2.1.1 for a diagramatic representation of the same wiring) from con-figuration files, and converting them into more standard C code, which is thenrun through the normal pxa27x[9] toolchain, as supplied by Intel.
12
configuration LEDTest {}implementation {
components Main,LedsC,SingleTimer,GenericComm as Comm,LEDTestM;
Main.StdControl -> LEDTestM.StdControl;Main.StdControl -> SingleTimer.StdControl;LEDTestM.Leds -> LedsC;LEDTestM.Timer -> SingleTimer.Timer;
Main.StdControl -> Comm.Control;LEDTestM.SendMsg -> Comm.SendMsg[0];LEDTestM.ReceiveMsg -> Comm.ReceiveMsg[0];
}
Figure 4.2.1.1: An example of TinyOS/NesC Wirings
Figure 4.2.1.2: A graphical representation of TinyOS/NesC wirings for the con-figuration in Figure: 4.2.1.1
AMStandard
The AMStandard modules in TinyOS are used for all serial communication onthe IMote2, including both the serial ports and the radio, and provide a com-mon interface for all routes of communication. Normally, these would haveone destination as is the case with radio packets and would have associatedacknowlegement messages send back as the data passes through the Unique-Send/UniqueReceive modules, although broadcast messages are possible by us-ing the full address schema (0xXXXX) and addressing packets to 0xFFFF (asper the CC2420 data sheet), and ACK messages are not generated nor expectedin this configuration ( TinyOS - CC2420 Description [3] ).
13
Figure 4.2.1.3: The TinyOS Network Stack
The GenericComm interface (to which most modules wire) overlays AM-Standard to transmit data around the system (See Figure 4.2.1.3).
Even with the 100 byte payloads and broadcast ability of the CC2420 andTinyOS, the issue of managing speed exists, hence it is far more desirable tohave the AM stack accept message payloads of larger than one fragment MTUin size and fragment the data into transmittable chunks.
This does mean that some method of packet fragmentation managementwould have to be implemented on both sides of the wireless link, as withoutthis mechanism in place, motes would not be able to reconstruct the originalmessage accurately, if at all.
This itself is problematic, simply determining if a packet is a fragment or anormal message which happens to follow the same format as a fragment is a largeissue, without even considering fragment recombination. One solution would beto simply reserve the first few bytes in any payload data for additional headerdata (See ”2009, 6th Jan - Active Messages”, Appendix B). While simple toimplement, this method would reduce the standard packet payload size, whichcould have a knock-on effect throughout any modules using the CC2420 standardpackets (AMStandard format TOS Msg). This includes the current B-MAClayer and any other modules that would use the radio.
Thankfully, the AMStandard system has an additional ‘type’ field, whichcan be regarded more like ‘ports’ on a normal socket-based network, where the‘type’ determined which GenericComm.receive function gets passed the message.This meant that the fragments could be easily determined from normal packets,and additionally, control messages could be split from the fragments duringhigh-speed transfer.
DMA
As an alternative to using the AM Layer to manage the radio data, the DMAcontroller could be used to copy any incoming data into the processor’s memory,then notify the processor of the new data via interrupts. This would completelycircumvent the AM system, and instead have to be managed by direct memorycalls. While faster for memory access, the packets would have to be immediatelydealt with on an interrupt, which may cause the network to drop packets whenthe CPU load is high. Using DMA is not advised by the TinyOS communityfor a variety of reasons, refer to the TinyOS website for details .
14
Limitations
TinyOS is an event base operating system for motes, which unforunately leads tosome odd programming techniques, as quite often, certain calls are impossiblefrom within events that one would normally call them from. In particular,inside a radio ’sendDone’ function, you cannot call radio functions directly, asthe program waits for the radio system to become free to run the call, but theradio system is waiting for the function to complete inside its signal callback.This means that for most of the protocol implementation the logic must becontained within posted ’tasks’.
Tasks are handled seperately from other code and are run when the schedulercalls them, thus by calling the radio transmit functions inside a posted taskone can avoid the livelock situation described above. However, because of thesimplicity of the TinyOS scheduler, tasks can have no parameters and no returns,so for complex behavior, such as what is described here, the state data for thesystem has to be contained in module-scope variables, quickly leading to aproportionally large memory footprint for the module as persistant variablesare used to control program flow.
Additionally, the version of TinyOS used for this project was 1.x as TinyOS2.x was not available for the IMote2 sensor mote. If this project was repeated,it may have to be significantly changed for it to perform on the TinyOS 2.xplatform.
4.3 Hardware Profiling
This section details the tests that were applied to the IMote2 network to deter-mine the current state of TinyOS communications via the CC24020 radio. Allthe speeds in this section are the data rate for payload data only, as the headersare outside the control of modules and effectively are wasted data.
In the experiments, the IMote2s were placed such that environmental effectswhich would normally affect the data rate were negligible, and every possibleeffort to ensure that no external factors affected the radio reception. This in-cluded (but was not limited to) increasing the radio output power to its highestlevel, and keeping the IMote2s within approximately 12 inches of each other. Inconfigurations involving more than two IMote2s, the motes were positioned ina grid, as detailed in each experiment.
15
Figure 4.3.0.4: 10 Mote position configurations
The exact positioning of the motes proved to have little or no effect on thethroughput, as demonstrated in Figure 4.3.0.4, in which each line represents therolling 10-point average throughput, but in each case the motes were placed indifferent positions, ranging from on top of each other to approximately a footapart.
4.3.1 Software Acknowlegements
The following tests use TinyOS’s built-in software acknowlegements. This is thedefault behavior for TinyOS, and has been implemented such that it sits be-tween the hardware (in this case the CC2420 radio chip) and the GenericCommmodule, allowing it to intercept and manage the packets flowing to and from theradio. This adds a considerable overhead to both transmission and reception, asthe medium has to cope with double the number of packets transmit becuase ofthe ACK mechanism. These tests are here purely for comparison and to showa baseline from which the protocol described here attempts to improve upon.
Data Rates for Standard TinyOS
This setup consisted of two motes, one transmitting as fast as possible, and theother logging the number of bytes of payload data received each second andoutputting them to the BLuSH terminal (See Figure 4.3.1.2 ). Originally, thistest was performed by using a timer set to one byte-millisecond (1024ms/sec)to try and force the radio to send data, skipping that byte-millisecond if theradio was in use. This caused the transmitting IMote2 to occasionally crash asa radio operation was attempted when the radio was still sending the previouspacket. These results were easily spotted as they had an large drop in speed forthat second, as marked in red on Figure 4.3.1.1. Therefore, these speeds, whilepossible, are impractical for normal usage, as having a mote crash in the fieldduring a normal send operation is unacceptable.
16
Figure 4.3.1.1: Original 28 Byte Throughput Test, with crash areas marked
Figure 4.3.1.2: 28 Byte Throughput Test
Data Rate with Increased Clock Speed
The following graph shows the result of increasing both the clock and bus speedon the IMote2. By increasing the clock speed we remove some of the delaysinside TinyOS by simply allowing the mote to process them more quickly, whilethe bus speed increase removes the delay in getting the data to and from theradio. This increases the data rate by a small amount (approximately 600B/secincrease). Because of this increase for almost no work, all further tests will berun with an increased clock and bus speed.
17
Figure 4.3.1.3: 28 Byte Clock Speed Comparison
These throughput rates are nowhere near the theoretical maximum for theCC2420 as calculated previously (See section 4.1.1 - “Specification”).
The Relationship between Data Rate and Payload Size
Using the same approach to recording data as described in the previous two tests,but for successively larger payload sizes, the following trend can be observed -see Figure 4.3.1.4.
Figure 4.3.1.4: Payload Size vs. Throughput
The vertical bars seen in Figure 4.3.1.4 show the upper and lower bounds ofeach speed reading for the a given payload size.
It is noteworthy at this tage to mention that due to the CC2420 radio chiponly having 128B for both its transmit and receive FIFO queues, message sizeslarger than 128B
2 , (64B) cannot be buffered in hardware, so packet loss proba-bility may increase as the radio discards the valid packet due to overflow errors.
18
4.3.2 No Software Acknowlegements
The following tests are identical to the tests above, but instead of using theTinyOS default ACK messages, these use no ACK mechanism whatsoever, halv-ing the number of messages flowing through the radio medium. These tests wereperformed immediately after the with-ACK set mentioned previously, as to re-move the possibility that environmental effects would change the results.
Data Rates for Standard TinyOS
The following results were otained by using the same test code as “SoftwareAcknowlegements - Data Rates for Standard TinyOS”, but instead of using aunicast transmission scheme, the packets were sent to the broadcast address,causing no ACK messages to be sent.
Figure 4.3.2.1: Broadcast throughput using unmodified TinyOS
When overlaid with the throughput data from the unicast test, very littlechange can be observed. While this was not exactly what was expected, it hasno real detrimental effect on the protocol, as the broadcast messages are sentto all motes in range, so the actual throughput can be measured as a functionof the number of motes in the group.
19
Figure 4.3.2.2: A comparison of unicast and broadcast throughput - unicastrates are shown in dotted red
Data Rate with Increased Clock Speed
In this section, the same tests were performed as in “Software Acknowlegements- Data Rate with Increased Clock Speed”, except the transmitter send data usingthe broadcast mechanism.
Figure 4.3.2.3 shows the throughput attained by this method;
Figure 4.3.2.3: Broadcast throughput using an increased bus and clock speed
Figure 4.3.2.4 shows the same data plot against the unicast data acquiredfor normal clocks speeds in previous tests.
20
Figure 4.3.2.4: Broadcast throughput with increased bus and clock speed againstequivalent unicast data
Additionally, the normal clock speed data was plot against the new high-speed data (See Figure 4.3.2.5), this shows an increase of 600B/sec, exactly thesame increase as seen in the equivalent unicast tests.
Figure 4.3.2.5: Broadcast throughput with increased bus and clock speed againstequivalent unicast data
The Relationship between Data Rate and Payload Size
Using the same method as described in “Software Acknowlegements - The Re-lationship between Data Rate and Payload Size” the follwing graphs were pro-duced. The only difference in these readings was the method of transmission,
21
where in this case broadcast messages were sent. Very little difference can beobserved between these throughput rates and the unicast data recorded previ-ously
Figure 4.3.2.6: Broadcast throughput vs Payload Size
Figure 4.3.2.7: Broadcast throughput and unicast throughput comparison
22
Chapter 5
High Speed Network LinkExperimentation
Once an accurate representation of the capabilities of the CC2420 radio had beenbuilt up, tests were performed using the protocol descibed in this document todetermine how the radio would act.
5.1 Burst Length in Relation to Fragment MTU
In these tests, the time taken to transmit a complete 512B burst was recordedfor at least 300 bursts. The results show a vaguely asymptotic trend towards40 byte-milliseconds. The measurements for time are taken in byte-milliseconds(1024Bms in 1 second) as the internal timer of the IMote2 works in these units.
Figure 5.1.0.1: Transmission time for bursts with differing fragment maximumtransmission units
It can be speculated that payload sizes greater than 99B (The maximum fora 100B packet length upper bound) would have a progressively smaller reductionin transmission time, as the curve tends towards the 40Bms mark.
23
5.2 Fragment Rerequests
Because the protocol uses broadcast messages for both the initial transmissionburst and the re-requested fragment transmissions and receivers attempt to useall incoming fragments at all times, it allows all receiver motes in the channelto receive the re-broadcast fragment, cutting down on multiple transmissionsof the same fragment. This behavior is especially useful in environments wheremotes are prone to losing signal completely for segments of time, (as would bethe case in areas of high electrical noise) as all motes would require packets inthe lost duration.
This allows the protocol to scale very well, as the number of requests is nolonger a function of the number of motes in the network, as would be the casefor a unicast-based protocol.
Figure 5.2.0.2: Point source interference on a mote group
Therefore in a situation such as in Figure 5.2.0.2 where a source of noise hasaffected two motes, only one set of requests for the fragments lost is requiredfor both to acquire the entire message.
The throughput for the entire group is fairly hard to calculate with ran-dom packet dropouts, however, in ideal conditions, the following applies (Figure5.2.0.3) to produce the graph shown in Figure 5.2.0.4.
24
Throughput =NumberOfReceivingMotes×BurstLength
T imeTakenForBurst
Where BurstLength = DataLength× DataLengthFragmentM TU
Figure 5.2.0.3: Calculating throughput in ideal conditions
Figure 5.2.0.4: Throughput vs Number Of Motes (Ideal)
In non-ideal conditions the motes would have an upper bound along theline of Figure 5.2.0.4, as the re-transmission requests and additional broadcastswould lower the overall data rate by inreasing the transit time for the data.
5.3 Channel Switching
To demonstrate that the CC2420 radio was changing channel, the followingtest was devised; two motes are running, one on channel 11 (offset 0) and oneon channel 12 (offset 1) both monitoring the channel. A third mote then hopsbetween the two channels transmitting a packet on each. If the mote is changingchannel, the first mote should see all the odd packets, and the second shouldsee all the even packets.
25
Figure 5.3.0.5: Motes on channels 11 and 12, showing packet count
The graph in Figure 5.3.0.5 shows that the motes are receiving packets al-ternately, demonstrating that the channel switching is working correctly.
26
Chapter 6
Conclusion
Overall the project was successful fulfiling its objectives as set out in the openingchapter of this document;
1. “Grouping for co-location” - The protocol has provision for grouping motesinto logical areas, fulfilling this specification parameter.
2. “Semi-reliable broadcast” - Via the re-request mechanism broadcast mes-sages are almost always received at the destination motes, with only ex-treme cases of noise or signal loss forcing the burst to fail. This could beeasily remidied by the controlling application module by merely rebroad-casting the data, or using a multi-hop routing layer above the single-hoplayer described here.
3. “Minimized contention” - By channel switching to a presumed-to-be-freechannel just before high speed transmission, the motes have the bestchance of receiving no contention, in addition to leaving the announce-ment channel which may be used for additional messages in the network.
4. “Backward compatability” - Because the HighSpeedNetworkLink moduleonly affects two radio ports, as long as existing application modules dontuse all of the available 255 ports for communication the high speed modulecan be merely bolted on between the application module and the radioand will be unaffected.
Over and above these goals, however, was the throughput acheived by usingthis protocol; an approximate peak throughput of 13kB/sec. A value more thanenough for a wide variety of sensor applications with large payload requirements.
Unfortunately, given the timescale of this project, performing any kind ofmulti-hop experimentation was impossible, however, with additional time theprotocol could have a routing layer bolted on fairly easily allowing further datato be acquired for messages requiring multiple burst-speed transmission to reachtheir destination group. Additionally, the HighSpeedNetworkLink module cre-ated to test the protocol is not production ready, and would require additionalwork to be useable by the TinyOS community. However, as a proof of concept,the protocol implementation as it stands befits its purpose.
27
Bibliography
[1] Gdb, the gnu project debugger. http://www.gnu.org/software/gdb/.
[2] Intel imote2 sensor mote. http://www.xbow.com/Products/productdetails.aspx?sid=253.
[3] Tinyos. http://www.tinyos.net/.
[4] Cc2420 - 2.4ghz ieee 802.15.4 / zigbee-ready rf transceiver. 2008.
[5] A parallel redezvous multi-channel mac protocol. IPSN ‘08: Proceedingsof the 7th International Conference on Information Processing in SensorNetworks, 2008. IEEE Computer Society, Washington, DC, USA.
[6] A practical multi-channel media access control protocol for wireless sensornetworks. IPSN ‘08: Proceedings of the 7th International Conference onInformation Processing in Sensor Networks, 2008. IEEE Computer Society,Washington, DC, USA.
[7] David Gay, David Culler, and Phillip Levis. nesC Language ReferenceManual, 2008.
[8] Lewis Girod, Martin Lukac, Vlad Trifa, and Deborah Estrin. The designand implementation of a self-calibrating distributed acoustic sensing plat-form.
[9] Intel. Intel PXA27x Processor Family. Developers Manual.
[10] H. Kim, Y. Shin and H. Cha. Y-mac: An energy-efficient multi-channelmac protocol for dense wireless sensor networks. IPSN ‘08: Proceedingsof the 7th International Conference on Information Processing in SensorNetworks, 2008. IEEE Computer Society, Washington, DC, USA.
[11] Akos Ledeczi, Andras Nadas, Peter Volgyesi, Gyorgy Balogh, BranislavKusy, Janos Sallai, Gabor Pap, Sebastyen Dora, Karoly Molnar, MiklosMaroti, and Gyula Simon. Countersniper system for urban warfare. ACMTransactions on Sensor Networks, Vol. 1, No. 2, 2005.
[12] Dominic Rath. Openocd - open on-chip debugger. http://openocd.berlios.de/web/, 2008. Free and Open On-Chip Debugging, In-SystemProgramming and Boundary-Scan Testing.
[13] John Vidler. Jflash, a java tool to control and automate openocd. http://www.themoggie.co.uk/code/TinyOS/jflash, 2008.
28
Appendix A
Proposal: EmbeddedNetworking for High DataRate Multi-SourceApplications
A.1 Abstract
There is currently a lack of research into the capabilities and performance of boththe IEEE 802.15.4 specification and the Intel iMote platform for large payloadsand streaming applications.[5] To help reduce this gap in current understandingthis project is designed to acquire concrete, quantifiable measurements for point-to-point communication. The current protocols for networking on embeddeddevices focus on power consumption and attempt to leave the network hardwareoff for most of the time, giving them longer battery life at the expense of networkspeed. The aim of the project would be to establish a protocol for high speednetworking in star topology networks designed for small-scale sensor networkswith a more theoretical look at other topologies. Focus is on a multiple audiostream input to a PC from several embedded devices using a network protocolbased around the IEEE 802.15.4 low-level protocol.[5]
A.2 Introduction
With the advent of low cost, low power consumption small embedded platforms,interest has been growing in both the research community and in industry inlarge wireless sensor networks [1], usually with low bandwidth requirements andlong battery life. This has led to a number of network protocols designed togive developers a low-power consumption, but highly reliable data transfer be-tween motes and (usually) more powerful computers which do the heavyweightdata processing. This is a perfect solution for infrequent data reading on largenetworks, (such as weather monitoring, i.e. pressure, temperature, wind speed,etc.) but applications with high bandwidth requirements using these same pro-
29
tocols soon suffer from poor performance[2]. Thus, the aim of this project isto address this network protocol shortfall by re-examining the manner in whichdata is transmitted in a sensor network to allow for more bandwidth for high-rate sensing applications. The rest of this proposal contains some backgroundon the problem and attempts to rectify it, the project proposal itself, containingthe aims and objectives for the project, and the methodology to be used duringthe project. A program of work is also supplied, detailing the expected durationfor each of the tasks in this project, along with a list of resources required tocomplete it. Any research material used to formulate this proposal are listed atthe end of this document.
A.3 Background
In most designs for embedded sensor networks, the IEEE 802.15.4 Medium Ac-cess Control (MAC) protocol is also used, which, in turn is usually used withthe ZigBee high-level protocol to provide Low-Rate Wireless Personal Area Net-works (LR-WPAN’s)[3]. This, while good for infrequent sensor readings in nonreal time applications does not allow for large payloads in its protocol, or, forthat matter, even define a ’large payload’ or how to handle them[3]. At theother end of the scale, is the IEEE 802.11 standard for wireless communica-tion, employed frequently in laptop computers and other similar specificationmobile devices (PDAs, Ultra-Portable machines, etc.) which can deal withspeeds of up to (and including) 54Mbit/s, which would, of course, be more thanenough to send substantial amounts of sensor data, but the transceivers arehigh-drain, CPU-intensive components, making them unsuitable for small, lowpower, embedded devices[2]. The uses for high speed embedded wireless arebecoming increasingly clear, as designers and developers find new uses for smalldisposable networked devices. Notable situations in which high speed transfer isdesirable could be in emergency and rescue operations, where fast deploymentof a network to relay information or video feeds around a scene is required.Alternatively as an example of a less critical systems application, multi-sourceaudio recording for video conferencing, with devices placed around the roomsgiving full audio coverage, and (assuming that the devices know their relativelocations) possibly spacial audio transmission, with the room being recreatedaudibly at the other conference location[1].
A.4 The Proposed Project
A.4.1 Aims and Objectives
The project will examine methods for achieving high speed data transfer onexisting IEEE 802.15.4 compatible hardware using Intel iMote devices as thehigh-speed data acquisition platform. The star network topology will be usedfor all of the design, implementation and testing phases, but grid and meshnetworks will be briefly touched upon in theory only as these are beyond thescope of this project. By using the star network topology, the focus of the projectwill be on the second example described in section 3, the multiple-source audiocapture example, as audio input can have almost any sample speed, giving greatflexibility for testing. However, location detection (adjacency calculations and
30
triangulation) will be omitted, as they are beyond the scope of this project. TheCSMA and CSMACA methods will be examined and evaluated for their merits in this applicationand the IEEE 802.15.4[5] standard will be used for low-level control of the radiomodules.
In conclusion; the following list concisely describes the aims of the project:
• Assess the capability of the Intel iMote platform to sample at high rateswhile managing the network stack.
• Assess the ability of the IEEE 802.15.4 standard to take large-payloads athigh speeds in one to one networks.
• Examine the networking methods available to retrieve multiple, high-speeddata sources simultaneously.
• Develop an API (if only a basic one) for high-speed communication forembedded devices to aid further development in this area.
A.4.2 Methodology
Following the same testing method as described in The networking methodswill be tested by sending a fixed amount of sample data through the networkand the transfer rate calculated based on the transfer time. Large numbers ofpackets should be sent as to adequately minimise any erroneous results, andmake any problems very apparent. The same sample data will be used on eachnetwork method, as to ensure that the results are comparable, and the sameiMotes will be used in the network for each test. The networks themselves willbe constructed in such a manner that any environmental effects are negated.This will be done by ensuring that the iMotes are always well within theirdocumented radio range of each other, and that each iMote can detect everyother iMote (overlapping radio fields) as to not corrupt the data acquired.
Accurate Measurement
To ensure that results attained from experiments in this project are represen-tative of the actual characteristics of the iMote and network, the same experi-mental methods will be used as described in section 4 - Experimental Setup - ofAnalysis of Audio Streaming Capability of Zigbee Networks [3]. For each con-figuration, 10 000 packets will be sent across the network link, although, as thenature of the data is such that a lossy packet scheme is preferable (as old packetsquickly become irrelevant due to the real-time nature of the application), so thenumber of packets successfully received will likely be less than the number ofpackets transmitted. Because of this, the number of packets transmitted andreceived will be counted separately to accurately measure packet loss. In addi-tion to the number of packets, the time the data takes to get from one iMote toanother will be monitored by time stamping the user data in packets generatedfrom a PC, sending to the same PC via a second iMote. This should give anaccurate representation of the time taken to transmit packets as it eliminatesand packet loss issues with bouncing packets back to the receiver. Packet injec-tion experimentation will also be carried out along with deliberate corruption of
31
data by external iMote nodes in an attempt to fully test retransmission methodsand strategies.
A.4.3 Scope
This project’s scope does not include issues with radio propagation, and ignoresany adverse effects by ensuring that all iMotes are well within radio range ofeach other. Mesh networks are also excluded from this project, as measure-ment of packet loss, corruption and propagation delay are meaningless withoutthe accurate characteristics of the individual links being known. Point to pointcommunication is the focus of the project, and will include both UDP-like mes-sages (no guarantee of delivery) and TCP-like messages (retransmission of failedpackets, sliding window) for audio data and iMote control respectively.
A.5 Programme of Work
The required elements of this project can be broken down as follows:
1. Toolchain Setup - Gather required resources to get code compiling andrunning on the motes’
2. Examine the supplied hardware in detail, especially the data acquisitionand network components.
3. Investigate current strategies for high speed networking on embedded plat-forms in more detail, and determine which approach to pursue.
4. Design and implement basic data acquisition using the audio input on themotes and see what data input rate can be achieved. Use a direct link toa PC for analysis at this stage (no networking).
5. Assess weather TinyOS or another similar operating system is required, orif a simple monotasking application is sufficient, and if an OS is required,implement a toolchain to install it on the motes.
6. Design and implement a basic single mote network link to a PC to get abase-line measurement for how much data a single network channel canactually run at.
7. Design and implement a multi-mote network based on section 6 to acquiremore than one data stream simultaneously and experiment with protocolsto achieve the highest data rate.
8. Design and implement a network API for subsequent developers to use forhigh-speed networking.
9. Finish Report
32
A.6 Resources Required
• At least 3 Intel iMote micro controllers, preferably more for the later stagesin testing.
• Radio modules to connect to the iMote controllers.
• Audio acquisition boards for the iMote controllers.
• A toolchain to compile C for the Intel iMote micro controllers and associ-ated hardware to connect iMotes to a PC.
A.7 References
1. John Heidemann, Ramesh Govindan An Overview of Embedded SensorNetworks (ISI TR-2004-594 )
2. Kurtis Kredo II, Prasant Mohapatra Medium access control in wirelesssensor networks
3. David Brunelli, Massimo Maggiorotti, Luca Benini, Fabio Luigi Bellifem-ine Analysis of Audio Streaming Capability of ZigBee Networks EWSN2008, LNCS 4913, pp. 189-204, 2008
4. M. Ferrari & L. PizziniacoAn Adaptive Scheme for Active Periods Schedule in IEEE 802.15.4 Wire-less NetworksISBN 978-1-4244-0398-1 [08/09/06]
5. Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer(PHY) Specifications for Low-RateWireless Personal Area Networks (WPANs)Print: ISBN 0-7381-4996-9 SH95552PDF: ISBN 0-7381-4997-7 SS9555208-09-06
33
Appendix B
Lab Book
This is a transcription of the lab book kept throughout the project.See http://www.themoggie.co.uk/code/TinyOS/Lab%20Book for the completescans.
B.1 2008
B.1.1 7 October - Ubuntu TinyOS Install
Req. Packages
• cvs
• subversion
• autoconf
• automake 1.9
• python-dev
• graphviz
• fakeroot
• g++
• g++-3.4
• gperf
• swig
• sun-java5-jdk
• alien
• libc6-dev-amd64 (For the stubs.h file)
• OpenOCD
34
Using the package repository: http://tinos.stanford.edu/tinyos/dists/ubuntuin the feisty/main directoryUsing the install guide from http://www.5secondfuse.com/tinyos/install.htmland the tinyos environment setup script to configure for TinyOS-1.x orTinyOS-2.x.Installed OpenOCD for JTAG control as perhttp://docs.tinyos.net/index.php/Imote2
B.1.2 9 October
NesC
Downloaded from http://tinyos.net/dist-1.1.0/tinyos/linux and installed as perthe installation guide in the package.
The ’Wasabi’ Tools
The XScale Tools are possibly the source of the missing binaries, but mustbe built from souce for Ubuntu as there are no prebuilt packages. Found theproblem with the missing binaries, and downgraded the version of NesC thatcomes with the hardy binaries from Apt. Toolchain now working, and can buildbinaries that will run on the Imote2 platform.
B.1.3 12 October - Package Conversion
All the packages I have had to convert are uploaded onto my web server. Forreference, conversion to Ubuntu/Debian binaries is achieved via ’Alien’
$ sudo alien [rpmfile]$ dpkg -i [debfile]
Converted:
• NesC
• Wasabi XScale toolchain
B.1.4 13 October - Fixing Build Errors
Fixing the dwarf2bd error on ”make imote2” The file”tools/make/pxa27x/pxa27x.rules” contains the symbolXBD SYMBOL EXTRACT containing ”dwarf2bd” for exporting the binaryto an exe format. (Why, I have yet to work out) Simply replacing that with”echo” so the command is output to the terminal (and thus, does not error)fixes the problem and the minary ”main.exe” works fine on the Imote2.
B.1.5 16 October
Superframe Structure
• Defined by the coordinator
• Divides the channel time into 16 distinct slots (The superframe itself)
35
• Beacon frame is always sent in the first slot (Assuming superframing ison)
Guaranteed Time Slots (GTS)
Can be allocated as part of the superframe and form contention-free periods(CFPs). Any transmission in a GTS must complete before the next GTS (norun-over)
Data Transfer to a Coordinator
Figure B.1.5.1: Data Transfer to a Coordinator
Data Tranfer to a Device
Figure B.1.5.2: Data Transfer to a Device
36
Again, this only works in beacon mode, akin to the PUSH setup for mail, withthe server informing the client of pending data.
The Beacon Frame
Size (in octets) Name Optional2 Fame Control No1 Sequence Number No4 or 10 Address Fields No0, 5, 6, 10, 14 Security Header Yes2 Superframe Spec No’k’ GTS Fields No’m’ Sending Address No’n’ Payload Size No2 FCS No
(From page 21, IEEE 802.15.4)FCS = Frame Check Sequence Frame Length = 7 + (4 to 24) + k + m + n
B.1.6 19 October
B-MAC - CSMA for low powered wireless networks
TDMA + Slotted ALOHA Not suitable due to scaling issues This means beaconmode 802.15.4 would also be unnaceptable for the same reasons
Channel Sampling [CCA]
Signal strength sampled when channel is assumed to be free
• After packet transmission
• When the radio stack int receiving valid data
Samples entered into a FIFO queue
• Optimum size of 10
Median average taken for the queue and added to an exponentially weightedmoving average
• Decay = 0.06
B.1.7 20 October - Meeting
• No contentionin the medium
• Static network
• Star network
• CC2420 Network chip
37
Figure B.1.7.1: Audio Events
Sample size of 4kB.
B.1.8 21 October
JTAG - Write Sequence
Using the openocd.cfg file (found in Blink/ in the apps dir) for the OpenOCDconfig, so with the config on your path;
$ sudo openocd -f openocd.cfg -d3
(”-d3” so we see what openocd is doing - verbose debug)
$ telnet localhost 6666Then inside telnet;haltflash protect 0 0 10 offflash erase_sector 0 0 10flash write_image [path-to-binary]resetresume
38
Figure B.1.8.1: Mote Cloud and Coordinator
B.1.9 23 October
Issues with programming IMotes’ (flash would not write?) fixed by setting theJTAG write speed to ’1’, capping its max write speed.
TinyOS - NesC programming
Each TinyOS ’module’ requires
name .nc
name M.nc
B.1.10 27 October - NesC Code
Pretty much the same as C, but divided up into different source files dependanton function;
MODULE.nc - Contains a ”configuration” and ”implementation”
configuration MODULE{...}implementation{components Main, ...;}
Additional: To ensure that the code is atomic use an ”atomic ... ” blockatound it to prevent the scheduler from pre-empting it.
39
B.1.11 21 November - CntToLedsAndRfm & RfmToLeds
Figure B.1.11.1: Counter to LEDs via Radio Example Flow
Timer - CountCount - LedsCount - Rfm - Rfm - Leds
B.1.12 25 November
TinyOS Modules
Steps for implementing new modules... Find the required interface on one oftwo paths:
1. tos/interfaces
2. contrib/imote2/tos/interfaces
Add it to either the module/provides section of if you’re providing the in-terface (if you can be wired on these calls) or if you’re using the interface, putit in the module/uses section.
Providing Functionality
If implementing commands defined in an interface, prefix all functions with”command” as they are in the interface definition file. However, the functionmust be prefixed by their module or alias name, so the interface definition:
command result_t init();
With the module name ”StdControl”, becomes;
command result_t StdControl.init(){ ... }
40
in your implementation.
Because a lot of modules use split control methods, events are often passedback to the calling module via event callbacks. If an interfaceimplements/requires the module to have thir callback functions, eg;
event result_t txBitDone();
Then the calling module must specify them with a prefix of the modulename/alias, eg;
event result_t Radio.txBitDone(){ ... }
Note, this does not require the module to implements SplitControl as aninterface unless it is using SplitControl methods for wiring.
B.1.13 25 November
Radio Communication - Confirmed Working
To allow radio functionality, use the following configuration in addition to yourcurrent setup;
implementation{components GenericComm as Comm;
Main.StdControl -> Comm.Control;[Module].SendMsg -> Comm.SendMsg[ID];[Module].ReceiveMsg -> Comm.ReceiveMsg[ID];}
Where ”[Module]” is your module name, and ”[ID]” is your packet ’port’.In the CC2420ControlM.nc file the radio tuning commands are laid out.
command result_t CC2420MControl.TunePreset( uint8_t channel );command result_t CC2420MControl.TuneManual( uint16_t frequency );
Preset values = 11 to 26 (Range 15) Frequency Values = 2400 to 2483 (Range83)
B.1.14 25 November
Blue Shell Integration (BLuSH) - Confirmed Working
The blue shell uses two calls to define a command. For a function ”Call”;
command Call.getName( char *buffer, uint8_t length){ ... }
and;
command Call.callApp(\tchar *cmdBuff,\tuint8_t cmdLen,\tchar *resBuff,\tuint8_t resLen){ ... }
41
Radio Power - Confirmed Working
Command result_t CC2420Control.SetRFPower( uint8_t power );
Values = 3 to 31 (Range 28)
B.1.15 26 Nov26 November
The TOS Msg Structure Field Size (B)length 1 fcfhi1 fcflo 1dsn 1destpan 2addr 2srcpan 2 Not Usedsrcaddr 2 Not Usedtype 1group 1 10B Header, see 3/Dec/08 for proofdata[len] len System Generatedstrength 1 System Generatedlqi 1 System Generatedcrc bool System Generatedack bool System Generatedtime 2 System Generatedtime32low 4 System Generatedtime32high 4 System Generated
Imote Speeds
(416, 208) - Working: 416, 208, 104
DVFS.SwitchCoreFreq( core, bus );
DVFS - Dynamic Voltage and Frequency Scaling
Test Data
Using a payload size of 28 bytes, speeds of approximately 4kB a second canbe achieved by using the standard tinyos-1.x network commands, although indoing so, the event stack gets flooded by network calls and eventually crashesthe mote.
ToDo
Determine valid values for mote bus and clock speeds. Figure out why thepayload size is immutable Test other payload sizes
B.1.16 28 November
Clock Speed Payload Size Payload Data RateLow 28 4kB/sHigh 28 4.5kB/sHigh 128 17kB/sHigh 256 0B/s
42
This data was acquired by forcing the IMotes to transmit -as-fast-as-possible-by saturating the event stack to the point of crashing the mote.
B.1.17 1 December
Speeds as high as 28,000B/s have proven acheivable using the TinyOS unicastprotocol using the event stack. These speeds, while sustainable, do tend to oc-cupy the mote for rather a lot of time, so the practicalities of using this schemefor live systems is questionable Inaddition to this, the core speed of the moteis required to be at the fastest mode, causing the system to consume relitavelylarge amounts of power. Also adding to the impracticalities of using this setup.However, bt using the ’snoop’ interface for radio communication (the same sys-tem as employed by routing modules for store-and-forward systems) the datarate is increased due to the multicast nature of this new setup. Additionally, theAMBroadcast interface (which would be used in a milticast setup irrespectiveto speed requirements) does not require recipiants to send ACK packets, so andradio with an in-built CSMA has less hardware level contention to deal with,potentially doubling the throughput (if ACK messages are of equivalent sizeto the transmitting message) Ignoring module/application spece descisions ontransmit approach, avoiding using the event stack is preferable, as any delaysin sending mulci-packet messages would be removed. As it stands, the stackis used for every 128B message, so for a 512B payload , 4 manual send() callswould need to be performed from the application. This obviously, calls thewhole stack 4 times, making it somewhat inefficient. Ideally, we want to handthe kernel-layer function a pointer to a payload memory area, a target mote anda payload length.
B.1.18 2 December
It is questionable if the kernel-level implementation of this protocol/transmissionschemea needs to be atomic. By being atomic, the transmission cannot be haltedmid-send by interrupts, however, in an application domain where fixed-delaysamples may be required, this is less than desireable. This said, it only becomessignifigant if the transmission takes longer than the fixed time slot, as it wouldcorrupt the sample.
B.1.19 3 December
B.1.20 CC2420 Calculations
The CC2420 radio specification declares; Max Throughput: 250kbps 2.4 GHzfrequencies 128B Tx/Rx buffers Using +vvv verbose debug mode, we see that:TXFIFO.length = 138 (when given a payload of size 128B) This gives us apacket header size of 10B Meaning the absolute maximum size of a packet is118B (for a payload) before we overflow the CC2420’s internal buffers. Exceptthat this does not work in practice.
B.1.21 4 December
The previous speeds attained were incorrectly measured, as although the pay-load arrat length was increasing, the total data send was only 10B, as I was
43
not increasing the payload length variable to the send() call. (See 26/Nov/08,”data[len]’ struct array”)
More CC2420 Calculations
250kb with a 128B buffer250x1000 = 250,000bps/128B = 1,953.125 Buffer fills/sec250x1024 = 256,000/128B = 2000 Buffer fills/secSo using this data 2000 buffer fills a second are possible. At this stage, I
believe hat the Tx/Rx buffer can only be filled with -one- packet at a time. Ifthis is true then by using the event system, with auto-ack on, we get 4000 (If asystem call is invoked for ACKs) calls to the event system, per second.
Figure B.1.21.1: CC2420 Signals
Ignoring my earlier blunder regarding the transmit length variable, the fullspeed of the radio will never be achieved by using the event system, as hugenumbers of calls are made, causing the OS to be inside its call system or thescheduler most of the time. Plus any other module using the system at thesame time will barely get a look in. Additionally, if the other module usesatomic blocks for any long operation, the data rate for the radio link will dropback to zero. Livelock is also a real possibility with this setup, as the radiomodule uses all but one call in the call stack, then gets preempted by anothermodule, the new module is stick waiting for a call slot to appear, but it neverwill. The obvious solution to this would be to implement a multi-packet trans-mission call. However, although this may seem simple, the problem lies as towhere it should be implemented. AMBroadcast and AMStandard are only re-ally interface configurations with GenericComm and HPLCC2420C/M, so anymodification here still really calls the event system still. HPLCC2420M doesall of the SPI calls to the radio itseld, but changing it at this level runs therust of breaking other modules that wire to it (AMStandard, GenericComm,and AMBroadcast to name a few). One alternative would be to design a newinterface based off GenericComm, that did allow packets to be sent sequentiallyat the HPLCC2420 layer and take over from the normal operation.
44
Figure B.1.21.2: The TinyOS Radio Stack
One possible problem to note at this stage: The HPLCC2420M module per-forms non-atomic calls to the radio. This could quite easily cause race conditionsif high-speed and non-high-speed links attempt to call SPI at the same time.
B.1.22 19 December - Using AMStandard for Broadcasts
CC2420-¿Broadcast on 0xFFFF Confirmed working.
B.2 2009
B.2.1 6 January
Active Messages
Figure B.2.1.1: Active Messages
The flags segment contains additional information that will be ignored by ex-isting modules.
45
Figure B.2.1.2: Active Message Modification
The bit depth for fragment Ids will be set in a #define as to allow forlarger/arbitrary size fragmentation. By using an additional pseudo-header andkeeping the payload size the same, fragmented packets can be discerned fromnormal AMs. Is any of this needed? After all, the AM’s are only seen bythe modules after being in the radio stack. If the stack is merely expanded tocontain functions to send more than 28B, packets, then framengations is moot,as it would just replicate the AM packets at the receiver.
Default AM Flow
Figure B.2.1.3: Default AM Flow
High Speed AM Flow
46
Figure B.2.1.4: High Speed AM Flow
By using this approach to transmit data we eliminate the calls throughwiring layers so minimising the stack usage, memory usage and CPU time. The”GetNext28B” function call in this diagram should construct the packets as wellas collecting the next 28B. If the ”Send” call hands a pointer to a TOS Msg withblank payload data, and a pointer to an area of memory containing the extendedlength payload data and a data length, then the ”GetNext28B” function can re-use the TOS Msg struct by filling the payload data then handing the struct tothe ”SendData” function (Actually the regular ”Send” call, but the non-wiredversion, internal to CC2420/GenericComm)
If the extended payload is not evenly devisable by 28B the payload data inthe final packet is undefined, but will almost always be the previous packetsdata.
47
Figure B.2.1.5: Extended Send Sequence
There is the possibility got more informative messages to be sent to thecalling module, such information would be off by default, and only enebled ifthe application warranted it.
Figure B.2.1.6: Extended Send Sequence, with Statistic Messages
48
Internal Call Sequence for Extended Sends
Figure B.2.1.7: Internal Call Sequence
Because the ”ExtSend” call, calls ”Send” directly, the module may need to bewired into itself otherwise the SplitControl used to call ”Send” may throw errorsas its return call would have nothing attached...
Calling Send
[boolean]wait = truecall CC2420.Send( ... );while( wait );
...
command CC2420.SendDone( ... ){wait = false;}
49
B.2.2 15 January
Rather than adding or modifying variables in the TOS Msg structure to de-termine the differences between fragments and regular packets, simply usingdifferent ’types’ will work.
Figure B.2.2.1: AMStandard Radio Calls
Because TinyOS keeps these message ’channels’ completely seperate, onetype -cannot- be mistaken for another.
Recombination
To recombine an extended packet, the receiving ’Mote must pervform an inser-sion/shell sort on all incoming fragments.
Figure B.2.2.2: Insersion Sort
Because we are far more likely to get packets in-order, the insersion can startat the end of the recombined structure.
By doing this, the insersion operation will almost always perform as an O(1),then O(n) when building a message in a random order.
50
Figure B.2.2.3: O(n) and O(1) Recombination Schemes
This also means that the linked list to contain these packets only needs tobe singly linked.
Figure B.2.2.4: Linked List Structure
Ergo;
typedef struct{fragment *back;int8_t *data;}
typedef struct{fragment *end;framgnet *start;}fragmented_packet;
51
B.2.3 17 January - Re-doing Speed Tests
28B payload, attempting to send 1000/sec Max speed: 28,000B/sec Attained:5,700B/sec [Mean: 5,649B/sec] 64B payload, attempting to send 1000/sec Maxspeed: 64,000B/sec Attained: 10,274.13B/sec 100B payload, attempting to send1000/sec Max speed: 100,000B/sec Attained: 13,480B/sec Fragment MTU =AM Payload - Fragment Address
B.2.4 21 January
Contrary to 15/Jan, where O(1) and O(n) schemes for reconstruction are dis-cussed, the fragments contain their ID, so no list is actually required to recon-struct the data, as offsets can be calculated for all packets upon delivery, soO(1) always. Offset = ID x Fragment MTU x sizeof(uint8 t)
B.2.5 23 January
Parameterized Interfaces By providing interfaces in the form;
interface SendMsg[uint8_t id];
and defining functions as;
event result_t SendMsg.sendDone[uint8_t id]( ... );
we can provide 256 generic interfaces, and by doing so, capture all ’ports’ atonce with only one function call.
Figure B.2.5.1: HPLCC2420 Signal
Data Rate
13,480B/sec @ 100B payloads = 134.8 packets/sec Header = 10B, so 110B totalper packet, ergo: 14828B/sec inc. header.
52
B.2.6 9 February - HighSpeedNetworkLink
radio state - Greater than 0, where radio is in use.
While( radio_state > 0 );radio_state = 1;... [Do stuff] ...radio_state = 0;
53