1. July 2012 Robert Moskowitz, Verizon
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Data size and other constraints accommodations
Date Submitted: July 18, 2012
Source: Robert Moskowitz, Verizon
Address 1000 Bent Creek Blvd, MechanicsBurg, PA, USA
Voice:+1 (248) ,
Re: Data size and other constraints accommodations
Abstract: MAC constraints that may limit L2R and how to accommodate them
Purpose: Inform L2R of MAC constraints and how to accommodate them within the MAC
Notice: This document has been prepared to assist the IEEE P 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 P
Robert Moskowitz, Verizon

2. Data size and other constraints accommodations
July 2012
Data size and other constraints accommodations
Robert Moskowitz
San Diego, CA
July 19, 2012
Robert Moskowitz, Verizon

3. Abstract L2R Forwarding Management
July 2012
Abstract
L2R Forwarding Management
Facts about the MAC that can impact L2R design
And impacted design
How has accommodated these constraints
How L2R can 'borrow' from
Robert Moskowitz, Verizon

4. Forwarding Management Needs
July 2012
Forwarding Management Needs
Maintaining forwarding information requires sending information between the forwarding nodes
This information tends to be big
This information is NOT for 'higher layer' processing
In what way(s) is this a challenge in ?
Robert Moskowitz, Verizon

5. Troublesome facts about 802.15.4 MAC
July 2012
Troublesome facts about MAC
does not support different classes of data payloads
All is left to the 'upper layer'
For example cannot support Zigbee 1.0 and 2.0 in the same PAN
MPDU is 127 bytes pre 4g
And even 4g devices MAY use a small MPDU
has no LLC
Removed with sundown
Robert Moskowitz, Verizon

6. Troublesome facts about 802.15.4 MAC
July 2012
Troublesome facts about MAC
These MAC constraints REQUIRE a unique approach for L2R support
Robert Moskowitz, Verizon

7. 802.15.9 Approach Use data payload Information Element
July 2012
Approach
Use data payload Information Element
IE processed before any data passed to 'higher layer'
Thus a traffic selector
Design IE format to support fragments of content
Use forced ACK to ensure delivery of all IE 'fragments'
4g and 4k will limit use of fragmentation
But necessarily not eliminate it
Robert Moskowitz, Verizon

8. July 2012
MAC and IE Formats
Robert Moskowitz, Verizon

9. More on 15.4e Information Elements
July 2012
More on 15.4e Information Elements
15.4e Information Elements
Use data payload IEs (not header IEs)
Larger payload length
Header IEs limited to 127 bytes
Need IE type assignment
MLME Nested limited to 255 bytes
Only 5 values available
Robert Moskowitz, Verizon

10. 802.15.9 Information Element Frame format IE header IE content
July 2012
Information Element
Frame format
IE header ID
Length
IE content
Control Field – 1 byte
KMP fragment
Robert Moskowitz, Verizon

11. KMP Information Element
July 2012
KMP Information Element
Octets: 1
Octets:
Bits: 1 7
KMP Fragment
Chaining flag
0 = last/only one
1 = yes, chaining
First packet: Multipurpose ID
Other packets: Chain count
Multipurpose ID:
98 = KMP
Chaining count: 2-96
2 = 2nd fragment
3 = 3rd fragment …
96 = 96th fragment
(last possible)
Robert Moskowitz, Verizon

12. L2R Leveraging 802.15.9 work Multipurpose ID = 99 July 2012
Robert Moskowitz, Verizon

13. July 2012
Open Discussion
Robert Moskowitz, Verizon