Improving IEEE 802.11 WLAN: QoS and Throughput Perspective

Sunghyun Choi, Ph.D.Assistant ProfessorSchool of Electrical EngineeringSeoul National UniversityE-mail: schoi@snu.ac.krURL: http://ee.snu.ac.kr/~schoi

2

Introduction to My Group in SNU

Multimedia & Wireless Networking Lab. (MWNL) Within School of Electrical Engineering,

Seoul National University

Started September 2003 One of the youngest groups in SoEE, SNU

1 (+2) Ph.D. & 3 masters students

3

Introduction to My Group in SNU (Cont’d) Working on WLAN MAC and around

Resource management – power, rate, … QoS & mobility TCP/UDP over WLAN

4G wireless network Cross-layer design (Sensor networks)

4

Contents

Introduction

QoS provisioning

Throughput enhancement

Conclusion

5

Introduction to IEEE 802.11 WLAN Wireless Ethernet with comparable speed

Supports up to 11 and/or 54 Mbps within >100 m range

Enable (indoor) wireless and mobile high-speed networking Runs at unlicensed bands at 2.4GHz and 5GHz Connectionless MAC and multiple PHYs

6

Limitations of Current 802.11

Lack of QoS support Best-effort service with contention-based MAC

Low throughput due to large overhead < 5 Mbps throughput at 11 Mbps 802.11b link

My group is currently working on improving both aspects Will show only preliminary results here

7

QoS Improvement

8

Emerging IEEE 802.11e MAC

New draft standard for QoS provisioning Expected to be finalized by early next year

Defining a new MAC backward compatible with the legacy MAC Legacy 802.11 MAC – DCF (+ PCF) 802.11e MAC – HCF with two access

mechanisms Controlled channel access Contention-based channel access (EDCA)

9

802.11 Distributed Coordination Function (DCF) Carrier Sense Multiple Access with Collision

Avoidance (CSMA/CA)

BusyMedium

SIFS

PIFS

DIFS

BackoffWindow

Slot Time

Defer Access Select Slot and decrement backoffas long as medium stays idle

DIFS

Contention WindowImmediate access whenmedium is idle >= DIFS

Next Frame

10

802.11e Access Category (AC) Access category (AC)

as a virtual DCF 4 ACs implemented

within a QSTA to support 8 priorities

Multiple ACs contend independently

The winning AC transmits a frame

AC0 AC1 AC2 AC3

Virtual Collision Handler

Backo

ff A

IFS[0]

BO

[0]

Backo

ff A

IFS[1]

BO

[1]

Backo

ff A

IFS[2]

BO

[2]

Backo

ff A

IFS[3]

BO

[3]

Transmission Attempt

11

Differentiated Channel Access of 802.11e EDCA Each AC contentds with

AIFS[AC] (instead of DIFS) and CWmin[AC] / CWmax[AC] (instead of CWmin / CWmax)

BusyMedium

SIFS

PIFS

AIFS[AC]

BackoffWindow

SlotTime

Defer Access Select Slot and decrement backoffas long as medium stays idle

AIFS[AC]+SlotTime

Contention Windowfrom [1,1+CWmin[AC]]

Immediate access whenmedium is idle >=AIFS[AC]+SlotTime

Next Frame

12

Simulation Results - DCF vs. EDCA Delay comparison

2 video (1.5 Mbps CBR), 4 voice (36.8 kbps CBR), 4 data (1 Mbps Poisson)

13

Our Software-Based Approach for RT Traffic Support

IEEE 802.11e is not available yet Even if it becomes available, many

existing legacy 802.11 APs will be there Especially, for WISP with many deployed

APs, replacing existing APs costs a lot of money

Software (or firmware) upgrade-based approach is very desirable at least in the short term

14

System Architecture

Device Driver

TCP/UDP

IP

PHY

MAC

RT+NRT

frame processing

TCP/UDP

IP

PHY

MAC

RT+NRT

RT NRT

frame processing

(a) Original Host AP driver

(b) Modified Host AP driver

15

Measurement Configuration

Linux + HostAP driver for Intersil chipsets one RTP (1.448 Mbps CBR) + one FTP

Console

Server

Host AP Clientswitch

Implement dual queue

16

One-Way Delay of RTP Traffic

Original

Modified

17

Percentage Gain in Performance Parameters

Test 1

ComparisonPercentage

gainOriginal

Two Queue

Throughput

TCP 3.851 3.703 -3.84%

RTP 1.448 1.448 0.00%

Jitter of RTP

Avg. 2.9 2.6 -10.34%

Max.

4.0 3.0 -25.00%

min. 2.0 2.0 0.00%

One-way delay of

RTP

Avg. 30.7 20.2 -34.20%

Max.

32.0 23.0 -28.13%

min. 32.0 18.0 -40.00%

Max delay variation of RTP

27.0 18.0 -33.33%

Percentage Gain in Performance Parameters

TCP throughput

RTP troughput

Jitter Avg.

Jitter Max.

Jitter Min

One-way delay Avg.

One-way delay Max.

One-way delay Min.

Max delay variation

-70%

-60%

-50%

-40%

-30%

-20%

-10%

0%

10%

18

Limitations and Future Work

Limitations of the current approach Running on top of legacy MAC with a single

FIFO queue AP cannot prevent/control contention from

stations Downlink RT transmission could be severely

delayed due to the uplink contentions

How to handle this situation is an on-going effort

19

Throughput Improvement

20

IEEE 802.11n Initiative

A new standardization effort to achieve over 100 Mbps throughput over WLAN

Via both PHY and MAC enhancement

We are considering the MAC improvement for throughput enhancement

21

Frame Size Affects Throughput 802.11 MAC/PHY have big fixed overheads

MAC header, IFSs, ACK, and Backoff PLCP preamble & header

Busy Channel

DIFS34

usec PPDU ACK

PLCPPreamble

PLCP Header

Payload FCS

16 usec >= 4 usec 24 octets Variable 4 octets

SIFS (16 usec)

Backoff - 9 usec x [0,CW] >= 24 usec

MAC Header

22

0

5

10

15

20

25

30

35

40

Datagram Size (octets)

Thro

ughp

ut (

Mbp

s)Theoretical Throughput for 54 Mbps

Preferred

Operation Range

23

Packet Size Statistics

This statistics is from the measurement taken in the 802.11 standard meeting room in the morning of July 22nd 2003

24

Frame Aggregation

Aggregation of multiple frames in order to reduce the fixed overheads relatively!

Multiple frames are aggregated above the MAC SAP The aggregated frame is transmitted via a data frame

25

Frame Formats

octets: 2 2 6 6 6 2 variable 4

octets: 3 5 variable IP

datagramSNAP

HeaderLLC

Header

Frame Control

Duration / ID Addr 1 Addr 2 Addr 3

Seq. Control Data FCS

802.2 LLC

802.11 MAC

octets: 2 2 6 6 6 2 variable 4

octets: 1 1 1 1 2 2 2 variable variable

Frame Control

Duration / ID

Addr 1

Addr 2

Addr 3

Seq. Control Data FCS

802.2 LLC with aggregation

802.11 MAC

Control(0x03)

Count(n)

Size 1 ... Size nEtherframe

1Etherframe

n...

octets: 6 6 2 variableSource

Addr.Type IP datagram

DestinationAddr.

SSAP(0xdd)

DSAP(0xdd)

Reserved

Original

With aggregation

26

Theoretical Throughput w/ Aggregation (w/o channel error)

0

5

10

15

20

25

30

35

40

Datagram Size (octets)

Thro

ughp

ut (

Mbp

s)

11a w/o aggregation 11a w/ aggregation # of aggregated datagrams

27

Theoretical Throughput w/ Aggregation (w/ channel error)

28

Performance Measurement

Implement frame aggregation in real platform Linux & Intersil-based platform (.11b) Measure the throughput performance of UDP

and TCP traffic Note: Frame aggregation is only applied when

there are multiple frames in the queue

Traffic generator AP STA

29

Measurement Results - UDP

Packet aggregation, RTP, 10Mbps

0

1

2

3

4

5

6

7

8

0 200 400 600 800 1000 1200 1400 1600Packet Size (bytes, application-level)

Thr

ough

put (

Mbp

s)

original

aggregation

Theoretical

Throughput performance of packet aggregation with fixed rate UDP

30

Measurement Results - TCP Throughput performance of packet aggregation with

TCP

Packet Aggregation, TCP

0

1

2

3

4

5

6

7

0 200 400 600 800 1000 1200 1400 1600Packet Size (bytes, application-level)

Thr

ough

put (

Mbp

s)

original

aggregation

Theoretical

31

Summary and Future Work

Shown that frame aggregation is a good way to improve 802.11 MAC throughput Via both analysis and measurements

Frame aggregation can be done above the MAC SAP very easily

Needs further measurements/simulations for more realistic scenarios

32

Concluding Remarks

IEEE 802.11 WLAN is becoming real popular these days

There is still a big room to improve the current 802.11 systems

Important to consider how any improved system co-exists with legacy systems