doc.: ieee 802.11-01/571r0 cc/rr model and simulations november, 2001 matthew sherman & wei lin,...
TRANSCRIPT
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
Wei LinAT&T Labs - Research
180 Park AvenueFlorham Park, NJ 07932
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