C80216m-09_2941 Slide #1 Re-arrangement of fields in the GRA IEs – Proposed Amendment Text Document Number: IEEE C80216m-09_2941 Date Submitted: Source: Sudhir Ramakrishna, Hyunkyu Yu, Heewon Kang, Zhouyue Pi Venue: Re: Contribution in support of a comment on LB30 Category: AWD Comments Area: Chapter (DL Control) Base Contribution: IEEE C80216m-09_2941 Purpose: To be discussed and adopted by TGm for the m AWD Notice: This document does not represent the agreed views of the IEEE 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 Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and. Further information is located at and.

C80216m-09_2941 Slide #2 Contribution Summary In D3, the GRA design is such that when it is segmented, it is not always possible to tell the GRA size from the 1 st segment alone This contribution proposes to re-arrange the GRA fields, so that the 1 st segment always indicates total size  Simplifies AMS parsing and increases overall reliability by eliminating some error conditions The proposal is illustrated in Slides 3 & 4 The illustrations assume the implementation of the segmentation scheme in C80216m_2575r1; this is for illustration only. The proposal itself is independent of the segmentation scheme in C80216m_2575r1, and can be used with other segmentation schemes, yielding the same benefits The text proposals are on Slides 5 & 6 Text in red strikethrough font = to be removed, text in blue underlined font = to be added, text in black = to be retained as in D3

C80216m-09_2941 Slide #3 Current Design – Cannot always calculate number of “segments” from 1 st “segment” alone Possible lengths of “User Bitmap” are 4, 8, 16 or 32. From a knowledge of “User Bitmap”, possible to know the lengths of the variable length fields, i.e., it is possible to know the lengths of the “MIMO Bitmap” and the “Resource Assignment Bitmap” fields. This is because these lengths can be calculated from number of “1”s in “User Bitmap”. Hence, knowledge of “User Bitmap”  we know total length (number of bits) of IE  we know how many “segments” the IE is partitioned into It would be desirable to calculate number of segments from 1 st segment alone. Consider example where “User Bitmap” is 32 bits long. 40 bits, 1 st segment 1 bit, set to “1” Indicates this is 1 st segment. Proposal in C80216m_2575r1 IE Type 4 bits Resource Offset 7 bits HFA Offset 6 bits User Bitmap 1 st 22 bits (out of 32) CRC 16 bits 40 bits, 2 nd segment 1 bit, set to “0” Indicates this is not the 1 st segment. IE Type 4 bits User Bitmap Last 10 bits (out of 32) CRC 16 bits Bits from “MIMO Bitmap” and /or Resource Assignment Bitmap”. Number of bits depends on number of “1”s in “User Bitmap” More segments Number of segments depends on number of “1”s in “User Bitmap” “User Bitmap” not entirely in 1 st segment  Not possible to calculate number of segments from 1 st segment alone

C80216m-09_2941 Slide #4 Modification – Change order in which fields appear HFA Offset 6 bits 40 bits, 1 st segment 1 bit, set to “1” Indicates this is 1 st segment. Proposal in C80216m_2575r1 IE Type 4 bits Resource Offset 1 st 3 bits (out of 7) User Bitmap All 32 bits CRC 16 bits 40 bits, 2 nd segment 1 bit, set to “0” Indicates this is not the 1 st segment. IE Type 4 bits CRC 16 bits Bits from “MIMO Bitmap” and /or Resource Assignment Bitmap”. Number of bits depends on number of “1”s in “User Bitmap” More segments  Number of segments depends on number of “1”s in “User Bitmap” “User Bitmap” entirely in 1 st segment  Possible to calculate number of segments from 1 st segment alone SyntaxSize in bits A-MAP IE Type4 User BitmapVariable Resource Offset7 HFA Offset6 If(Group MIMO mode set == 0b01){ MIMO BitmapVariable } Resource Assignment Bitmap Variable Resource Offset Last 3 bits (out of 7) Modified IE Structure; Change Position of “User Bitmap” All else remains the same (i.e., all fields/sizes/interpretations remain the same) Same example, i.e., “User Bitmap” is 32 bits long (= longest length for this field) Now, entire “User Bitmap” always fits into 1 st segment Hence by above position change, “User Bitmap” always appears in 1 st segment  can always calculate number of segments from 1 st segment alone Will help in processing, detecting/reducing error conditions

C80216m-09_2941 Slide #5 Text Proposal 1 – Modify Table 825 “DL group resource allocation A-MAP IE” on Page 435 in Section of D3 as follows.

C80216m-09_2941 Slide #6 Text Proposal 2 – Modify Table 826 “UL group resource allocation A-MAP IE” on Page 436 in Section of D3 as follows.