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

[STDS-802-16] =?gb2312?B?UkU6IFtTVERTLTgwMi0xNl0gtPC4tDogW1NURFMtODAyLTE2XSBhIHF1ZXM=?= =?gb2312?B?dGlvbiBvbiBVR1M=?=



You still have the problem that the PHY can be adapting during this time period for this SS and others and there will be dynamic bursty traffic as well.  You'll still throw away half the bandwidth of the systems by concentrating too much on a cellular voice replacement system rather than a broadband wireless system.

-----Original Message-----
From: Lin Zhibin [mailto:linzhibin@HUAWEI.COM]
Sent: Wednesday, March 09, 2005 5:00 AM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] 答复: [STDS-802-16] a question on UGS

Maybe there exists some mechanisms that could both reduce the overload
of DL_MAP and UL_MAP and avoid the bandwidth waste of fixed allocation.
If the UL_MAP_IE and DL_MAP_IE for a UGS service isn't changed, we could
reduce the transmission frequency.  For exmaple, it can be transmitted
every 5 frames instead of every 1 frame. While SS reads DL_MAP and
UL_MAP and found expected IEs lost, it then know that they are not
changed. If BS need reschedule the resource, it can still broadcast new
UL_MAP_IE and DL_MAP_IE in any frame, and SS will know the change
immediately.

Best regard,

Lin Zhibin
Huawei Technologies, Co., LTD.
+86-21-68644808-24028



-----邮件原件-----
发件人: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] 代表 Raja Banerjea
发送时间: 2005年3月9日 0:54
收件人: STDS-802-16@LISTSERV.IEEE.ORG
主题: Re: [STDS-802-16] a question on UGS


The grants are made to the SS on the basic CID and not per connection.
Making grants per connection would increase the overhead substantially.
A conforment SS would use the grants on the basic CID for the traffic
which is of the highest priority. This has the added advantage that the
SS can transmit UGS payload as soon as it receives it and a grants is
available from the BS. I agree with Ken that nailing up a UGS connection
would therefore not reduce the overhead. Regards, -Raja



-----Original Message-----
From: owner-stds-802-16@ieee.org [mailto:owner-stds-802-16@ieee.org]On
Behalf Of Kenneth Stanwood
Sent: Tuesday, March 08, 2005 8:49 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] a question on UGS


Using fixed locations drops us backwards two generations in BWA systems.
It has been shown numerous time over the past 5 years both through
simulations (albeit proprietary and unshared for the most part),
algorithm descriptions, and real systems in the field, that handling the
bursty nature of today's broadband traffic, especially with an adaptive
PHY, if most efficiently handled by dynamic scheduling.  The map
overhead incurred by a good scheduler is less than the bandwidth waste
of a fixed allocation.  Remember also that this is not a voice-only
system.  If all you have is voice, a more simplistic approach works, but
there are already a lot of good systems designed specifically for voice.

Ken

-----Original Message-----
From: albanese@NET.INFOCOM.UNIROMA1.IT
[mailto:albanese@NET.INFOCOM.UNIROMA1.IT]
Sent: Tuesday, March 08, 2005 8:16 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] a question on UGS

Hi all,

I think you could have an increased overhead (fragmentation...) and
scheduler complexity in both cases:
-   with the opportunity of a "permanent" assignment of the BW
-   BW assignment on frame basis.
The increased overhead is a consequence of the lack in the available
bandwidth and of scheduler design choices. In any case, I think that a
"permanent" assignment of the BW for the UGS traffic class can
potentially be a good idea to improve system efficiency.

Best regards
Roberto Albanese


Quoting Itzik Kitroser <itzikk@RUNCOM.CO.IL>:

> Weidong,
>
> You need to think also about the consequences of going in your
approach, and
> possible effect on the scheduler it can cause.
>
> Taking your approach, the scheduler will have to map allocations
"around"
> multiple fixed allocations, which will not necessary be segmented
together,
> this can both increase the complexity of the scheduler and also add
more
> overhead both to the MAP (more entries when fragmenting) and
allocating more
> BW per request, again due to additional fragmentation header.
>
> Regards,
>
> Itzik.
>
>   _____
>
> From: owner-stds-802-16@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of weidong yang
> Sent: Tuesday, March 08, 2005 12:35 AM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] a question on UGS
>
>
> Baraa,
>
> In this case,  the overhead  due to DL_MAP & UL_MAP IEs could be very
> substantial if lots of conversations are going on. (I did a search,
> and found this issue was raised in  IEEE
C802.16e-04/368r2
> by KT & Korea University)
> I don't know whether other people also think this is a serious
problem.
>
> -----Original Message-----
> From: Al Dabagh, Baraa [mailto:baraa.al.dabagh@INTEL.COM]
> Sent: Monday, March 07, 2005 4:05 PM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] a question on UGS
>
>
>
> Correct.
>
>
>
>
>   _____
>
>
> From: owner-stds-802-16@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of weidong yang
> Sent: Monday, March 07, 2005 1:54 PM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: [STDS-802-16] a question on UGS
>
>
>
> Dear all,
>
> I have a question on UGS.
>
> After reading the 802.16-2004 document, I come to the understanding
>
> suppose we want to set up a voice conversation over 802.16-2004,  in
every
> frame (let us assume
>
> the frame duration is 10 ms)  where a downlink burst or an uplink
burst for
>
> that conversation is assigned, the assignment(s) has/have to be
signified
> through DL_MAP and UL_MAP,
>
> there isn't a way to make a "permanent" assignment for that
conversation, so
> the assignments don't have to
>
> be specifed each time in DL_MAP or UL_MAP. Is my understanding
correct?
>
>
>
> Weidong
>
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.