<author>, <company>

Slides:



Advertisements
Similar presentations
November 2010 doc.: IEEE e Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: LB60 comment.
Advertisements

June 16, 2018 doc.: IEEE r0 January, 2005
Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for adding a version number and for the treatment.
Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for adding a frame version number and for the.
Submission Title: [Resolution on comment #20,22 and 30]
Submission Title: [Add name of submission]
<month year> doc.: IEEE <# > <April 2008>
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Add name of submission] Date Submitted:
doc.: IEEE <doc#>
October 2017 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [AES-256 for ] Date Submitted: [17.
October 2017 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [AES-256 for ] Date Submitted: [17.
doc.: IEEE <02/139r0> <January 2002> May, 2009
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Considerations on general MAC frame] Date Submitted:
doc.: IEEE <doc#>
NOV 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Application Specific Information Element] Date.
March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Toumaz response to TG6 Call for Applications]
<month year> doc.: IEEE < e>
March 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [SG SECN Call for Proposals] Date Submitted:
doc.: IEEE <doc#>
<May,2009> doc.: IEEE <doc .....> <July 2009>
doc.: IEEE <doc#1>
<doc.: IEEE −doc>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improved Delayed ACK response Frame for.
doc.: IEEE <doc#>
< November, 2011 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [More Low Energy Mechanism Details]
doc.: IEEE <doc#>
May 2009 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ 1-octet MAC Header frame types ] Date Submitted:
Submission Title: [Resolution on comment #20,22 and 30]
November 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [MAC for Secure Ranging] Date Submitted:
January 2010 doc.: IEEE /0825r2 January 2010
Submission Title: [WG WNG Liaison Report January08]
<author>, <company>
November 2009 doc.: IEEE /0825r0 November 2009
<author>, <company>
<month year> doc.: IEEE <xyz> November 2000
<author>, <company>
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
Submission Title: [Frame and packet structure in ]
<month year>20 Jan 2006
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Considerations on general MAC frame] Date Submitted:
<month year> doc.: IEEE < e>
May 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Delayed Negative Acknowledgement (Dly-NACK)]
doc.: IEEE <doc#>
<month year> <January 2019>
March 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [DF6 Radio-burst length over PSDU size] Date.
doc.: IEEE <doc#>
doc.: IEEE <doc g>
July 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Modified Delayed (Dly) Acknowledgement for.
doc.: IEEE < IETF>
<month year> doc.: IEEE <030158r0> <March 2003>
<author>, <company>
doc.: IEEE < IETF>
June, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [OFDM PHY Mode Representation] Date Submitted:
doc.: IEEE < IETF>
September 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Suggested TG3c PAR Changes] Date Submitted:
doc.: IEEE <doc#>
<author>, <company>
August, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improve the latency between GTS request.
Jan 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Call for THz Contributions Date Submitted: January.
Submission Title: TG9ma Agenda for September Meeting
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: 14 August,
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: 14 August,
Jan 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TeraHertz Closing Report Date Submitted: January.
12/15/2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [AWGN Simulation Results] Date Submitted:
Presentation transcript:

<author>, <company> <month year> October 2018 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE P802.15.13 – Variable MAC frame format using information elements Date Submitted: 23 Okt. 2018 Source: Kai Lennert Bober, Volker Jungnickel [Fraunhofer HHI] Address: Einsteinufer 37, 10587 Berlin, Germany Voice:[+49-30-31002 302], E-Mail:[kai.lennert.bober@hhi.fraunhofer.de] Voice:[+49-30-31002 768], E-Mail:[volker.jungnickel@hhi.fraunhofer.de] Re: Abstract: Purpose: Contribution to IEEE P802.15.13 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. Kai Lennert Bober, HHI <author>, <company>

IEEE P802.15.13 Variable MAC frame format using information elements <month year> October 2018 IEEE P802.15.13 Variable MAC frame format using information elements Date: 2018-10-23 Authors: Kai Lennert Bober, HHI <author>, <company>

October 2018 Content This doc. contains a proposal to introduce variable information elements (IEs) in the MAC frame, similar to the MAC frame defined by IEEE 802.15.4. Kai Lennert Bober, HHI

Current state of the MAC frame October 2018 Current state of the MAC frame The general MAC frame format was covered in documents 15-18-0185-01-0013 15-18-0269-00-0013 15-18-0270-05-0013 Frame formats for management and control frames were proposed in document 15-18-0393-02-0013 Kai Lennert Bober, HHI

Latest proposed general MAC header format October 2018 Latest proposed general MAC header format General MAC frame format Octets: 2 0/2   6 0/6 0/2 0/5/6/10 /14  variable 4 Frame control ACK information Receiver Address Transmitter Address Auxiliary Address 1 Sequence control Auxiliary Address 2 Auxiliary security header Frame payload FCS MHR MSDU MFR Frame control field ACK information field Bits: 0-1  2-7 8 9 10 11 12 13-15 Frame version Frame type / subtype To backhaul From backhaul Security enabled ACK request ACK info Reserved Bits: 0-4 5-13 14-15 Device address Sequence number ACK Sequence control field Auxiliary security header Bits: 0-3 4-15 Fragment Number Sequence number ? Kai Lennert Bober, HHI

Open questions regarding frame fields October 2018 Open questions regarding frame fields Some polling-specific functionality is present in the general MAC frame format. Can we omit it for the reservation-based scheme? Can the short address be reintroduced in the MAC frame header? Is the Auxiliary Address 2 ever used? Why does the device address in the ACK info field only have 5 bits? Is it required at all? Why 2 bits for ACK? ACK, NACK, ? If we have a fragment number in the MAC header, we also need at least a “more fragments” bit. Kai Lennert Bober, HHI

Auxiliary Security Header October 2018 Option 1: restructure MAC frame format based on the use of information elements MAC header includes core information Information required for specific purposes is kept in so called Information Elements (IEs) Variable number of IEs is added between “core header” and payload Octets: 2 2/6 0/2 variable 4 Frame control Receiver Address Transmitter Address Sequence Control Auxiliary Security Header IEs Frame Payload FCS Header IEs Payload IEs MHR MSDU MFR Kai Lennert Bober, HHI

Essential fields contained in “core header” October 2018 Essential fields contained in “core header” Frame control field Bits: 0-1  2-7 8 9 10 11 12-15 Frame version Frame Type / Subtype Short Address Used Sequence Enabled Security Enabled IEs Present Reserved Sequence control field Bits: 0-3 4 5-15 Fragment Number More Fragments Sequence Number Auxiliary security header field TBD Kai Lennert Bober, HHI

Move specific fields into IEs in header and in payload October 2018 Move specific fields into IEs in header and in payload Header IE format: Payload IE format: Bits: 0-6 7-14 15 Octets: 0-127 Length in octets Element ID Type = 0 Content Bits: 0-6 7-14 15 Octets: 0-127 Length in octets Element ID Type = 1 Content Example: IE Content for ACK IE Bits: 0-48 5-13 14-15 Device Address Sequence Number ACK Other IEs: Backhaul integration (auxiliary address fields) … Kai Lennert Bober, HHI

Auxiliary Security Header October 2018 Option 2: preserve currently proposed MAC frame header and only add IEs Keep the proposed general MAC header But: (re-)enable short representation for receiver and transmitter addresses via bit in frame control Add optional header and payload IEs after MAC header Add „IEs present“ field to Frame Control Add addressing mode field to Frame Control Octets: 2 0/2  2/6 0/2/6 0/6 0/2 variable 4 Frame Control ACK Information Receiver Address Transmitter Address Auxiliary Address 1 Sequence Control Auxiliary Address 2 Auxiliary Security Header IEs Frame Payload FCS Header IEs Payload IEs MHR MSDU MFR Kai Lennert Bober, HHI

What happens with the frame type? October 2018 What happens with the frame type? If IEs are used, why do we need a frame type? In theory, a single general MAC frame format could be used with all types of frame For further discussion… Kai Lennert Bober, HHI