Doc.: IEEE 802.11-06/1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 1 Ambiguous terms in IEEE 802.11s/D0.03 Notice: This document has been.

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0035r0 Submission Jan 2005 Jon Edney InTalk2kSlide 1 Retiring the DS – a proposal Notice: This document has been prepared to assist.
Advertisements

Doc.: IEEE /0693r0 Submission May 2007 Osama Aboul-Magd, Nortel Networks Slide 1 Supporting Drop Eligibility in IEEE MAC Notice: This document.
Doc.: IEEE /0032r1 Submission January 2007 Donghee Shim et al, LG Electronics, Inc.Slide 1 Comments resolutions: Emergency call support in 11u.
Doc.: IEEE /0001r0 Submission Jan 2006 Bin Wang, ZTE CorporationSlide 1 ESS Load Balancing Notice: This document has been prepared to assist IEEE.
Doc.: IEEE /2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 1 Wireless Bridge Common Practices Notice: This document has been.
Doc.: IEEE /0256r0 Submission February 2007 A. Centonza, D. StephensonSlide 1 Limitations on the Use of EBR Notice: This document has been prepared.
Doc.: IEEE /0247r1 Submission March 2005 Atsushi FujiwaraSlide 1 Advantages of multiple channel usage in 11s WLAN Mesh network Notice: This document.
Doc.: IEEE /0866r1 Submission September 2005 Michael Montemurro, Chantry NetworksSlide 1 Mobility Domain Definition and Description Notice: This.
November 2005 Floyd Simpson, MotorolaSlide 1 doc.: IEEE /1193r0 Submission LB78 D3.0 Active Scanning Comments (clause ) Notice: This.
Doc.: IEEE /90r0 Submission Nov., 2012 NICTSlide b NICT Proposal IEEE P Wireless RANs Date: Authors: Notice: This document.
Doc.: IEEE /0048r0 Submission March 2005 Tatsuji Munaka, Mitsubishi Electric Corp.Slide 1 User Scenario example; Sensor Overlay Network Notice:
Doc.: IEEE /1867r1 Submission November r Security TeamSlide 1 TGr Security Requirements Notice: This document has been prepared to.
Doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 1 Thoughts on Peer Capacity Date: Authors: Notice: This document.
Doc.: IEEE /1138r0 Submission November 2005 Cheng Hong, PanasonicSlide 1 Authorization Information in interworking Notice: This document has been.
Doc.: IEEE /0644r2 Submission May 2006 Päivi Ruuska, NokiaSlide 1 Measurement Pilot Transmission Information as optional information in Probe.
May 2006 Justin McNew, TechnoComSlide 1 doc.: IEEE p Submission p Recommendations Notice: This document has been prepared to.
Doc.: IEEE /0025r1 Submission January 2007 Peng Mo, Huawei Technologies Co., Ltd.Slide 1 MAPID for User Plane Support Notice: This document has.
Doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 1 IEEE 802 Architecture Issues Notice: This document has.
Doc.: IEEE /1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: Authors: Notice: This document.
Doc.: IEEE /0239r0 Submission March 2005 Montemurro, Smith, Edney, KumarSlide 1 Resource pre-allocation and commmunication adhoc report Notice:
Doc.: IEEE /0072r0 Submission January 2009 Slide 1 Proxy ARP Issue for Direct Link Setup Notice: This document has been prepared to assist IEEE.
November 2005doc.: IEEE /1079r0 Stuart GoldenNovember Notice: This document has been prepared to assist IEEE It is offered as a.
Doc.: IEEE /0757r0 Submission July 2005 C Trecker, Azimuth SystemsSlide 1 Test Methodology for measuring Fast BSS Transition Performance Notice:
Doc.: IEEE /1057r0 Submission November 2005 Bin Wang, ZTE CorporationSlide 1 Using AP’s Location Information in Load Balancing Notice: This document.
Doc.: IEEE /1212r0 Submission TGT and MEF Liaison Notice: This document has been prepared to assist IEEE It is offered as a basis for.
Doc.: IEEE /0667r0 Submission July 2005 Mike Moreton, STMicroelectronicsSlide 1 Multiple Networks Notice: This document has been prepared to assist.
Doc.: IEEE /0039r1 Submission January 2007 Larry Green, Ixia Slide 1 TCP Parameters and Settings Notice: This document has been prepared to assist.
Doc.: IEEE /0028r0 Submission January 2005 Eleanor Hepworth, Siemens Roke ManorSlide 1 Definitions and Terminology Notice: This document has been.
Doc.: IEEE /xxxx-r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 1 Tree Based Routing Protocol (I20) Five Minute Summary.
Doc.: IEEE /0197r0 Submission March 2005 Nancy Cam-Winget et alSlide 1 TAP & JIT Merge Process Notice: This document has been prepared to assist.
Doc.: IEEE /0136r0 Submission January 2007 Dave Stephenson, Cisco Systems, Inc.Slide 1 Input to Information Model Date: Notice:
Doc.: IEEE /0295r0 Submission March 15, 2011 Fei Tong, CSRSlide 1 Reference waveform generator for 11ac Notice: This document has been prepared.
doc.: IEEE /0611r2 Submission July 2005 Alexander Cheng, C-cation, Inc.Slide 1 Self-organizing and Auto-configuring Mesh Networks Notice: This.
Network Sharing Architecture
Beacon Measurement on Pilot Frames
Self-organizing and Auto-configuring Mesh Networks
Resource Request/Response Discussion
Lightweight Mesh Point – A confusing term
LB73 Noise and Location Categories
Self-organizing and Auto-configuring Mesh Networks
3GPP Extended Date: Authors: July 2005 July 2005
[place presentation subject title text here]
Decision Topology Definitions
Mesh Networks Alliance (MNA)
Coexistence problem of s Congestion Control
Self-organizing and Auto-configuring Mesh Networks
TGu Requirements Change Motion
Lightweight Mesh Point – A confusing term
R8E4 and XML Date: January 12th 2006 Authors: January 2006
Coexistence problem of s Congestion Control
Proposal for User Plane Support for QoS Mapping
TGs San Diego Closing Report
Protection Assurance Method
Ambiguous terms in IEEE s/D0.03
TGs PAR Amendment Authors: March 2007 Date: March 2007
Proposed DLS Teardown Date: Ovadia, Ginzburg, Intel
May 2006 doc.: IEEE /0601r0 May 2006 Handling the Groupcast Sequence Number for Proxied Device in Multihop Mesh Date: Authors: Notice:
IEEE WG Opening Report – July 2007
Lightweight Mesh Point – A confusing term
Limiting GAS State-1 Query Response Length
Document Organization Discussion
Motion to go to Letter Ballot
Lightweight Mesh Point – A confusing term
MAC Address Spoofing in Mesh
Lightweight Mesh Point – A confusing term
Greenfield protection mechanism
Wireless Architectural Thoughts
Proposal for User Plane Support for QoS Mapping
TGs March Mid-Week Report
Selection Procedure Recommendation
Presentation transcript:

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 1 Ambiguous terms in IEEE s/D0.03 Notice: This document has been prepared to assist IEEE 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 Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date:

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 2 Authors:

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 3 Abstract [1] defines several variants of a Mesh Point (MP). However, besides the definition of the entity called MP all other definitions are vague and unclear. The imprecise introduction of new entity categories leaves too much room for interpretation thus putting a risk on a successful letter ballot of a draft amendment of IEEE s. To simplify future work and to achieve better consistency we propose to limit the scope of IEEE s on the definition of an MP. Any other functionality can be either co-located with an MP or can be achieved by an according configuration that allows for implementation with a reduced set of features. These principles allow to achieve the same variety of devices as described in [1], however without the need for the complexity of defining the interdependency of the entities of [1].

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 4 Entities defined by

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 5 Devices currently defined by and its amendments AbbreviationFull description STAStation APAccess Point PCPoint Coordinator ?Portal QSTAQoS Station nQSTANon-QoS Station QAPQoS Access Point nQAPNon-QoS Access Point HCHybrid Coordinator

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 6 Station (STA) “Any device that contains an IEEE conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 7 Access Point (AP) “Any entity that has station functionality and provides access to the distribution services, via the wireless medium (WM) for associated stations” “An access point (AP) is a STA that provides access to the DS by providing DS services in addition to acting as a STA”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 8 Point Coordinator (PC) No dedicated definition Several remarks spread across the standard Usually co-located with the AP Uses the Point Coordination Function during the Contention Free Period –Polling based medium access

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 9 Portal “The logical point at which medium access control (MAC) service data units (MSDUs) from a non-IEEE local area network (LAN) enter the distribution system (DS) of an extended service set (ESS)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 10 Quality of Service (QoS) Station (QSTA) “A station (STA) that implements the QoS facility. A QSTA acts as an non-QSTA (nQSTA) when associated in a non-QoS basic service set (nQBSS)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 11 Non-QoS Station (nQSTA) “A station (STA) that does not support the quality of service (QoS) facility”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 12 Quality of Service (QoS) Access Point (QAP) “An access point (AP) that supports the QoS facility specified in this amendment. The functions of a QAP are a superset of the functions of a non-QAP (nQAP), and thus a QAP is able to function as an nQAP to non- QoS stations (nQSTAs)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 13 Non-QoS Access Point (nQAP) “An access point (AP) that does not support the quality of service (QoS) facility”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 14 Hybrid Coordinator (HC) “A type of coordinator, defined as part of the quality of service (QoS) facility, that implements the frame exchange sequences and medium access control (MAC) service data unit (MSDU) handling rules defined by the hybrid coordination function (HCF). The HC operates during both the contention period (CP) and contention- free period (CFP). The HC performs bandwidth management including the allocation of transmission opportunities (TXOPs) to QoS stations (QSTAs). The HC is collocated with a QoS access point (QAP)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 15 A lot of entities … In , every entity has a part that is a station –A Station is the part that is sink or source of any traffic Some entities are closely related –AP & PC & HC & Portal … –HC & QAP There is some understanding that works like LEGO –Add another brick  Add another functionality –An AP could work as a STA when AP functionality is turned off –A Portal becomes an AP when e.g. “Ethernet” (most often used as non-WLAN) cable is unplugged –…

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 16 Sink of traffic An entity that is sink of traffic The frame ends here –It will not be relayed  A Station

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 17 Source of traffic An entity that is source of traffic The entity generates the frame –It is the first time that the frame appears  A Station

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 18 A relaying entity The entity has one more ports The entity receives a frame on a port It relays the frame –On the same port or –To another port At least one of the ports is connected to a WLAN  An AP or a Portal

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 19 A Portal The portal has at least two ports –It interconnects a an a non LAN –It relays frames (MSDUs) between the different LANs

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 20 “Systems” defined by

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 21 And there is the surroundings … IEEE entities can be grouped – uses different names for different sets of entities –The name of a set depends on the entities that are part of set

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 22 Basic Service Set (BSS) “A set of stations controlled by a single coordination function”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 23 Distribution System (DS) “A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 24 Independent Basic Service Set (IBSS) “A BSS that forms a self-contained network, and in which no access to a distribution system (DS) is available”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 25 Infrastructure “The infrastructure includes the distribution system medium (DSM), access point (AP), and portal entities. It is also the logical location of distribution and integration service functions of an extended service set (ESS). An infrastructure contains one or more APs and zero or more portals in addition to the distribution system (DS)”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 26 Extended Service Set (ESS) “A set of one or more interconnected basic service sets (BSSs) and integrated local area networks (LANs) that appears as a single BSS to the logical link control (LLC) layer at any station associated with one of those BSSs”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 27 The Distribution System Interconnects different BSSs Creates the Extended Service Set (ESS) May exist solely within an entity (AP, Portal …)

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 28 Entities defined by s

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 29 What does s provide? s tries to define “some” of the “grey boxes” –Some seem to be more complicated than others –Some are pretty easy

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 30 Devices currently defined by s/D0.03 AbbreviationFull description MPMesh Point ?Non-forwarding Mesh Point ?Light-weight Mesh Point MAPMesh Access Point MPPMesh Point collocated with a Mesh Portal

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 31 Mesh Point (MP) “Any IEEE entity that contains an IEEE –conformant Medium Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM), that is within a WLAN Mesh, and that supports WLAN Mesh Services”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 32 Non-forwarding Mesh Point ?

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 33 Light-weight Mesh Point ?

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 34 Mesh AP (MAP): “Any Mesh Point that is also an Access Point”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 35 Mesh Point collocated with a Mesh Portal (MPP) “A point at which MSDUs exit and enter a WLAN Mesh to and from other parts of a DS or to and from a non network. A Mesh Portal can be collocated with an IEEE portal”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 36 The “environment” of s

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 37 IBSS vs. Ad hoc BSS vs. Mesh WLAN Infrastructure BSS –Centralized, needs AP –All communication via AP –Stations communicate with AP only –Stations synchronized to AP AP sends beacon frames –Any traffic goes via the AP –A portal may connect to other networks (bridging) Usually co-located with AP –Star topology –Has a common identifier Ad hoc BSS –All stations must be in mutual communication range –Stations do not forward frames on behalf of others –Closed network –Any topology –Distributed synchronization scheme All stations participate in beacon frame generation –Has a common identifier Mesh WLAN (or Mesh BSS?) –Entities need not be in mutual communication range –Entities may mutually forward frames –Any topology –May synchronize whole Mesh –Has a common identifier

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 38 What is a Mesh WLAN? defines a BSS as “A set of stations controlled by a single coordination function” –Is a Mesh WLAN some kind of a BSS? –The BSS definition has nothing about communication ranges, amount of hops etc. Does [1] define a Mesh BSS instead of a Mesh WLAN? In which “space” do MPs communicate? –Do they communicate in the DS? –Do they communicate in the ESS? Is a Mesh WLAN an ESS Mesh, see [2]?

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 39 Ambiguous definitions in IEEE P802.11s/D0.03

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 40 Example: Mesh WLAN that consists of MPs only The example has no MAPs  Therefore, there are no APs Every Infrastructure BSS has an AP (See Infrastructure definition)  Hence, the example doesn’t form an Infrastructure BSS A Distribution System (DS) interconnects BSSs to create an Extended Service Set (ESS)  Hence, the example Mesh WLAN has no/does not form a DS?  Thus, the example Mesh WLAN does not form an ESS?

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 41 What’s the difference? Is there any? Example  –A “Mesh Point” co-located with a “Portal” –A “Mesh Portal” Example  –A “Mesh Access Point” –A “Mesh Point co-located with an “Access Point” Example  –A “Mesh Point” that advertises Null-routing –A “non-forwarding Mesh Point” Example  –“Mesh Portal” co-located with a “Mesh Access Point” –“Mesh Portal” co-located with an “Access Point” –“Mesh Access Point” co- located with a “Portal” –“Access Point” co-located with a “Mesh Portal” –“Access Point” co-located with a “Portal” and a “Mesh Point”

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 42 Are there combinations possible? What could be a non-forwarding Mesh Access Point (MAP)? What could be a non-forwarding Mesh Portal (MPP)?

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 43 Proposed changes to definitions in IEEE P802.11s/D0.03

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 44 Mesh Point  A relaying entity The entity has one more ports The entity receives a frame on a port It relays the frame –On the same port or –To another port At least one of the ports is connected to a WLAN [1]  An MP or MPP

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 45 Mesh Point in a Mesh WLAN An MP solely connects with other MPs An MP may be co-located with an AP –Then it provides the AP service to stations –Then, [1] calls it an MAP

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 46 Frames to or from an MP An MP “may be” or “is always” co- located with a station –The station part of this merged entity can generate or consume frames –It uses the MP part to have the frames being relayed

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 47 Non-forwarding MP Is configured to not to relay frames The MP propagates a “Null route” –Reason for null-routing is hidden to others  Not important –It is a configuration choice –A vendor may choose to implement an MP without routing capability –Routing is a matter of capabilities –Participation in Mesh in not affected

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 48 Light-weight Mesh Point Communicates with anything in its range Never requests frames to be forwarded –Key difference to a non-forwarding MP Does not relay frames Is a configuration choice –Does not need to be separately defined

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 49 Configuration choices allow for variety MPs may have different configuration –Non-forwarding & Light- weight MPs use “Null”- Routing –Light-weight MP never requests frame forwarding Configuration determines implementation and vice versa –Non-forwarding MP has no routing capability ↔ A device that is configured to not forward needs no routing capability Implementation hidden to other devices –No interesting –Black box –Devices need to distribute configuration settings only –No differentiation of device classes needed An MP that is not capable of forwarding is the same as an MP that chooses not to forward

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 50 Co-location in : Access Point May be co-located with –Station AP itself may be addressed for maintenance etc. –Point Coordinator (PC) Implements PCF –Hybrid Coordinator (HC) Implements HCCA  QoS guarantee –Portal Provides bridging to other networks

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 51 Break functions into parts Assumption 1 –(AP)  (MP) =  –(Portal)  (AP) =  –… Assumption 2 –(AP)  (MP) = (STA) –(Portal)  (AP) = (STA) –… Let (.) denote the set of functions provided by the according type of entity –(AP) = “The set of AP functions” –(MP) = “The set of MP functions” –Accordingly for Portal, STA … Difference between Assumption 1 & 2 unimportant for our discussion –However, separation of STA functionality (1) provides benefits

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 52 Which definition of an MAP is correct? (AP)  (MP) = (MAP) –A MAP is the sum of functionality of an AP and an MP (MAP) \ [(AP)  (MP)] ≠  –An MAP has more capability than the sum of an AP and an MP [1] defines a Mesh Access Point as “Any Mesh Point that is also an Access Point”. Which interpretation is correct? The decision is crucial for standardization efforts of s. If TGs chooses the right hand interpretation, a lot of differentiations are needed (see e: QSTA vs. nQSTA etc.) If TGs decides for the left hand interpretation, the final s amendment needs to define an MP only. Anything else can be co-located with an MP.

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 53 Principle of Co-location Break things into independent entities Combine entities to new compositions MPs may be co-located with –Station –AP –Portal –PC –HC –Root node –… Avoid introduction of unnecessary definitions

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide s co-location, example: Mesh Access Point (MAP) AP operates in BSS –Hierarchy: Superior to stations Grants or denies access to BSS –Provides stations with AP services –Forwards frames on behalf of stations –… MP operates in Mesh WLAN –Flat Hierarchy: All MPs are equal –Provides frame forwarding –Path selection –Security services –… Combines MP & AP functionality The Definition how the AP part internally communicates with the MP is outside thes scope of s –Vendor specific –Not important for standard

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide s – It’s all about MPs s veterans may remember: –We merged two proposals One had something about “simplicity” in its name … –Introducing more names and dependencies doesn’t make it simple … Instead of introducing several different types of entities we should focus on the definition of an MP – nothing else –Configuration options may allow for a “special” MPs A configuration option may be to not to choose to forward (route) frames  Non-forwarding MP All current entities defined by [1] are special configurations of an “Mesh Point” or equal a “Mesh Point” that is co-located with something additional.

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 56 Conclusion IEEE s should solely define the term Mesh Point (MP) –No other terms needed –Reduce amount of newly introduced devices to 1 –Makes amendment more stringent –Avoid unnecessary confusion e has “xyz-entities” and “non-xyz-entities” “Non-MAP MP”, “Non-MPP MP”, “Non-forwarding MP” etc. –Letter ballot much easier if only one new thing is defined members know about APs etc. There is a very fixed conception in people’s mind. But how to explain MAPs etc.?

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 57 Straw poll Are you in favor of the following decision? –IEEE 802 Task Group “s” shall focus on the definition of the entity called “Mesh Point” (MP). The definition of any other entity shall be considered out-of-scope of IEEE 802 Task Group “s”. IEEE 802 Task Group “s” shall allow for flexible MP configuration, thus allowing a variety of MPs that have currently different names (“non-forwarding MP”, “Light-weight MP” etc.). The flexible configuration shall allow to implement MPs that need a sub-set of functions of IEEE s only. IEEE 802 Task Group “s” shall allow for co-located entities that extend the definition of an MP (e.g. an MP that is co-located with an AP forms the entity that is currently defined as an MAP). IEEE 802 Task Group “s” shall consider the aforementioned guidelines during its future work and instruct its editor to accordingly form the next draft (P802.11s/D0.04 or P802.11s/D1.0 if the TG decides to go on letter ballot). Yes/No/Abstain: CANCELED

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 58 Straw poll Shall we reduce the entity terms defined in [1] to the single and only term “MP”? Yes/No/Abstain: 10/3/19

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 59 References [1]IEEE P802.11s/D0.03 [2]IEEE , doc , PAR for IEEE ESS Mesh

doc.: IEEE /1371r1 Submission September 2006 Guido R. Hiertz, PhilipsSlide 60 Annex Funnies –[1]: “Figure s6: Connecting a WLAN Mesh LAN …” A “Wireless Local Area Network Mesh Local Area Network”? Wow! Three different persons may have five different opinions what that could be! Do we really want to define such things? Is a Mesh WLAN LAN something else? What would be a WLAN Mesh MAN?