IEEE 802.16m Headers Design
Document Number: IEEE C80216m-09/0481
Date Submitted: 2009-02-27
Source:
Baowei Ji
Email: bji@sta.samsung.com
Phone: +1-972-761-7167
Samsung Electronics
Venue:
IEEE Session #60, Vancouver, Canada
Base Contributions:
Re:
CR for tgmsdd
Purpose:
Notice:
Discussion and Approval
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 .
Headers in 16m SDD (1/2)
 Generic MAC Header
EH (1)
FlowID (4)
Length (3)
Length (8)
 Extended header
Last
Type
(Length : TBD)
TBD
Body Contents
(Variable Length)
 Frag. and packing
headers (FFS)
Slide 1
Headers in 16m SDD (2/2)
 Issues with the Generic MAC Header
• It is contradictory with what said in Section 10.12 “Multiple MAC SDUs
and/or SDU fragments from different unicast connections belonging to the
same AMS can be multiplexed into a single MAC PDU.”, because,
• There is only one Generic MAC Header per MPDU; and only this header
has a FlowID field.
• The “length” field is only of 11 bits, which may not be enough to support a
large MAC SDU.
 Issues with the Extended Header
• Are those Extender Headers used for carrying MAC Management
Messages? In that case, the FlowID for MAC Management is missing from
the header.
Slide 2
Proposed MAC Header
 MAC Header for MAC SDUs
• EH
• if “EH = 0”, no more MAC Header
• else, another MAC Header follows
• LF
• if “LF = 0”, 10-bit length field
• else, 18-bit length field
 No need for specifying MAC Extended Headers.
 MAC Management Messages are differentiated from traffic data by
the MAC Management FlowID(s)
Slide 3
Proposed MAC Headers (cont.)
 If it is desirable to specify a number of special MAC control
messages
• FlowIDs could be used for differentiating those messages; or
• If there is no enough FlowIDs, those messages could be grouped into one
FlowID together with the following morph MAC Header
EH (1)
FlowID (4)
TYPE (TBD)
Length (TBD, may be ommited)
Slide 4
Proposed non-ARQ Header
FI (framing indicator)
• 1st bit tells whether it
starts with a fragment
• 2nd bit tells whether it
ends with a fragment
E (extension bit)
• ‘1’ -> another E+LI pair
• ‘0’ -> no more
SN (sequence number)
LF (LI flag)
• ‘00’ -> 5-bit LI
• ‘01’ -> 7-bit LI
• ‘10’ -> 11-bit LI
• ‘11” -> 16-bit LI
Slide 5
Proposed ARQ Header (RF=“0”)
RF
• ‘0’-> initial transmission
• ‘1’-> re-transmission
with re-fragmentation
P
• ‘0’ -> default
• ‘1’ -> poll for feedback
Slide 6
Proposed ARQ Header (RF=“1”)
LSF (during refragmentation)
• ‘0’-> not the last
segment
• ‘1’-> the last segment
SO (during refragmentation)
The fragment offset
Slide 7
Suggested Text
 Remove Section 10.12.1.1 and 10.12.2
 Add the MAC header format on Slide 3 into Section 10.12.1
 Add the header format on slides 6, 7, and 8 into Section 10.12.2.1
Slide 8