Methods for providing Quality of Service in WLANs W.Burakowski, A. Beben, J.Sliwinski Institute of Telecommunications, Warsaw University of Technology,

Methods for providing Quality of Service in WLANs

W.Burakowski, A. Beben, J.Sliwinski

Institute of Telecommunications, Warsaw University of Technology, Poland

Slide 2COST 279 Final Seminar, Lisbon, 27-29 June 2005

Outline

Class of Service (CoS) concept for providing end_to_end QoS in heterogeneous and multi-domain networks

How to provide CoSs in WLANs

Method for improving packet delay characteristics in WLANs

Summary


Problem statement

Objective: Assuring strict end_to_end QoS guarantees at the packet layer

Network environment: heterogeneous and multi-domain networks

Different access network technologies: WiFi, xDSL, UMTS, LAN/Ethernet

IP core

To follow concept of Classes of Service (acc. to the IETF proposal)

„Service class” represents a set of traffic that requires specific delay, loss and jitter characteristics from the network for which a consistent and defined per hop-behaviour applies

AS1

AS2 AS3

AS4

AP

WiFi

IP Core IP Core

LAN


CoSs: IETF proposal (1)

Tolerance To Tolerance To Inter-Provider

Service Class (Aggregate)

Loss Delay Jitter PHB

End-To-End Service Class Loss Delay Jitter

DSCP Name

DSCP Value

Ctrl Low Low Yes CS Network Control

Low Low Yes CS7 111000

Telephony VLow Vlow VLow EF 101110 Signalling Low Low Yes CS5 101000

MM Conferencing

L-M Vlow Low AF4x 100xx0*

RT Interactive

Low Vlow Low CS4 100000 Real Time VLow VLow VLow EF

Broadcast Video

VLow Med Low CS3 011000

MM Streaming

L-M Med Yes AF3x 011xx0*

Low Latency Data

Low L-M Yes AF2x 010xx0*

OAM Low Med Yes CS2 010000

None Real Time

Low LIM Yes AF

High ThruPut Data

Low M-H Yes AF1x 001xx0*

Best Effort NS NS NS DF Standard NS NS NS DF 000000

11 Basic CoSs and 4 aggregated CoSs


CoSs: IETF proposal (2), exemplary applications

Aggregated types of CoSs Types of CoSs Examples of applications CTRL Network control Network routing

Telephony IP telephony bearer Signalling IP telephony signaling MM conferencing H.323/V2 videoconferencing (elastic)

RT interactive Video conferencing and interactive gaming Real Time

Broadcast video Broadcast TV and live events

MM streaming Streaming video and audio on demand Low-latency data Client/Server transactions Web-based ordering OAM Non-critical OAM&P

Non-Real Time

High throughput data Store and forward applications

Best Effort Standard Undifferentiated applications


Exemplary set of CoSs

QoS Objectives Aggregated Types of

Classes of Service

Basic End-To-End Service Class

IPLR Mean IPTD

IPDV

Telephony 10-3 100 ms 50 ms RT RT

Interactive 10-3 100 ms 50 ms

MM Streaming

10-3 1 s U NRT

High ThruPut

Data 10-3 1 s U

Best Effort Standard U U U

Basic CoSs – visible by the users and can be deployed in some access networks (e.g. in LAN/Ethrenet)

Aggregated CoSs – can be deployed in some parts of the networks (e.g. WLANs, inter-domain links)


CoSs: An example of deployment in network

Access 1 (WLAN)

Access 2 (UMTS)

Core

Telephony

RT Interact.

MM Stream.

High Thr. D.

Standard

RT

NRT

BE

Over-provisioned

RT

NRT

BE

User request for basic end-to-end

CoS

Aggregated CoSs

implemented on inter-

domain link

Aggregated CoSs

implemented on inter-

domain link

Aggregated CoSs

implemented in core domain

Aggregated CoSs implemented inside domain

mapping mapping mapping mapping mapping

RT

NRT

BE

RT

NRT

BE

Aggregated CoSs implemented inside domain


CoSs: An example of deployment in network

End-to-end CoS path

QoS domain path QoS domain path QoS domain path QoS inter-domain path

QoS inter-domain path

QoS signalling

QoS routing

RM

QoS Request

QoS Request QoS Request

QoS Request QoS Request

RA

QoS Request

CoS CoS CoS CoS CoS

RM RM


CoSs in WLANs (1)

EthernetxDSLCable

Access Point

Edge Router

Possible bottlenecks


CoSs in WLANs: status

Currently available Near future: 802.11e (September 2005 ?)

DCF

- no QoS

- contention based operation

- widely deployed

PCF

-irregular polling

-no equipment

-not deployed (!)

EDCA HCCA

- relative QoS

- just hitting the market

- polling based

- available in long term

WLAN Standard IEEE 802.11

DCF – Distributed Coordination Function

PCF – Point Coordination Function

EDCA - Enhanced Distributed Channel Access

HCCA - Hybrid Coordinated Channel Access


CoSs in WLANs: status

Investigated approaches for handling QoS traffic in WLANs:

Tuning of MAC parameters to get „a priority” of QoS traffic over the best effort

Enhancement of MAC layer for improving polling mechanism

Any of the proposed approaches is not sufficient for supporting CoSs


CoSs in WLANs: Mechanisms in 802.11

DCF access Distributed, random, contention based access Assures „equal” access to medium

No traffic differentiation, no QoS guaranties – a single best effort service

Best effort

traffic APBE


Proposed solution (1)

Best effort

traffic APBE

Use 802.11 DCF mode


To separate in a physical way the QoS traffic from the best effort traffic by keeping two APs – one for QoS traffic and one for best effort traffic


Use 802.11 DCF mode

Best effort

traffic

QoS traffic APQOS

APBE

QoS controller


General strategy: Terminal has access to 2 associated APs

One for BE traffic One for QoS traffic (RT and N-RT)

Problems to be solved: Switching between APs Differentiation between „real” and „non-

real” time traffics How to perform admission control


Connection scenario

AP-BE AP-QoS

T T T T T

Switch HUB

Router RMWiFi-QoS topology

SIP

proxy

RM – Resource Manager

Connection scenario

AP-BE AP-QoS

T T T T T

Switch HUB

Router

RM

QoS request

Terminal sends by AP-BE its QoS request to SIP Proxy

SIP

proxy

Connection scenario

AP-BE AP-QoS

T T T T T

Switch HUB

Router RM

QoS

req

ues

t

SIP Proxy sends the QoS request to RM where CAC is performed

SIP

proxy

Connection scenario

AP-BE AP-QoS

T T T T T

Switch HUB

Router RM

RM reads the MAC address

Connection scenario

AP-BE AP-QoS

T T T T T

Switch HUB

Router RM

RM adds the MAC

addressto „allowed”

list

Connection scenario

AP-BE AP-QoS

T T T T T

Switch HUB

Router RM

RM adds the MAC

address to „denied”

Connection scenario

AP-BE AP-QoS

TT T T T

Switch HUB

Router RMQoS confirmation

Terminal is attached to the AP-QoS and QoS confirmation is send


Traffic handling: Differentiation of RT and NRT The bottleneck is DOWNLINK only

Need to implement QoS mechanisms on the top of MAC: Separate queues for RT and NRT Policers (RT) and shapers (NRT) Admission Control

EuQoS WiFi LLC

PHY layer (802.11 a,b or g)

MAC layer (802.11 in DCF mode)

PQ

policers

RT NRT

shapers

RT NRT

policers shapers

EuQoS WiFi LLC layer implemented on an open source

APs

Standard 802.11 MAC and PHY

layers


Admission Control

Engineering approach

The main idea: WLAN is stable until the offered load does not exceed serving capabilities

i S trea m s

P P S i T eff i

T eff

CW m in

2 S lo tT im e T D A T A T S IF S T AC K T D IF S

T D A T A T p rea m b le T h ea d er

L D A T A h ea d er L packet 8

R P H YT AC K T p rea m b le T h ea d er

L A C K hea der 8

R P H Y

0 0,2 0,4 0,6 0,8 1

PPS – Packets per second


Simulation results (1)

Single APQOS with a number of terminals Two types of streams:

RT service: symmetrical voice connection G.729 codec; 20 ms packet inter-arrival time (50 pkt/s) for each direction; 60 bytes packets (IP+UDP+RTP+payload).

NRT service: Greedy TCP flows in downstream direction only, 512 kbit/s shaped throughput;

QoS traffic APQOS

QoS controller



Conclusions: Relatively large delay variation is caused by

„random access” mechanism in MAC To fulfill e2e QoS requirements additional

mechanism may by required!

(a) average delay (b) 99.9% quantile of IPDV

0

3

6

9

12

0 1 2 3 4 5 6 7

Num ber of high throughput connections

Nu

mb

er o

f vo

ice

con

nec

tio

ns

0

0.5

1

1.5

2

Tim

e (m

s)

Number of voice connections

average IPTD dow nstream

average IPTD upstream0

3

6

9

12

0 1 2 3 4 5 6 7

Num ber of high throughput connections

Nu

mb

er o

f vo

ice

con

nec

tio

ns

0

5

10

15

20

Tim

e (m

s)

Number of voice connections

99.9% quantile of IPTD dow nstream

99.9% quantile of IPTD upstream

Acceptance region


Method for improving delay characteristics in WLANs (1) Delay variation in WLANs is caused by transmission

backoffs and collisions coming from MAC protocol behaviour

To overcome we need synchronisation between streams, like in TDMA

time

period D period D

D3

Tx

CBR#1

CBR#2

- packet arrival, D – CBR interarrival time - packet transmission Tx - transmission

period D

conflict conflict

CBR#3

without synchronization

actions required for synchronization

after synchronization

time


Method for improving delay characteristics in WLANs (2) The „self synchronisation” mechanism enforces synchronization

between CBR sources by introducing for each CBR stream different initial delay Di

The value of Di is fixed independently in each station based on the last successful transmission as the interval between the moment when packet transmission starts and the moment of its arrival

T1

T2+D

T3

Tb=3

Tb=5 T1+D

T3+D

WT3

WT1

WT2

WTi – Wireless terminal i (i=1,2,3) D– CBR traffic interarrival time; - moment of packet arrival; T1, T2, T3 - starting moments of successful packet transmission for WTi; Tb – backoff time

T2

D D



Single APQOS with a number of terminals Only VoIP streams:

RT service: symmetrical voice connection G.729 codec; 20 ms packet inter-arrival time (50 pkt/s) for each direction; 60 bytes packets (IP+UDP+RTP+payload).

QoS traffic APQOS

QoS controller



standard WLAN enhanced WLAN

Conclusion: The method assures constant delay!

Histogram of the transfer delay differences between two consecutive packets after synchronisation phase (11 VoIP streams)


Numerical results (3)

VoIP streams start transmission at the random moments

Cumulative distribution function of the synchronization time

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10

CD

F

T ime [slots]

8 streams11 streams12 streams

VoIP streams start transmission at the same time (worst case)

Conclusion: For the random start synchronization is reached quickly


Summary

Providing e2e QoS requires to assure QoS in each part of the network

The concept of CoSs is exploited

Providing CoSs in WLANs requires: Separation between QoS and best effort traffics Additional traffic handling mechanisms Application of admission control

The solution is verified by simulation and is planned for implementation

We can get excellent delay charactaristics for VoIP by adding „self synchronisation” mechanism

Documents

Methods for providing Quality of Service in WLANs W.Burakowski, A. Beben, J.Sliwinski Institute of Telecommunications, Warsaw University of Technology,