1. Sept 2004
doc.: IEEE a
Nov 2004
Project: IEEE P 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:[ ], FAX: [ ],
Re: [Update to information, based on 13-Mar 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 P 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 P
Tom Siep, Cambridge Silicon Radio
Tom Siep, TMS Associates, LLC

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

3. Intent for 802.1 Arch Committee
Nov 2004
Intent for 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

4. 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

5. Known issues – 802.15 (as presented at Sunday meeting in San Antonio)
Nov 2004
Known issues – (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

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

7. 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 the same)
Tom Siep, Cambridge Silicon Radio

8. 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

9. 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

10. 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

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

12. 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

13. (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

14. { } Prioritized issues – 802.15 Management Issues Issues
Nov 2004
Management Issues
Prioritized issues –
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

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

16. Work to be done by 802.15 Form plans to solve issues
Nov 2004
Work to be done by
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