Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Layer 2 frame encapsulation } Date Submitted: [9 July, 2004] Source: [Bill Shvodian] Company [Freescale Semiconductor] Address [8133 Leesburg Pike, Suite 700, Vienna, VA 22182, USA] Voice:[703-269-3047], FAX: [703-269-3092], E-Mail:[bill.shvodian @ freescale.com] [Dae-kyu Bae] Company [Samsung Electronics] Address [416 Maetan-3Dong, Yeongtong-Gu, Suwon-City, Gyeonggi-Do, South Korea] Voice:[+82-31-200-3648], FAX: [+31-200-3350], E-Mail:[pango @ samsung.com] Re: [802.15.3b call for contributions] Abstract: [This document describes a new frame format which allows the encapsulation of layer 2 frames in 802.15.3 frames and to identify the proper FCSL for a frame. ] Purpose: [The author wishes the IEEE to consider including this material in the 802.15.3b MAC enhancements.] 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. Bill Shvodian, Freescale, D. K. Bae Samsung

2. Layer 2 frame encapsulation inside an 802.15.3 frame Bill Shvodian, Freescale, D. K. Bae Samsung

3. Overview • The problems • Why this is a MAC layer issue • Isn’t WiMedia’s WiMux going to solve this? • Why the 802.2/SNAP header isn’t the right solution for encapsulation of MAC frames • The proposed solution Bill Shvodian, Freescale, D. K. Bae Samsung

4. Problem 1 • 802.15.3 describes FCSLs sitting above the MAC, but does not provide a mechanism to identify which FCSL format a frame is using. • How is the FCSL for a particular frame identified? • In theory the protocol contained in a stream can be negotiated in advance. However, this may not be ideal • Asynchronous traffic using stream 0 does not have a unique stream index • Different DEVs in the same piconet may have different PALs or even multiple PALs. • One or more of the PALs may use stream 0 for asynchronous traffic including possibly broadcast frames. • It may not always be appropriate to use an LLC/SNAP header. Bill Shvodian, Freescale, D. K. Bae Samsung

5. Multiple FCSLs This Figure is from IEEE 802.15.3-2003 Bill Shvodian, Freescale, D. K. Bae Samsung

6. Problem 2 • 802.15.3 only uses 8 bit DEVIDs in MAC headers to reduce frame header overhead • Each DEV in the piconet handles the translation between MAC address and DEVID • The decision to use DEVID in the headers was made with the understanding that it would impact the ability to do layer 2 addressing beyond the piconet because devices can only address a destination in the piconet, not across multiple piconets or wired LAN segments Bill Shvodian, Freescale, D. K. Bae Samsung

7. Isn’t WiMedia’s WiMux layer going to solve these problems? • Due to new WiMedia secrecy rules WiMedia members can’t tell non-members if it will or if it won’t, or even which MAC is the baseline for WiMedia. Bill Shvodian, Freescale, D. K. Bae Samsung

8. LLC/SNAP Header • We need something like a SNAP header. Can’t the 802.2/SNAP header be used to identify the protocol? • The SNAP in the 802.2/SNAP header identifies the upper layer protocol contained in the packet. Since 802.2 sits above the MAC, an 802.2 frame is encapsulated inside a MAC frame. • It would be inappropriate to put an 802.2 frame inside an Ethernet Frame and then put another 802.2/SNAP header on top of that – it would result in recursive layering. 802.15.3MAC Header LLC/SNAP Header 802.3 MAC Header LLC/SNAP Header IP Datagram Bill Shvodian, Freescale, D. K. Bae Samsung

9. Proposed Solution • Create a new 802.15.3 frame type that provides identification of the FCSL that a frame belongs to • The new frame type will contain a 16 bit field to identify the FCSL type for the frame • This field is similar to the Ethernet Ethertype field and will identify the format of the encapsulated frame. http://standards.ieee.org/regauth/ethertype/ • Modify the MAC SAP to include a parameter to identify the FCSL that the frame is associated with • Allow for an optional encapsulation of a full layer 2 packet including the header Bill Shvodian, Freescale, D. K. Bae Samsung

10. New Frame type • The new frame type includes a 16 bit payload type field. New frame type 802.15.3MAC Header Payload type Payload Example: encapsulated 1394 Frame 802.15.3MAC Header Payload type 1394 frame Payload Example frame: Encapsulated Ethernet 802.15.3MAC Header Payload type 802.3 MAC Header LLC/SNAP Header IP Datagram Bill Shvodian, Freescale, D. K. Bae Samsung

11. Payload type field • Frame type = 101 • The proposed payload type field is 16 bits between the MAC header and the data payload • The IEEE RAC would register payload type the way they register Ethertype for Ethernet Bill Shvodian, Freescale, D. K. Bae Samsung

12. Conclusion • Adding a new frame type that identifies the FCSL of a frame fixes a deficiency in 802.15.3 by allowing a frame to be associated with an FCSL. Bill Shvodian, Freescale, D. K. Bae Samsung