univ. of tehran wireless ad hoc networkingwireless ad hoc networks1univ. of tehran1 special topics...

Univ. of Tehran

Wireless Ad hoc NetworkingWireless Ad Hoc

Networks 1Univ. of Tehran 1

Special TopicsSpecial Topics on on

Wireless Ad-hoc Wireless Ad-hoc NetworksNetworks

University of TehranDept. of EE and Computer Engineering

By:Dr. Nasser Yazdani

Lecture 11: Quality of Quality of Services on Wireless Services on Wireless

NetworksNetworks

Univ. of Tehran Wireless Ad hoc Networking 2Univ. of Tehran 2

Covered topicsCovered topics How to support real-time applications on

wireless network? References

Chapter 6 of the book

“Protection and Guarantee for Voice and Video Traffic in IEEE 802.11e Wireless LANs” by Yang Xiao, Haizhon Li and Sunghyun Choi.


OutlineOutline Quality of Service QoS on IP networks:

Integrated Services Differentiated Services

QoS on Wireless Link QoS Routing Cross layer Design

Univ. of Tehran Wireless Ad hoc Networking 4

What is QoS? Many views. User Satisfaction, etc. Some applications require “deliver on time” assurances

must come from inside the network

Example application (audio) sample voice once every 125us each sample has a playback time packets experience variable delay in network add constant factor to playback time: playback point

Microphone

Speaker

Sampler,

A D

converter

Buffer,

D A


Applications? Elastic (delay-tolerant)

Tolerate delays and losses Can adapt to congestion

Non-elastic (Real-Time) Needs some kind of guarantee from network

Main Question? How guarantee Delay and losses End to End, is it enough? In the Network

QoS Parameters Bandwidth Latency Jitter Loss


Utility Curve Shapes

BW

U

BW

U

BW

U

Elastic Hard real-time

Delay-adaptive


General view QoS depends on all layers.

Cross layer problem? It is a hard problem

It needs some kind of state maintenance in contrast to IP design philosophy.


What we should do? Maximize User Satisfaction (U) Mechanism?

Best effort is not enough Isolate traffics and flows

Active queue management Policing

Say no for some traffics Admission control


Integrated ServicesIntegrated Services

Differentiated ServicesDifferentiated Services

Integrated ServicesIntegrated Services

Differentiated ServicesDifferentiated Services

Two Broad Two Broad ApproachApproach


Integrated ServiceIntegrated Service Enhancing IP Service Model

Add QoS service classes Explicit resource management at IP

level Per flow state maintained at routers

which is used for admission control and scheduling set up by signaling protocol, users explicitly

request their needs. This is done with RSVP protocol


Integrated Services Example

Sender Receiver

Achieve per-flow bandwidth and delay guarantees Example: guarantee 1MBps and < 100 ms delay to a flow

Path RSVP Message



SenderReceiver

Allocate resources - perform per-flow admission control

RESV RSVP Message



SenderReceiver

Install per-flow state


SenderReceiver

Install per flow state


RESV RSVP Message


Integrated Services : Data Path

SenderReceiver

Per-flow classification


Integrated Services : Data Path

SenderReceiver

Per-flow buffer management



SenderReceiver

• Per-flow scheduling


Service Types Multiple service classes Service can be viewed as a contract between

network and communication client end-to-end service other service scopes possible

Three defined services Best-Effort for (best-effort or elastic) Guaranteed Service for hard real-time (“Real-Time

applications”) Controlled Load for soft real-time (“tolerant”

applications)


Flowspec Rspec: describes service requested from network

controlled-load: none guaranteed: delay target

Tspec: describes flow’s traffic characteristics average bandwidth + burstiness: token bucket filter token rate r bucket depth B must have a token to send a byte must have n tokens to send n bytes start with no tokens accumulate tokens at rate of r per second can accumulate no more than B tokens


Per-Router Mechanisms

Admission Control decide if a new flow can be supported answer depends on service class and

policy not the same as policing

Packet Processing classification: associate each packet with

the appropriate reservation scheduling: manage queues so each

packet receives the requested service


What is the Problem? Intserv can support QoS, but

Too complex Not scalable

Queuing & scheduling Classification speed Hardware Restriction

DiffServ aims at providing QoS with simple mechanisms so that it scales and can be deployed.

push the complexity to the “edges” of the network. Provide weaker guarantee


DiffServ Architecture Ingress routers (Edge Routers)

Perform per aggregate shaping or policing (Behavior Aggregate) Mark packets with Code Points, each CP represent a Class of

Service (DSCP DiffServ Code Point) Core routers

Implement Per Hop Behavior (PHB) for each DSCP Process packets based on DSCP

IngressEgressEgress

IngressEgressEgress

DS-1 DS-2

Edge router Core router


Differentiated Service (DS) Field

Version HLen TOS Length

Identification Fragment offsetFlags

Source address

Destination address

TTL Protocol Header checksum

0 4 8 16 19 31

Data

IPheader

DS filed reuse the first 6 bits from the former Type of Service (TOS) byte

The other two bits are proposed to be used by ECN

DS Field0 5 6 7


Per Hop Behavior (PHB) Define behavior of individual routers

rather than end-to-end services Two PHBs

Assured Forwarding (AF, A type) Expedited Forwarding (EF, P type) Plus, best-effort service!


DiffServ Implementations Two important proposals

RIO Mechanism (1 service) The Scalable Share Differentiation

architecture (SSD) Two-Bit architecture RFC (2475)


Two-Bit Architecture Proposes three different levels of

service: Premium Service. Assured Service. Best Effort Service.

Two-bit architecture: Packets get differentiated by two bits in

their header. Premium bit (P-bit) Assured Service bit (A-bit)


RFC 2475: Overall Architecture

Classifier

Meter

MarkerShaper/Dropper

Classifiers:

1. Multifield Classifier (MF)

2. Behavior Aggregate Classifier (BA)


Traffic Conditioning Schedulers: Work-conserving or Non-work-

conserving Traffic conditioning uses Non-work-

conserving ones Implementations

Leaky Bucket Token Bucket Hybrid approaches

Leaky-Token Bucket Dual Token Bucket


Leaky Bucket Smoothes traffic and generates

constant rate

b bits

r b/s


Token Bucket Filter Described by 2 parameters:

Token rate r: rate of tokens placed in the bucket

Bucket depth b: capacity of the bucket Operation:

Tokens are placed in bucket at rate r If bucket fills, tokens are discarded Sending a packet of size P uses P tokens If bucket has P tokens, packet sent at max

rate, else must wait for tokens to accumulate


Token Bucket Operation

Tokens

Packet

Overflow

Tokens Tokens

Packet

Enough tokens packet goes through,tokens removed

Not enough tokens wait for tokens to accumulate


Token Bucket On the long run, rate is limited to r On the short run, a burst of size b can be

sent Token Bucket 3 possible uses

Shaping Delay pkts from entering net (shaping)

Policing Drop pkts that arrive without tokens

Metering (Marking) Let all pkts pass through, mark ones without tokens


QoS Issues on wirelessQoS Issues on wireless

Dynamically varying network topology

Imprecise state information Lack of central coordination Error-prone shared radio channel Hidden terminal problem Limited resource availability Insecure medium


Different approachesDifferent approaches

MAC layer Network Layer Cross Layer


Flexible QoS Model for MANETs (FQMM)

FQMM is the first QoS Model proposed in 2000 for MANETs by Xiao et al.

The model can be characterized as a “hybrid” IntServ/DiffServ Model since the highest priority is assigned per-flow

provisioning. the rest is assigned per-class provisioning.

Three types of nodes again defined Ingress (transmit) Core (forward) Egress (receive)

1

2

5

3

4

6 7

ingress

egress

core

1

2

5

3

4

6 7

ingress

egress

core


Signaling is used to reserve and release resources.

Prerequisites of QoS Signaling Reliable transfer of signals between routers Correct Interpretation and activation of the

appropriate mechanisms to handle the signal. Signaling can be divided into “In-band” and

“Out-of-band”.

Most papers support that “In-band” Signaling is more appropriate for MANETs.

QoS Signaling


In-band VS Out-of Band Signaling

In-band Signaling, network control information is encapsulated in data packets + Lightweight Not Flexible for defining new Service Classes.

Out-of-band Signaling, network control information is carried in separate packets using explicit control packets.

Heavyweight signaling packets must have higher priority to achieve on

time notification => can lead to complex systems.+ Scalability. Signal packets don’t rely on data packets+ We can have rich set of services, since we don’t need to

“steal“ bits from data packets

Source Address

Destination Address

TTL Header CheckSum

Fragment Offset

Total Length

Options Padding

Identification

Protocol

Flags

Version Hdr Len Prec TOS

32 bits

(Shaded fields are absent from IPv6 header)


INSIGNIA – MANETs QoS Signaling

INSIGNIA is the first signaling protocol designed solely for MANETs by Ahn et al. 1998.

Can be characterized as an “In-band RSVP” protocol. It encapsulates control info in the IP Option field

(called now INSIGNIA Option field). It keeps flow state for the real time (RT) flows. It is “Soft State”. The argument is that assurance

that resources are released is more important than overhead that anyway exists.

RSVP {

In-band

{


INSIGNIA – OPTION Field

The INSIGNIA OPTION field

1 bit

MAX/MIN

BandwithIndicator

16 bits

MAX MIN

Bandwith Request

1 bit

REQ/RES

ReservationMode

ServiceType

RT/BE

PayloadIndicator

RT/BE

1 bit 1 bit

Reservation Mode (REQ/RES): indicates whether there is already a reservation for this packet. If “no”, the packet is forwarded to INSIGNIA

Module which in coordination with a AC may either: grant resources Service Type = RT (real-time).deny resources Service Type = BE (best-effort).

If “yes”, the packet will be forwarded with the allowed resources.

Bandwidth Request (MAX/MIN): indicates the requested amount of bandwidth.


INSIGNIA – Bottleneck Node

Ms

M5

M4

M1

M2 M3

MD

reservation/service/bandwidth bottleneck node

REQ/RT/MIN

REQ/RT/MAX

REQ/RT/MAX

REQ/RT/MIN

During the flow reservation process a node may be a bottleneck:The service will degrade from RT/MAX -> RT/MIN.

If M2 is heavy-loaded it may also degrade the service level to BE/MIN where there is actually no QoS.


INSIGNIA

INSIGNIA is just the signaling protocol of a complete QoS Architecture.

INSIGNIA Drawbacks. Only 2 classes of services (RT) and (BE). Flow state information must be kept in mobile

hosts.

To realize a complete QoS Architecture we also need many other components as well as a Routing Protocol (e.g. DSR, AODV, TORA).


QoS Routing and QoS for AODV

Routing is an essential component for QoS. It can inform a source node of the bandwidth and QoS availability of a destination node

We know that AODV is a successful an on-demand routing protocol based on the ideas of both DSDV and DSR.

We also know that when a node in AODV desires to send a message to some destination node it initiates a Route Discovery Process (RREQ).


QoS for AODV QoS for AODV was proposed in 2000 by C. Perkins

and E. Royer. The main idea of making AODV QoS enabled is to

add extensions to the route messages (RREQ, RREP).

A node that receives a RREQ + QoS Extension must be able to meet the service requirement in order to rebroadcast the RREQ (if not in cache).

In order to handle the QoS extensions some changes need to be on the routing tables

AODV current fields.Destination Sequence Number, Interface, Hop Count, Next Hop, List of Precursors

AODV new fields. (4 new fields)1) Maximum Delay, 2) Minimum Available Bandwidth, 3) List of Sources Requesting Delay Guarantees and 4) List of Sources Requesting Bandwidth Guarantees


QoS for AODV - Delay Handling Delay with the Maximum Delay extension

and the List of Sources Requesting Delay Guarantees. Example shows how the with the Maximum Delay

extension and the List of Sources Requesting Delay Guarantees are utilized during route discovery process.

cachedelay(C->D)=50 =TraversalTime

+ delay

RREQ2delay=10ingress

Acore C

Traversal_time= 5 0

core BTraversal_time= 3 0

RREQ1delay=100

egressD

RREQ1delay=70

RREQ1delay=20

RREP1delay=0

cachedelay(B->D)=80

RREP1delay=50

RREP1delay=80

1

2

x


QoS for AODV - Bandwidth

Handling Bandwidth is similar to handling Delay requests.

Actually a RREQ can include both types. Example shows how the with the Minimum Available

Bandwidth extension and the List of Sources Requesting Bandwidth Guarantees are utilized during route discovery process.

RREQ2minband=80K

cacheband(C->D)=50

ingressA

core CAvailable_Bandwidth

= 50K

core BAvailable_Bandwidth

= 100K

egressD

RREP1bandwidth=INF

cacheband(B->D)=50

RREP1bandwidth=50

2

x

RREQ1min_bandwidth=10Kbps



RREP1bandwidth=50

min{INF,50}

1


QoS for AODV - Loosing QoS

cachedelay(C->D)=50

ingressA

core CTraversal_time= 5 0

core BTraversal_time= 3 0

egressD

cachedelay(B->D)=80

cachedelay(B->D)=80

QOS_LOSTQOS_LOST

Loosing Quality of Service Parametersif after establishment a node detects that the QoS can’t be maintained any more it originates a ICMP QOS_LOST message, to all depending nodes.== > Reason why we keep a List of Sources Requesting Delay/Bandwidth Guarantees.

Reasons for loosing QoS Parameters. Increased Load of a node. Why would a node take over more jobs that it can handle?

Univ. of Tehran

Protection and Guarantee for Voice and Video Traffic in IEEE 802.11e Wireless LANs

•Yang Xiao•Haizhon Li

•Sunghyun Choi

Univ. of Tehran

Goal: Provide two level mechanism to enhance IEEE 802.11e (QoS)1. First Level

A. Tried-and-known Method (ETD)B. Early protection method (ENB)

• That is to enhance admission control of 802.11e

• Protect the existing voice and video flow from the new and other existing voice and video flows

2. The Second Level• That is to reduce influences on collisions by

data traffic, and more fully utilize the channel capacity

• To protect the existing voice and video flow from the best effort traffic

Univ. of Tehran

Motivation

Admission control is not good enough Admission control is good only when the

traffic load is not heavy Data traffics have influences on QoS

flows due to collisions Even though much of the channel

capacity can be used many best-effort traffic degrade the existing voice/video flow since many data transmissions cause many collisions

Univ. of Tehran

IEEE 802.11 DCF

Each station check whether the medium is idle before attempting to transmitif (idle for DISF period)

transmit immediatelyelse (busy for the medium)

a. wait until the medium becomes idleb. id the channel stays idle during DIFS period

start a backoff process by selecting a backoff counter (BC)

Backoff ProcessFor (each slot time)

if (medium is idle)BC is decremented

elsefrozen backoff process

if(BC == 0)the frame is transmitted

Univ. of Tehran

802.11 Distributed co-ordination function

Univ. of Tehran

IEEE 802.11e EDCF Hybrid Coordination function to support

QoS Contention based channel access

Enhanced Distributed Coordination Function Considered in this paper due to:

Simplicity Can support many QoS applications

Centrally controlled channel access schemes Not considered in the paper

Univ. of Tehran

EDCF: TXOP (transmission opportunity)

TXOP is a time period when a station has the right to initiate the transmission

Defined by: Starting time Maximum duration

Station cannot transmit a frame beyond TXOP

In case of larger frames, fragmentation may be required

Univ. of Tehran

EDCS: Access categories and priorities Four access categories Eight different

priorities Differentiated ACs are

achieved by differentiatin:

AIFS (Arbitration Inter Frame Space)

CWmin

CWmax

If one AC has a smaller AIGS or CWmin or CWmax, the ACs traffic has a better chance to access the medium

Univ. of Tehran

EDCF: medium control in a nutshell Each queue acts as a independent

MAC entity with a different AIFS, different initial window and different max. window size.

Each queue has its own backoff counter BO[i]

If more than one queue finishes the backoff at the same time higher AC is preferred by the virtual collision handler

Univ. of Tehran

EDCF timing diagram

Univ. of Tehran

First Level Protection and Guarantee Goal:

To protect existing QoS flows, whether a new flow can enter the system or not

Components QAP QSTA

Work as follows QAP calculates budget[AC] and announces via beacon

The budget is allowable transmission time per AC in beacon interval

If budget == 0 then new flows wont be allowed to gain medium

QSTA calculates its local transmission limit per AC The real transmission time per AC <= transmission limit

per AC

Univ. of Tehran

DAC: Procedure at QAP QAP transmits Qos Parameter Set Element

(QPSE) to QSTAs via beacons CWmin[i], CWmax[i], AIFS[i] (i = 0 … 3) TXOPBudget[i] & surplusFactor[i] (i = 1,2,3)

TXOPBudget[i]: additional amount of time available for AC i during next interval

surplusFactor[i]: ratio of over-the-air bandwidth reserved for AC i to the bandwidth of transported frames required for successful transmission.

Univ. of Tehran

DAC: Procedure at QAP

TXOPBudget[i] = Max(ATL[i] – TxTime[i] * surplusFactor[i] , 0)

ATL[i]: max amount of time that may be used for transmission of AC i, per beacon.

TxTime[i]: time occupied by transmissions from each AC during the beacon period, including SIFS and ACK times

Set to zero immediately following transmission of a beacon

For each data transmission QAP adds the time equal to frame transmission time and all overhead involved (SIFS and ACK) to TxTime counter.

Univ. of Tehran

DAC: procedure at each QSTA When a transmission budget for an

AC is depleted: New QSTAs cannot gain transmission

time Existing QSTAs cannot increase

transmission time per beacon interval Thus above mechanism protects

existing flows

Univ. of Tehran

DAC: local variables maitained by each QSTA TxUsed[i]: time occupied by transmission

irrespective of success or not TxSuccess[i]: transmission time for

successful transmission TxLimit[i]: station shall not transmit if

doing so => TxUsed[i] > TxLimit[i] TxRemainder[i] = TxLimit[i] – TxUsed[i]

Carry over to next beacon if station cant transmit TxMemory[i]: resources utilized during a

beacon interval. f: damping function

Univ. of Tehran

DAC: procedure at each QSTA at each target beacon time For new QSTAs which start transmission with this

AC in the next interval If TXOPBudget[i] = 0

TxMemory[i] = TxRemainder = 0 If TXOPBudget[i] > 0

TxMemory = [0, TXOPBudget[i] / SurplusFactor[i]] For other QSTAs:

If TXOPBudget[i] = 0 TxMemory[i] is unchanged

If TXOPBudget[i] > 0 TxMemory[i] = f*TxMemory[i] + (I - f)*(TxSuccess[i] *

SurplusFactor[i] + TXOPBudget[i]) TxSuccess[i] = 0 TxLimit = TxMemory[i] + TxRemainder[i]

Univ. of Tehran

Enhancements

Enhancement with required throughputs and/or delays (tried-and-known)

By observing several beacon intervals, the information whether the currently available capacity can accept a new flow can be determined

DAC + ETD Enhancements with a non-zero budget

values (early-protection) When the budget is below some threshold, new

flows are not allowed to enter. DAC + ENB

Univ. of Tehran

The Second Level Protection and Guarantee Data traffic will affect existing voice

and video flow Goal is to reduce the number of

collisions or collision probability, caused by data traffic

Dynamically control data traffic parameters

Window increasing factor changes with the backoff stage.

Univ. of Tehran

Fast backoff

σi:window increasing factor (any real no > 1) for backoff stage i (i = 1 … Lretry)

Fast Backoff 2 <= σ1 < … <σretry Fast backoff achieves a larger window

size much quicker and becomes faster when backoff stage is large

Univ. of Tehran

Dynamically adjusting parameters when fail / consecutive success When a frame reaches retry limit and is

dropped CWmin[0] = Θ * CWmin[0] (Θ > 1) AIFS[0] = AIFS[0] / ψ (ψ > 1)

When station successfully transmits m consecutive frames:

CWmin[0] = CWmin[0] / Θ (Θ > 1) AIFS[0] = AIFS[0] / ψ (ψ > 1)

Fast Backoff plus dynamic adjustments BF + DAFS

Univ. of Tehran

With or without DAC

Univ. of Tehran

Voice, video and data traffic

univ. of tehran wireless ad hoc networkingwireless ad hoc networks1univ. of tehran1 special topics...

Documents

guarantee delay

wireless ad

wireless networkswireless

ip networks

e wireless lans

ms delay

delay guaranteesexample

kind of guarantee