1 / 46

MAC Protocol for PAN

MAC Protocol for PAN. Medium Access Control (MAC ). Controlling when to send a packet and when to listen for a packet are perhaps the two most important operations in a wireless network Especially, idly waiting wastes huge amounts of energy

irenemoore
Télécharger la présentation

MAC Protocol for PAN

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. MAC Protocol for PAN

  2. Medium Access Control (MAC) • Controlling when to send a packet and when to listen for a packet are perhaps the two most important operations in a wireless network • Especially, idly waiting wastes huge amounts of energy • This chapter discusses schemes for this medium access control that are • Suitable to mobile and wireless networks • Emphasize energy-efficient operation

  3. Overview • Principal options and difficulties • Contention-based protocols • Schedule-based protocols • IEEE 802.15.4

  4. Main options Wireless medium access Centralized Distributed Schedule-based Contention-based Contention-based Schedule-based Fixedassignment Demandassignment Fixedassignment Demandassignment

  5. Principal options and difficulties • Medium access in wireless networks is difficult mainly because of • Impossible (or very difficult) to send and receive at the same time • Interference situation at receiver is what counts for transmission success, but can be very different from what sender can observe • High error rates (for signaling packets) compound the issues • Requirement • As usual: high throughput, low overhead, low error rates, … • Additionally: energy-efficient, handle switched off devices!

  6. Requirements for energy-efficient MACprotocols • Recall • Transmissions are costly • Receiving about as expensive as transmitting • Idling can be cheaper but is still expensive • Energy problems • Collisions – wasted effort when two packets collide • Overhearing – waste effort in receiving a packet destined for another node • Idle listening – sitting idly and trying to receive when nobody is sending • Protocol overhead • Always nice: Low complexity solution

  7. Centralized medium access • Idea: Have a central station control when a node may access the medium • Example: Polling, centralized computation of TDMA schedules • Advantage: Simple, quite efficient (e.g., no collisions), burdens the central station • Not directly feasible for non-trivial wireless network sizes • But: Can be quite useful when network is somehow divided into smaller groups • Clusters, in each cluster medium access can be controlled centrally – compare Bluetooth piconets, for example  Usually, distributed medium access is considered

  8. Schedule- vs. contention-based MACs • Schedule-based MAC • A schedule exists, regulating which participant may use which resource at which time (TDMA component) • Typical resource: frequency band in a given physical space (with a given code, CDMA) • Schedule can be fixed or computed on demand • Usually: mixed – difference fixed/on demand is one of time scales • Usually, collisions, overhearing, idle listening are not issues • Needed: time synchronization! • Contention-based protocols • Risk of colliding packets is deliberately taken • Hope: coordination overhead can be saved, resulting in overall improved efficiency • Mechanisms to handle/reduce probability/impact of collisions required • Usually, randomization used somehow

  9. Overview • Principal options and difficulties • Contention-based protocols • MACA • S-MAC, T-MAC • Preamble sampling, B-MAC • PAMAS • Schedule-based protocols • IEEE 802.15.4

  10. ALOHA • The simplest possible medium access protocol: Just talk when you feel like it • Formally: Whenever a packet should be transmitted, it is transmitted immediately • Introduced in 1985 by Abrahmson et al., University of Hawaii • Goal: Use of satellite networks Packets are transmitted at arbitrary times

  11. ALOHA network – Multiple Access • The earliest random-access method, was developed at the • Univ. of Hawaii in the early 1970s. • Base station is central controller • Base station acts as a hop • Potential collisions, all incoming data is @ 407 MHz

  12. ALOHA • Pure ALOHA Random Access • Each station sends a frame whenever it has a frames to send. • However, there is only one channel to share, there is the possibility of collision between frames from different stations. Frames in a pure ALOHA network

  13. ALOHA Procedure for pure ALOHA protocol

  14. ALOHA – Analysis • ALOHA advantages • Trivially simple • No coordination between participants necessary • ALOHA disadvantages • Collisions can and will occur – sender does not check channel state • Sender has no (immediate) means of learning about the success of its transmission – link layer mechanisms (ACKs) are needed • ACKs can collide as well 

  15. ALOHA – Performance • Assume a Poisson arrival process to describe packet transmissions • Infinite number of stations, all behave identically, independently • Time between two attempts is exponentially distributed • Let G be the mean number of transmission attempts per packet length • All packets are of unit time length • Then: • For a packet transmission to be successful, it must not collide with any other packet • How likely is such a collision? • Question: How long is a packet “vulnerable” by other transmissions?

  16. ALOHA – Performance • A packet X is destroyed by another packet either • Starting up to one packet time before X • Starting up to immediately before the end of X • Hence: Packet is successful if there is no additional transmission in two packet times • Probability: P0 = P (1 transmission in two packet times) = 2Ge-2G • Throughput S (G) = 1 Packet / 2 time units * Probability = Ge-2G • Optimal for G = 0.5, S = 1/(2e) = 1/(2*2.718) = 0.185

  17. A slight improvement: Slotted ALOHA • ALOHA’s problem: Long vulnerability period of a packet • Reduce it by introducing time slots – transmissions may only start at the start of a slot • Slot synchronization is assumed to be “somehow” available • Result: Vulnerability period is halved, throughput is doubled • S(G) = Ge-G • Optimal at G=1, S=1/e

  18. Slotted ALOHA • Slotted ALOHA • We divide the time into slots of Tfr s and force the station to send only at the beginning of the time slot.

  19. Note Slotted ALOHA The throughput for slotted ALOHA is S = G × e−G . The maximum throughput Smax = 0.368 when G = 1. • S is the average number of successful transmissions, called throughput. • G is the average number of frames generated by the • system during one frame transmission time.

  20. Slotted ALOHA • Slotted ALOHA vulnerable time = Tfr Vulnerable time for slotted ALOHA protocol

  21. S 1 1 G Performance dependence on offered load • For (slotted) ALOHA, closed form analysis of throughput S as function of G is simple ! Anything but a high-performance protocol • In particular: throughput collapses as load increases! Ideal

  22. CAMA/CA and NAV DIFS – distributed interframe space, NAV – network allocation vector SIFS – short interframe space, RTS – request to send, CTS – clear to send * Collision only occurs during handshake period (RTS, CTS)

  23. 802.11 RTS : Request to Send CTS : Clear to Send ACK : Acknowlegment DIFS : Distributed Interframe Space SIFS : Short Interfrace Space

  24. A B C Problems for the MAC-Protocol • Hidden Terminal Problem • Exposed Terminal Problem A B C D

  25. Exposed Terminal Problem

  26. 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.  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: Also: recall exposed terminal scenario A B C D

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

  28. Multiple Access with Collision Avoidance (MACA) • Sender B asks receiver C whether C is able to receive a transmissionRequest 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)

  29. RTS/CTS • RTS/CTS ameliorate, but do not solve hidden/exposed terminal problems • Example problem cases:

  30. MACA Problem: Idle listening • Need to sense carrier for RTS or CTS packets • In some form shared by many CSMA variants; but e.g. not by busy tones • Simple sleeping will break the protocol • IEEE 802.11 solution: ATIM (Ad-hoc Traffic Indication Message) 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? • …

  31. STEM Sparse Topology and Energy Management Protocol • A node periodically wakes up to listen to the wakeup channel, and keeps awake upon receiving a wakeup packet intended for itself. • The wakeup packets are sent by some nodes that have packets to send. • Two channels • Wakeup channel • On the wakeup channel data is announced • Data Channel • Otherwise the data channel is always in sleep mode • Status of a sensor • Monitor state • nodes are idle, no transmission • Transfer state • STEM-B • Transmitter wakes up the receiver by a beacon on the wakeup channel • no RTS/CTS • STEM-T • Transmitter sends busy tone signal on the wakeup channel to get the receiver‘s attention

  32. 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 (rendezvous) 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 Sensor-MAC (S-MAC)

  33. S-MAC Frames • S-MAC adopts a message passing concept • long messages are broken into small frames • only one RTS/CTS communication for each messages • each frame is acknowledged separately • each frame contains the information about the message length • The NAV (not available) variable of suppressed neighbors is adjusted appropriately • Problems: Fairness

  34. Mediation Device Protocol • Goal: Avoid useless listening on the channel for messages • Uses: mediation device (MD) which is available all the time • Protocol • Sender B sends RTS to MD • MD stores this information • Receiver C sends query to MD • MD tells reciever C when to wake up • C sends CTS to B (now in sync) • B sends data • C acknowledges • C returns to old timing • Main disadvantage: • MD has to be energy independent • Solution: Distributed Mediation Device Protocol • Nodes randomly wake up and serve as mediation device • Problem: no guarantees on full coverage of MD

  35. B-MAC (Berkeley MAC) • Combines several of the above discussed ideas • Takes care to provide practically relevant solutions • Clear Channel Assessment (CCA) • 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 (by multiple senders): random backoff if channel is found busy • Optional: Immediate link layer acknowledgements for received packets

  36. B-MAC • Low Power Listening • 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 implementation • Clean and simple interface Currently: Often considered as the default WSN MAC protocol

  37. B-MAC Sender Sleep Preamble Message t Receiver Sleep Sleep Receive t Asynchronously maintained wake-up period

  38. CSMA • State diagram of CSMA sender

  39. Power Aware Multi-Access 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 DATA 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 Controlchannel Busy tone sent by B RTS A  B CTS B  A Time Data A  B Datachannel

  40. B ? C A 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) • CTS and busy tone collide, A receives no CTS, does not send data Busy tone by C Controlchannel RTS A  B CTS B  A Time Datachannel No data!

  41. Overview • Principal options and difficulties • Contention-based protocols • Schedule-based protocols • LEACH • IEEE 802.15.4

  42. 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 • Setup phase; details: later • 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

  43. LEACH rounds

  44. IEEE 802.15.4 • IEEE standard for low-rate WPAN applications • Goals: low-to-medium bit rates, moderate delays without too stringent guarantee requirements, low energy consumption • Physical layer (27 channels) • 20 kbps over 1 channel @ 868-868.6 MHz • 40 kbps over 10 channels @ 905 – 928 MHz • 250 kbps over 16 channels @ 2.4 GHz • MAC protocol • Single channel at any one time • Combines contention-based and schedule-based schemes • Asymmetric: nodes can assume different roles

  45. IEEE 802.15.4 MAC overview • Star networks: devices are associated with coordinators • Forming a PAN, identified by a PAN identifier • Coordinator • Bookkeeping of devices, address assignment, generate beacons • Talks to devices and peer coordinators • Beacon-mode superframe structure • GTS assigned to devices upon request

  46. Thank you ! Q & A

More Related