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

[STDS-802-16] Fw: [802-11TGK] Service Load in BSS load element



I wanted to bring this topic to the attention of the 802.16 community, 
especially to Netman TG contributors and participants. Additional metrics 
are likely to be requested by 802.21 and others as we move down this path.

Thanks,
Phillip Barber

----- Original Message ----- 
From: "Phillip Barber" <pbarber@broadbandmobiletech.com>
To: <Michael.G.Williams@nokia.com>
Cc: <vivek.g.gupta@intel.com>; <ajayrajkumar@lucent.com>; 
<xiaoyu.liu@samsung.com>
Sent: Wednesday, December 14, 2005 7:37 PM
Subject: Re: [802-11TGK] Service Load in BSS load element


> 802.16 does not currently have anything similar. There is a course metric 
> for percentage air interface loading that was added to 16g, but that is 
> all. But 802.16 does not have anything similar to what you are discussing.
>
> In the past, vendors have not wanted to include such metrics because the 
> thought them relatively unrevealing, that the precision and value depended 
> on the specific implementation and method of measurement, and that they 
> constrained implementation without providing adequate benefit. Of course, 
> that is for 802.16-2004 and 802.16e that only have a single operator 
> network and single operator mobility in mind. As with 802.21, metrics and 
> other methods that made little sense premised on a single network 
> assumption begin to become at least interesting, if not vital, for 
> cross-network handover; much more so on cross-technology handover.
>
> I will bring this to the attention of the 802.16 community for discussion.
>
> Thanks,
> Phillip Barber
> Chief Scientist
> Broadband Wireless Solutions
> Huawei Technologies Co., LTD.
>
>
> ----- Original Message ----- 
> From: <Michael.G.Williams@nokia.com>
> To: <pbarber@broadbandmobiletech.com>
> Cc: <vivek.g.gupta@intel.com>; <ajayrajkumar@lucent.com>; 
> <xiaoyu.liu@samsung.com>
> Sent: Wednesday, December 14, 2005 2:42 PM
> Subject: FW: [802-11TGK] Service Load in BSS load element
>
>
> Hi Phil,
>
> Do you see .21 being able to create a notion of average load on an edge
> node that is useful as an abstraction to higher layers? .11 uses the
> following, how does it compare to .16?
>
> BR,
> Michael
>
> ________________________________
>
> From: ***** IEEE stds-802-11-tgk List *****
> [mailto:STDS-802-11-TGK@LISTSERV.IEEE.ORG] On Behalf Of ext Joe Kwak
> Sent: Wednesday, December 14, 2005 12:14 PM
> To: STDS-802-11-TGK@LISTSERV.IEEE.ORG
> Subject: Re: [802-11TGK] Service Load in BSS load element
>
>
> --- This message came from the IEEE 802.11 Task Group K Technical
> Reflector --- Hi Srini and others,
>
> The TGk BSS Load element contains summary metrics describing AP service
> loads
> in terms of average medium access delays experienced for transmitted
> traffic
> at different Access Categories (AC).  The average is computed over many
> transmitted frames
> (200 minimum) and thus will have resolution in the sub-microsecond
> range.  Simulations
> (ref: p22 of 05/0079r1) have shown that the access delay range of
> interest is from
> 50usec (a DIFS period) to 5.5msec.
>
> One of the purposes of the loading metric is to be able to compare AP
> loading at any AC of interest
> between two or more roaming candidate APs.  As a comparative metric, the
> resolution needs to be fine
> enough to evaluate differences between APs operating anywhere along the
> loading
> range from 50usec to 5.5msec.  For this reason a logarithmic scaling is
> used.
> Using a convenient 1 octet length for the metric and scaling across 252
> values (steps) provides
> microsecond resolution (step size) at the 50 usec end of the range, and
> 100usec resolution
> (step size) at the 5.5msec end of the range.
>
> Several other LB78 commenters had questions about this and about the
> logarithmic
> scaling details.   In the next version of the TGk draft, the scaling for
> this
> new access delay metric will be explicitly defined. This explicit
> definition
> can be found in 05/1260r0, which has been uploaded to the server.
>
> I hope this information has answered your questions.
>
> Best regards,
> Joe Kwak
>
>
> At 12:29 PM 12/12/2005 -0800, Srinivas Kandala wrote:
>
>
> --- This message came from the IEEE 802.11 Task Group K
> Technical Reflector --- 
>
> I have a question on the Service Load.
>
>
>
> From what I can understand, if the queue is not blocked, it
> appears that the encoded value = exp [delay in milliseconds].
>
>
>
> Is this correct? If it is correct, can someone clarify the
> motivation behind such an encoding scheme? I could not understand why
> the resolution should be at a microsecond level, when the delay is over
> 5 milliseconds.
>
>
>
> Thanks.
>
> Regards,
>
> Srini
>
>
>
> ---
>
> Srinivas Kandala
>
> Airgo Networks, Inc.
>
> Ph: (650) 475-1977
>
>
>
> ________________________________________________________________________
> _______
>
> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT
> send your request to this CLOSED reflector. We use this valuable tool to
> communicate on the issues at hand.
>
> SELF SERVICE OPTION: Point your Browser to -
> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGK and then
> amend your subscription on the form provided. If you require removal
> from the reflector press the LEAVE button.
>
> Further information can be found at:
> http://www.ieee802.org/11/Email_Subscribe.html
> ________________________________________________________________________
> _______
>
> ________________________________________________________________________
> _______
>
> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
> request to this CLOSED reflector. We use this valuable tool to
> communicate on the issues at hand.
>
> SELF SERVICE OPTION: Point your Browser to -
> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGK and then
> amend your subscription on the form provided. If you require removal
> from the reflector press the LEAVE button.
>
> Further information can be found at:
> http://www.ieee802.org/11/Email_Subscribe.html
> ________________________________________________________________________
> _______
>
>