C80216m-08_xxx

Project IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>

Title Group resource allocation for DL data

Date Submitted

2008-05-05

Source(s) Xiaoyi WangYousuf SaifullahShashikant MaheshwariXin QiNSN

E-mail: xiaoyi.wang@nsn.com yousuf.saifullah@nsn.com shashi.Maheshwari@nsn.com xin.qi@nsn.com

Re: IEEE 802.16m-08/016r1: Call for Contributions on Project 802.16m 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 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>.

2

C80216m-08_xxx

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

C80216m-08_xxx

GRA using RAB – coding MCS, and size

MCS\ # of slots 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

QPSK-1/2 6 12 18 24 30 36 42 48 54 60 66 72 78 84 90

QPSK-3/4 9 18 27 36 45 54 63 72 81 90 99 108 117 126 135

16QAM-1/2 12 24 36 48 60 72 84 96 108 120 132 144 156 168 180

16QAM-3/4 18 36 54 72 90 108 126 144 162 180 198 216 234 252 270

64QAM-1/2 18 36 54 72 90 108 126 144 162 180 198 216 234 252 270

64QAM-2/3 24 48 72 96 120 144 168 192 216 240 264 288 312 336 360

64QAM-3/4 27 54 81 108 135 162 189 216 243 270 297 324 351 378 405

• 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 ~60 bytes. If we consider retransmission, then we can have 120 bytes every 40ms

– For allocation and size we can say that we are interested in 100-140 bytes with number of slots < 15. For the mandatory CC case red entries shows this case.

– As we can see there are only 14 cases that match the requirements, and 4 bits are enough to cover information of allocation size and MCS.

4

C80216m-08_xxx

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.

• Thus for a regular size payload, e.g. VoIP, MCS, size, and location can be coded in 1 byte.

5

C80216m-08_xxx

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

slot index

sub-

chan

nel i

ndex

0

1

2

15

0 1 2 13

A

A3

B1

C3

D8

A

B

C

D

G1

G3

C

B D

6

C80216m-08_xxx

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

C80216m-08_xxx

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

C80216m-08_xxx

GRA using multi-user packet

• User detects its own packet through GMH attached for every packet.

GMH

DataGMH

DataGMH

DataCRC

GMH

Data

User1 User2 User3 User4CRC

CRC

CRC

Multi user

Header

GMH

DataGMH

DataGMH

DataGMH

Data

User1 User2 User3 User4

CRC

Option 1: Concatenation with single CRC

Option 2: Concatenation with individual CRC

9

C80216m-08_xxx

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

C80216m-08_xxx

Proposed Text to be included in SDD

Insert following section in SDD

11.x.5.2.4 Group Resource allocation

11.x.5.2.4.1 Group allocation bitmap

11.x.5.2.4.2 Multi User packet