340 likes | 518 Views
Multipath Multimedia Transmission in MANETs SWAN & NOMAD. Marcin Michalak michalak@iam.unibe.ch. Agenda. Basic questions and assumptions Discussed Scenario Related work: SWAN: Stateless Wireless Ad-hoc Networks NOMAD: Filters for Mobile IP Role of Layers Network/Application interaction
E N D
Multipath Multimedia Transmission in MANETsSWAN & NOMAD Marcin Michalak michalak@iam.unibe.ch
Agenda • Basic questions and assumptions • Discussed Scenario • Related work: • SWAN: Stateless Wireless Ad-hoc Networks • NOMAD: Filters for Mobile IP • Role of Layers • Network/Application interaction • Summary & Goals • Questions
Basic questions • how to effectively transfer real-time (multimedia) traffic in mobile ad-hoc networks? • how to cater for: • mobility • highly unreliable, shared medium • changing conditions
Assumptions • Practical approach: • changing network as little as possible • some nodes may not be improvement-aware (transparent) • no heavy QoS infrastructure • good quality at low cost
Discussed scenario • streaming live video • RTP/UDP transport • multipath routing • mobile ad-hoc network
SWAN • Stateless Wireless Ad-hoc Networks • intermediate nodes don’t keep per-flow or aggregate state information • differentiate real-time and best-effort traffic • QoS-capable MAC not needed • AIMD algorithm (+ * - like TCP window) • uses feedback information (ECN – explicit congestion notification) http://comet.ctr.columbia.edu/swan/
SWAN - principles • rate control: per-hop MAC delay measurements, performed locally at every node • source-based admission control: aggregated real-time traffic info • implemented in ns-2 and Linux/AODV
SWAN operation • classifier: differentiates RT and BE packets • shaper: • processes BE packets (leaky bucket) • delays them (rate) • no admission control in intermediate nodes • admission controller: • estimates local bw • sends probe
SWAN – rate control • each node independently regulates best effort traffic • packet delay -> shaper (from MAC ACK) • local-rate control for best-effort traffic • quickly adapts to changes
SWAN – AIMD rate control algorithm if (n > 0) s= s * (1 – r/100); else s= s+c; if ((s-a) > a * g/100) s=a*(1+g/100); Procedure called every T seconds: 1+ packets have delays > threshold decrease r% increase by c kbps shaping rate – actual rate > g% of actual rate – adjust
SWAN – admission control • task: efficiently estimate local bandwidth availability • listen to medium and measure RT traffic rate (running average) • sender-based admission control -> real-time • + dynamic regulation of real-time traffic
SWAN: Admission control procedure S UDP bw=? • S sends a probe packet -> D • estimate bw available • UDP with bottleneck bw field • intermediate nodes update field • no bw reservation • admission? of the flow UDP bw=8 UDP bw=8 UDP D bw=6
SWAN – regulation algorithm • each node measures continuously utilization of its real-time traffic • congestion detected: mark ECN bits destination • destination notifies source • reestablishment of the session
SWAN – network map update bw mark ECN regulate bw drop flow check bw find route admit? flow regulate bw
SWAN - simulations • ns-2 • 50 nodes, 1500 x 300m • 4 voice (32 kbps), 4 video (200kbps) flows • video: MPEG-1 stream • background: TCP mixture of FTP/Web • mobility: • random waypoint model • speed up to 72km/h • node chooses destination, moves, pauses when reached • average 3 hops
SWAN - results • RT Delay below 8 ms (33-77% better) • -> 15-20% less TCP traffic • Much lower jitter
SWAN – impact on mobility • RT traffic delay much lower and more constant • sacrifices TCP traffic Average RT Traffic Delay (ms) Average TCP goodput (kbps)
SWAN – advantages and results • simple & fast • effective: • lower delay & jitter for RT traffic • TCP-friendly • works with mobility & ad-hoc • no complex signalling mechanism • Questions & ideas: • how does it behave when implemented partially? • applying multipath – multiflow? • interaction with applications?
NOMAD: Mobile IP and ad-hoc • NOMAD: IST project: Uni Bremen, Telscom, HUT, OTE, T-SYSTEMS and MARAC • Filters developed by COMNETS-ikom from University of Bremen • Filters for Mobile IP: 2 IETF drafts (v4 and v6) • NOMADHOC draft • Purpose: • simultaneous use of multiple points of attachment on a single Mobile Device • distribution of multiple flows • distribution of single flow GPRS UMTS
NOMAD - Modes of operations Reg. Reg. Reg. Filter FC Filter Proto=udp & Proto=udp & Port=5000 Weight=20 Port=5000 Weight=80 Weight=0 Index=1 Index=1 Index=1 Multiple Flow Distribution Single Flow Distribution Flow Drop
Filter Modules • Types of Filter Modules • DSCP / Flow Label , Traffic Class • Protocol Number • Source Address • Source Network • Source Port Number • Source Port Number Range • Destination Port Number • Destination Port Number Range • Free form, specifies the value of an area anywhere within the packet • OR between Filter Module Predicates (src port == 500 || 600) • AND between Filter Modules (proto == udp & src port == 500) • OR between Filters (src port == 500 || src port == 600)
NOMADHOC Extensions: AODV Enabling Multiple Paths • F bit on RREQ & RREP Processing Filters • By Source (RREP-ACK, F bit on) • Filter extensions are attached to the RREP-ACK • Destination applies reverse filtering • No changes apply to intermediate nodes draft-nomadhoc-manet-filters-00.txt
Adaptation of Layers How are layers affected by the new approach? Application Layer MDC (video) Session Layer m+RTP (multipath) Transport Layer UDP Network Layer AOMDV+ NOMAD Link Layer 802.11
Application • make it ad-hoc aware: • wireless • mobility • multipath • how to do it? • multipath multimedia encoding • Multiple Description Coding (MDC) Application Layer Session Layer Transport Layer Network Layer Link Layer
Session + Transport • meta-RTP/UDP: • resequencing at the receiver • react on link changes using RTCP messages • more frequent than in wired networks • to be continued... Application Layer Session Layer Transport Layer Network Layer Link Layer
Network • IP + AOMDV (or another multipath) • NOMAD filters for flows distribution (multi- path/interface) • allocation + admission of flows (SWAN): • how to recognize them? • how to interact with application? Application Layer Session Layer Transport Layer Network Layer Link Layer
Link Layer • WLAN 802.11(b) • shared medium • no control • adaptation to changing conditions possible • ACKs • delay can be computed (SWAN) -> available bandwidth Application Layer Session Layer Transport Layer Network Layer Link Layer
Networkapplication interaction Application Application mark flows indicate flow priority (indicate flow band width) • Protocol: • transparent for the network • stateless • light admit/reject flows congestion info (bandwidth left) Network Network
4 bits Version = 6 8 bits Traffic class 20 bits Flow label 16 bits Payload length 8 bits Next header 8 bits Hop Limit 128 bits Source Address 128 bits Destination Address Flows and distribution • 2 flows: • enough distribution • more: too much overhead, hard to find/keep independent 2+ routes • flow label to indicate (sub)flows • process ID (16 bits) + flow ID (4 bits) • odd/even flows: different paths (e.g. 2x video + 2x audio) (+ TOS/Traffic class to indicate RT data) 8 bits Traffic class 20 bits Flow label IPv6 header
Summary • SWAN: • flow admission • flow control • effect: • decreases delay & jitter • NOMAD filters – flow distribution across: • multipath • multiple interfaces • application-network interaction • flow indication (flow label) • congestion indication
Goals • creating complete architecture: • SWAN • NOMAD extensions • user/application/network interaction • making it work
Related Topics • load balancing • QoS • Policy Routing, Active Routing • Internet Gateways for ad-hoc