Special Topics on Wireless Ad-hoc Networks

1
Special Topics on Wireless Ad-hoc Networks
Lecture 11 Quality of Services on Wireless
Networks

• University of Tehran
• Dept. of EE and Computer Engineering
• By
• Dr. Nasser Yazdani

Univ. of Tehran
1
2
Covered 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.

Univ. of Tehran
2
3
Outline

• Quality of Service
• QoS on IP networks
• Integrated Services
• Differentiated Services
• QoS on Wireless Link
• QoS Routing
• Cross layer Design

Univ. of Tehran
3
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

Sampler
,
Microphone
Buffer
,
A D
D A
converter
Speaker
5
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

6
Utility Curve Shapes
U
U
Elastic
Hard real-time
BW
BW
Delay-adaptive
U
BW
7
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.

8
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

9
Integrated ServicesDifferentiated Services
Two Broad Approach
10
Integrated 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

11
Integrated Services Example

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

Path RSVP Message
Receiver
Sender







12
Integrated Services Example

• Allocate resources - perform per-flow admission
  control

Receiver
RESV RSVP Message
Sender







13
Integrated Services Example

• Install per-flow state

Receiver
Sender







14
Integrated Services Example

• Install per flow state

Receiver
RESV RSVP Message
Sender







15
Integrated Services Data Path

• Per-flow classification

Receiver
Sender











16
Integrated Services Data Path

• Per-flow buffer management

Receiver
Sender











17
Integrated Services Example

• Per-flow scheduling

Receiver
Sender











18
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)

19
Flowspec

• Rspec describes service requested from network
• controlled-load none
• guaranteed delay target
• Tspec describes flows 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

20
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

21
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

22
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

DS-2
DS-1
Ingress
Egress
Egress
Ingress
Edge router
Core router
23
Differentiated Service (DS) Field
0
5
6
7
DS Field
0
4
8
16
19
31
Version
HLen
TOS
Length
Identification
Flags
Fragment offset
IP header
TTL
Protocol
Header checksum
Source address
Destination address
Data

• 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

24
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!

25
DiffServ Implementations

• Two important proposals
• RIO Mechanism (1 service)
• The Scalable Share Differentiation architecture
  (SSD)
• Two-Bit architecture
• RFC (2475)

26
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)

27
RFC 2475 Overall Architecture

• Classifiers
• Multifield Classifier (MF)
• Behavior Aggregate Classifier (BA)

28
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

29
Leaky Bucket

• Smoothes traffic and generates constant rate

b bits
r b/s
30
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

31
Token Bucket Operation
Tokens
Tokens
Tokens
Overflow
Packet
Packet
Not enough tokens ? wait for tokens to accumulate
Enough tokens ? packet goes through, tokens
removed
32
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

33
QoS 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

Univ. of Tehran
33
34
Different approaches

• MAC layer
• Network Layer
• Cross Layer

Univ. of Tehran
34
35
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)

36
QoS Signaling

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

37
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 gt can lead to
  complex systems.
• Scalability. Signal packets dont rely on data
  packets
• We can have rich set of services, since we
  dont need to steal bits from data packets

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

In-band
RSVP
39
INSIGNIA OPTION Field

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

40
INSIGNIA Bottleneck Node

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

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

41
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).

42
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).

43
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

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

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

46
QoS for AODV - Loosing QoS

• Loosing Quality of Service Parameters
• if after establishment a node detects that the
  QoS cant be maintained any more it originates a
  ICMP QOS_LOST message, to all depending nodes.
• gt 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?

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

• Yang Xiao
• Haizhon Li
• Sunghyun Choi

48
Goal Provide two level mechanism to enhance IEEE
802.11e (QoS)

• First Level
• Tried-and-known Method (ETD)
• 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
• 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

49
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

50
IEEE 802.11 DCF

• Each station check whether the medium is idle
  before attempting to transmit
• if (idle for DISF period)
• transmit immediately
• else (busy for the medium)
• a. wait until the medium becomes idle
• b. id the channel stays idle during DIFS period
• start a backoff process by selecting a backoff
  counter (BC)
• Backoff Process
• For (each slot time)
• if (medium is idle)
• BC is decremented
• else
• frozen backoff process
• if(BC 0)
• the frame is transmitted

51
802.11 Distributed co-ordination function
52
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

53
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

54
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

55
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 BOi
• If more than one queue finishes the backoff at
  the same time higher AC is preferred by the
  virtual collision handler

56
EDCF timing diagram
57
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 budgetAC 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 lt transmission
  limit per AC

58
DAC Procedure at QAP

• QAP transmits Qos Parameter Set Element (QPSE) to
  QSTAs via beacons
• CWmini, CWmaxi, AIFSi (i 0 3)
• TXOPBudgeti surplusFactori (i 1,2,3)
• TXOPBudgeti additional amount of time
  available for AC i during next interval
• surplusFactori ratio of over-the-air bandwidth
  reserved for AC i to the bandwidth of transported
  frames required for successful transmission.

59
DAC Procedure at QAP

• TXOPBudgeti Max(ATLi TxTimei
  surplusFactori , 0)
• ATLi max amount of time that may be used for
  transmission of AC i, per beacon.
• TxTimei 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.

60
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

61
DAC local variables maitained by each QSTA

• TxUsedi time occupied by transmission
  irrespective of success or not
• TxSuccessi transmission time for successful
  transmission
• TxLimiti station shall not transmit if doing
  so gt TxUsedi gt TxLimiti
• TxRemainderi TxLimiti TxUsedi
• Carry over to next beacon if station cant
  transmit
• TxMemoryi resources utilized during a beacon
  interval.
• f damping function

62
DAC procedure at each QSTA at each target beacon
time

• For new QSTAs which start transmission with this
  AC in the next interval
• If TXOPBudgeti 0
• TxMemoryi TxRemainder 0
• If TXOPBudgeti gt 0
• TxMemory 0, TXOPBudgeti / SurplusFactori
• For other QSTAs
• If TXOPBudgeti 0
• TxMemoryi is unchanged
• If TXOPBudgeti gt 0
• TxMemoryi fTxMemoryi (I -
  f)(TxSuccessi SurplusFactori
  TXOPBudgeti)
• TxSuccessi 0
• TxLimit TxMemoryi TxRemainderi

63
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

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

65
Fast backoff

• siwindow increasing factor (any real no gt 1) for
  backoff stage i (i 1 Lretry)
• Fast Backoff
• 2 lt s1 lt ltsretry
• Fast backoff achieves a larger window size much
  quicker and becomes faster when backoff stage is
  large

66
Dynamically adjusting parameters when fail /
consecutive success

• When a frame reaches retry limit and is dropped
• CWmin0 T CWmin0 (T gt 1)
• AIFS0 AIFS0 / ? (? gt 1)
• When station successfully transmits m consecutive
  frames
• CWmin0 CWmin0 / T (T gt 1)
• AIFS0 AIFS0 / ? (? gt 1)
• Fast Backoff plus dynamic adjustments
• BF DAFS

67
With or without DAC
68
Voice, video and data traffic