1 / 10

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.

aram
Download Presentation

Motivations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Motivations

  2. 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 ~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.

  3. 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. GRA using RAB – coding location

  4. 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

  5. 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. Savings Analysis

  6. 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. 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

  8. Data packet size of each MS are flexible Efficient in MAP overhead Better coding gain due to longer encoding length Advantages of multi-user packets

  9. 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 Proposed Text to be included in SDD

More Related