IEEE C802.16m-09/0782r1
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
MAC Header Restructure
Date
Submitted
2009-04-30
Source(s)
Joey Chou
Muthaiah Venkatachalam,
Sassan Ahmadi,
Xiangying Yang,
Jose Puthenkulam,
Jie Hui,
Intel
Re:
TGm SDD: SON
Abstract
This contribution proposes text for MAC header restructure.
Purpose
Adopt proposed text.
Notice
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>.
E-mail: joey.chou@intel.com
MAC Header Restructure
Joey Chou, Muthaiah Venkatachalam, Sassan Ahmadi, Xiangying Yang, Jose Puthenkulam, Jie Hui,
Intel
I.
Introduction
IEEE 802.16 GMH has been loaded with excessive features in the previous amendments
1
IEEE C802.16m-09/0782r1
and revisions. In order to support many advanced features in 802.16m efficiently, the
restructure of the MAC header is needed. Here are some guidelines for the MAC header
restructure:

Reuse – The restructure should take into account the reuse of existing MAC
management and signaling messages in order to minimize the impacts to
802.16Rev2 standard.

Efficiency – The existing GMH is 6 bytes long that is extremely inefficient in
sending small singling messages. The new header structure should take into
account not only the size of the message, but also how often a message is sent.

Flexibility – The existing MAC header has two many layers identified by the
subtypes that are not flexible to support new features.
802.16Rev2 MAC Header Structure
Since reuse is one of the guidelines, we first look at the MAC header structure in its base
standard 802,16Rev2 that can be divided into the following categories:


Per PDU, per SDU subheader, extended subheader (Figure 1, Figure 3)
o
Packing
o
Fragmentation
o
MAC management message
UL MAC Signaling Header Type I & Type II without data payload (Figure 2 &
Figure 4)
HT=0, EC=0
GMH UL/DL MAC
PDU with data
payload
no encryption
HT=0, EC=1
GMH UL/DL MAC
PDU with data
payload
with encryption
Type Bit #0
DL – FFSH (8 bits), UL – GMSH (7 or 16 bits)
Type Bit #1
PSH (16 or 24 bits)
Type Bit #2
FSH (8 or 16 bits)
Type Bit #3
Extended for Non-ARQ connection
Type Bit #4
ARQ feedback(variable)
Type Bit #5
Reserved
Figure 1: GMH UL/DL MAC PDU with data payload
2
IEEE C802.16m-09/0782r1
HT=1, EC=0
UL MAC PDU w/o
payload
Type #0
BR incremental (19 bits + CID)
Type #1
BR aggregate (19 bits + CID)
Type #2
PHY channel report (19 bits + CID)
Type #3
BR with UL power report (19 bits + CID)
Type #4
BR and CINR report (19 bits + CID)
Type #5
BR with UL sleep control (19 bits + CID)
Type #7
SN report (11 bits + CID)
Type #6
CQICH allocation report (19 bits + CID)
Figure 2: UL MAC Signaling Header Type I without data payload
HT=0, EC=0
ESF = 0
No extended
subhedader
HT=0, EC=1
DL Ext SubHeader
HT=1, EC=0
HT=1, EC=1
UL Ext SubHeader
ESF = 1
Extended
subheader
Type #0
SDU_SN (8 bits)
Type #1
DL sleep control (24 bits)
Type #2
Fast feedback control (24 bits)
Type #3
SN request (8 bits)
Type #4
PDU SN short (8 bits)
Type #5
PDU SN long (16 bits)
Type #6-127
Reserved
Type #0
MIMO mode feedback (8 bits)
Type #1
UL Tx Power Report (8 bits)
Type #2
Mini-feedback (16 bits)
Type #3
PDU SN short (8 bits)
Type #4
PDU SN long (16 bits)
Type #5
Persistent allocation error event (8 bits)
Type #6
ertPS resumption bitmap (8 bits)
Type #7-127
Reserved
Figure 3: GMH UL/DL Extended Subheaders
3
IEEE C802.16m-09/0782r1
Type #1
Reserved
HT=1, EC=1
DL: compressed DL-MAP
UL: MAC PDU w/o payload
Type #0
Type #0
CQI & MIMO feedback (9 bits)
Type #1
DL average CINR (5 bits)
Type #2
MIMO Coeff feedback (9 bits)
Type #3
Preferred DL Channel (8 bits)
Type #4
UL Tx Power (8 bits)
Type #5
PHY Channel feedback (18 bits)
Type #6
AMC band indication (32 bits)
Type #7
Short-term precoding feedback (4 bits)
Type #8
Multiple types of feedback (variable max 32 bits)
Type #9
Long-term precoding feedback (14 bits)
Type #10
Combined DL Avg. CINR (5 bits)
Type #11
MOMO channel feedback (32 bits)
Type #12
CINR feedback (16 bits)
Type #13
Closed-loop MIMO feedback (max 26 bits)
Type #14-15
Reserved
Figure 4: UL MAC Signaling Header Type II without data payload
802.16Rev2 MAC Header Structure
Flow ID (4)
EH (1)
LEN (3)
LEN (8)
Figure 5: Generic MAC header format
Figure 5 is the generic MAC header, as defined in the current SDD. Flow ID is 4 bits long,
and is defined as the following to address up to 16 service flows.

0000: MAC signaling channel

0001: MAC management channel

0010: L2_transfer channel

0011 – 1011: MAC data transport

1100 – 1111: reserved
MAC Signaling Header
4
IEEE C802.16m-09/0782r1
EH (1)
=1
Flow ID (4) = 0000
LEN (3)
LEN (8)
SigType (5)
SigLen (3)
SigLen = 1
MAC Sigaling Data (8)
SigLen = 2
MAC Sigaling Data (8)
SigLen = 3
MAC Sigaling Data (8)
SigLen = 4
MAC Sigaling Data (8)
SigLen = 5
MAC Sigaling Data (8)
Figure 6: MAC Signaling Header
Figure 6 defines the MAC signaling header to support UL MAC Signaling Header Type I &
Type II without data payload, as shown in Figure 2 & 4. Type I and Type II signaling data
ranges from 5 bits to 32 bits. MAC Signaling Header can scale from 2 to 6 bytes that can
support up to 40 bits signaling data.

Flow ID: = 0000

EH: = 1 to indicate the existence of MAC signaling header

SigType: is 5 bits long, and can represent up to 32 MAC signals

SigLen: indicates the length of MAC signaling data in bytes, 3 bits long with
the maximum value of 5 to dynamically support signaling data up to 40 bits
MAC Payload with Extended Header
Flow ID (4) = 0011 - 1011
EH (1)
=0
LEN (3)
LEN (8)
MAC Payload Data (8)
LEN
MAC Payload Data (8)
Figure 7: MAC Payload Data without Extended Header
5
IEEE C802.16m-09/0782r1
Figure 7 shows the format of MAC payload data that does not include any headers or
extended headers. The MAC payload channels are identified by flow ID 0011 – 1011.
10.12.2 and 10.12.2.1 define the Extended Header and fragmentation / packing header
that will be present when EH bit is set in GMH. It is not possible to have one EH bit to
indicate two headers. 802.16Rev2 has EH, FSH, and PSH bits to support extended header,
fragmentation, and packing headers.
MAC Payload Data with Extended Header & Fragmentation / Packing Header
Flow ID (4) = 0011 - 1011
EH (1)
=1
LEN (3)
LEN (8)
EHLen (8)
Rsvd
EHType (7)
EHType specific Data (8)
EHLen
FPH
=1
EHType (7)
EHType specific Data (8)
SN (8)
SN (2)
FC (2)
FLen (4)
FLen (7)
Rsvd
MAC Fragment Data (8)
Flen
MAC Fragment Data (8)
Figure 8: MAC Payload Data with Extended Header & Fragmentation / Packing Header
Figure 8 shows a MAC payload data that includes extended header and fragmentation /
packing header to support per PDU, per SDU subheader, and extended subheader, as
shown in Figure 2 & 4. The extended header is changed slightly from the Extended
Subheader of 802.16Rev2 (in Fig 35) since a single EH bit is used to control the colocation of the extended header and fragmentation / packing header. The format of the
extended header is described below.
6
IEEE C802.16m-09/0782r1

EHLen: 8 bits long to indicate the length of extended headers

EHType: indicate the type of the extended header

EHType specific data: payload specific to each extended header type

FPH: is only present in the last extended header. When FPH = 1, indicates the
presence of fragmentation / packing header; FPH = 0, no fragmentation / packing
header
The format of the fragmentation / packing header is described below.

SN: fragment sequence number, 10 bits long

FC: Fragmentation control bits, 2 bits long

FLen: the length of each fragment, 11 bits long
MAC Payload Data with Fragmentation / Packing Header
Flow ID (4) = 0011 - 1011
EH (1)
=1
LEN (3)
LEN (8)
EHLen (8) = 0
SN (8)
SN (2)
FC (2)
FLen (4)
FLen (7)
Rsvd
MAC Fragment Data (8)
Flen
MAC Fragment Data (8)
Figure 9: MAC Payload Data with Fragmentation / Packing Header
Figure 9 show a MAC payload data with fragmentation / packing header. EHLen = 0
means the extended header is missing.
7
IEEE C802.16m-09/0782r1
MAC PDU
GMH
EH =
1,
LEN
=a
FPEH
SN = P
FC = 2,
FLEN =
b
FPEH
SN = 0
FC = 0,
FLEN =
c
Last
fragment
of MAC
SDU #1
unfragmented
MAC SDU #2
FPEH
SN = 0
FC = 0, unfragmented
FLEN = MAC SDU #3
d
…
FPEH
SN = 1
FC = 1,
FLEN =
e
1st fragment
MAC SDU #N
a = b + c+ d + e + size(FPEH) * 4
MAC PDU
GMH
EH =
1,
LEN
=a
FPEH
SN = x
FC = 3, Continuing
FLEN = fragment
of MAC
b
SDU #1
MAC PDU
FPEH
SN = 0
FC = 0, unfragmented
FLEN = MAC SDU #2
c
GMH
EH =
1,
LEN
=d
MAC PDU
FPEH
SN =
Continuing
x+1
FC = 3, fragment
FLEN = of MAC
SDU #1
e
..
GMH
EH =
1,
LEN
=f
FPEH
SN =
Continuing
x+2
FC = 3, fragment of
FLEN = MAC SDU
#1
g
a = b + c + size(FPEH) * 2
Figure 10: Fragmentation / Packing examples
MAC management Message without Fragmentation
Figure 10 shows an example of MAC payload with fragmentation and packing.
EH (1)
=0
Flow ID (4) = 0001
LEN (3)
LEN (8)
MAC Management Data (8)
LEN
MAC Management Data (8)
MAC Management Data (8)
Figure 11: MAC Management Message without fragmentation
Figure 11 shows the format of MAC management message without fragmentation.

Flow ID = 0001

EH = 0
MAC management Message with Fragmentation
8
IEEE C802.16m-09/0782r1
Flow ID (4) = 0001
EH (1)
=1
LEN (3)
LEN (8)
SN (8)
SN (2)
FC (2)
FLen (4)
FLen (7)
Rsvd
MAC Management Data (8)
FLen
MAC Management Data (8)
MAC Management Data (8)
Figure 12: MAC Management Message with fragmentation
Figure 12 shows the format of MAC management message with fragmentation.
II.

Flow ID = 0001

EH = 1
Proposed text
10.12.1 MAC header formats
10.12.1.1 Generic MAC Header
Flow ID (4)
EH (1)
LEN (3)
LEN (8)
Figure 22 Generic MAC header format

FlowID (Flow Identifier): This field indicates the service flow that is addressed. This field is
4bits long, and is defined as the following to address up to 16 flows.

0000: MAC signaling channel

0001: MAC management channel

0010: L2_transfer channel

0011 – 1011: MAC data transport
9
IEEE C802.16m-09/0782r1

 1100 – 1111: reserved
EH (Extended Header Presence Indicator): When set to ‘1”, this field indicates that an
Extended Header is present following this GMH.

Length: Length of the payload. This field is 11bits long
10.12.1.3 MAC Payload without Extended Header
Figure 23 shows the format of MAC payload data that does not include any headers or
extended headers. The MAC payload channels are identified by flow ID 0011 – 1011.
Flow ID (4) = 0011 - 1011
EH (1)
=0
LEN (3)
LEN (8)
MAC Payload Data (8)
LEN
MAC Payload Data (8)
Figure 23: MAC Payload Data without Extended Header
10.12.1.4 MAC Management Message without Extended Header
EH (1)
=0
Flow ID (4) = 0001
LEN (3)
LEN (8)
MAC Management Data (8)
LEN
MAC Management Data (8)
MAC Management Data (8)
Figure 24: MAC Management Message without fragmentation
Figure 24 shows the format of MAC management message without fragmentation.

Flow ID = 0001

EH = 0
10.12.2 Extended header
10
IEEE C802.16m-09/0782r1
The inclusion of extended header is indicated by EH indicator bit in MAC Header. The EH format is
shown in Figure 24 and will be used unless specified otherwise.
Figure 24 Extended Header Format



Last: When the “Last” bit is set, this extended header is the last one. If this bit is not set, another
extended header will follow the current extended header.
Type: indicates the type of extended header. The length is TBD.
Body Contents: Type-dependent contents.
10.12.2.1 MAC Payload with Extended Header and Fragmentation and packing
extended header
Figure 25 shows a MAC payload data that includes extended header and fragmentation /
packing header. This fragmentation and packing extended header is shown in Figure 25. This
header shall be used when MAC PDU contains single transport connection payload. The location of
this header exists after the last extended header ( i.e. extended header with ‘Last’ = ‘1’) if ‘EH’ in
GMH set to ‘1’ or after the GMH if ‘EH’ in GMH set to ‘0’.
Flow ID (4) = 0011 - 1011
EH (1)
=1
LEN (3)
LEN (8)
EHLen (8)
Rsvd
EHType (7)
EHType specific Data (8)
EHLen
FPH
=1
EHType (7)
EHType specific Data (8)
SN (8)
SN (2)
FC (2)
FLen (4)
FLen (7)
MAC Fragment Data (8)
Flen
MAC Fragment Data (8)
11
Rsvd
IEEE C802.16m-09/0782r1
Figure 25: MAC Payload Data with Extended Header & Fragmentation / Packing Header
The format of the extended header is described below.

EHLen: 8 bits long to indicate the length of extended headers

EHType: indicate the type of the extended header

EHType specific data: payload specific to each extended header type

FPH: is only present in the last extended header. When FPH = 1, indicates the
presence of fragmentation / packing header; FPH = 0, no fragmentation / packing
header
Figure 25 Fragmentation and packing extended header format for transport connection
The format of the fragmentation / packing header is described below.

SN (10 bits): Payload sequence number

FC (2 bits): Fragmentation control bits definition is given in Table 2.

End (1 bit): If this bit set to ‘0’, another ‘Length’ and ‘End’ field are followed. If this bit set
to ‘1’, reserved bits may follow for byte alignment

FLenLength (11bits): This field represents the length of SDU/SDU fragment. If a payload
consists of ‘N’ SDU/SDU fragments, N-1 length fields are present in the header

Rsvd: Reserved bits for byte alignment.
FC
00
01
10
11
Meaning
The first byte of data in the MPDU payload
is the first byte of a MAC SDU. The last byte
of data in the MPDU payload is the last byte
of a MAC SDU.
The first byte of data in the MPDU payload
is the first byte of a MAC SDU. The last byte
of data in the MPDU payload is not the last
byte of a MAC SDU.
The first byte of data in the MPDU payload
is not the first byte of a MAC SDU. The last
byte of data in the MPDU payload is the last
byte of a MAC SDU.
The first byte of data in the MPDU payload
is not the first byte of a MAC SDU. The last
byte of data in the MPDU payload is not the
last byte of a MAC SDU.
Examples
One or Multiple Full SDUs packed in an
MPDU
a) MPDU with only First fragment of an SDU
b) MPDU with one or more unfragmented
SDUs, followed by first fragment of
subsequent SDU
a) MPDU with only Last fragment of an SDU
b) MPDU with Last fragment of an SDU,
followed by one or more unfragmented
subsequent SDUs
a) MPDU with only middle fragment of an
SDU
b) MPDU with Last fragment of an SDU,
followed by zero or more unfragmented
SDUs, followed by first fragment of a
subsequent SDU
Table 2 Fragmentation control information
12
IEEE C802.16m-09/0782r1
MAC PDU
GMH
EH =
1,
LEN
=a
FPEH
SN = P
FC = 2,
FLEN =
b
FPEH
SN = 0
FC = 0,
FLEN =
c
Last
fragment
of MAC
SDU #1
unfragmented
MAC SDU #2
FPEH
SN = 0
FC = 0, unfragmented
FLEN = MAC SDU #3
d
…
FPEH
SN = 1
FC = 1,
FLEN =
e
1st fragment
MAC SDU #N
a = b + c+ d + e + size(FPEH) * 4
MAC PDU
GMH
EH =
1,
LEN
=a
FPEH
SN = x
FC = 3, Continuing
FLEN = fragment
of MAC
b
SDU #1
MAC PDU
FPEH
SN = 0
FC = 0, unfragmented
FLEN = MAC SDU #2
c
GMH
EH =
1,
LEN
=d
MAC PDU
FPEH
SN =
Continuing
x+1
FC = 3, fragment
FLEN = of MAC
SDU #1
e
..
GMH
EH =
1,
LEN
=f
FPEH
SN =
Continuing
x+2
FC = 3, fragment of
FLEN = MAC SDU
#1
g
a = b + c + size(FPEH) * 2
Figure 26: Fragmentation / Packing examples
10.12.2.2 MAC Payload with fragmentation and packing extended header
Figure 27 show a MAC payload data with fragmentation / packing header.

EH = 1 indicates the presence of extended header and fragmentation / packing
header

EHLen = 0 means the extended header is missing.
Flow ID (4) = 0011 - 1011
EH (1)
=1
LEN (3)
LEN (8)
EHLen (8) = 0
SN (8)
SN (2)
FC (2)
FLen (4)
FLen (7)
MAC Fragment Data (8)
Flen
MAC Fragment Data (8)
13
Rsvd
IEEE C802.16m-09/0782r1
Figure 27: MAC Payload Data with Fragmentation / Packing Header
10.12.2.3 MAC Management Message with Fragmentation extended header
Figure 28 shows the MAC management message with fragmentation / packing header.

Flow ID = 0001

EH = 1

SN (10 bits): Payload sequence number

FC (2 bits): Fragmentation control bits definition is given in Table 2.

Rsvd: Reserved bits for byte alignment.

FLen(11 bits): length of the MAC management message fragment
EH (1)
=1
Flow ID (4) = 0001
LEN (3)
LEN (8)
SN (8)
SN (2)
FC (2)
FLen (4)
FLen (7)
Rsvd
MAC Management Data (8)
FLen
MAC Management Data (8)
MAC Management Data (8)
Figure 28: MAC Management Message with fragmentation / packing header
10.12.3 MAC Signaling header
Figure 29 defines the MAC signaling header that is used to send short or real time
signaling messages.

Flow ID: = 0000

EH: = 1 to indicate the existence of MAC signaling header
14
IEEE C802.16m-09/0782r1

SigType: is 5 bits long, and can represent up to 32 MAC signals

SigLen: indicates the length of MAC signaling data in bytes, 3 bits long with
the maximum value of 5 to dynamically support signaling data up to 40 bits.
Flow ID (4) = 0000
EH (1)
=1
LEN (3)
LEN (8)
SigType (5)
SigLen (3)
SigLen = 1
MAC Sigaling Data (8)
SigLen = 2
MAC Sigaling Data (8)
SigLen = 3
MAC Sigaling Data (8)
SigLen = 4
MAC Sigaling Data (8)
SigLen = 5
MAC Sigaling Data (8)
Figure 29: MAC Signaling Header
15