November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 1

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

CC/RR Model and Simulations

Date: November 12, 2001

Matthew ShermanAT&T Labs - Research

180 Park AvenueFlorham Park, NJ 07932

973-236-6791mjsherman@att.com

Wei LinAT&T Labs - Research

180 Park AvenueFlorham Park, NJ 07932

973-236-6812linw@att.com

Authors:

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 2

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Simulation Goal

• Show anticipated advantages of CC/RR protocol over straight “PCF”– Maintain QoS Guarantees in overloaded network– Reduced Control frame overhead for large

networks– Improved performance for IP traffic over PCF

• Evaluate differences in behavior for– Always Polling all stations (Standing poll)– Using CC/RR protocol for dynamic polling

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 3

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Background

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 4

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

PCF Model Status• Prior descriptions in:

– IEEE 802.11-01/099– IEEE 802.11-00/373

• PCF model developed by AT&T Labs– Philips Research added PHY overhead for 802.11a

and 802.11b• Validation by Philips and AT&T

– Comparison to analytical numbers • Will become part of OPNET standard Library

– Excludes CC/RR– No date for release

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 5

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

CC/RR MAC Model Status

• Based on PCF model• Philips added initial CC/RR implementation• Enhanced by AT&T

– Added actual CC and RR frame formats– Implemented CC fields– Dynamic allocation of CC_Ops– Automated maintenance of polling list

• Includes station state (On / Off Polling list)– Interface to OPNET IP stack

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 6

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

CC/RR Scenario Status• Existing PCF scenario not appropriate for CC/RR• Needed much larger number of stations

– CC/RR intended to reduce excess polling• Not a big issue in small networks

– More typical of 802.11 meeting that home networking• Completed several new scenarios showing CC/RR advantages

over straight polling (standing poll)• Added IP stack to simulations

– More realistic simulation of applications– Look for interactions with MAC

• Simulations in OPNET 7.0 PL16 with June 2001 model library– All parameters default except as noted

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 7

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

CC/RR Node / MAC Models

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 8

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

AP Node Model

• Full IP stack• Bridge to Ethernet• Enable interface to IP

cloud

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 9

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

STA Node Model

• Full IP stack• Interface to OPNET

application models

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 10

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

WLAN MAC Process Model

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 11

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

MAC Parameters• Added new PCF functionality options

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 12

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

New CC/RR MAC Parameters

• Max CCOP per CCI - Determines Max Controlled Contention Opportunities (CCOPs) per Controlled Contention Interval (CCI). If set to Unlimited, no limit to the allowed number of CCOPs. This attribute only used by the AP, with other STA reading appropriate values from CC Frame. Actual number of CCOPs is adapted by the AP based on load. Must be at least one CCI per Beacon period in the current simulations.

• Permission Probability - Probability (0-1) determining which STAs may contend with RR's during a CCI. Only used by AP when sending the CC frame. Other STA will read permission probability from the CC frame.

• RR Retirement - In an AP, after receiving an RR from an STA, determines how many consecutive Beacon periods must occur without sending or receiving data to that STA before an RR is retired (the STA is removed from the polling list). Each time data is sent or received, the number of cycles till retirement is reset to this value. In an STA, this parameter is used to infer how many beacon periods must transpire without sending or receiving data before a new RR must be sent. This parameter is ignored if RR's are not used by this STA or AP.

• Adapt Permission Probability - This attribute determines if the permission probability (PP) is adapted from it's initial setting by the AP using the programs internal routines. If this attribute is disabled, PP cannot be adapted. If enabled, the program will attempt to adapt PP for optimum efficiency.

• Max Empty CCI - This value controls the number of CCI permitted per a Beacon Period (CFP). If set to Unlimited, the AP will initiate a CCI after every polling cycle, rather than initiate the DCF. If this attribute is set to a positive integer, say n, this parameter causes AP to stop initiating CCI after the nth empty CCI.

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 13

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Superframe Structures

Beacon

Polling* Cycle

Contention Free Period (CFP) Contention Period (CP)

CCICF-End

Beacon

CC/RR Superframe Structure

Polling Cycle

CCI

Polling Cycle

CCI

Beacon

Polling* Cycle

Contention Free Period (CFP) Contention Period (CP)

CF-End

Beacon

Standing Poll Superframe Structure

Polling Cycle

Polling Cycle

* Number of polling cycles varies from 1 - N based on other simulation parameters

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 14

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

CC/RR Scenarios and Results

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 15

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Global Network

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 16

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Common Scenario Attributes

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 17

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

WLAN-Scenario

• 1 AP, 6 voice STAs and 23 FTP heavy & HTTP heavy STAs

• Overloaded wireless LAN network

• 64kbps PCM G.711 PCM voice

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 18

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

FTP heavy application attributes Voice application attributes

Application Attributes

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 19

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

HTTP heavy application attributes

Application Attributes (Cont)

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 20

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

• All MAC parameters set to defaults on Slides 11 &12 except as noted– CFP Interval 18 milliseconds (hidden on slide 11)

• Wlan_SP_2v4 Scenario– All STA & AP set for Standing Poll

• Wlan_CR1_2v4 Scenario– All STA & AP set for CC/RR

• Max CCOP per CCI: unlimited• Permission probability: 0.5• RR retirement: 3 beacon periods• Adapt permission probability: enabled• Max empty CCI: unlimited

Scenario Differences

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 21

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Packet Drops at MAC (Global)

• Drops indicate overload conditions– No Voice drops– All drops from AP

• FTP / HTTP has heavier downstream

• Modest drops for Standing Poll

• Slight drop at end for CC/RR

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 22

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Load at MAC (Global)

• Overall, CC/RR scenario has higher loading

• Averages– CC/RR: 2.7 Mbps

– SP: 2.2 Mbps

• Standing Poll Reduced Load due to IP Fall back for delay and lost packet issues

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 23

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Delay through MAC (Global)

• Substantial delay issues for Standing Poll

• CC/RR maintains acceptable overall delay (See next slide)

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 24

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Delay through MAC (CC/RR)

• Zoom of prior data for CC/RR

• Shows delays generally limited to one Super Frame

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 25

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Throughput at MAC (Global)

• CC/RR higher throughput than Standing Poll Overall

• Averages– CC/RR: 2.7 Mbps

– SP: 2.2 Mbps

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 26

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Control Traffic Received at AP

• Includes RRs, Nulls and Acks

• Standing Poll has roughly 1 Mbps more control traffic received than CC/RR

• Averages– CC/RR: 0.9 Mbps – SP: 2.0 Mbps

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 27

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Control Traffic Sent from AP• Traffic includes Beacons,

CCs, Polls, and CF-Ends • Roughly 100 Kbps more

control data sent for Standing Poll than for CC/RR

• Averages– CC/RR: 143 Kbps – SP: 240 Kbps

• Less Tx control traffic since more downlink traffic than uplink– Piggyback Polls don’t count

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 28

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Delay at Voice STA #19

• Last Voice STA on Polling list– Always worst delay

• See good performance for both Standing Poll and CC/RR

• CC/RR slightly better

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 29

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Throughput at Voice STA #19

• Shows typical throughput at Voice Station with IP / Application overheads

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 30

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

• STA #28 shows typical performance near end of polling list

• CC/RR shows dramatically better delay performance than Standing Poll

Delay at FTP STA #28

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 31

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Throughput at FTP STA #28• CC/RR achieve

significantly greater throughput

• Due mostly to delay / drop issues for standing poll

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 32

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Conclusions

November, 2001

Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 33

doc.: IEEE 802.11-01/571r0

CC/RR Model and Simulations

Conclusions

• Model of PCF MAC with CC/RR completed• Simulations comparing performance of

CC/RR with Standing Poll (SP) in large over loaded network completed– Demonstrates that both CC/RR and SP can

maintain QoS in over load conditions– Control traffic reduced for CC/RR relative to SP– IP applications achieve greater throughput and

robustness using CC/RR compared to SP