Re: [STDS-802-16] a question on UGS
The mechanism in 802.16 work very well in the real world if you know how to write a good scheduler. If you think about how fast the PHY may need to adapt per SS, you realize quickly that we need dynamic allocations to safeguard the underlying signal quality necessary as a foundation of QoS. This is a challenge that does not exist to the same extent in cell phone systems like GSM or CDMA. It also doesn't exist to the same extent in DOCSIS. Adding non-voice traffic aggravates the problem. The standard provides a mechanism to enable high-QoS with low overhead for BROADBAND WIRELESS ACCESS systems with and adaptive physical layer. It self-corrects via intelligent use of aggregate and incremental bandwidth requests, without the overhead and delay of ACKs, for such issues as an SS not hearing a grant, a BS not hearing a request, and an SS using the bandwidth for a slightly different purpose. The protocol has been proven in REAL-WORLD systems to work very well for both VoIP !
and for TCP. There have been proprietary simulations funded at universities that have proven that the protocol works very well.
Obviously, if the only thing you ever wanted to send was voice, there could be a more optimal way.
Additionally, the way the standard has degenerated over that past couple years because of changes forced by companies that didn't understand QoS in an adaptive PHY environment, the current method has morphed into something with map elements much larger than they need to be.
But, we are in a situation where we have a corrigendum that can only accept corrections, not feature changes. 802.16e is in sponsor ballot recirculation, and it is against 802.16 rules to add feature changes at this point. So, on top of the notion of fixed grants being detrimental to efficient bandwidth allocation in an adaptive PHY system that carries bursty as well as more predictable traffic, we are at a point in the standard where there is no place to insert this reversion to the old fixed allocation BWA systems of 7 years ago.
Ken
-----Original Message-----
From: david maez [mailto:dmaez@NAVINI.COM]
Sent: Thursday, March 10, 2005 7:15 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] a question on UGS
on behalf of Dannel Wee
Has anyone considered the implications on the uplink? For the downlink, the DLMAP advantage seems obvious when assuming a packet switched system. However, in the uplink, if uplink bandwidth is not pre-reserved for expected data, this could impact the response time of TCP-ACKs and cause throttling of the TCP sessions. This could affect peak rates of video streams and FTP sessions. I'm wondering what is everyone else's take on this.
Also, should we be concerned that users occupying only a small percent of a system's throughput could potentially reduce your capacity significantly? Imagine that 10% of a 10MHz system could mean over 200 voice channels. This seems uncomfortably similar to the 3G systems which led to the evolution of the DO systems. Perhaps we should consider a method to allow both methods of assignment.
-----Original Message-----
From: Lei Wang [mailto:LWang@CYGNUSCOM.COM]
Sent: Thursday, March 10, 2005 1:47 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] a question on UGS
JianJun and All,
This is exactly the topic that has been extensively/comprehensively discussed in 802.16 group back to about two year ago, that is, grant per SS (GPSS) vs grant per connection (GPC). We used to have both mechanisms in our dot16 standards. After multiple discussions in multiple sessions, we finally came to agree that grant per SS (GPSS) is a better mechanism to minimize the MAP overhead and also leaves flexibility for the SS to utilize the granted bandwidth smartly to meet QoS of multiple active connections.
With grant per SS, as long as there are other active service flows in addition to UGS ones, the extra overhead of MAP IEs for UGS connections is really trivial, because one MAP IE is used for the granted allocations to multiple connections of the same SS. There is no doubt that it would adds more overhead rather than saving if grant per connection would be re-introduced again. Plus, we are talking about systems supporting multimedia applications, not voice-only, so any way there will be other active service flows co-existing with UGS.
Regards,
Lei
-----Original Message-----
From: wujianjun [mailto:wujianjun@HUAWEI.COM]
Sent: Wednesday, March 09, 2005 11:01 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] a question on UGS
I think if the CID of DL_MAP/UL_MAP is traffic connection CID, not Basic CID,
maybe the UGS service connection's resource allocation can appear only one times when
the UGS service connection resouce is not changed.
because when the resource allocation of DL_MAP/UL_MAP aim at SS, you can not insure
only one UGS service connection as to this SS.
Best Regards,
Wujianjun
Huawei technologies Co.,Ltd
phone:+86-21-68644808-24717
mobile:+86-21-13818172348
**********************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended recipient(s)
is prohibited. If you receive this e-mail in error, please notify the sender by phone or
email immediately and delete it!
**********************************************************************************************
----- Original Message -----
From: "david maez" <dmaez@NAVINI.COM>
To: <STDS-802-16@listserv.ieee.org>
Sent: Thursday, March 10, 2005 5:16 AM
Subject: Re: [STDS-802-16] RE: [STDS-802-16] ??: [STDS-802-16] a question on UGS
> I think fixed allocation for short periods also makes in the case where compressed headers are used(only a few bytes is needed for VoIP). Fixed allocation should be an option since the MSS always decodes the DLMAP (allocation can changed/terminated anytime).
>
> -Dave
> -----Original Message-----
> From: Kenneth Stanwood [mailto:kstanwood@CYGNUSCOM.COM]
> Sent: Wednesday, March 09, 2005 2:55 PM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: [STDS-802-16] RE: [STDS-802-16] ??: [STDS-802-16] a question on UGS
>
>
> 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.