Sept 2004 doc.: IEEE 802.15-15-04-0551-00-001a Nov 2004 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [802 Architecture Ad Hoc Meeting] Date Submitted: [13-Mar-05] Source: [Tom Siep] Company [Cambridge Silicon Radio] Address [Suite 100, ms 365, 1802 Pleasant Valley Dr, Garland, TX, USA, 75040] Voice:[+1 972 496 0766], FAX: [+1 469 366 1480], E-Mail:[tom.siep@ieee.org] Re: [Update to information, based on 13-Mar-05 802 Architecture committee meeting] Abstract: [Report on 802 Architecture Ad Hoc meeting to address work items.] Purpose: [WG report.] Notice: This document has been prepared to assist the IEEE P802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Tom Siep, Cambridge Silicon Radio Tom Siep, TMS Associates, LLC

802 Architecture Ad Hoc Meeting Sept 2004 doc.: IEEE 802.15-15-04-0551-00-001a Nov 2004 NOTE: Changes made as a result of 13-Mar-05 802 Architecture Group meeting are in BLUE 802 Architecture Ad Hoc Meeting Tom Siep TMS Associates, LLC 802.15 Liaison to 802 Architecture Committee Tom Siep, Cambridge Silicon Radio Tom Siep, TMS Associates, LLC

Intent for 802.1 Arch Committee Nov 2004 Intent for 802.1 Arch Committee Improve alignment between WG projects and existing 802 architecture by: Identifying current problems, omissions, conflicts, ramifications, and their potential resolution Identifying potential refinements or changes to the architecture Providing a regular forum in which such discussion can take place, in a lower pressure environment than is possible during the core Plenary cycle. Tom Siep, Cambridge Silicon Radio

Proposals for resolution Nov 2004 Proposals for resolution Due diligence issues – need to fix 802 procedures TJ to propose to SEC that the rules for forwarding to SB & RevCom be strengthened WGs should review projects against PAR/5C requirements during the development cycle Each WG: Prioritize issues Characterize the problem Propose approach to resolve, or identify as intractable Identify other groups (802 or external) that may be affected Tom Siep, Cambridge Silicon Radio

Known issues – 802.15 (as presented at Sunday meeting in San Antonio) Nov 2004 Known issues – 802.15 (as presented at Sunday meeting in San Antonio) Are PANs different from WLANs? We hope the answer is “No” (wrt the MAC service) Security What functionality is needed Who does what aspect Bridging compatibility – handling of multicasts, no clause 6 section for .1D LLC – acts as a block to passing additional (e.g., QoS) parameters Mesh (not the same as the .11 issue though) QoS Architectural consistency across three MACs (Signal) Power/channel management Tom Siep, Cambridge Silicon Radio

Are PANs different from WLANs? Nov 2004 Are PANs different from WLANs? Does not apply, interface to 802.1 is essentially the same Tom Siep, Cambridge Silicon Radio

Security What functionality is needed? Nov 2004 Security What functionality is needed? Need secure access control to the resources of the medium to ensure QoS Since it is intended to run without an infrastructure, cannot rely on centralized authority to ensure security “Who does what aspect?” does not apply (interface to 802.1 the same) Tom Siep, Cambridge Silicon Radio

Nov 2004 Bridging compatibility – handling of multicasts, no clause 6 section for .1D Compatibility with .1D 15.1a – Bridging is handled in BNEP, which maps to Ethernet. 15.3 – Annex A (normative) specifies compatibility 15.4 – Annex A (normative) specifies compatibility Multicasts 15.1a – does not do multicast 15.3 – Had multicast, being revised in current work 15.4 – Had broadcast, being revised to include multicast in current work Tom Siep, Cambridge Silicon Radio

LLC – acts as a block to passing additional (e.g., QoS) parameters Nov 2004 LLC – acts as a block to passing additional (e.g., QoS) parameters All 3 MAC need LLC support to requests to create/modify/terminate streams based on QoS parameters Data needs to be able to be associated with a stream at the MAC SAP QoS changes need to be communicated to the higher layers Need to be able to inquire QoS characteristics of remote nodes Tom Siep, Cambridge Silicon Radio

Mesh (not the same as the .11 issue though) Nov 2004 Mesh (not the same as the .11 issue though) Work in progress in 15.5 Tom Siep, Cambridge Silicon Radio

QoS Block asynchronous data Nov 2004 QoS Block asynchronous data Need block size to plan and allocate resources Tom Siep, Cambridge Silicon Radio

Architectural consistency across three MACs Nov 2004 Architectural consistency across three MACs Relatively consistent in approach, same interface to upper 802 layers Tom Siep, Cambridge Silicon Radio

(Signal) Power/channel management Nov 2004 (Signal) Power/channel management Need a way to pass (up and down) information that is important to wireless, for example Transmit power Regulatory domain Signal quality Coexistence information Other Must be extensible Tom Siep, Cambridge Silicon Radio

{ } Prioritized issues – 802.15 Management Issues Issues Nov 2004 Management Issues Prioritized issues – 802.15 Issues LLC – acts as a block to passing additional (e.g., QoS) parameters QoS (Signal) Power/channel management 64bit to 48 bit address mapping for bridging (new topic) Smaller than 100 octets allowed for minimum packet size Bridging compatibility – handling of multicasts, no clause 6 section for .1D Non-Issues Are PANs different from WLANs? Security Mesh (work TBD) Architectural consistency across three MACs { Not architectural issues } Not addressed at Sunday meeting Tom Siep, Cambridge Silicon Radio

Other Groups Affected LLC – acts as a block  802.1 and 802.2 Nov 2004 Other Groups Affected LLC – acts as a block  802.1 and 802.2 QoS  802.1 and 802.2 (Signal) Power/channel management  802.1 and 802.2 64bit to 48 bit address mapping for bridging  802.1 and 802.2 Smaller than 100 octet packets  802.1 and 802.2 Bridging compatibility – internal problem being worked Tom Siep, Cambridge Silicon Radio

Work to be done by 802.15 Form plans to solve issues Nov 2004 Work to be done by 802.15 Form plans to solve issues Determine feasibility of plans Study proposal to use IETF model for QoS – will it work for .15 TGs? Characterize management function needs Can’t do bridging 64 to 48 bit addresses – are we OK with this? Tom Siep, Cambridge Silicon Radio