1. Group resource allocation for DL data Date Submitted 2008-05-05
Project
IEEE Broadband Wireless Access Working Group <
Title
Group resource allocation for DL data
Date Submitted
Source(s)
Xiaoyi Wang
Yousuf Saifullah
Shashikant Maheshwari
Xin Qi
NSN
Andrea Bacioccola
Nokia
Re:
IEEE m-08/016r1: Call for Contributions on Project m System Description Document (SDD).
Target topic: “DL resource allocation”.
Abstract
This contribution proposes group resource allocation method to be used in 16m.
Purpose
For discussion and approval by TGm
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 <

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 m-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. GRA using RAB – coding MCS, and size
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 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.
MCS\ # of slots 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
QPSK-1/2 18 24 30 36 42 48 54 60 66 72 78 84 90
QPSK-3/4 27 45 63 81 99
108
117
126
135
16QAM-1/2 96
120
132
144
156
168
180
16QAM-3/4
162
198
216
234
252
270
64QAM-1/2
64QAM-2/3
192
240
264
288
312
336
360
64QAM-3/4
189
243
297
324
351
378
405

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. 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. 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. 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. GRA using multi-user packet
User detects its own packet through GMH attached for every packet.
Option 1: Concatenation with single CRC
Option 2: Concatenation with individual CRC

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. Proposed Text to be included in SDD
Insert following section in SDD
11.x Group Resource allocation
11.x Group allocation bitmap
11.x Multi User packet