Group Resource Allocation
Document Number:
IEEE C80216m-08/289r4
Date Submitted:
2008-07-07
Source:
Xiaoyi Wang,
Yousuf Saifullah
Shashikant Maheshwari
Xin Qi
Haihong Zheng
Nokia Siemens Networks
Andrea Bacioccola
Nokia
Heping Li Dongjie, No.11
Beijing, China
Voice:
IEEE C80216m-08/289r4
+8613511021252
E-mail: xiaoyi.wang@nsn.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:
<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 >.
1
IEEE C80216m-08/289r4
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
2
IEEE C80216m-08/289r4
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 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.
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
3
IEEE C80216m-08/289r4
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.
4
IEEE C80216m-08/289r4
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
A
0
1
G
3
D
C
2
A
C
B
D
A
3
B
1
C
3
D
8
sub-channel index
G
1
B
15
0
1
2
13
slot index
5
IEEE C80216m-08/289r4
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.
6
IEEE C80216m-08/289r4
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.
7
IEEE C80216m-08/289r4
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.
User1
G
M
H
Data
User2
C
R
C
G
M
H
Data
User3
C
R
C
G
M
H
Data
User4
C
R
C
G
M
H
Data
C
R
C
Encoded together
8
IEEE C80216m-08/289r4
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
9
IEEE C80216m-08/289r4
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.
10