doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 1 Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3-MAC-Architecture-Considerations] Date Submitted: [20Sept00] Source: [Tom Siep] Company [Texas Instruments] Address [12500 TI Blvd, m/s 8723, Dallas, TX 75243, USA] Voice:[ ], FAX: [ ], Re: [Original Document] Abstract:[Discussion of / combination MACs] Purpose:[The purpose of this presentation is to foster discussion on the advisability of tight integration of dissimilar MACs.] Notice:This document has been prepared to assist the 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 2 IEEE Working Group for Wireless Personal Area Networks™ TG3 MAC Architecture Considerations

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 3 Definitions MAC-PAN = Primary or fallback MAC with a Wireless Personal Area Network topology MAC-LAN = Extended function MAC with a Wireless Local Area Network topology

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 4 Fundamental Question: Given that you want multiple MAC functionality, how should the Standard be constructed? –Include MAC-LAN as independent entity –Include MAC-LAN with reference to original –Point to MAC-LAN –Omit MAC-LAN references from MAC-PAN Standard

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 5 Include MAC-LAN as Independent Entity PRO –Severs the tie to external document –Simplifies the isolation of required/optional features CON –Creates a “new”, uncontrolled version of an existing Standard –Blurs distinctions in the Marketplace

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 6 Include MAC-LAN with reference to original PRO –Text to original is included (with option choices) –Allows tight integration CON –Standards will drift apart, rendering the MAC- PAN invalid –Standards may drift towards incompatible versions

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 7 Point to MAC-LAN PRO –Easier to do –Full option set of MAC-LAN Standard available CON –Standards will drift apart, with no control mechanism –Standards may drift towards incompatible versions

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 8 Omit MAC-LAN References from MAC-PAN Standard PRO –Relieves uncontrolled changes –Reduces complexity of MAC description –Does not dictate intra-layer behavior CON –Requires multiple Standards references

doc.: IEEE /288r0 Submission September 2000 Tom Siep, Texas InstrumentsSlide 9 Technical Editor’s Recommendation Omit MAC-LAN References –Coordination of Standards is very difficult -- keeping ONE Standard up to date is hard! –If the reason for inclusion is compatibility with MAC- LAN, version control becomes complex –A coordination of two MAC implementations and two PHY implementations is likely not able to be generalized –Standards should specify behavior sets, if an existing behavior set needs to be added for a product, it can specify both standards