1 / 73

Wireless Sensor Networks MAC Layer

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

betty_james
Télécharger la présentation

Wireless Sensor Networks MAC Layer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Wireless Sensor NetworksMAC Layer Professor Jack Stankovic University of Virginia 2006

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

  3. WSN Architecture – MAC?

  4. Ad Hoc Wireless Sensor Networks Reality – Irregular Multi- cast 2 6 data 6 2

  5. Outline • 802.11 DCF (essential aspects) • S-MAC (briefly) • B-MAC • Multi-Channel MAC

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

  7. TDMA on Wired Network A B C C B A Repeat Cycle 0 1 2 3 Time (Slots) Scales?

  8. TDMA in Wireless Network B D E A C /D? C B A /E Time Disadvantages? WSN Issues? Optimizations?

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

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

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

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

  13. 802.11b

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

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

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

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

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

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

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

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

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

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

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

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

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

  27. B-MAC • Configurable (Key Feature!) • Small core • Factor out functionality and expose to higher layers • Can be tailored to different types of networks

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

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

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

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

  32. B-MAC • If Not Clear on CCA Listen • Use a congestion backoff time (if none provided use a default)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  48. Multi-Channel MAC • MMAC – Multi-channel MAC • Other solutions exist • SSCH – Slotted Seeded Channel Hopping • MMSN – Multi-Channel Mac for Sensor Networks

  49. 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, …

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

More Related