Download presentation
Presentation is loading. Please wait.
Published byAmia Humm Modified over 10 years ago
1
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 1 CC/RR Model and Simulations Date: November 12, 2001 Matthew Sherman AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 973-236-6791 mjsherman@att.com Wei Lin AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 973-236-6812 linw@att.com Authors:
2
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 2 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
3
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 3 Background
4
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 4 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
5
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 5 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
6
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 6 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
7
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 7 CC/RR Node / MAC Models
8
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 8 AP Node Model Full IP stack Bridge to Ethernet Enable interface to IP cloud
9
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 9 STA Node Model Full IP stack Interface to OPNET application models
10
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 10 WLAN MAC Process Model
11
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 11 MAC Parameters Added new PCF functionality options
12
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 12 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.
13
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 13 Superframe Structures BeaconBeacon Polling* Cycle Contention Free Period (CFP)Contention Period (CP) CCI CF- End BeaconBeacon CC/RR Superframe Structure Polling Cycle CCI Polling Cycle CCI BeaconBeacon Polling* Cycle Contention Free Period (CFP)Contention Period (CP) CF- End BeaconBeacon Standing Poll Superframe Structure Polling Cycle Polling Cycle * Number of polling cycles varies from 1 - N based on other simulation parameters
14
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 14 CC/RR Scenarios and Results
15
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 15 Global Network
16
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 16 Common Scenario Attributes
17
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 17 WLAN-Scenario 1 AP, 6 voice STAs and 23 FTP heavy & HTTP heavy STAs Overloaded wireless LAN network 64kbps PCM G.711 PCM voice
18
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 18 FTP heavy application attributesVoice application attributes Application Attributes
19
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 19 HTTP heavy application attributes Application Attributes (Cont)
20
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 20 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
21
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 21 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
22
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 22 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
23
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 23 Delay through MAC (Global) Substantial delay issues for Standing Poll CC/RR maintains acceptable overall delay (See next slide)
24
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 24 Delay through MAC (CC/RR) Zoom of prior data for CC/RR Shows delays generally limited to one Super Frame
25
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 25 Throughput at MAC (Global) CC/RR higher throughput than Standing Poll Overall Averages –CC/RR: 2.7 Mbps –SP: 2.2 Mbps
26
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 26 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
27
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 27 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
28
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 28 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
29
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 29 Throughput at Voice STA #19 Shows typical throughput at Voice Station with IP / Application overheads
30
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 30 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
31
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 31 Throughput at FTP STA #28 CC/RR achieve significantly greater throughput Due mostly to delay / drop issues for standing poll
32
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 32 Conclusions
33
doc.: IEEE 802.11-01/571r0 CC/RR Model and Simulations November, 2001 Matthew Sherman & Wei Lin, AT&T Labs - ResearchSlide 33 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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.