250 likes | 373 Vues
This paper presents CMAC, an energy-efficient medium access control layer protocol designed for wireless sensor networks (WSNs). CMAC optimizes performance through unsynchronized duty cycling, aggressive RTS, and convergent packet forwarding, minimizing synchronization overhead while achieving high throughput and low latency. The evaluation demonstrates that CMAC outperforms existing MAC protocols in energy efficiency, making it an ideal choice for WSN applications focused on long lifetime and low maintenance.
E N D
CMAC: An energy efficient mac layer protocol using convergent packet forwarding for wireless sensor networks SECON 2007 Sha liu, Kai-wei fan, Prasun sinha Department of computer science and engineering, Ohio state university Presentation: Jinhyung Lee Computer Network Lab
Contents 1 / 17 • Introduction • Contribution • Features • Evaluation • Conclusion • Discussion
Introduction 2 / 17 • MAC layer design goals for wsn • Long lifetime • Low latency • Low maintenance overhead • High throughput • Existing solutions • Synchronized MAC • SMAC, TMAC, DMAC • Consume a lot of energy on periodic synchronization • Unsynchronized MAC • BMAC, XMAC • Use long preambles
Contribution 3 / 17 • CMAC • Unsynchronized duty cycling • No synchronization overhead • Aggressive RTS, Anycast • Quickly make routing progress • Convergent packet forwarding • Avoid overhead of anycast • Achieved goals • Energy efficiency • Low latency • High throughput
Convergent MAC 4 / 17 • Aggressive RTS • Anycast packet forwarding • Convergent forwarding
Convergent MAC • Aggressive RTS • Anycast packet forwarding • Convergent forwarding
Aggressive RTS 5 / 17 Aggressive RTS Sender Sleep Sleep Sleep RTS RTS RTS RX Packet Sleep Sleep Receiver Sleep Sleep Sleep RX CTS Packet Sleep • Long preamble mechanism of BMAC • High latency • Breaks up long preamble into multiple rts packets • RTS burst • Sender receives a CTS, it sends packet immediately • Latency at each hop could be reduced by half
Aggressive RTS 6 / 17 RTS RTS Channel check • Assess channel quickly during each wake up time • To allow nodes to work at a very low duty cycle • If receiver wakes up during the gap between two RTSs • miss RTS burst
Aggressive RTS 7 / 17 RTS RTS RTS RTS (a) (b) Channel check Channel check RTS RTS Executed channel check Canceled channel check (c) Channel check • Double channel check • Check the channel twice to avoid missing activities • For each channel check, nodes sample up to 5 times • Between two channel checks, put to sleep mode • Interval must be shorter than RTS transmission time
Convergent MAC • Aggressive RTS • Anycast packet forwarding • Convergent forwarding
Anycast packet forwarding 8 / 17 • Nodes other than target receiver may • Wake up earlier • Can make some progress toward sink • Reduce latency • Anycast to the one closest to destination • Forwarding set • Neighbor nodes of the sender that are closer to the destination • Partition into 3 sub regions
Anycast packet forwarding 9 / 17 mini-slot CTS slot RTS Canceled RTS Sender CTS Node in R1 Node in R1 Canceled CTS Canceled CTS Node in R2 Canceled CTS Node in R3 • More than one node may contend to send cts • Each gap between two consecutive RTS is divided • 3 CTS slots for (R1, R2, R3) • Prioritize the cts packet transmission • Each CTS slot divided into mini-slots • Each node in the same region randomly picks up a mini-slot
Convergent MAC • Aggressive RTS • Anycast packet forwarding • Convergent forwarding
Convergent forwarding 10 / 17 • Anycast has higher overhead than unicast • Suboptimal routes • Anycast RTS/CTS • Switch from anycast to unicast if • Node is able to communicate with a node in R1 • Cannot find a better next hop than current one • Nodes stay awake for a short duration after receiving a packet • Synchronized wake-up scheduling • Timeout
Convergent forwarding 11 / 17
Experiments 12 / 17 • Testbed : kansei testbed • 105 XSM nodes • 7 x 15 topology, separation of 3 feet • Implementation parameters
Experiments 13 / 17 • Metrics • Throughput • Latency • Normalized energy consumption • Scenarios • Static event • Moving event • Comparison • CMAC 1%, BMAC 1% • CMAC 100%, BMAC 100%
Experiments – static scenario 14 / 17 Energy Consumption Throughput Latency
Experiments - moving scenario 15 / 17 Energy Consumption Throughput Latency
Simulation 16 / 17 Energy Consumption Throughput Latency
Conclusion 17 / 17 • CMAC • aggressive RTS, anycast, convergent packet forwarding • Supports high throughput, low latency and consumes less energy than existing solutions • Discussion • Noconsideration of node mobility • Awake duration after receiving packet is sensitive to performance • For low data rates, can’t converge from anycast to unicast • Too similar with XMAC
Thank You CS 710
Appendix CS 710
How long should nodes keep awake after receiving a packet? • Longer awake period →lower latency • But longer awake period may not be more energy efficient • Dependent on data rate and node density lambda: packet arrival rate in a Poisson arrival process
Performance of anycast if lack of convergence • Experiment settings: • Vary transmission ranges to create different node densities • Metric: • Latency normalized by distance (hops in unicast) • Results: • CMAC 1% achieves lower latency than BMAC 1%