Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] DL_MAP_IE/UL_MAP_IE Overhead for Voice Applications



A potential solution to this problem is the use of reduced private maps. 
Private maps are not broadcast, but unicast to a specific users. A 
private map can point to an allocation in a subsequent frame, and this 
allocation can itself contain another private map, thereby setting up a 
"chain" of recurring allocations. In addition, private maps have a 
"periodicity" feature. Using this feature, the allocations can be made 
to repeat automatically, without the use of an explicit private map, 
thereby generating allocations without any map overhead.

For example, with a 20 msec codec rate, if we assume 5 msec frames, a 
periodic private map chain can be set up to repeat allocations every 
fourth frame.

These private maps are described in 802.16e amendment-- see section 
8.4.5.8. (Note that there are several flavors of private maps, but only 
the flavor described in 8.4.5.8 of 802.16e contains the periodicity 
feature.)

Arvind

Galata Kulesi wrote:
> I will appreciate if someone can elaborate on the question below.
> 
> According to what is understood from the standard document (October 2004 
> version), in OFDMA, the BW allocation of all transmissions (UL or DL) 
> should be indicated in the MAP message.
> A Data region indication in the DL_MAP consumes 6.5 bytes and similarly 
> a data burst indication in the UL-MAP consumes 4 bytes.
> An ordinary compressed voice packet (not VoIP) at 10 Kbps with 
> compression window of 20 msec is 25 Bytes.
> Ignoring the MAC header overhead, in the DL, such a voice application 
> necessitaes ~20% DL-MAP overhead and in the UL it necessitates ~14% 
> overhead. (All of it is loaded onto the DL transmission). (If we 
> consider the MAC header - 6 Bytes - , the overhead is ~33% and ~28% 
> respectively.) All these, without taking into consideration the encoding 
> rate, the repetiotion and etc.
> Does the standard suggests any method to reduce this huge overhead?
> 
> Regards
> Galata
> 
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search! 
> http://search.msn.com/