UNIT IV Data link layer protocols
Link Layer Frame synchronization. Data are sent in blocks called frames. The beginning and end of each frame must be recognized. Flow control. The sending station must not send frames at a rate faster then the receiving station can absorb them. Error control. Any bit errors introduced by the transmission system must be checked & corrected. Addressing. On a multipoint line, such as a LAN, the identity of the two stations involved in a transmission must be specified. Link management. The initiation, maintenance, and termination of a data exchange requires a fair amount of coordination and cooperation among stations.
MAC Layer Low duty cycle protocols and wakeup concepts
Generality on protocol energy assessment Energy consumption mainly due to the transceiver activity; Protocol energy assessment based on transceiver states: Transmit time; Receive time; Idle time (Sleeping time in sensor-nets); Switching time (USUALLY NOT ASSESSED); Switching energy negligible in ad-hoc wireless network protocol assessment (e.g. WiFi);
Switching in standard wireless networks Is defined as the transition time that elapses between the end of a transceiver state and the beginning of the following one; Possible switching states consist of: RX/TX and TX/RX TX/Sleep and Sleep/TX RX/Sleep and Sleep/RX State transition is fast little amount of energy is consumed. Switching energy is much smaller than total energy spent.
Sensor network characteristics Energy consumption: primary objective The wake-up concept Very low duty cycle (even less than 5%) Small packets smaller than in ad-hoc networks (e.g. temperature data is few bytes) Low data traffic per node Can we consider switching energy still negligible for low duty cycle sensor networks?
Saving Energy Various protocols have been implemented to solve the problem of energy in Sensor networks CSMA- Periodic Listen and Sleep; Contention during listening Low-Power Listening (LPL)- Asynchronous Listening Scheduled Listening (S-MAC)- Maintaining Synchronization
Low-Power Listening (LPL) Reference:http://www.cse.wustl.edu/~lu/cs537s/Slides/scp.pdf
Scheduled Listening Reference:http://www.cse.wustl.edu/~lu/cs537s/Slides/scp.pdf
Scheduled Listening and LPL Scheduled listening Advantage efficient transmission Disadvantages- Synchronization overhead Listen interval is too long in existing protocols Low-Power Listening Advantage minimizes listen cost when no traffic Disadvantage high costs on transmission
Contention-based protocols MACA (Multiple Access Collision Avoidance) S-MAC (Sensor Multiple Access Control), T-MAC (Timeout-MAC) Preamble sampling, B-MAC (Berkeley MAC) PAMAS (power aware multi-access protocol with signaling)
Distributed, contention-based MAC Basic ideas for a distributed MAC ALOHA no good in most cases Listen before talk (Carrier Sense Multiple Access, CSMA) better, but suffers from sender not knowing what is going on at receiver, might destroy packets despite first listening for a Receiver. Additionally needs some possibility to inform possible senders in its vicinity about impending transmission (to shut them up for this duration) Hidden terminal scenario: A B C D
Main options to shut up senders Receiver informs potential interferers while a reception is on-going By sending out a signal indicating just that Problem: Cannot use same channel on which actual reception takes place! Use separate channel for signaling Busy tone protocol Receiver informs potential interferers before a reception is on-going Can use same channel Receiver itself needs to be informed, by sender, about impending transmission Potential interferers need to be aware of such information, need to store it
Receiver informs interferers before transmission MACA Sender B asks receiver C whether C is able to receive a transmission Request to Send (RTS) Receiver C agrees, sends out a Clear to Send (CTS) Potential interferers overhear either RTS or CTS and know about impending transmission and for how long it will last Store this information in a Network Allocation Vector B sends, C acks! MACA protocol (used e.g. in IEEE 802.11) NAV indicates busy medium A B C D RTS Data CTS Ack NAV indicates busy medium
RTS/CTS RTS/CTS improves performance, but do not solve hidden/exposed terminal problems Example problem cases: A B C D A B C D RTS RTS CTS RTS CTS RTS Data RTS Data CTS CTS Data Ack
MACA Problem: Idle listening Need to sense carrier for RTS or CTS packets In some form shared by many CSMA variants; e.g. not busy tones Simple sleeping will break the protocol IEEE 802.11 solution: ATIM windows & sleeping Basic idea: Nodes that have data buffered for receivers send traffic indicators at pre-arranged points in time Receivers need to wake up at these points, but can sleep otherwise Parameters to adjust in MACA Random delays how long to wait between listen/transmission attempts? Number of RTS/CTS/ACK re-trials?
Sensor-MAC (S-MAC) MACA s idle listening is particularly unsuitable if average data rate is low Most of the time, nothing happens Idea: Switch nodes off, ensure that neighboring nodes turn on simultaneously to allow packet exchange (rendez-vous) Only in these active periods, packet exchanges happen Need to also exchange wakeup schedule between neighbors When awake, essentially perform RTS/CTS Use SYNCH, RTS, CTS phases Wakeup period Sleep period Active period For SYNCH For RTS For CTS
S-MAC synchronized islands Nodes try to pick up schedule synchronization from neighboring nodes If no neighbor found, nodes pick some schedule to start with If additional nodes join, some node might learn about two different schedules from different nodes Synchronized islands To bridge this gap, it has to follow both schemes A A A A A A B B B B B E E E E E E E C C C C C D D D D Time
Timeout-MAC (T-MAC) In S-MAC, active period is of constant length What if no traffic actually happens? Nodes stay awake needlessly long Idea: Prematurely go back to sleep mode when no traffic has happened for a certain time (=timeout)! T- MAC Adaptive duty cycle! One ensuing problem: Early sleeping C wants to send to D, but is hindered by transmission A! B Two solutions exist! A B C D CTS May not send Timeout, go back to sleep as nothing happened
Solutions for early sleeping Future request-to-send (FRTS) Taking priority on full buffers
Future-Request-To-Send (FRTS) The idea is to let other node know that we still have a message for it, but are ourselves prohibited from using the medium. The FRTS packet contains the length of time for which communication is blocked. The node that receives the FRTS packet knows that it will be the future target of an RTS packet and must be awake by that time. When C overhears CTS packets coming from node B it will send FRTS packet to inform node D to wakeup when A s transmission to B is finished.
To avoid collision at B between data packet from A and FRTS packet from C, A transmits data-send (DS) packet of size equal to FRTS packet. DS has no useful info. After sending DS packet, A transmits its data packet to B. FRTS may result in more energy loss during high traffic.
Taking priority on full buffers This means that when a node receives an RTS packet destined for it, it immediately sends its own RTS packet to another node, instead of replying with a CTS like normal. It has two effects. First, the node has an even higher chance of transmitting its own message, since it effectively wins the medium upon hearing a competing RTS; node C may transmit to node D after losing contention to node B.
Secondly, the full-buffer priority scheme introduces a limited form of flow control into the network, which is advantageous in a nodes-tosink communication pattern; node B is prevented from sending until node C has enough buffer space Advantages: Probability of early sleeping problem is reduced. The scheme introduces limited flow control in the network. T-MAC uses a threshold: a node may only use this scheme when it has lost contention at least twice.
Preamble Sampling So far: Periodic sleeping supported by some means to synchronize wake up of nodes to ensure rendez-vous between sender and receiver Alternative option: Don t try to explicitly synchronize nodes Have receiver sleep and only periodically sample the channel In preamble sampling, nodes save energy by keeping their radios off most of the time to reduce idle listening. To receive frames, nodes periodically wake up for a short time to sample the channel to check whether there is an ongoing transmission on the channel.
A transmission is detected when a node finds that a preamble is being transmitted, in which case it keeps its radio on to receive the data frame that is sent just after the preamble. The preamble is used to indicate that a data frame will be transmitted and is long enough to make sure that all potential receivers wake up at least once during its transmission Use long preambles to ensure that receiver stays awake to catch actual packet Example: WiseMAC Start transmission: Long preamble Actual packet Check channel Check channel Check channel Check channel Stay awake!
B-MAC Combines several of the above discussed ideas Takes care to provide practically relevant solutions Clear Channel Assessment Adapts to noise floor by sampling channel when it is assumed to be free Samples are exponentially averaged, result used in gain control For actual assessment when sending a packet, look at five channel samples channel is free if even a single one of them is significantly below noise Optional: random backoff if channel is found busy Optional: Immediate link layer acknowledgements for received packets
B-MAC II Low Power Listening (= preamble sampling) Uses the clear channel assessment techniques to decide whether there is a packet arriving when node wakes up Timeout puts node back to sleep if no packet arrived B-MAC does not have Synchronization RTS/CTS Results in simpler, leaner implementation Clean and simple interface Currently: Often considered as the default WSN MAC protocol
Power Aware Multiaccess with Signaling PAMAS Idea: combine busy tone with RTS/CTS Results in detailed overhearing avoidance, does not address idle listening Uses separate data and control channels Procedure Node A transmits RTS on control channel, does not sense channel Node B receives RTS, sends CTS on control channel if it can receive and does not know about ongoing transmissions B sends busy tone as it starts to receive data Control channel Data channel RTS A! B CTS B! A Busy tone sent by B Data A! B Time
PAMAS Already ongoing transmission Suppose a node C in vicinity of A is already receiving a packet when A initiates RTS Procedure A sends RTS to B C is sending busy tone (as it receives data) C A CTS and busy tone collide, A receives no CTS, does not send data? B Control channel Data channel Busy tone by C RTS A! B CTS B! A No data! Time Similarly: Ongoing transmission near B destroys RTS by busy tone
Schedule-based protocols LEACH (Low Energy Adaptive Clustering Hierarchy) SMACS TRAMA (Traffic Adaptive Medium Access)
Low-Energy Adaptive Clustering Hierarchy (LEACH) Given: dense network of nodes, reporting to a central sink, each node can reach sink directly Idea: Group nodes into clusters, controlled by clusterhead About 5% of nodes become clusterhead (depends on scenario) Role of clusterhead is rotated to share the burden Clusterheads advertise themselves, ordinary nodes join CH with strongest signal Clusterheads organize CDMA code for all member transmissions TDMA schedule to be used within a cluster In steady state operation CHs collect & aggregate data from all cluster members Report aggregated data to sink using CDMA
LEACH rounds Fixed-length round.. Setup phase Steady-state phase.... Time slot 1 Time slot 2.. Time slot n Time slot 1.. Advertisement phase Cluster setup phase Broadcast schedule Self-election of clusterheads Clusterheads compete with CSMA Members compete with CSMA
SMACS Given: many radio channels, superframes of known length (not necessarily in phase, but still time synchronization required!) Goal: set up directional links between neighboring nodes Link: radio channel + time slot at both sender and receiver Free of collisions at receiver Channel picked randomly, slot is searched greedily until a collisionfree slot is found Receivers sleep and only wake up in their assigned time slots, once per superframe In effect: a local construction of a schedule
SMACS link setup Case 1: Node X, Y both so far unconnected Node X sends invitation message Node Y answers, telling X that is unconnected to any other node Node X tells Y to pick slot/frequency for the link Node Y sends back the link specification Case 2: X has some neighbors, Y not Node X will construct link specification and instruct Y to use it (since Y is unattached) Case 3: X no neighbors, Y has some Y picks link specification Case 4: both nodes already have links Nodes exchange their schedules and pick free slots/frequencies in mutual agreement X Type1 (X, unconnected) Type2(X, Y, unconnected) Type3 (Y, --) Type4(LinkSpec) Message exchanges protected by randomized backoff Y
TRAMA (Traffic Adaptive Medium Access) Nodes are synchronized Time divided into cycles, divided into Random access periods Scheduled access periods Nodes exchange neighborhood information Learning about their two-hop neighborhood Using neighborhood exchange protocol: In random access period, send small, incremental neighborhood update information in randomly selected time slots Nodes exchange schedules Using schedule exchange protocol Similar to neighborhood exchange
TRAMA adaptive election Given: Each node knows its two-hop neighborhood and their current schedules How to decide which slot (in scheduled access period) a node can use? Use node identifier x and globally known hash function h For time slot t, compute priority p = h (x t) Compute this priority for next k time slots for node itself and all twohop neighbors Node uses those time slots for which it has the highest priority Priorities of node A and its two neighbors B & C t = 0 t = 1 t = 2 t=3 t = 4 t = 5 A 14 23 9 56 3 26 B 33 64 8 12 44 6 C 53 18 6 33 57 2
TRAMA possible conflicts When does a node have to receive? Easy case: one-hop neighbor has won a time slot and announced a packet for it But complications exist compare example What does B believe? A thinks it can send B knows that D has higher priority in its 2-hop neighborhood! Rules for resolving such conflicts are part of TRAMA A D B C Prio 100 Prio 95 Prio 79 Prio 200
Comparison: TRAMA, S-MAC Comparison between TRAMA & S-MAC Energy savings in TRAMA depend on load situation Energy savings in S-MAC depend on duty cycle TRAMA (as typical for a TDMA scheme) has higher delay but higher maximum throughput than contention-based S-MAC TRAMA disadvantage: substantial memory/cpu requirements for schedule computation
Sensor MAC(S-MAC) protocol for WSN
Design Considerations of WSN Primary attributes: Energy Efficiency often difficult to recharge or replace batteries prolonging the network lifetime is important Scalability Some nodes may die or new nodes may join Secondary attributes: Fairness, latency, throughput and bandwidth
Sources of Energy Inefficiency Collision Overhearing Control packet overhead Idle listening
Existing MAC Design Contention-based protocols IEEE 802.11 Idle listening PAMAS heavy duty cycle of the radio, avoids overhearing, idle listening TDMA based protocols Advantages - Reduced energy consumption Problems requires real clusters, and does not support scalability
Design goal of S-MAC Reduce energy consumption Support good scalability Self-configurable
S-MAC Tries to reduce wastage of energy from all four sources of energy inefficiency Collision by using RTS and CTS Overhearing by switching the radio off when transmission is not meant for that node Control Overhead by message passing Idle listening by periodic listen and sleep
Is the improvement free of cost? No In exchange there is some reduction in perhop fairness and latency But does not reduce end-to-end fairness and latency Is it important for sensor networks?
Network Assumptions Composed of many small nodes deployed in ad hoc fashion Most communication will be between nodes as peers, rather than a single base station Nodes must self-configure
Application Assumptions Dedicated to a single application or a few collaborative application Involves in-network processing to reduce traffic and increase life time Applications will have long idle periods and can tolerate some latency
Components of S-MAC Periodic listen and sleep Collision and Overhearing avoidance Message passing
Periodic Listen and Sleep Each node goes into periodic sleep mode during which it switches the radio off and sets a timer to awake later When the timer expires, it wakes up Selection of sleep and listen duration is based on the application scenarios Neighboring nodes are synchronized together
Contd. Nodes exchange schedules by broadcast Multiple neighbors contend for the medium Once transmission starts, it does not stop until completed A B C D
Choosing and Maintaining Schedules Each node maintains a schedule table that stores schedules of all its known neighbors. To establish the initial schedule (at the startup) following steps are followed: A node first listens for a certain amount of time. If it does not hear a schedule from another node, it randomly chooses a schedule and broadcast its schedule immediately. This node is called a SYNCHRONIZER.
If a node receives a schedule from a neighbor before choosing its own schedule, it just follows this neighbor s schedule. This node is called a FOLLOWER and it waits for a random delay and broadcasts its schedule. 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.
Rules for Joining a New Node Listen for a long time until an active node is discovered Send INTRO packet to the active node Active node forwards its schedule table Treat all the nodes on table as potential neighbors and contact them later If possible follow the synchronizer s schedule else establish a random schedule and broadcast the schedule
Maintaining Synchronization Timer synchronization among neighbors are needed to prevent the clock drift. Done by periodic updating using a SYNC packet. Updating period can be quite long as we don t require tight synchronization. Synchronizer needs to periodically send SYNC to its followers. If a follower has a neighbor that has a different schedule with it, it also needs update that neighbor.
Time of next sleep is relative to the moment that the sender finishes transmitting the SYNC packet Receivers will adjust their timer counters immediately after they receive the SYNC packet Listen interval is divided into two parts: one for receiving SYNC and other for receiving RTS
Timing Relationship of Possible Situations
Collision Avoidance Similar to IEEE802.11 using RTS/CTS mechanism Perform carrier sense before initiating a transmission If a node fails to get the medium, it goes to sleep and wakes up when the receiver is free and listening again Broadcast packets are sent without RTS/CTS Unicast packets follow the sequence of RTS/CTS/DATA/ACK between the sender and receiver
Overhearing Avoidance Duration field in each transmitted packet indicates how long the remaining transmission will be. So if a node receives a packet destined o another node, it knows how long it has to keep silent. The node records this value in network allocation vector (NAV) and set a timer.
When a node has data to send, it first looks at NAV. If NAV is not zero, then medium is busy (virtual carrier sense). Medium is determined as free if both virtual and physical carrier sense indicate the medium is free. All immediate neighbors of both the sender and receiver should sleep after they hear RTS or CTS packet until the current transmission is over.
Message Passing A message is a collection of meaningful, interrelated units of data Transmitting a long message as a packet is disadvantageous as the re-transmission cost is high Fragmentation into small packets will lead to high control overhead as each packet should contend using RTS/CTS
Solution Fragment message in to small packets and transmit them as a burst Advantages Reduces latency of the message Reduces control overhead Disadvantage Node-to-node fairness is reduced, as nodes with small packets to send has to wait till the message burst is transmitted
Naming and Addressing
Names vs. addresses Name: Denote/refer to things Nodes, networks, data, transactions, Often, but not always, unique (globally, network-wide, locally) Ad hoc: nodes WSN: Data! Addresses: Information needed to find these things Street address, IP address, MAC address Often, but not always, unique (globally, network-wide, locally) Addresses often hierarchical, because of their intended use in, e.g., routing protocols Services to map between names and addresses E.g., DNS Sometimes, same data serves as name and address IP addresses are prominent examples
Fundamentals Unique Node Identifier (UID): It is a persistent data item unique for each node. E.g. Vendor name, product name, serial number MAC address: Used to distinguish between one-hop neighbors of a node. Imp. in contention based MAC protocols Including MAC add. Into unicast MAC packets, a node can determine which packets are not destined to it & go into sleep mode while such packet is in transit. OVERHEARING AVOIDANCE.
Network Address: It is used to find and denote a node over multiple hops; connected to routing. Network identifiers: In geographically overlapping WSN of the same type & working in same frequency band, distinguishing is done by network identifiers. E.g. medical body area sensor networks for clinical patients in the same room have to be distinguished to prevent confusion of sensor data belonging to different patients.
Resource identifiers: A name or resource identifier is represented in userunderstandable term or in the way that means something to the user. E.g. after reading www.gmail.com, an experienced reader knows that it refers to the web server In contrast, by looking at IP address 199.184.165.136, hardly anyone can draw conclusion.
Issues in address management Address allocation: Assign an entity an address from a given pool of possible addresses Distributed address assignment (centralized like DHCP does not scale) Address deallocation: Once address no longer used, put it back into the address pool Because of limited pool size Graceful or abrupt, depending on node actions Address representation Conflict detection & resolution (Duplicate Address Detection) What to do when the same address is assigned multiple times? Can happen e.g. when two networks merge Binding Map between addresses used by different protocol layers E.g., IP addresses are bound to MAC address by ARP
Uniqueness of addresses 1. Globally unique: A globally unique address or identifier is supposed to occur at most once all over the world. E.g. the 48-bit IEEE MAC addresses used in Ethernet and Token Ring networks. The binary representation of such addresses must be sufficiently large to accommodate all devices worldwide.
2. Networkwide unique: A networkwide unique address is supposed to be unique within a given network, but the same address can be used in different networks. By having different networks A and B, we mean that there is no pair of nodes a A and b B that can communicate
3. Locally unique: A locally unique address might occur several times in the same network, but it should be unique within a suitably defined neighborhood E.g. In a sensor network that have different sensor types like temperature, humidity, and light sensors. We might require that no two temperature sensors have the same address but a temperature and a humidity sensor may. In this case, the neighborhood is constituted by the sensors of the same type.
Address allocation and assignment The address assignment can happen a priori (e.g. during the manufacturing process or before network deployment) or on demand, by using an address assignment protocol. Such an on-demand address assignment protocol can be either centralized or distributed. In a centralized solution, there is one single authority/node taking care of (parts of) the address pool. In distributed solutions, there is no such exposed node. Instead, potentially all nodes play the same role in address assignment. Address release/deallocation plays an important role when networkwide or locally unique addresses are assigned on demand.
Duplicate Address Detection (DAD) In distributed address assignment networkwide uniqueness may not be granted at all times Strong DAD If address x is assigned to A at time t0 and to B at time t1, the conflict must be detected within t1+t, where T is some fixed time bound Weak DAD Duplicate addresses are tolerated as long as they do not distort ongoing sessions.
Address and name management in wireless sensor networks
MAC addresses are indispensable if the MAC protocol shall employ overhearing avoidance and go into sleep mode as often as possible. However, do MAC addresses need to be globally or networkwide unique? No, since the scope of a MAC protocol is communication between neighboring nodes and it is sufficient that addresses are locally unique within a two-hop neighborhood. This requirement ensures that no two neighbors of a selected node have the same MAC address. Locally unique addresses potentially are short but need an address assignment protocol.
How about higher-layer addresses, specifically network layer addresses, which for traditional routing protocols must be globally or networkwide unique? Fulfilling this requirement is a formidable task. This requirement is not really necessary in wireless sensor networks since after all the whole network is not a collection of individual nodes belonging to individual users but the nodes collaborate to process signals and events from the physical environment. Users ultimately are interested in the data and not in the individual or groups of nodes delivering them. Taking this a step further, the data can also influence the operation of protocols, which is the essence of data-centric networking.