1. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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.

2. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 2 Layer 2 frame encapsulation inside an 802.15.3 frame

3. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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

4. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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.

5. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 5 Multiple FCSLs This Figure is from IEEE 802.15.3-2003

6. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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

7. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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.

8. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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 HeaderLLC/SNAP Header802.3 MAC HeaderLLC/SNAP HeaderIP Datagram

9. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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/ 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

10. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 10 New Frame type 802.15.3MAC HeaderPayload type802.3 MAC HeaderLLC/SNAP HeaderIP Datagram The new frame type includes a 16 bit payload type field. 802.15.3MAC HeaderPayload typePayload New frame type Example frame: Encapsulated Ethernet 802.15.3MAC HeaderPayload type1394 frame Payload Example: encapsulated 1394 Frame

11. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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

12. doc.: IEEE 802.15-04-0317r0 Submission July, 2004 Bill Shvodian, Freescale, D. K. Bae SamsungSlide 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.