Re: [STDS-802-16] a question on UGS
Hi,
Newbie to 802.16 - I used to work on DOCSIS systems quite some time back.
Agree that the GPSS mechanism allows the SS to make intelligent
decisions on how to divide the UL grant between the SDUs awaiting
transmission. A great example is UGS - in DOCSIS when a UGS grant is
made (DOCSIS supports GPC only), if there is no SDU waiting for the
UGS connection, the grant is wasted. And conversely, if a UGS SDU is
waiting and there is a grant for another connection, this grant cannot
be used for transmitting the UGS SDU.
GPSS resolves this problem by leaving the decision to the entity that
has the best information to make it - SS. This helps lower the latency
for UGS (and other higher priority connections') SDU transmissions and
possibly make best use of UL grants from BS.
The downside of GPSS mechanism is that the BS now has no clue about
how the bandwidth is divided between connections by SS. It is possible
that the BS made a UL grant for RTPS connection but the grant was used
up for a UGS connection. BS has no idea about this and hence may end
up not granting the RTPS connection any more bandwidth (over the
minimum rate) - ultimately, it so becomes that the RPTS connection
suffers till it gets a grant at a later point of time. It would be
interesting to see a simulation of multiple connections per SS using
up each other's UL grants.
Another issue with GPSS is that the BS has no idea of the MAC
overheads in the transmissions from the SS. BS may make a grant for a
single 200 byte MPDU (thinking it is a 190 byte SDU with 10-byte MAC
header). Consider that the SS uses this for 2 93-byte SDUs (with 2
2-byte packing SH and 10 byte MAC header). For QoS settings like
minimum reserved rate, this becomes a nightmare situation since BS
does not have an idea of the exact number of payload bytes that SS has
used for transmission.
An additional problem is that of bandwidth requests - when a unicast
UL grant is received by SS, it has to cancel the request times for all
connections that made a request previously. This is because the SS has
no idea whether its request was received by BS or not and the UL grant
CID does not resolve this conundrum. This can cause higher access
(incoming SDU time to actual transmission) latency compared to a GPC
scenario just because in GPC, the timers are cancelled only when a
grant is received for the connection making the request.
All in all, GPSS and GPC both have their pros and cons - GPC serves
DOCSIS reasonably well.
Kalash
On Wed, 9 Mar 2005 23:46:51 -0800, Lei Wang <LWang@cygnuscom.com> wrote:
> 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.
>