1 / 33

CC/RR Model and Simulations

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. CC/RR Model and Simulations. Authors:. Date: November 12, 2001.

ginata
Download Presentation

CC/RR Model and Simulations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 CC/RR Model and Simulations Authors: Date: November 12, 2001 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  3. Background Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  7. CC/RR Node / MAC Models Matthew Sherman & Wei Lin, AT&T Labs - Research

  8. AP Node Model • Full IP stack • Bridge to Ethernet • Enable interface to IP cloud Matthew Sherman & Wei Lin, AT&T Labs - Research

  9. STA Node Model • Full IP stack • Interface to OPNET application models Matthew Sherman & Wei Lin, AT&T Labs - Research

  10. WLAN MAC Process Model Matthew Sherman & Wei Lin, AT&T Labs - Research

  11. MAC Parameters • Added new PCF functionality options Matthew Sherman & Wei Lin, AT&T Labs - Research

  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. Matthew Sherman & Wei Lin, AT&T Labs - Research

  13. Beacon Beacon CCI CCI CCI Superframe Structures CC/RR Superframe Structure Contention Free Period (CFP) Contention Period (CP) Beacon CF-End Polling* Cycle Polling Cycle Polling Cycle Standing Poll Superframe Structure Contention Free Period (CFP) Contention Period (CP) Beacon CF-End Polling* Cycle Polling Cycle Polling Cycle * Number of polling cycles varies from 1 - N based on other simulation parameters Matthew Sherman & Wei Lin, AT&T Labs - Research

  14. CC/RR Scenarios and Results Matthew Sherman & Wei Lin, AT&T Labs - Research

  15. Global Network Matthew Sherman & Wei Lin, AT&T Labs - Research

  16. Common Scenario Attributes Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  18. Application Attributes FTP heavy application attributes Voice application attributes Matthew Sherman & Wei Lin, AT&T Labs - Research

  19. Application Attributes (Cont) HTTP heavy application attributes Matthew Sherman & Wei Lin, AT&T Labs - Research

  20. Scenario Differences • 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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  23. Delay through MAC (Global) • Substantial delay issues for Standing Poll • CC/RR maintains acceptable overall delay (See next slide) Matthew Sherman & Wei Lin, AT&T Labs - Research

  24. Delay through MAC (CC/RR) • Zoom of prior data for CC/RR • Shows delays generally limited to one Super Frame Matthew Sherman & Wei Lin, AT&T Labs - Research

  25. Throughput at MAC (Global) • CC/RR higher throughput than Standing Poll Overall • Averages • CC/RR: 2.7 Mbps • SP: 2.2 Mbps Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

  29. Throughput at Voice STA #19 • Shows typical throughput at Voice Station with IP / Application overheads Matthew Sherman & Wei Lin, AT&T Labs - Research

  30. Delay at FTP STA #28 • STA #28 shows typical performance near end of polling list • CC/RR shows dramatically better delay performance than Standing Poll Matthew Sherman & Wei Lin, AT&T Labs - Research

  31. Throughput at FTP STA #28 • CC/RR achieve significantly greater throughput • Due mostly to delay / drop issues for standing poll Matthew Sherman & Wei Lin, AT&T Labs - Research

  32. Conclusions Matthew Sherman & Wei Lin, AT&T Labs - Research

  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 Matthew Sherman & Wei Lin, AT&T Labs - Research

More Related