Mesh Networks Alliance (MNA) Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2005 Mesh Networks Alliance (MNA) Date: 2005-09-22 Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Guido R. Hiertz et al., ComNets/Philips John Doe, Some Company

Authors: July 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0 Guido R. Hiertz et al., ComNets/Philips John Doe, Some Company

5min statement from July 2005 Guido R. Hiertz et al., ComNets/Philips

Performance right from the first radio on July 2005 Scalability Single channel, single radio Multi channel, single radio Multi channel, multi radio Performance right from the first radio on Guido R. Hiertz et al., ComNets/Philips

Combines well known 802.11 technology July 2005 Combination Contention Free Period (CFP) Beacon frames Transmission Opportunity (TXOP) Combines well known 802.11 technology Guido R. Hiertz et al., ComNets/Philips

Reliability for backbone July 2005 Coexistence Dedicated resources Mesh traffic  Contention Free Period Station traffic  Contention Period Reliability for backbone Compatibility for BSS Guido R. Hiertz et al., ComNets/Philips

Fully compatible with 802.11-1999 July 2005 Compatibility Seamless 802.11 integration Stations work in Contention Period (CP) DCF, EDCA, HCCA … Fully compatible with 802.11-1999 Guido R. Hiertz et al., ComNets/Philips

Highly efficient with limited available channels July 2005 Efficiency Spatial frequency reuse Interference aware Economical channel usage Highly efficient with limited available channels Guido R. Hiertz et al., ComNets/Philips

Provides secure keys for 802.11i July 2005 Security Light weight key distribution Flexible Scalable Provides secure keys for 802.11i Guido R. Hiertz et al., ComNets/Philips

Play without plug Easy technology Auto-configuration July 2005 Play without plug No plug and play  Play immediately! Easy technology Auto-configuration Guido R. Hiertz et al., ComNets/Philips

Ready for the next decade July 2005 Future Ready for 802.11n Frame Aggregation 40MHz channels PHY independent DSSS, FHSS, OFDM, MIMO … Radio agnostic Ready for the next decade Guido R. Hiertz et al., ComNets/Philips

Updates to our 5min statement as you requested July 2005 Updates to our 5min statement as you requested Guido R. Hiertz et al., ComNets/Philips

Feedback! We received a lot of feedback July 2005 Feedback! We received a lot of feedback Thanks for your suggestions and interest! The following slides reply to your comments Guido R. Hiertz et al., ComNets/Philips

Simulation End to End delay July 2005 Simulation End to End delay Guido R. Hiertz et al., ComNets/Philips

Basic Multi-hop route 4 hop route Duplex data transmission July 2005 Basic Multi-hop route 4 hop route Duplex data transmission STA attached to MP Final MP as gateway to Internet PHY QPSK½ (12 Mb/s) ~20ms – 23ms Superframe duration Guido R. Hiertz et al., ComNets/Philips

Throughput Cumulative throughput, packet size 80 B July 2005 Throughput Cumulative throughput, packet size 80 B “Full superframe for EDCA” vs. “MNA during CFP & EDCA during CP” Guido R. Hiertz et al., ComNets/Philips

July 2005 End to End Delay EDCA (prio. 0), delay per route with offered traffic 300kb/s, packet size 80 B MNA MAC, delay per route with offered traffic 300kb/s, packet size 80 B 99% Guido R. Hiertz et al., ComNets/Philips

Outdoor scenario Offered traffic: CBR PHY QPSK¾ (18Mb/s) July 2005 Outdoor scenario Offered traffic: CBR Downlink routes Uplink routes PHY QPSK¾ (18Mb/s) ~12ms – 15ms Superframe duration EDCA parameters See page 48 Attenuation Walls: 11 dB Guido R. Hiertz et al., ComNets/Philips

July 2005 Downlink Throughput EDCA (prio. 0), throughput per route, packet size 80 B EDCA during full Superframe MNA MAC, throughput per route, packet size 80 B MNA during CFP only Guido R. Hiertz et al., ComNets/Philips

July 2005 End to End Delay EDCA (prio. 0), delay per route at offered traffic 400kb/s, packet size 80 B MNA MAC, delay per route at offered traffic 400kb/s, packet size 80 B Two Hops Three Hops 99% Single Hop Guido R. Hiertz et al., ComNets/Philips

July 2005 We simulate Mesh! Guido R. Hiertz et al., ComNets/Philips

Therefore, .11e & .11n are no longer WLAN but WPAN? July 2005 TGe & TGn 802.11e stations must be pollable (HCCA) 802.11e introduces Transmission Opportunity 802.11e introduces Block (ACK) transmissions 802.11n introduces Frame Aggregation All this 802.11 technologies reduce contention for the channel by introducing slotted transmissions. Therefore, .11e & .11n are no longer WLAN but WPAN? Guido R. Hiertz et al., ComNets/Philips

We combine existing elements of 802.11. July 2005 Our basic elements Beacon (mandatory since 1999), Contention Free Period (compatible with every station since 1999), Transmission Opportunity (since draft 1.0 of 802.11e in 2001). We combine existing elements of 802.11. Guido R. Hiertz et al., ComNets/Philips

July 2005 TGs Motto “Perfection is achieved not when there is nothing left to add but when there is nothing left to take away.” Can we take Contention Free Period, Beacon and Transmission Opportunity away to make 802.11s perfect? Guido R. Hiertz et al., ComNets/Philips

Mesh Networks Alliance July 2005 Mesh Networks Alliance Proposal H:9 Performance right from the beginning. All with existing 802.11 technology! Let’s get in contact! Guido R. Hiertz et al., ComNets/Philips

Things you might want to consider … July 2005 It’s your choice It’s your vote Things you might want to consider … Guido R. Hiertz et al., ComNets/Philips

Considering proposals (1) July 2005 Considering proposals (1) Does a proposals mandate two or more radios? If yes: Why? Does the system perform with single radio on single channel? Does the system scale with the amount of channels and radios? Future broadband PHY might have a single channel only. Does the Mesh WLAN design still work then? Is a proposal really PHY agnostic? We are ought to do so. Guido R. Hiertz et al., ComNets/Philips

Considering proposals (2) July 2005 Considering proposals (2) Multiple hop severely decrease performance in 802.11. Can the Mesh WLAN coexist on the same channel with legacy 802.11 stations? (non-QoS, non-802.11e stations)  How? The Mesh WLAN carries the aggregated traffic. Should its channel access not have higher priority than its associated stations? Do single hop routes dominate in the Mesh WLAN? Does this lead to starvation of multi-hop routes? Guido R. Hiertz et al., ComNets/Philips

Considering proposals (3) July 2005 Considering proposals (3) Simulation needs to be performed We do Mesh WLAN!  Mesh is Multi-Hop  Do not simulate single hop only Interference, reception and CCA range are all different Signal to noise ratio gives packet error rate Signal to noise ratio depends on distance of stations and interferers, transmission power and PHY mode  Static packet error rate do not work in Mesh WLAN simulation Guido R. Hiertz et al., ComNets/Philips

Considering proposals (4) July 2005 Considering proposals (4) 19-05-0029-00-0000-Estimating-PER-Caused-by-Interference.ppt “Estimating Packet Error Rate Caused by Interference – A Coexistence Assurance Methodology” We include a channel model as described here See page 51 Packet error rate vs. Signal to Interference Ratio Mesh is all about forwarding  Mesh is all about neighbors  Mesh is all about interference, coexistence and concurrent, competing transmissions Does a proposal consider this? Guido R. Hiertz et al., ComNets/Philips

Considering proposals (5) July 2005 Considering proposals (5) http://grouper.ieee.org/groups/802/19/pub/ca.html IEEE 802.19 Coexistence Technical Advisory Group (TAG): “Per the 802 P&P and IF indicated in the five criteria, the wireless working group shall produce a coexistence assurance (CA) document in the process of preparing for working group letter ballot and sponsor ballot. IEEE 802 projects requiring a coexistence assurance (CA) document: […] 802.11s Mesh Networking” Is a proposal aware of this? Guido R. Hiertz et al., ComNets/Philips

Considering proposals (6) July 2005 Considering proposals (6) On which technical basis do you compare proposals? Performance evaluation? Technical description? Don’t we all look for the best technical approach? If no changes are needed for Mesh WLAN, why does TGs not define a recommended practice? If you can have significant increase in the performance why would you choose a lower? Would your customers understand your decision? Guido R. Hiertz et al., ComNets/Philips