Proposal for PDU Structure Document Number IEEE S

Proposal for PDU Structure Document Number: IEEE S 802. 16 m-09/0606 Date Submitted: 2009 -03 -02 Source: David Johnston Intel Corporation Venue: Vancouver, March 2008 Base Contribution: Re: IEEE 802. 16 m-08/003 r 7 Purpose: To improve the signaling overhead in MAC PDUs. Notice: E-mail: dj. johnston@intel. com This document does not represent the agreed views of the IEEE 802. 16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802. 16. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: <http: //standards. ieee. org/guides/bylaws/sect 6 -7. html#6> and <http: //standards. ieee. org/guides/opman/sect 6. html#6. 3>. Further information is located at <http: //standards. ieee. org/board/pat-material. html> and <http: //standards. ieee. org/board/pat >.

A Combined PDU Proposal Must Address • Header Format – • Subheader Mechanism – – • Over subheaders or not? Reduced PN? Uplink header protection (AHCS, Reduced CMAC tuple) Management Frame Protection Management flows – – • HCS, AHCS, CRC performance with HARQ CRC Avoiding errored lengths messing up neighbors Encryption format – – • Flow ID in PSH? Error detection big picture – – • PDU_SN? In the GMH or the map? Multiple destinations in same packet PDU or not? – • FPSH, ARQ etc Sub header type in subheader or MAC Header? Null subheader? PDU Ordering, in-order delivery – • Per flow state, SHI, EKS, length, HCS 1 channel? separate arq channel? or keep Primary & Basic Bidirectional flows (reduced flow ID space use) Anonymous transmissions – – Uplink contention flows. Special header format needed? Station. ID Subheader?

PDU Design Proposal • Overview – A small evolution from current text to address header efficiency, decoding efficiency and system complexity. – 2 Byte GMH, based on tweaked SDD GMH – Fixed size signaling PDUs • All subheaders (except fragmentation SH) become fixed size signal PDUs. No non deterministic parsing time. – 3 reserved management connection types, one with ARQ, one without, one with Station ID

Decoding Headers • In this proposal, decision tree to classify PDU type and length is short, bushy and requires inspection of only the first two bytes. Before After Process flow. ID & signal type or Flow. ID EH bit & length. (First two bytes) Inspect EH bit, flow. ID & length Process signal, managemnt Or traffic PDU as necessary Inspect Subheader Type if EH =1 (third byte) Process Different Subheader management or traffic types Iterate through variable size subheaders with loops in them Simple Enough that I would let hardware do it. Not simple Enough that I would let hardware do it.

Benefits • Simpler, Priority Traffic Handling – Since first 4 bits determine the header format and the first two bytes determine the length for all header formats. . Per PDU It is an O(1) process to inspect the first two bytes of the PDU to identify and process the High Priority signals and traffic first. – Current text requires a non deterministic level of processing per PDU, digging multiple bytes into complex, variable size subheaders.

Flows • 4 bit Flow ID – 4 flows reserved for signaling purposes – So 12 transport flows in each direction. – Supports management ARQ, E. G. for EAP traffic. Flow ID Meaning 15 -4 Transport Data Connections 3 Signaling Channel 2 Management PDUs with Station ID 1 Management Connection with ARQ 0 Management Connection without ARQ

Small Tweak to MAC Header • Where Flow ID signals a different header format (E. G. for signaling headers) we do not want the subsequent 12 bits broken into two fields. – So Flow. ID and Subheader Indicator Swapped from current SDD • Before. EH FLOWID[3: 0] LEN[10: 8] LEN[7: 0] • After. FLOWID[3: 0] EH LEN[7: 0] LEN[10: 8]

FSH • Subheader preferably is only a single fragmentation subheader format. – Other things go in signaling headers FLOWID[3: 0] EH=1 LEN[7: 0] FSH [not defined here] LEN[10: 8]

MAC Header with Station. ID • In some cases, we need to encode the Station ID. Flow. ID 2 reserved for this variant PDU header format. 0010 EH LEN[10: 8] LEN[7: 0] Station. ID[15: 8] Station. ID[7: 0] Flow. ID[3: 0] HCS[3: 0]

Signaling Header • All signaling headers are fixed size. Size depends on type. • 15 signaling headers • 255 extended signaling headers • Flow. ID 3 reserved to signal these header formats Type = 0011 SH_Type[3: 0] Type = 0011 SH_Type = 1111 Extended. Type[7: 0]

Signaling PDU Types Example. Normal (for frequent signals) Type Field Name Extended (for less frequent signals) Size 0 Small Bandwidth Request (BR) 4 1 PN 4 2 ICV 9 3 ARQ ACK 3 4 ARQ NACK 4 5 ARQ Feedback Poll 2 Type Field Name Size (bytes) 0 Large BR Request 6 1 ARQ Extended NACK 6 2 ARQ Extended ACK 6 … … 14 Burst end (padding indicator) 1 4 through 255 15 Extended Type Follows 0 … 4 through 13 Reserved

SDD Impacts • Change in SDD – Swap SHI and Flow. ID in 2 bytes header • Define in SDD – Reserved Flows Table (See slide 4) – Header with Station. ID • Point out where such PDU header is used. – Signaling Header format (but not specific signaling headers) • Examples of use – Extended Signaling Header format (but not specific extended signaling header) • Examples of use – ARQ signaling headers (low in detail, unless we agree on the details) • Examples of use – Security encapsulation – in separate security proposal. 09/491