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

Re: [802.19] WhiteSpace Coexistence Use Cases



Ben,
 
speaking for myself, thank you for your thoughtful and helpful comments.
 
I will respond to your questions. 
 
The Study Group decided to have fairly well-defined scopes for its tasks --- which I view as a good thing.
 
It is my recollection that the purpose of the Coex Use Cases document is to identify the Use Case scenarios, and to also include in it an assessment of how various technologies coexist.  This can be seen in Section 4 of the document, with the red-green matrix.  This is where the "identify potential limitations" wording comes from in the sentence I added, and upon which you commented was negative and with good insight you asked, "why only examine limitations?"  These are great comments and questions, and the reason is simply this is what the group decided the scope of THIS particular document should be; it is a step in the work flow for this group.  More analysis and perhaps developing solutions or improvements is then a logical next step (and is in our work plan).
 
I believe this addresses your excellent question about why the limitation... it is only a limitation in our Step One. 
 
I like your redlines in the second sentence, and believe "enhance" is a better choice.  I hope that the authors of the document will use the wording I suggested, but alter it as you have suggested.
 
About your question relating to "develop mechanisms," in honesty I did not originate that language --- I was only trying to keep the gist of the idea that was already in that paragraph --- about work which would or could follow this first step document.  I added the wording about possible modifications to base standards, because that is directly from our work plan (my recollection --- I did not actually go back and check Steve's document or the minutes on this, I admit). 
 
I like your questioning of what is meant by "develop mechanisms," because I too had some reluctance over that terminology.  I would rather be more specific than overly general, and this sounds a bit funny to me when you really try to interpret what it means.  I personally would rather stick with commenting on standards.  I would like to hear more about exactly what others mean when they have written "...developing mechanisms that can be used by industry..."
 
I suggest in response to your question about what is meant by "develop mechanisms," that it would be an improvement for this paragraph to just stop at the last comma, making that a period.
 
As such, the new proposed wording:
 
The purpose of this document is to identify and examine potential limitations on operation and use of the White Space spectrum when more than one radio technology is attempting to use a band.  A goal is to lay the foundation for further investigations into the feasibility and effort required to operate devices more efficiently in such coexistence situations in the White Space.  Such future work enabled by this document may include investigation of modifications to base standards to enhance efficient White Space use.
 
later, tjk
 
 


From: Benjamin A. Rolfe [mailto:ben@xxxxxxxxxxxxxx]
Sent: Wednesday, June 10, 2009 8:25 AM
To: Thomas Kolze; STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: Re: [802.19] WhiteSpace Coexistence Use Cases

Some editorial remarks in red.  Not intended to be contentious,  just trying to help ;-).  I agree that this is a more specific description of purpose than the CBer reference, which is vague at best and meaningful mostly to people beyond a certain age.   Better instead to keep it simple and clearly state the problem - interference will be a limiting factor on capacity in Whitespace (did I get it right?). 
 
I think that making the goal of 19 to recommend potential tweaks to existing standards and to produce coexistence recommendations (as a recommended practice perhaps) makes good sense and fits nicely the role of dot-19.  Coexistence guidance for development of new 802 standards is clearly within the scope of dot-19, as would be I think application and deployment recommendations as well.
 
Not sure I got your other points, but agree it is useful to catalogue the likely technologies that will come to play in WS, identify the coexistence properties of each, and define some likely usage scenarios, which will enable the kind of coexistence analysis we're used to doing (provide separation distance, tx power, antenna characteristics, etc). Which then can lead to concrete recommendations.  Makes sense to me. 
 
Hope that helps.
-Ben
 
----- Original Message -----
From: "Thomas Kolze" <tkolze@xxxxxxxxxxxx>
To: <STDS-802-19@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, June 09, 2009 1:35 PM
Subject: Re: [802.19] WhiteSpace Coexistence Use Cases
 
 

> Richard, Mark, Alex,
>
> I propose the following wording for the third paragraph of Section 1. Introduction:
>
> The purpose of this document is to identify and examine potential limitations on operation and use of the White Space spectrum when more than one radio technology is attempting to use a band. 
 
Only going to examine limitations? seems very negative...perhaps I've missed the point. 
 
A goal is to lay the foundation for further investigations into the feasibility and effort required to operate devices more efficiently in such coexistence situations in the White Space.  Such future work enabled by this document may include investigation of modifications to base standards to achieve (acheive or enhance?) efficient White Space use, or development of mechanisms that can be used by industry in White Space spectrum to improve efficiency. 
 
By "develop machanisms" do you mean the result will be a recommended practices or some other kind of standards document?  Might as well be specific as there is a finite number of things an 802 WG can produce.
 

>
> As reference, the current wording in Document 26r1 IS:
>
> The purpose of this document is to lay the foundation for developing mechanisms that can be used by industry in White Space spectrum to prevent the type of problems suffered by the Citizen Band (CB).  In the CB bands, interference became such an issue that wide spread use ceased and low cost widely available equipment became uneconomic.
>
> --- --- ---
>
> DISCUSSION
>
> Firstly, the proposed wording change addresses correctly (I believe) what the purpose and goals of this document are as decided by the Study Group decisions/polls.  I believe this proposed wording is not contentious, but time will determine that.
>
> Secondly, I would like more discussion before the group sets in stone the reference to "the type of problems suffered by the Citizen Band (CB)."  I believe the CB reference is a very effective statement for use informally within our Study Group, as we try to explain concepts and get at the heart of problems as we grapple with them, but upon reflection I am questioning this wording and analogy in an official document from our Study Group.  The CB reference misses the mark for our study, in my opinion, on several key points:
>
> 1) CBs are entirely one technology attempting to share bands, and the CB technology is not separate technologies attempting to coexist, which is what we are dealing with in TV Whitespace. 
>
> 2) The "type of problem encountered" by CBs in the '70s, which is what I believe is being referenced in the existing text, has a name in networking --- "congestion collapse."  This happened with CBs, owing to CBs' own brief, boom for a period of a few years.  This exact problem has occurred with many different technologies in their early generations.  However, CB technology has not addressed pushing a higher point of efficiency for onset of "congestion collapse", whereas other technologies have.  CB technology "has chosen" --- in a sense --- to remain what it was.  CBs are still in use today, serving their core users; the technology is what it is.  The core CB users are probably very glad that the bulk of the fad users have moved on to other technologies, and that their CB technology has remained simple.  The economy of the technology may not be suitable to the fad users, but it very well may be suitable to the core users.  If not, something will change.  That is the market.
>
> 3) This exact same issue of "congestion collapse" which occured with CB also occurred with Ethernet, and Aloha, and perhaps other technologies --- the simplicity of the technology led to a limitation --- a threshold of "congestion collapse" which was lower than could be provided by more advanced (and more complicated) sharing techniques.  However, in these technologies, unlike with CB, more advanced sharing techniques were developed.  For example, Ethernet and ultimately 802.11 and many other technologies, eventually developed techniques that pushed up to higher efficiency (throughput as a fraction of dedicated channel capacity) the onset of "congestion collapse" in their networks.  These are better examples to use in our report, since these are examples where techniques were developed and adopted to push up the onset of "congestion collapse," enabling higher efficiency on their networks. 
>
> 4) CBs are still in use today.  Although the advancement in other technologies over the last 30 years has almost certainly had an impact on the CB business, it is not correct (I believe) to characterize the CB business as a failure, which is a "take away" I get from the existing wording.  It serves its core users and it is what it is.  It may eventually be "mothballed", as is probably the fate of all technology.  Bottom line, citing a technology which had its heyday over 30 years ago, but is still serving a purpose today, does not deliver our message most effectively (my opinion).  I think we can make the same point but with more fitting examples or references.
>
> I hope this isn't overkill for making the case for my simple suggestion.
>
> Later, tjk
>
> -----Original Message-----
> From: Gerald Chouinard [mailto:gerald.chouinard@xxxxxx]
> Sent: Tuesday, June 09, 2009 5:59 AM
> To:
STDS-802-19@xxxxxxxxxxxxxxxxx
> Subject: [802.19] WhiteSpace Coexistence Use Cases
>
> Richard, Mark, Alex,
>
> Thank's for the effort in putting this white paper together.  See my
> comments in 'track change' in the attached copy.  I guess this could be
> discussed on the teleconference calls if time permits.
>
> Gerald
>