Transcript IEEE C802.16m-08/641

MAC Header Design
Document Number:
IEEE C802.16m-08/641
Date Submitted:
2008-07-07
Source:
Xiao Xu and Hua Xu
Voice:
+1-847-632-2176
Motorola Inc.
E-mail:
[email protected]
Venue:
IEEE 802.16m-08/024: Call for Comments and Contributions on Project 802.16m System Description Document (SDD), on the topic of
“Upper MAC Concepts”.
Base Contribution:
Purpose:
For review and adapt.
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 >.
1
Background and Problem
– Currently for each MAC PDU, 6 bytes are
used for generic MAC header (GMH)
– A lot of header and subheader types are not
organized logically
– These MAC overheads significantly reduces
system capacity, especially for applications
such as VOIP, where the payload is relatively
small.
2
Current Generic MAC Header Structure
3
All the fields in GMH
•
•
•
•
•
•
•
•
•
Header type – only needed when multiple header types are defined.
Clearly, this bit is not needed for DL. Do we need the bandwidth request
header for UL?
Message length – needed when multiple PDUs are sent in one MAC header
CID – if the flow ID (transport CID) is used in the resource allocation, why
do we repeat this at each packet? -- unless the allocation is for multiple
flows. What is the trade-off between making individual allocation for each
MAC PDU vs. concatenate them into one HARQ packets (HARQ CRC,
allocation message, vs. larger MAC header and FSH and PSH)
EC – can be removed from the header and exchange these info during
connection establishment process only. They don’t need to be transmitted
in every MAC PDU.
CI – If only one MAC PDU is sent in each HARQ burst, there is no need of
MAC PDU CRC, there for no need of CI bit.
Type – after moving all the sub-headers to extended subheader format, we
don’t need these Type bits for existing 5 subheaders.
ESF – Keep this bit if we have sub headers
EKS – If encryption is enabled, this 2 bits is needed for every PDU. Can it
be with other encryption entities, such as PN and ICV?
HCS – extra protection for header, with HARQ CRC, this is redundant
4
Proposed MAC Header
• Option 1:
– One small header, such as ESF (1 bit) indicate if sub-headers
are included plus EKS (2 bits) if encryption enabled plut
fragmentation/packing indication field, etc.
– Reorganize all the none GMH headers, subheaders and
extended subheaders into the subheader format
• Option 2:
– Two header types one with payload the other without payload
– Reorganize all the headers, subheaders, and extended
subheaders into the subheader format
• Option 3:
– All the headers, subheaders, and extended subheaders are
headers with the same format starting with the group length field
(8 bits) and header type (8 bits)
5