doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 1 IEEE 802 Architecture Issues 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: Authors:

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 2 Despite being “allocated” issues by the other WGs, they might not be our issues Other group allocated some issues –“QoS/class of service” How do you map QoS between different networks? –“Protocol definition vs scope” What is the scope of the protocol definition? –“Security” –“Bridging compatibility – handling of multicasts” –“LLC – acts as a block to passing additional (e.g., QoS) parameters” How do you set up QoS connection across multiple links? –“Mesh” –“What is the (future).11 architecture” –“Power/channel management” These “allocated” issues might not be ’s issues –At least some of the issues are not really issues for the 802 architecture group eg security –It is not clear what some of the “issues” actually are Although we can all speculate

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 3 What are the benefits? What are we trying to achieve? –“Alignment between WG projects & the 802 architecture” Why is alignment good? –Supports work sharing (and reuse of existing work) –Allows definition of common interfaces What gains are possible? –Helps to define more self-contained problems –Supports extensibility: can extend one area of the standard without impacting too many other parts

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 4 Protocol Definition vs. Scope Traditional protocol definition scope is STA ↔ AP, low down in the stack (below LLC) However, we are now building more complex systems that interact with entities beyond this scope. –802.11i reuses architecture elements from 802.1X –802.11k is considering neighbourhoods of APs, we no longer consider links in isolation Protocol definition is phrased in terms of entities, but these entities are not described –which is good when considered within the original scope of this work

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 5 Protocol Definition vs. Scope However, as we introduce more complex functionality we hit some problems: –lack of interoperability between different virtual AP implementations is not a protocol problem, but an architectural problem related to how identifiers relate to one another – defines its own set of identifiers, the relationship between these identifiers and those defined by IEEE 802 is not well defined e.g. how should networks be identified? –The protocol definition is no longer self-contained What is the best approach to address this situation? –broaden the scope of ? –specify behaviour through reuse of other 802 standards?

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 6 TGu - Interworking Addressing some issues as stated in slide 2 (Andrew Myles) QoS Mapping from TGe to network Network Selection Admission Control User subscription

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 7 AP Functionality –Good start to refining IEEE architecture –Needs to continue –Who is addressing the “Integration Service” ? TGs (Mesh) –Mesh Portal definition –What is the ESS TGp (WAVE) –Alternative Architecture

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 8 Mesh Networking Not a WLAN Mesh Mesh Point Mesh Portal Mesh Point Mesh Point Mesh Point Mesh Point Mesh Point Mesh Point Mesh Point Mesh Point Mesh Portal WLAN Mesh #1 WLAN Mesh #2 AP DS Mesh Portal Portal Mesh Point Mesh Point Mesh Portal/ Portal

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 9 IEEE Developing a standard specifying a common handoff framework applicable to IEEE 802 standards, wired and wireless. Also includes IEEE 802 to non-802 technologies (e.g. Cellular) Initially , How does this affect the standard. Can TGu manage any required changes?

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 10 Heterogeneous System IEEE is looking at how sessions can be handed over between the different 802 media. They are looking at pulling these technologies together for multi-interface terminals and networks. However, as each wireless standard evolves (.15, 16,.11) with various tweaks and forays into network connectivity; does there reach a point, where overlaps in each standard mean that they become one? They currently have separate markets because they operate in different performance regimes. Will a future IEEE and.16 become essentially the same technology with different market areas?

doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 11 Summary IEEE starting to move in the right direction TGu could provide input to 802 arch group? Eventually have a heterogeneous architecture which fits all IEEE 802 technology ??