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

RE: stds-80220-requirements: New Material: Priority Access




When I teach QoS to my class, I use these as terms of reference:
	- bandwidth efficiency
	- latency, interactivity
	- jitter
	- determinism
You could argue for other terms but these are sufficient to make the
principle point: no free lunch.

If you want to optimize bandwidth efficiency -- certainly a laudable
goal in some instances -- then you'll be trading off everything else to
get it.  Including any mechanisms that would provide priority access (a
decrease in latency).  If you need to optimize priority access, you can
do that too, but it will be purchased at the expense of bandwidth
efficiency.  
	The means to this control is the design and the configuration of the
MAC.  A timeslice (TDM) access system coupled with a scheduling
algorithm can provide determinism, control jitter and allow you to trade
off b/w efficiency vs latency by the way you configure it (by
controlling what we used to call token holding times in token LANs)

In a packet switched system, the notions of 'bumping' don't make much
sense.  The lower priority customer/application simply waits longer for
access and gets less of it when it is his turn.  



Do we need some QoS control (which at layer two boils down to access
control)?  Definitely.  

On Mon, 2003-10-27 at 12:09, Jim Tomcik wrote:
> At 04:42 PM 10/24/2003 -0700, Chickinsky, Alan wrote:
> 
> >Jim-
> >
> >can we say that Priority Access is a case of QOS?
> 
> Alan,
> 
> I was considering whether QoS was sufficient, but I fear it might not 
> be.  To deal with priority access there are several items to consider, some 
> of which involve MAC, in particular.
> 
> 1.  QoS support is certainly part of the picture; its needed to control the 
> flow of data to/from a Mobile Terminal in the presence of network congestion.
> 
> 2.  I don't think QoS covers the ability of the infrastructure to bump 
> (i.e. terminate connected service to) already connected terminals in an 
> overloaded system when priority-authorized stations are trying to gain 
> access.  This function isn't as simple as a disconnect, either.  Most MTs 
> today will retry until they succeed, thus keeping the access mechanism 
> clogged up.
> 
> 3.  QoS doesn't seem to cover the MAC issue of allowing/granting a subset 
> of so-authorized MTs to contend for access to the wireless medium when many 
> un-authorized MTs may be trying to access the medium too.
> 
> Marc, to achieve items 2 and 3 above, I think this might have to be be a 
> device-type authorization issue.  From an infrastructure viewpoint, there 
> has to be some way to sort out devices trying to get access to the system.
> 
> Jim
> 
> 
> >alan
> >
> >-----Original Message-----
> >From: James Tomcik [mailto:jtomcik@qualcomm.com]
> >Sent: Friday, October 24, 2003 5:55 PM
> >To: 'Stds-80220-Requirements (E-mail)'
> >Subject: stds-80220-requirements: New Material: Priority Access
> >
> >
> >
> >As I review the requirements document, I realize that the requirement for a
> >priority access mechanism has been lost.  Accordingly, please re-include
> >the following in an appropriate section:
> >
> >x.x.x  Priority Access Mechanism
> >
> >The Air Interface shall provide priority access to authorized Mobile
> >Terminals.
> >
> >
> >Rationale:
> >
> >In emergency situations, wireless communications systems typically are
> >overloaded very quickly, making communication among emergency personnel
> >nearly impossible.  This requirement provides for support to these critical
> >communication situations.  This is becoming a requirement in other
> >commercial systems and should be also carried into 802.20's air interface.
> >
> >............................................................................
> >......
> >
> >                 James D. Tomcik
> >                 QUALCOMM, Incorporated
> >                 (858) 658-3231 (Voice)
> >                 (619) 890-9537 (Cellular)
> >                 From:  San Diego, CA
> >                 PGP: 5D0F 93A6 E99D 39D8 B024  0A9B 6361 ACE9 202C C780
> >............................................................................
> >......
> 
> ..................................................................................
> 
> 		James D. Tomcik
> 		QUALCOMM, Incorporated
> 		(858) 658-3231 (Voice)
> 		(619) 890-9537 (Cellular)
> 		From:  San Diego, CA
> 		PGP: 5D0F 93A6 E99D 39D8 B024  0A9B 6361 ACE9 202C C780
> ..................................................................................
-- 
b