MAC Layer

Some images taken from http://www.cs.uni-paderborn.de/index.php?id=1119&L=1

CSMA at sender fails to detect collision at receiver - A wants to transmit to B and cannot hear that C is transmitting a message heard by B
CSMA at sender detects potential collision that will not be actual collision at receiver - B transmits to A and C transmits to D

collisions - collisions cost energy since packets that collide are useless and must be retransmitted
overhearing - wireless is inherently broadcast and a node will spend energy receiving packets destined for other nodes
overhead - MAC control messages incur overhead
idle listening - a node in "listening" state consumes energy

Centralized solutions dedicate a central authority to coordinate who accesses the medium and when.

Pros: easy to implement
Cons: either require battery-powered node to act as coordinator or will drain battery of sensor selected as coordinator

Schedule-based solutions assign specific transmission/reception slots. Fixed assignment divides resources equally among nodes as in TDMA. Demand assignment allocates resources on a short-term basis as in token ring.

Pros: avoid idle listening, schedules can avoid collisions
Cons: overhead required to set up schedules, time synchronization required, may not adapt to changing load

Contention-based solutions leave nodes to compete with each other for resources when needed as in CSMA and ALOHA.

Contention-based solutions encounter the hidden/exposed terminal problems discussed above. Two commonly-discussed solutions are the following:

Busy Tone - two frequency channels are used, one for data and one for control. When a node starts to receive a packet destined for it, it emits a signal on the control channel that ends when the reception is finished. Before transmitting, a node senses the control channel and only transmits if there is no busy tone.
RTS/CTS (used in 802.11) - before sending, a node sends a "Request To Send" packet. If the receiver receives the RTS correctly, it replies with a "Clear To Send". Any node hearing the CTS (even if it didn't hear the RTS), knows that the channel is busy.

Problem 1: C cannot decode the CTS from B to determine the duration of the exchange because of collision with RTS from D. C does not know how long transmission will be and replies to second RTS from D causing a collision.
Problem 2: C cannot decode B's CTS and, upon receiving CTS from D, sends data causing collision at B.
Solution: Ensure CTS packets are longer than RTS packets. C is guaranteed to sense B's CTS after it finishes its RTS and will not send data. Also, in such case C must defer transmission for time to send 1 max-length data packet.

Idea: avoid spending time in idle state (either radio or entire node) by periodically sleeping/turning off.
Duty cycle: ratio of listen period to (listen+sleep period)
Small duty cycle - sleep most of the time, conserve energy, BUT increased latency for message delivery

Goal: reduce energy consumption, support good scalability and collision avoidance
Periodic listen and sleep - duty cycle is 50%, sleep for .5 seconds, listen for .5 seconds (time determined by app)
To talk to a node, wait until it is awake and use RTS/CTS before sending message
Nodes attempt to maintain same schedule as neighbors

Wait for certain time period. If no schedule heard, randomly choose a time to sleep and broadcast. Broadcasting node becomes synchronizer.
If schedule received during waiting period, node becomes a follower and will set its schedule to be the same. Wait for random delay and rebroadcast.
In rare cases, a node may hear two schedules and adopt both.

Times exchanged are relative (e.g., I will go to sleep in .25 seconds).
Listen period must be greater than clock error/drift to ensure lack of time synchronization isn't a significant problem.
Still, periodic resync is necessary. Nodes periodically resend a SYNC packet indicating time of next sleep and receivers adjust time accordingly.

Listen period - divided into SYNC portion and RTS portion. During SYNC portion, nodes listen for SYNC messages. During RTS portion, nodes listen for RTS messages and reply with CTS when appropriate. Data transmission follows.
Collision avoidance - before sending a SYNC or RTS packet, the sender senses the medium for a random amount of time. If no traffic is heard, it transmits.
Overhearing avoidance - nodes may sleep after hearing RTS/CTS sequence. The assumption is that this saves energy since data packets are longer and nodes will avoid hearing data packets destined for other nodes.

Goal: distribute energy burden of scheduling communication across all nodes.
Idea: network is partitioned into clusters. Each cluster has a clusterhead that schedules communication, receives data, and reports data to the base station.
Advertisement Phase: each round. each node decides whether to be a clusterhead, based on a preconfigured suggested percentage of clusterheads (5%) and the number of times the node has served as clusterhead, and sends an advertisement. Using received signal strength (RSSI), nodes decide which clusterhead to join. A CSMA protocol is used for this communication.
Cluster Set-up Phase: nodes use CSMA to join a cluster by informing the clusterhead of their decisions.
Schedule Creation: The clusterhead uses TDMA to schedule times for each node in the cluster to transmit.
Data Transmission: nodes send data during their allocated times. Nodes can turn off their radios when not transmitting. The clusterhead must remain on during the entire phase. Once the clusterhead has received data from all nodes, it aggregate the data and forwards it to the base station.
Multiple Clusters: to avoid collisions, each clusterhead chooses a CDMA code for the cluster.

Date: 2008-04-18