CMPE 257: Wireless and Mobile Networking

Transcription

1 CMPE 257: Wireless and Mobile Networking Katia Obraczka Computer Engineering UCSC Baskin Engineering Lecture 4 1

2 Announcements Project proposals. Due April 17 th. Submit by to attachment (plain text or pdf) Exam: May 14 (tentative). 2

3 Student Presentations Suggested topics/speakers: IoT (Anuj?) Mobility management/characterization (Larissa?) Security Energy management SDN (Ben?) Location management 3

4 Today MAC (cont d). 4

5 MACAW [Bharghavan, 1994]. Proposed as improvement to MACA [Karn, 1990]. Note that first IEEE standard (IEEE legacy ) released in Both MACA and MACAW are precursors of

6 MACA Multiple Access Collision Avoidance (MACA). Proposed as alternative to CS in CSMA. Contention at receiver, not at sender. Introduced CA. MACA does not use CS. RTS/CTS handshake (2-way). 6

7 MACA If node A wants to transmit to B, it first sends an RTS packet to B, indicating the length of the data transmission to follow. B returns a CTS packet to A with the expected length of the transmission. A starts transmission when it successfully receives CTS. RTS and CTS packets are much shorter than data packets. A neighboring node overhearing an RTS defers its own transmission until the corresponding CTS would have been finished. A node hearing the CTS defers for the expected length of the data transmission. 7

8 MACA (Cont d) Nodes close to sender: If no CTS heard, OK to transmit. Why? Avoid exposed terminal problem: nodes that hear only RTS can transmit simultaneously with RTS sender. Nodes close to receiver: Upon hearing CTS, defer till after data. Avoid hidden terminal. Binary exponential back-off (BEB). 8

9 MACAW Inspired basic changes to MACA: Additional signaling. Modified backoff algorithm. 9

10 MACA s BEB BEB = binary exponential back-off. Back-off timer doubled at every collision. Reduced to default value after successful RTS-CTS exchange. Possible unfair channel allocation (starvation). 10

11 MACAW Backoff Tries to avoid BEB s unfairness. Proposed fix: sharing congestion information among nodes. Backoff counter information propagated in packet header. After successful transmission, neighbors have the same backoff counter. 11

12 Backoff Timer Adjustment MACA adjusts backoff timer fairly quickly. MACAW tries to prevent large variations of the back-off value. Uses multiplicative increase and linear decrease (MILD). Upon collision, back-off timer multiplied by 1.5. Upon successful transmission, decremented by 1. 12

13 Data Transmission in MACAW Added ACK. Reliability at layer 2. If ACK not received: Retransmit frame. Increment back-off timer if RTS-CTS unsuccessful. 13

14 Data Transmission in MACAW Added small Data Sending (DS) control frame. Addresses exposed terminal problem. In MACA, exposed node (received RTS but not CTS) is allowed to transmit. Example: S1->R1 and S2->R2 CTS from R2 may collide with transmission S1->R1. S2 does not get CTS from R2 and backs-off. Fix: make sure S2 knows RTS-CTS exchange between S1 and R1 was successful. S1 sends small control frame, DS, before sending data. DS contains data exchange duration. When S2 receives DS, defers its transmission. R1 S1 S2 R2 14

15 Data Transmission in MACAW Added Request for Request-to-Send (RRTS). R2 contends on behalf of S2 if it received RTS from S2 and it could not have responded because deferring due to S1->R1 exchange. When S2 receives RRTS from R2, proceeds with RTS. Stations overhearing the RRTS defer long enough to hear successful RTS-CTS. RRTS RRTS S2 R2 R1 S1 15

16 FAMA 16

17 FAMA Protocols Floor Acquisition Multiple Access. Floor acquisition = gain control of channel. Assumptions: Single-channel, asynchronoustransmission systems. Floor acquisition: Packet sensing: Aloha style RTS transmission. Carrier sensing `a la CSMA. 17

18 FAMA Protocols MACA is an example of a FAMA protocol. Floor acquisition on packet-by-packet basis. No physical CS; only virtual CS. RTS/CTS exchange. RTS is sent using Aloha. 18

19 FAMA Paper (Garcia-Luna et al.) Floor acquisition strategy that use: Carrier sensing Receiver-based busy tone mechanism End result: priority to stations that successfully complete RTS-CTS handshake. 19

20 FAMA-NPS FAMA non-persistent packet sensing. No carrier sensing, i.e., MACA. Uses ALOHA to transmit RTS. RTS duration = 2*channel maximum propagation delay. Ensures so data does not collide with RTS- CTS. 20

21 FAMA-NCS Non-persistent CS + RTS/CTS. Non-persistent CS using uniform distribution of back-off. CTS dominance Length of CTS > RTS + 1 max RTT. CTS dominates in its neighborhood in case of RTS being transmitted concurrently. Dominating CTS like a busy tone. 21

22 CTS Dominance 22

23 Schedule-Based MACs: TRAMA, DYNAMMA, Soft-TDMAC Slides adapted from Vladi Petkov s presentation 23

24 What s schedule-based MAC? How is it different from random access MAC? 24

25 Outline TRAMA and DYNAMMA Common features TRAMA protocol description DYNAMMA protocol description Results comparison Soft-TDMAC 25

26 Features of TRAMA and DYNAMMA Common to both Schedule based data transmission Energy-efficient Use of 2-hop neighborhood information TRAMA! Application independent! Explicit schedules! Single channel DYNAMMA! Application independent! Flow-based! Multi-channel 26

27 The need for 2-hop neighborhoods: Hidden terminals 27

28 The need for 2-hop neighborhoods: Hidden terminals 28

29 The need for 2-hop neighborhoods: Who else can transmit? 29

30 The need for 2-hop neighborhoods: They can 30

31 The need for 2-hop neighborhoods: How could they know? 31

32 Neighborhood-aware contention Resolution (NCR) Presented in A New Approach to Channel Access Scheduling for Ad Hoc Networks Determines priority allocation for each contending entity Different for each contention context (slot) Respected by all other contending entities NCR algorithm 32

33 TRAMA Overview Random access mode Permits node join/leave Contention based access Sized according to how dynamic and number of nodes Neighbor Protocol runs in this mode Scheduled access mode Adaptive Election Algorithm Schedule Exchange Protocol Data transfer 33

34 TRAMA Neighbor Protocol! Gathers neighborhood information by exchanging signaling packets 34

35 TRAMA Schedule Exchange Protocol Maintains traffic-based schedule information Transmitter for slot re-use. Receiver: power efficiency. 35

36 TRAMA Schedule Exchange Protocol 1. SCHEDULE_INTERVAL determined from application traffic generation 2. Node computes winning slots (highest priority among 2-hop neighbors) 3. Node announces receivers for the slots or gives up vacant slots (bitmap scheme allows broadcast and multicast) 4. Last slot in interval is reserved for broadcasting next interval s schedule 36

37 TRAMA Adaptive Election Algorithm Node u s priority at time t determined by: This priority is used by the SEP to determine winning slots At any give time slot, t, node u is in: TX if u has highest priority in 2-hop neighborhood and has data to send RX if it is intended receiver of the current transmitter SL otherwise Why is this important? 37

38 DYNAMMA Overview! Dynamically adapts to traffic patterns! Collision-free multi-channel operation! Minimum signaling overhead 38

39 DYNAMMA Functional elements Traffic and Neighbor Discovery Happens in signaling slots (all nodes awake) Signaling packet holds: Superframe ID Location of signaling slot within superframe One-hop neighborhood information Traffic information Distributed scheduling algorithm Gather active contending flows for this timeslot Compute flow priorities Examine and schedule flows starting at highest priority rather involved see paper for details 39

40 DYNAMMA Traffic classification! Flows are put into the 3 classes depending on their arrival and service rates 40

41 Results outline TRAMA Synthetic traffic scenario Sensor network data-sink scenarios DYNAMMA Synthetic traffic scenario Sensor network data-sink scenario Testbed experiments 41

42 TRAMA Evaluation Simulation setup TRAMA compared to: NAMA, , CSMA, SMAC Synthetic data generation Each node sends to randomly chosen neighbor Poisson data sources Data-gathering scenario Data sink periodically requests data from all sensors 42

43 TRAMA Synthetic traffic delivery and delay 43

44 TRAMA Synthetic traffic energy consumption 44

45 TRAMA Data gathering corner and center sink 45

46 TRAMA Data gathering edge sink 46

47 TRAMA Data gathering energy consumption 47

48 DYNAMMA Delivery ratio and delay 48

49 DYNAMMA Energy consumption 49

50 DYNAMMA Testbed implementation 50

51 Differences and similarities 51

52 Soft-TDMAC Paper contributions " Present Soft-TDMAC Software TDMA-based multi-hop MAC protocol " Achieve microsecond precision networkwide synchronization Better than any previously achieved on top of commodity hardware 52

53 Soft-TDMAC Paper contributions (cont d) " Present an extensible Linux MAC implementation architecture MAC protocol coded in userspace software module Not dependent on hardware timers With small modification will work on any hardware 53

54 Soft-TDMAC Structure Time slot width: T s = 16us One slot fits: 12 6Mbps Mbps Control TxOp: 20 slots Data TxOp: variable 54

55 Soft-TDMAC Linux Architecture Kernel module 55 High Resolution Timers requires fully preemptible, real-time kerne

56 Soft-TDMAC Linux Architecture Userspace library 56

57 Soft-TDMAC Linux Architecture Userspace MAC implementation 57

58 Soft-TDMAC Testbed HP nc6000 laptops Atheros AR5212 cards Linux kernel MadWifi driver modified for debugging/profiling 58