Proposal for PDU Structure
Document Number:
IEEE S802.16m-09/0606
Date Submitted:
2009-03-02
Source:
David Johnston
Intel Corporation
Venue:
Vancouver, March 2008
Base Contribution:
Re: IEEE 802.16m-08/003r7
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/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Further information is located at <http://standards.ieee.org/board/pat/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?
StationID 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 flowID & signal type
or FlowID EH bit & length.
(First two bytes)
Inspect EH bit, flowID & 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 FlowID 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 StationID
• In some cases, we need to encode the Station
ID. FlowID 2 reserved for this variant PDU
header format.
0010
EH
LEN[10:8]
LEN[7:0]
StationID[15:8]
StationID[7:0]
FlowID[3:0]
HCS[3:0]
Signaling Header
• All signaling headers are fixed size. Size depends on
type.
• 15 signaling headers
• 255 extended signaling headers
• FlowID 3 reserved to signal these header formats
Type = 0011
SH_Type[3:0]
Type = 0011
SH_Type = 1111
ExtendedType[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
Reserved
SDD Impacts
• Change in SDD
– Swap SHI and FlowID in 2 bytes header
• Define in SDD
– Reserved Flows Table (See slide 4)
– Header with StationID
• 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