1. 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-7167bji@sta.samsung.com Samsung Electronics Venue:IEEE Session #60, Vancouver, Canada Base Contributions: Re: CR for tgmsdd Purpose: Discussion and Approval 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: and.http://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/guides/opman/sect6.html#6.3 Further information is located at and http://standards.ieee.org/board/pat.http://standards.ieee.org/board/pat/pat-material.htmlhttp://standards.ieee.org/board/pat

2. Headers in 16m SDD (1/2)  Generic MAC Header  Extended header  Frag. and packing headers (FFS) Slide 1 EH (1)FlowID (4)Length (3) Length (8)

3. 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

4. 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

5. 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 Slide 4 EH (1)FlowID (4)TYPE (TBD) Length (TBD, may be ommited)

6. Proposed non-ARQ Header Slide 5 FI (framing indicator) 1 st bit tells whether it starts with a fragment 2 nd 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

7. Proposed ARQ Header (RF=“0”) Slide 6 RF ‘0’-> initial transmission ‘1’-> re-transmission with re-fragmentation P ‘0’ -> default ‘1’ -> poll for feedback

8. Proposed ARQ Header (RF=“1”) Slide 7 LSF (during re- fragmentation) ‘0’-> not the last segment ‘1’-> the last segment SO (during re- fragmentation) The fragment offset

9. 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