840 likes | 1.6k Views
Wireless Sensor Networks MAC Layer. Professor Jack Stankovic University of Virginia 2006. What is a MAC Protocol. Medium Access Control Coordinate actions over a shared channel (basic theme of many solutions) Test channel to see if busy If busy, wait If not busy, transmit
E N D
Wireless Sensor NetworksMAC Layer Professor Jack Stankovic University of Virginia 2006
What is a MAC Protocol • Medium Access Control • Coordinate actions over a shared channel (basic theme of many solutions) • Test channel to see if busy • If busy, wait • If not busy, transmit • If collision, back off and try again later
Ad Hoc Wireless Sensor Networks Reality – Irregular Multi- cast 2 6 data 6 2
Outline • 802.11 DCF (essential aspects) • S-MAC (briefly) • B-MAC • Multi-Channel MAC
Types of MAC Protocols • Contention Based • 802.11b DCF (CSMA) • S-MAC, T-MAC, Z-MAC and B-MAC(all for WSN) • Scheduled Based • TDMA, NAMA, TRAMA • Multi-Channel - MMAC
TDMA on Wired Network A B C C B A Repeat Cycle 0 1 2 3 Time (Slots) Scales?
TDMA in Wireless Network B D E A C /D? C B A /E Time Disadvantages? WSN Issues? Optimizations?
802.11 DCF RTS A B CTS • Main Parts • Sense channel – if not busy transmit • Send Request to Send (RTS) – include how much time is needed for transmission – a function of the length of the message • Clear to Send (CTS) – include (repeat) how much time is needed • Send Data Packet Data
802.11 DCF RTS A B CTS • Main Parts • Sense channel – if not busy transmit • If busy then do a random backoff in a window before trying again Data Interval is time slotted (e.g., 10 slots) Use counter (choose counter value in window) Wait until channel is clear and start decrementing the counter as long as channel remains idle If channel is/gets busy then freeze counter until free When counter = 0 try RTS
802.11 DCF RTS A B CTS • Main Parts • If RTS is lost • Detected by no CTS • Consider this congestion • Then double the length of the window Data
802.11 DCF RTS A B CTS • Main Parts • Inter-frame spacing • 4 different inter-frame spacings • Enables each packet to have a different priority when contending for the channel Data ACK SIFS SIFS PIFS DIFS EIFS CTS/ACK Increasing in Length of wait DIFS RTS
802.11 DCF ATIM A B ATIM-ACK • Main Parts • Power Saving Mode – doze mode C ATIM Window Time Beacon Beacon All nodes awake in ATIM window A and B stay awake during entire beacon interval If node does not send or receive ATIM it enters Doze mode until next beacon
802.11 DCF RTS A B CTS • Example – no concurrency • Sense channel – if not busy transmit RTS • C responds with CTS Data B sends to C A hears RTS D hears CTS – Both A and D know to wait and for how long A B C D B’s Range C’s Range
802.11 DCF RTS A B CTS • Hidden Terminal Problem • Use same example (B sends to C) • D cannot hear B so what if it transmits before C sends a CTS Data A B C D B’s Range C’s Range
802.11 DCF RTS A B CTS • Exposed Terminal Problem • B sends to A • C wants to send to D, but is prevented because it heard that B is transmitting Data A B C D B’s Range C’s Range
Design - Fn(Types of Traffic) • Classical MACs optimize for the general case and for arbitrary patterns and workloads • WSN • Local Uni/broadcast • Nodes to sink (perhaps all in one direction) • Periodic or rare (burst communication) • Must consider energy
What Makes a Good MAC for WSN • Low power operation • Effective collision avoidance • Simple implementation, small code and RAM size • Efficient channel utilization at low and high data rates • Reconfigurable by network protocols • Tolerant to changing RF/networking conditions • Scalable to large numbers of nodes
Energy Consumption • Idle Listening (largest amount) • Due to collisions • Protocol overhead (control packets) • Overhearing (a node receives packets not destined for it – could have been asleep)
Idle Listening • When will a node receive a packet? Listen 100% of the time. Expensive! • Three Schemes • Schedule (like S-MAC) • Wake-up packet – use energy in packet • Use duty cycle in CSMA and a long preamble • Node awakes periodically and listens for preamble; if preamble there, it stays awake
Duty Cycle Example Preamble Stay awake W sleep sleep W Node here wants to send packet Nodes awake and hear preamble W = wake up their radio
S-MAC • Node’s radio is asleep during the passive part of frame • Active part: communicate with neighbors and send any messages queued during the passive/sleep time Active Passive/Sleep 115 ms 885 ms Clock drift of say 500 microsecs is not a problem
S-MAC • At each active period, nodes exchange sync info • After SYNC period, data can be sent using RTS-CTS • If a node overhears a RTS-CTS it sleeps, but will awake a short time after the neighbor has transmitted to immediately send its own data • NOTE: All communication is packed into the active part
S-MAC • End result: Trades saving energy for less throughput and greater latency • Good for what type of traffic patterns? • Light traffic • When latency not a problem
B-MAC • CSMA • Improves over S-MAC • Better packet delivery rates • Higher Throughput • Lower Latency • Less energy consumption • Adaptive preamble sampling scheme to reduce duty cycle and minimize idle sampling • Moves MAC functions up the stack
B-MAC • Configurable (Key Feature!) • Small core • Factor out functionality and expose to higher layers • Can be tailored to different types of networks
B-MAC – 4 Capabilities • Clear channel assessment (CCA) • Packet backoff • Link layer acks • Low power listening (LPL) • Via an interface these 4 things can be adjusted
B-MAC • CCA • Determine if the channel is clear • How • Ambient noise changes over time • Use weighted moving average of samples when the channel is presumed to be idle • Use 5 to 10 samples • Note: 802.15.4 uses 1 sample • Subject to many false alarms (i.e., protocol thinks that noise is a packet) • Wastes energy
B-MAC • Listen (is there a real packet coming?) • Check 5 samples • If outlier spike well below threshold then this is not a packet • A real packet would have too much energy to have such a “negative” spike • If no outlier, then this is a packet THR Real Packet
B-MAC • Interface – turn CCA off/on • OFF -> implement a scheduling protocol above B-MAC (e.g., you know when the channel is idle or busy)(such as TDMA) • ON -> • When ready to send there is an initial backoff time • Caller can set that time, else a default • After the initial backoff, run CCA listen Wake Up Ready to Send Backoff CCA Listen Time
B-MAC • If Not Clear on CCA Listen • Use a congestion backoff time (if none provided use a default)
B-MAC • At receiver (no packet to send) • Node wakes up • Turns on radio • Listens • If it hears a preamble/packet it stays awake to receive incoming packet • After packet arrives it goes back to sleep • If no packet was received after a timeout then just go back to sleep
B-MAC • At sender CCA is used to see if channel is clear • At receiver CCA is used to see if channel is active and hence this receiver needs to stay awake
B-MAC • LPL (low power listening) • Duty cycle the radio through periodic sampling 100 ms Uses CCA No. of samples Of radio signal Idle listening is defined as being awake and sampling when nothing is being sent.
B-MAC • Preamble length is matched to the interval that the channel is checked for activity • Check every 100 ms then preamble must be at least 100 ms • Wake up, listen, detect activity, receive the preamble, receive the message • Wake up, listen………..nothing, go back to sleep • B-MAC Interface • Check interval and preamble length are parameters
B-MAC • Optional link layer ACK • If on, there will be an ACK sent for every packet • Note: you can decide on a packet by packet basis if you want ACK or not • Why is this useful? • High priority packets want ACK • Sensing redundancy – may not need ACKs
B-MAC • Analytical Model for Energy Consumption (see paper if interested) • E = E(Transmit) + E(Receive) + E(Listen) + E(Data Sampling) + E(Sleeping) • E(Listen) can be reduced via MAC layer • Plus reduce collisions, max time in sleep • Lower transmit power
B-MAC • Other points to make (about paper) • No RTS/CTS (no waste of energy) • Consider (small data) packet sizes!!!! • Micro-benchmarks • Typical needs/operations (see what they consider typical for a MAC protocol) • You may need to define micro-benchmarks for your project, if any
B-MAC • Analytical model is validated (generalize) • Interesting tradeoffs demonstrated • Compare against state-of-art S-MAC in actual implementation • Workload: Run real Surge application (monitoring type application) – integrate BMAC and MintRoute
B-MAC • See Figure 1 – Interfaces for BMAC in nesC • Table 1 – code and data sizes • Table 2 – Time and current consumption for various send/rcv operations
Single Channel MAC(up to now) • Example – Mica2 Motes • Choose either 433MHz OR 916MHz as frequency channel • Implies ONE channel • Requires ONE transceiver per node • Entire system runs with this single frequency channel
Multi-Channel MAC • N transceivers per node – expensive • Example with 2 per node RTS/CTS F1 Control Channel A B F2 Data Channel 50% of bandwidth for control
More Transceivers • 2 transceivers per node • 1 for control • 1 for data and reuse the control channel during data transmission phase • N transceivers • Expensive and form factor • Solutions not that practical for WSN
Multi-Channel MAC • Can you have multi-channel MAC with single transceiver per node? • YES • As long as that transceiver can dynamically shift between frequencies Time Different nodes can Transmit simultaneously Negotiate For Freq. On Default Freq
Negotiate on default frequency – F-0 via typical RTS/CTS F-N F-1 Does not require multiple radios (transceivers) per node! (also can reuse F-0)
Multi-Channel MAC • Utilize multiple channels/frequencies to avoid conflicts and increase throughput • 802.11b allows multiple frequencies at physical layer (14 channels, but use 3 to avoid overlap) • MAC for 802.11 is designed for a single channel – not suitable for multi-channel 5 MZ ~25 MHz apart 6 1 11
Multi-Channel MAC • MMAC – Multi-channel MAC • Other solutions exist • SSCH – Slotted Seeded Channel Hopping • MMSN – Multi-Channel Mac for Sensor Networks
MMAC • Assumptions • N channels • No Overlap • Same Bandwidth in each channel • Single half-duplex transceiver (transmit or receive but not both) • Time to switch channels is 224 usec • Nodes are synchronized • Clock sync also needed for tracking, computing velocity, identifying time of an event, …
Basic Idea Beacon Interval ATIM Window Negotiate and choose Channels Listen on default channel Nodes contend in here just as for 802.11 doze mode