mac layer protocols for sensor networks - univ...
TRANSCRIPT
MAC Layer Protocols for Sensor Networks
Leonardo Leiria Fernandes
Compiled by C. Pham for educational purposes.Background color has been modified in this presentation. Some slides were also added
Contents
l Basic Concepts l S-MAC l T-MAC l B-MAC l P-MAC l Z-MAC
S-MAC - Sensor MAC
l Nodes periodically sleep l Trades energy efficiency for lower
throughput and higher latency l Sleep during other nodes transmissions
Listen Sleep t Listen Sleep
Periodic Listen and Sleep l If no sensing event happens, nodes are idle
for a long time l So it is not necessary to keep the nodes
listening all the time l Each node go into periodic sleep mode during
which it switches the radio off and sets a timer to awake later
l When the timer expires it wakes up and listens to see if any other node wants to talk to it
Added slide by C. Pham
Added slide by C. Pham
l If a node A wants to talk to node B, it just waits until B is listening
l If multiple neighbors want to talk to a node, they need to contend for the medium
l Contention mechanism is the same as that in IEEE802.11 (using RTS and CTS)
l After they start data transmission, they do not go to periodic sleep until they finish transmission
Added slide by C. Pham
Choosing and Maintaining Schedules
l Each node maintains a schedule table that stores schedules of all its known neighbors.
l To establish the initial schedule (at the startup) following steps are followed: n A node first listens for a certain amount of time. n If it does not hear a schedule from another node, it
randomly chooses a schedule and broadcast its schedule immediately.
n This node is called a SYNCHRONIZER.
Added slide by C. Pham
l If a node receives a schedule from a neighbor before choosing its own schedule, it just follows this neighbor’s schedule.
l This node is called a FOLLOWER and it waits for a random delay and broadcasts its schedule.
l If a node receives a neighbor’s schedule after it selects its own schedule, it adopts to both schedules and broadcasts its own schedule before going to sleep.
Maintaining Synchronization l Timer synchronization among neighbors are
needed to prevent the clock drift. l Done by periodic updating using a SYNC
packet. l Updating period can be quite long as we
don’t require tight synchronization. l Synchronizer needs to periodically send
SYNC to its followers. l If a follower has a neighbor that has a
different schedule with it, it also needs update that neighbor.
Added slide by C. Pham
Added slide by C. Pham
l Time of next sleep is relative to the moment that the sender finishes transmitting the SYNC packet
l Receivers will adjust their timer counters immediately after they receive the SYNC packet
l Listen interval is divided into two parts: one for receiving SYNC and other for receiving RTS
Added slide by C. Pham
Timing Relationship of Possible Situations
S-MAC Results
Latency and throughput are problems, but adaptive listening improves it significantly
S-MAC Results
l Energy savings significant compared to “non-sleeping” protocols
T-MAC - Timeout MAC
l Transmit all messages in bursts of variable length and sleep between bursts
l RTS / CTS / ACK Scheme l Synchronization similar to S-MAC
T-MAC Operation
T-MAC Results
l T-MAC saves energy compared to S-MAC l The “early sleeping problem” limits the
maximum throughput l Further testing on real sensors needed
B-MAC - Berkeley MAC
l B-MAC’s Goals: n Low power operation n Effective collision avoidance n Simple implementation (small code) n Efficient at both low and high data rates n Reconfigurable by upper layers n Tolerant to changes on the network n Scalable to large number of nodes
B-MAC’s Features
l Clear Channel Assessment (CCA) l Low Power Listening (LPL) using preamble
sampling l Hidden terminal and multi-packet
mechanisms not provided, should be implemented, if needed, by higher layers
Sleep t
Receive Receiver
Sleep t
Preamble Sender Message
Sleep
B-MAC Interface
l CCA on/off l Acknowledgements on/off l Initial and congestion backoff in a per
packet basis l Configurable check interval and
preamble length
B-MAC Lifetime Model
!
E = Erx + Etx + Elisten + Ed + Esleep
Erx = trxcrxbVEtx = ttxctxbV
Elisten " Esample1ti
Ed = tdcdataVEsleep = tsleepcsleepV
l E can be calculated if hardware constants, sample rate, number of neighboring nodes and check time/preamble are known
l Better: E can be minimized by varying check time/preamble if constants, sample rate and neighboring nodes are known
B-MAC Results
l Performs better than the other studied protocols in most cases
l System model can be complicated for application and routing protocol developers
l Protocol widely used because has good results even with default parameters
P-MAC - Pattern MAC
l Patterns are 0*1 strings with size 1-N l Every node starts with 1 as pattern l Number of 0’s grow exponentially up to a
threshold δ and then linearly up to N-1 l TR = CW + RTS + CTS + DATA + ACK l N = tradeoff between latency and energy
Patterns vs Schedules Local
Pattern Bit Packet to
Send Receiver Pattern Bit
Local Schedule
1 1 1 1 1 1 0 1- 1 0 * 1- 0 1 1 1 0 1 0 0 0 0 * 0
P-MAC Evaluation
l Simulated results are better than SMAC l Good for relatively stable traffic
conditions l Adaptation to changes on traffic might
be slow l Loose time synchronization required l Needs more testing and comparison
with other protocols besides S-MAC
Z-MAC - Zebra MAC l Runs on top of B-MAC l Combines TDMA and CSMA features
CSMA l Pros
n Simple n Scalable
l Cons n Collisions due to
hidden terminals n RTS/CTS is
overhead
TDMA l Pros
n Naturally avoids collisions
l Cons n Complexity of
scheduling n Synchronization
needed
Z-MAC Initialization l Neighborhood discovery through ping
messages containing known neighbors l Two-hop neighborhood used as input for a
scheduling algorithm (DRAND) l Running time and message complexity of
DRAND is O(δ), where δ is the two-hop neighborhood size
l The idea is to compensate the initialization energy consumption during the protocol normal operation
Z-MAC Time Slot Assignment
!
2a"1 # Fi < 2a "1l2a + si( for : l = 0,1,2...)
Z-MAC Transmission Control
The Transmission Rule: l If owner of slot
n Take a random backoff within To n Run CCA and, if channel is clear, transmit
l Else n Wait for To n Take a random backoff within [To,Tno] n Run CCA and, if channel is clear, transmit
Z-MAC HCL Mode l Nodes can be in “High Contention
Level” (HCL) l A node is in HCL only if it recently received
an “Explicit Contention Notification” (ECN) from a two-hop neighbor
l Nodes in HCL are not allowed to contend for the channel on their two-hop neighbors’ time slots
l A node decides to send an ECN if it is losing too many messages (application ACK’s) or based on noise measured through CCA
Z-MAC Receiving Schedule
l B-MAC based l Time slots should be large enough for
contention, CCA and one B-MAC packet transmission
l Slot size choice, like in B-MAC, left to application
Z-MAC Results
l Z-MAC performs better than B-MAC when load is high
l As expected, fairness increases with Z-MAC l Complexity of the protocol can be a problem
Conclusions
l Between the protocols studied, B-MAC still seems to be the best one for applications in general
l Application developers seem not to use B-MAC’s control interface
l Middleware service could make such optimizations according to network status
Thank You
Questions or comments?
Thank you for coming!