MACs for sensor nets review Aloha Slotted aloha

MACs for sensor nets

review • Aloha • Slotted aloha • CSMA • Listen before sending • Non/1/P-persistent Prob of no others = e^-R 2 T where R is the data rate T 2 T • P_r = (1 -a)*a^CW / (1 -a^CW) * a^-r • Sum from 1 to CW is one => will send within r steps • 802. 11 – CTS/RTS – Virtual channel sensing – RTS/CTS/DATA/ACK • DBTMA

MAC issues • Collision avoidance – – Basic task of MACs Contention based MAC (like the ones discussed) Contention free or reduced contention Energy efficiency • Key issue – Scalability + adaptability – Channel utilization • Not always important in sensor nets – Latency • The delay from when a node wants to send, to when it actually does send. • Sometime this is important. However, often the sensing is done on human time scales and latency is on CPU scales. But 100 ms can easily add to seconds – Throughput • Not a chief concern in sensor nets (usually) • Goodput is a concern in the sense that is good put ios far lower than throughput, then energy is being wasted. – Fairness

Energy issues in MACs • Collisions – When packet collide, the two transmissions are wasted, leading to wasted energy. • Idle listening – When nodes are listening and there is no data to send or receive, then energy is wasted. In this case it is better to turn off the radio until transmissions are ready to occur. . But then contention might be an issue – Idle: receiving: transmission power ratio: • 1: 1. 05: 1. 4 for wavelan card • 1: 2: 2. 5 digitan wireless LAN • 1: 1: 1. 41 for our mica – Idle listening can account for 50 -100% of the energy • Overhearing – When node receive packets destined for other nodes, these packets are decoded which take processing time and wastes energy • Control overhead – Many control packet (for sync and schedule exchange) can use energy

Polling MACs • • Master asks each node if it has data to transmit or sends it data The is never a collisions The master can provide Qo. S Problems – – • Heavy load on the master Slaves must always be ready for beacon Polling can be difficult is there and many nodes All nodes must be in range of the master Bluetooth uses polling – Max of seven slaves per master – Slaves can be put into low power modes • Hold – Sleep for a defined period of time – The node must be put into hold every time • Sniff – The slave skips a fixed number of master transmission slots – Wakes up for a few slots and then goes back to sleep for a few slots • Park – The slave is put to sleep and loses its address. – It wakes every now and then to receive a synchronization beacon – It ca come back alive at the beaconing time

Schedule MACs • TDMA (didn’t we just go on and on about how statistical multiplexing is best…) – The nodes must be synchronized – Mobile phones use TDMA. The base station synchronized. Also, mobile phones stream data… – TDMA allow node to sleep when not scheduled – Problems • Scheduling is difficult – Elect a cluster head – As node join or die • A large number of node cannot easily be accommodated without greatly increasing latency – Base stations may exist. In which case advance scheduling may be possible

Schedule MACs • Suppose that a clock has drift in range E. • If the sleep period is T, then it might wake up ET too early/late. • If a node wants to synchronize/communicate, and its wake up time has error ET. So the total error is 2 ET • Thus, a node must be awake for 2 ET in order to catch the other node. • Also, it must wait a bit more for the transmission and propagation delay = Tc. • So the total time to be awake is Tc+2 ET • The relative sleep wake time (duty cycle) is (Tc + 2 ET) / T • Tc/T->0 as T->inf, • but 2 ET/T=2 E for all T and hence puts a bound on the duty-cycle and hence lifetime. • Also, this awake time is required for each communicating pair or scheduled wake up time,

Examples of scheduled macs • Pottie: – FDMA or CDMA is used so contentions are avoided – TDMA is used to save power. – Links between nodes are established by exchanging/agreeing on a schedule. That is, the end nodes agree on when data might be transmitted over the link. – Of course, multiple links might be active at the same time, but FDMA and CDMA avoids contention. – If the node degree is high, then many time slots must be used…. • Since FDMA/CDMa is used, then multiple transmission could occur at the same time…but synchronization might be an issue • LEACH – Nodes are grouped into cluster hierarchies – Cluster heads are elected based on available energy and are varied/rotated – The cluster heads act like base stations and all communication is between the children and the cluster head.

Mediation device (V 1) • Version 1 – – – – A mediation device (MD) helps other nodes communicate The MD is always listening Other nodes wake up and beacon with their ID and time schedule When a node wants to send, it sends an rts along with its schedule and the address of where it wants to send to The MD records this infor When the desired destination sends its beacon, the MD responds with a the time offset so the destination knows when the source will next be awake. When the source sends its next rts, the destination is awake and responds with a cts… Both nodes go back to their previous schedule so their beaconing does not conflict

Mediation device (V 1) source dest MD rts beacon Response With time to next wake up rts cts data beacon

Mediation device • A node wakes up and acts like a MD for a limited amount of time and then goes back to normal mode • It might only act as a MD for one period (where all nodes send one beacon period) • There is a challenge to make it so that there is typically one node awake, eithere will be too many or too few.

Contention-based protocols • No time scheduling • Wasted energy in collisions • Nodes must sleep – so some sort of timing and synch is needed, it the scheduling is easier. • Nodes often listen – wastes energy

S-MAC • • • Implemented in our Motes Contention-based But energy efficient sleep listen Coarse-grain sleep/wakeup. Low duty-cycle 1 -10% Nodes can select their own schedule. Nodes share schedules. If a node wants to transmit to a neighbor it simply waits until that neighbor is awake. But the nodes try to coordinate. – When a node starts, it listens and adapts to the first schedule heard. If none is heard, it picks on, a broadcasts it. – Periodically, nodes perform neighbor discovery and listen for other neighbors SYNC packet – Each node has a table of neighbors and their schedule – Schedule change • Send a new schedule to your neighbor when your neighbor is awake. • Continue to also wake-up at old schedule until all neighbors have been updated (push schedule – pull data) • To prevent clock drift, SYNC packets are sent. Also, the listening period is long, so exact timing is not needed. – A node that took another nodes schedule will SYNC to that node,

S-MAC data transmission • When a node wants to send, it waits until the correct time, senses the channel, and sends an RTS. • The RTS includes a duration, so neighboring nodes know how long to sleep for (? ) • Performance • Low energy • Long latency since nodes must wait – especially bad over multiple hops • Bad fairness if schedules are different (nodes with schedules that start first get higher priority)

T-mac / s-mac enhancements • • • Idea: events happen in bursts – so stay awake after an event and sleep longer between events Stay active, listening and sending until there is nothing to do for TA seconds Something to do includes – – – • • • the periodic listening scheduled event Reception of radio x-mission Sensing collision (I. e, , a loud signal that cannot be decoded (interference prone on ISM bands) End of transmission (of data or ACK) A neighbors RTS/CTS exchange A node that fails to get a CTS does not sleep, but waits and tries again. While the desired node may be asleep, it may also be overhearing another transmission. It will stay awake until TA sec after that transmission has completed. Nodes only sleep during other transmissions if the packet is long… A->B->C->D • If C wants to send to D, it might wait because it hears a CTS from B. However, d has not heard the CTS and goes to sleep. So when c transmits, d will be asleep. (Of course, if B wants to relay to c, then it can do so, but this may cause C’s buffer to fill. So C may stop sending CTSs to B. As B’s buffer fills it stops sending CTSs to A so c can transmit (back-presure)

Hybrid scheme • Contention period and scheduled period • During the contention period, node transmit a short message with the desired destination and the time when the trans will occur – aloha • At that time, the node transmits • Since the initial transmission is small=short, collisions are minor and the on time is short. • Nodes sleep when not in contention period

TRAMA – traffic aware medium access protocol • • • Random access period and schedule access time period Random access is for schedule exchange Each node broadcasts its and its neighbors schedule – Hence each node can learn the schedules within a 2 -hop radius – As a result, when a node transmits, it can determine not only is the destination is listening, but it the destinations neighbors might also be transmitting or receiving – thus there is no hidden node problem. • • Schedules are only exchanged rarely, so the random access is not a problem A node can determine its schedule based on the amount of traffic needed to send. (difficult to do when traffic is very bursty, the mean does not provide much information about the worst-case) – Slots are not just round-robin – The node-id, and the slot time are put through the MD 5 to get the priority of each node. The node with the highest 2 -hop priority wins. All node can determine who wins. A node can precompute when it wins • Schedules – A node will mark which node(s) will be the receiver in each of this nodes winning slots. (receiver is marked with 0/1 in bit-map fashion) – The last slot in the schedule has all zeros since the next schedule will be announced then – Other all zero slots mean no transmission, so other nodes can take them (based on priority.