1. IEEE C80216m-08/289r5 1 Group Resource Allocation Document Number: IEEE C80216m-08/289r5 Date Submitted: 2008-07-07 Source: Xiaoyi Wang, Voice:+8613511021252 Yousuf Saifullah Shashikant Maheshwari Xin Qi Haihong Zheng Nokia Siemens Networks E-mail: xiaoyi.wang@nsn.comxiaoyi.wang@nsn.com Andrea Bacioccola Nokia Heping Li Dongjie, No.11 Beijing, China Kevin Power Fujitsu E-mail: Kevin.power@uk.fujitsu.com Venue: IEEE 802.16m-08/024: Call for Contributions on Project 802.16m System Description Document (SDD). Base Contribution: N/A Purpose: Discussion and approval by TGm for the 802.16m SDD 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/pat-material.htmlhttp://standards.ieee.org/board/pat

2. IEEE C80216m-08/289r5 2 Motivations Current 16e resource allocation results in too high overhead to feed large amount of users. Persistent allocation could reduce overhead in some scenarios. However there are other issues e.g. there might be holes in resource, the scheduling algorithm is complicated. In the discussion of control channel design we need to consider efficient resource allocation methods The SRD requirements (IEEE 802.16m-08/002r4) necessitate efficient control channel signaling design with capability of accommodating a large numbers of users 16m should provide various type of resource allocation methods for different traffic classes with low overhead We are proposing Group Resource Allocation (GRA) methods with two variants: –Using RAB (Resource Allocation Bitmap) – suitable for small payload size, e.g. VoIP –Using multi-user packet

3. IEEE C80216m-08/289r5 3 GRA using RAB – coding MCS, and size MCS\ # of slots123456789101112131415 QPSK-1/261218243036424854606672788490 QPSK-3/4918273645546372819099108117126135 16QAM-1/21224364860728496108120132144156168180 16QAM-3/41836547290108126144162180198216234252270 64QAM-1/21836547290108126144162180198216234252270 64QAM-2/324487296120144168192216240264288312336360 64QAM-3/4275481108135162189216243270297324351378405 Resource Allocation Bitmap (RAB) optimizes Location & size, CID, and MCS for an allocation Coding MCS and full size –For example, VoIP has packet interval time of 20 msec and packet size of ~48 bytes. If we consider retransmission, then we can have 96 bytes every 40ms –Considering the payload, we can say that we are interested in 80-110 bytes with number of slots < 15. For the mandatory CC case red entries shows this case. –As we can see there are only 15 cases that match the requirements, and 4 bits are enough to cover information of allocation size and MCS.

4. IEEE C80216m-08/289r5 4 GRA using RAB – coding location Coding location of the allocation –Take a specified number of bits for indicating different options of the allocations –for example with 4 bits it is possible to have 16 optional locations which should be enough in most of the cases since different bitmaps (and locations) could be assigned in beginning of the connection to different terminals. –The codec of that 4 bits should be negotiated during connection setup process. Thus for a regular size payload, e.g. VoIP, MCS, size, and location can be coded in 1 byte.

5. IEEE C80216m-08/289r5 5 GRA using RAB – coding connections Divide active connections into groups Using a bitmap indicate which group is active in a frame For the active groups, append a bitmap (in the order of group id) for indicating which connections of the group are active. For each active connection, append the code for the location, size, and MCS

6. IEEE C80216m-08/289r5 6 Savings Analysis In 16m, resource allocation are done in each sub-frame or concatenated sub-frame. Here we consider one DL sub-frame as example. we could have 10*3=30 slots in DL per sector (5MHz bandwidth PUSC with reuse factor=3, FFT size=1024). Now if we have user with mandatory CC coding and 64QAM-3/4 (highest MCS in WiMAX) it means that there are 27 bytes per slot. Therefore we would need to have an allocation of 5 slots in every 20ms when user is active (talking period) and no allocations when user is inactive (silent period). This would mean that in worst case there could be 48 bit MAP overhead for DL and 38 bits for UL for each user. DL-MAP must be sent with QPSK-1/2 (= 6 bytes/slot) and possibly with a repetition coding 4. The total signaling overhead is 7.16 slots (4*(48+38)/(8*6)) for each user. One paired sub-frames can only accommodate 2 (Int(30/(7.16+5)))VoIP users. When using GRA with RAB. the overhead of MAP for each user is 8 bits for DL-MAP and 8 bits for UL-MAP. The total signaling overhead is 4*(8+8)*/(8*6)=1.3 slots for each user. One paired sub-frames can accommodate 3 (int(30/(1.3+5))) VoIP users. Thus the overhead of DL-MAP would be ~5 times smaller than with the current regular DL-MAP of WiMAX. This would improve VoIP capacity significantly.

7. IEEE C80216m-08/289r5 7 GRA using multi-user packet Users are assigned to different groups with a group id based on MCS. Group id is informed to every user in the group. BS uses Group id to allocate resource to a particular group. DL data packets from all users in this group are encoded together. Multi-user packet is transmitted by BS using assigned group resources. Group Resources are either static, semi-static or dynamic. Every user in this group shall decode this multi-user packet, and navigate to its own packet.

8. IEEE C80216m-08/289r5 8 GRA using multi-user packet Group id is included in the DL MAP. The error detection code (e.g., CRC) for each MPDU in the multi-user packet is masked with MS Id (refer to contribution C80216m-08/645). MS in the group decodes the entire multi-user packet first and detects its own packet by verifying the masked error detection code.

9. IEEE C80216m-08/289r5 9 Advantages of multi-user packets Data packet size of each MS are flexible Efficient in MAP overhead Better coding gain due to longer encoding length

10. IEEE C80216m-08/289r5 10 Proposed Text to be included in SDD Insert following section in SDD 11.x.6.2.3.1.2.1 Group messages A group message allocates resources to multiple users. Each group is associated with a set of resources, which are allocated to individual users of the group by the group message. VoIP is an example of the subclass of services that use group messages. If data from different MSs is encoded together, Group messages shall indicate group id, MCS, resource location and size to whole group. If data from different MSs is encoded separately, Group message should further indicate the MCS/size/location of each MS.