1. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Report on 802 Architecture Ad Hoc] Date Submitted: [18 March 05] Source: [Tom Siep] Company [Cambridge Silicon Radio] Address [1651 N. Collins Blvd. Suite 210 Richardson Texas, 75080, USA] Voice:[+1 972 469 766 8680], FAX: [], E-Mail:[tom.siep@csr.com] Re: [Original document.] Abstract:[Results of 802.15 Ad Hoc meeting on 802 Architecture] Purpose:[Brief WG on ad hoc meeting] 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.

2. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 2 Dot15 architecture ad hoc Carry forward from Sunday meeting Call for (wireless) action Dot 15 issues: –User-driven needs –QoS –Addressing –Management –LLC –Bridging/Multicasts

3. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 3 Prioritized issues – 802.15 (review of previous presentation) Issues 1.LLC – acts as a block to passing additional (e.g., QoS) parameters 2.QoS 3.(Signal) Power/channel management 4.64bit to 48 bit address mapping for bridging (new topic) 5.Smaller than 100 octets allowed for minimum packet size 6.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 Management issues { Not addressed at Sunday meeting Not architectural issues }

4. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 4 Call for (wireless) action The current 802 architecture activity is essentially a discussion forum No concrete outputs (those which change the overall architecture) are envisioned from this group We believe that the 802 wireless community has an common interest in ensuring that the issues discussed at this ad hoc are solved Action: contact other wireless groups and set up a meeting at the next interim to discuss how to go forward with an architecture that meets the needs of heterogeneous networks

5. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 5 User-driven needs People who will be setting up networks in the future will no longer primarily be systems administrators – It is required that there be no user configuration Users’ QoS expectations are not satisfied by current models –When the user connects to a wire, wireless QoS is lost –QoS between different wireless systems has no commonality

6. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 6 QoS There is a fundamental question: What is “802 QoS”? No standard method for heterogeneous networks to communicate QoS information exists Wireless problems are the same as wired, only amplified by an order of magnitude We need a “system solution” for heterogeneous networks

7. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 7 Where does QoS belong? Where do the components of QoS belong? –Admissions control –Link quality feedback –Enforcement Which entity has the required information readily available? –If not MAC, then common signaling mechanisms must be in place –If in MAC, must be consistent across media (uniform parameters)

8. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 8 Addressing 64/48 bit addresses must be able to be interconnected by users, transparently “Bridging” (in the 802.1 sense) between 64/48 bit address domains is not possible Another solution must be standardized. Possibly by: –L3 bridges –Concealed routers

9. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 9 Management There is a need for a general way of connecting heterogeneous networks for “higher layer services” Management must be specified for all 802’s – it should be in scope for 802 architecture activity

10. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 10 LLC LLC strategy: Repair --or-- Abandon LLC describes the data path, but the management path is more important

11. doc.: IEEE 802.15- 15-05-0173-00-0000 Submission March 2005 Tom Siep, Cambridge Silicon RadioSlide 11 Bridging/Multicasts 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