Re: [802.19] Coexistence PAR
Hello Tom.. Hoping that Cor won't mind.. I thought I should answer
your "at the time" question..
Last December, I'd agreed to help Mat Sherman by acting as recording
secretary for one of the early TVWS ECSG telecons. In executing those
duties, in an email to Cor acknowledging his attendance, I added a
"PS" to respond to his question about boot strapping in his email.
(see below)
Note that this "PS" was a purely a hypothetical (but I think
practical) treatment of how a database, wireless operator, and fixed
TVWS radio might work/interact in a "boot strap" procedure used before
deployment.
I am at your disposal to further clarify the concepts I mentioned in
the PS of the email should that be of interest to you.
Respectfully,
Dan Lubar
Managing Partner
RelayServices
4450 Arapahoe Ave, Suite 100
Boulder, CO 80303
303-847-4114 desk
---------- Forwarded message ----------
From: Dan Lubar <dlubar@xxxxxxxx>
Date: Wed, Dec 17, 2008 at 3:11 PM
Subject: Re: To yesterday's TVWS conference call attendees..
To: Cor van de Water <CWater@xxxxxxxxxx>
Mr van de Water,
Yours was the one name missing in the minutes so I'm glad you've emailed..
Thank you for your reply. I've added you to the list of attendees..
Respectfully,
Dan Lubar
RelayServices
PS: I'd offer the following possible deployment scenario for a fixed
TVWS radio "bootstrap". (ie being enabled for operation)..
Prior to installation, an operator connects the radio to an Internet
connection to register the device with a given/required database and
maybe do one or two other things. (I'd imagine radios should ship in
"listen only" mode)
Once the device is installed onsite, the radio would then be able to
be enabled to operate only after hearing an "enablement message" from
its BS. (ie after hearding the BS that tells it.. "use these
channels, at this power level and send me this info")
There might also be a "tell me what your location is before I allow
you to transmit" iteration but that may or may not be needed.
On Wed, Dec 17, 2008 at 1:22 PM, Cor van de Water <CWater@xxxxxxxxxx> wrote:
> I attended,
> also I asked the question about the bootstrapping
> of the radio that only has a (TV Whitespaces) backhaul,
> how can it check the database whether it can activate
> its backhaul radio link without activating its backhaul?
>
> Thanks for taking the minutes,
>
> Cor van de Water
> Director HW & Systems Architecture Group
> Proxim Wireless Corporation http://www.proxim.com
> Email: CWater@xxxxxxxxxx Private: http://www.cvandewater.com
> Skype: cor_van_de_water IM: cor_van_de_water@xxxxxxxxxxx
> Tel: +1 408 383 7626 VoIP: +31 20 3987567 FWD# 25925
> Tel: +91 (040)23117400 x203 XoIP: +31877841130
>
> Please consider the environment before printing this e-mail.
> ----- Original Message -----
> From: "Dan Lubar" <dlubar@xxxxxxxx>
> To: <WHITESPACE@xxxxxxxxxxxxxxxxx>
> Sent: Wednesday, December 17, 2008 2:57 PM
> Subject: To yesterday's TVWS conference call attendees..
>
>
>> Greetings everyone..
>>
>> If you attended yesterday's TV WS ECSG teleconference call..
>>
>> Below is the preliminary list of attendees (sorted by last name) that
>> we captured yesterday.
>>
>> If you were on yesterday's call, please confirm your name is correct
>> and is on this list.
>>
>> If you attended but find that your name is missing (and you'd like
>> your name to be recorded for the minutes) please email me with your
>> name and affiliation so it can be added in.
>>
>> Thanks for your time..
>>
>> Best regards,
>>
>> Dan Lubar
>> RelayServices
>>
On Mon, Jul 20, 2009 at 3:11 PM, Thomas Kolze<tkolze@xxxxxxxxxxxx> wrote:
> My comment pertains to being precise about differentiating between what the
> "TVWS group" "says" versus what individuals, or even a majority of
> individuals in any one session, might "say". I am not speaking to the
> technical issues being discussed, but have an important point nonetheless.
>
> In Cor's email below he writes:
>
> "Several months ago I asked the TVWS group..."
>
> and then writes:
>
> "The answer at that time was..."
>
> I don't recall a TVWS Study Group response on this issue. I am wondering if
> the response that Cor is describing is an opinion of one or several people,
> or if it was actually a finding of the TVWS SG. As well-meaning and correct
> as that opinion might be, if it is only an opinion and not an official
> finding of the TVWS SG, then I caution that we take care not to mislead Cor
> or any others in misrepresenting the opinion as a TVWS SG response.
>
> Does Chair Steve recall if there was an official response on the matter Cor
> writes about, or was this just an opinion of one or several expressed within
> the group?
>
> later, tjk
> ________________________________
> From: whitespace@xxxxxxxx [mailto:whitespace@xxxxxxxx] On Behalf Of Reuss,
> Ed
> Sent: Monday, July 20, 2009 10:50 AM
> To: Cor van de Water; Shellhammer, Steve; Benjamin A. Rolfe;
> STDS-802-19@xxxxxxxxxxxxxxxxx; WHITESPACE@xxxxxxxxxxxxxxxxx
> Subject: RE: [802.19] Coexistence PAR
>
> So include the relevant portions of the database associated with that AP/BS
> in the beacon. (And you thought we had “beacon bloat” before?) If the amount
> of data chokes the beacon, then send it out in little portions over ten
> seconds to perhaps as long as ten minutes, depending on the immediacy
> required for attachment, similar to the orbital ephemeris data on GPS. If
> you need fast handoff to a neighboring AP/BS, you can include the data for
> several of your neighbor AP’s/BS’s as well, perhaps at a lower bandwidth &
> repetition rate, again similar to GPS.
>
>
>
> -- Ed Reuss
>
>
>
> ________________________________
>
> From: whitespace@xxxxxxxx [mailto:whitespace@xxxxxxxx] On Behalf Of Cor van
> de Water
> Sent: Monday, July 20, 2009 10:16 AM
> To: Shellhammer, Steve; Benjamin A. Rolfe; STDS-802-19@xxxxxxxxxxxxxxxxx;
> WHITESPACE@xxxxxxxxxxxxxxxxx
> Subject: RE: [802.19] Coexistence PAR
>
>
>
> Several months ago I asked the TVWS group
>
> how to handle (bootstrap) a TVWS device which
>
> *only* has wireless backhaul access to a database.
>
> The answer at that time was that a specific bootstrap
>
> procedure would be defined to allow (temporary) access
>
> to the medium until the databse could be queried and the
>
> final access decided based on database contents.
>
> It is somewhat comparable to authentication of a device,
>
> how can you authenticate access as you are not allowed
>
> to communicate before you are authenticated?
>
>
>
> One of the major applications of wireless outdoor radios is
>
> to transport data where no cables are, so a TVWS device
>
> is really dependent on the wireless backhaul to connect
>
> to a database, to find out if it is allowed to transmit....
>
>
>
> BTW, it is not feasible to restrict the TVWS device in power
>
> before database access is achieved as many wireless
>
> outdoor links require the full transmit power to give the
>
> necessary link budget for reliable communication, so if
>
> there is a restriction for database bootstrap then I think
>
> it must be something like a timed limit.
>
>
>
> Even a restriction in frequency may be hard to achieve,
>
> because how do you coordinate the peer radio to use the
>
> same frequency as the new starting TVWS device?
>
>
>
> Regards,
>
>
>
> Cor van de Water
> Director HW & Systems Architecture Group
> Proxim Wireless Corporation http://www.proxim.com
> Email: CWater@xxxxxxxxxx Private: http://www.cvandewater.com
> Skype: cor_van_de_water IM: cor_van_de_water@xxxxxxxxxxx
> Tel: +1 408 383 7626 magicJack: +1 408 844 3932
> Tel: +91 (040)23117400 x203 XoIP: +31877841130
>
> Please consider the environment before printing this e-mail.
>
>
>
>
>
> ________________________________
>
> From: whitespace@xxxxxxxx [mailto:whitespace@xxxxxxxx] On Behalf Of
> Shellhammer, Steve
> Sent: Monday, July 20, 2009 3:27 AM
> To: Benjamin A. Rolfe; STDS-802-19@xxxxxxxxxxxxxxxxx; 802TVWS
> (WHITESPACE@xxxxxxxxxxxxxxxxx)
> Subject: RE: [802.19] Coexistence PAR
>
> Ivan and Rolfe,
>
>
>
> Thanks for commenting. My comments below.
>
>
>
> Steve
>
>
>
> From: Benjamin A. Rolfe [mailto:ben@xxxxxxxxxxxxxx]
> Sent: Sunday, July 19, 2009 1:57 PM
> To: STDS-802-19@xxxxxxxxxxxxxxxxx
> Subject: Re: [802.19] Coexistence PAR
>
>
>
> I agree with Ivan that this discussion could be very useful, so here's a
> contribution to keep it going.
>
>
>
> ----- Original Message -----
>
> From: Ivan Reede
>
> To: STDS-802-19@xxxxxxxxxxxxxxxxx
>
> Sent: Sunday, July 19, 2009 6:08 AM
>
> Subject: [802.19] Coexistence PAR
>
>
>
> 802. 19 TAG (stds-802-19@xxxxxxxx) <802. 19 TAG (stds-802-19@xxxxxxxx)>;
> 802TVWS (WHITESPACE@xxxxxxxxxxxxxxxxx) <802TVWS
> (WHITESPACE@xxxxxxxxxxxxxxxxx)>
>
>
>
> Hi Steve,
>
>
>
> looking qat your questions below, I think an e-mail thread/discussion could
> be productive.
>
>
>
> you ask three questions, namely:
>
>
>
> 1. Is the communication link between TVWS devices wireless or wired?
>
> Is this relevant? If we make the process IP address based, routers
> will find their way over the most efficient route, irrespective of wether it
> is wired or wireless. The real question may be if we want something on
> coexistence to work on stations (for 802.11) or CPEs (for 802.16 and 802.22)
> before thay associate to their AP (for 802.11) or BS (for 802.16 and 802.22)
> if they don't have a backhaul connection. The same goes for APs and BSs for
> 802.11 and 802.16. I beleive 802.22 has already made the decision that
> following the R&O, they would stay mute if they were not connected to a
> database.
>
>
>
> This last assumtpions seems profoundly limiting. It implies that every
> wireless devices had some other connection by which it can pass IP traffic
> and connect with the data base. Perhaps this is more a concern with the
> current R&O but it seems likely to change if good alternative coexistence
> mechanisms are presented. The database approach seems to solve the problem
> of coexistence for backhaul connected devices and by implication systems
> with centralized control only (such as 16 and 22), and the issue of
> coexistence of devices that need to sort it out on their own (ad-hoc
> networking) is where additional work is most needed. But since I've not been
> deeply involed in the discussions within the SG I probably missed something
> important :0).
>
>
>
> SJS> If we want to support sensing only devices then we will need a
> wireless link. If we only want to support devices with database access then
> we do not need to define the lower layers. So this is an important decision
> since it has a big impact on the scope of the project.
>
>
>
> 2. Do we use a centralized or distributed decision process?
>
> I don;t think this should be a discussion for a layer 5-6-7 level. I
> think this is out of scope. You may think differently. I would rather see a
> discussion about the effect of both models on what we will be doing as both
> models seem to be presented... From what I have read up to date, three
> different groups are working on a distrbuted approach, one of which I have
> presented and Google have presented their cetnralized approach. I think
> whatever we do should be agnostic of the database format, all we should be
> concerned about at this point should be that the "database data" is made
> available to us and in what format we would like to see it. 802.22 has
> started crafting a proposal. It is far from reaching concesnsus, but one
> thing seemed clear, they would want to have the available channel list in
> the format of a table of maximum allowable power for each channel for an
> area of interest.
>
>
>
> Seems a mixing of concepts - centralized information aggregation vs decision
> making. The form in which information on usage is collected, stored and
> disimnated seems independent of using that information to decide what
> spectrum is available and how to best use it.
>
>
>
> SJS> Agreed the centralized data repository and centralized control are
> very different. Ivan brought up the database. One thing that is important
> to understand is what information is available from the database. In the US
> the only items that the FCC specifies is what are the available set of
> channels. So that does not help with coexistence of 802 wireless devices.
> For coexistence other information would need to be available and how that
> data is made available is an issue.
>
>
>
> 3. What adaptations should be provided (scheduling, bandwidth channel
> splitting, transmit power control, etc.)
>
> I would like to see discussion on how flexible we can make the system
> and the tradeoffs each of there has. The obvious are FDM (frequency
> division), TDM (time division) and SDM (spacial division) and the multiple
> combinations of these one may use.
>
>
>
> This may go most directly to the scope of the PAR - what is the project
> output? I can envision a recommended practice that provides specific
> mechanisms that apply to using other 802 standards in WS, which would
> include all the suggested methods above as well as perhaps others. An RP
> could address PHY, MAC and LLC layer methods (within the scope of 802). I
> suppose another alternative is a "guide" similar to what P2030 is scoped to
> produce, which could include methods and specific protocols for control and
> coordination (again, there are some limits wrt the scope of 802?).
>
>
>
> SJS> My personal opinion is that a RP or guide is not likely to be very
> useful. If the SG wants to standardize something it should be a standard.
>
>
>
> OK, enough said... I hope this e-mail should be sufficent to fire up the
> discussion over the e-mail thread and help make our teleconferences more
> productive.
>
>
>
> And my 2 cents, if not making it more productive perhaps at least making the
> thread more active :-).
>
>
>
>
>
> just my 2 cents worth,
>
>
>
> Ivan Reede
>
> ----- Original Message -----
>
> From: Shellhammer, Steve
>
> To: 802. 19 TAG (stds-802-19@xxxxxxxx) ; 802TVWS
> (WHITESPACE@xxxxxxxxxxxxxxxxx)
>
> Sent: Saturday, July 18, 2009 1:44 AM
>
> Subject: SG Extension Approved & Conference Calls Schedule
>
>
>
> TVWS Coexistence SG,
>
>
>
> The EC approved the SG extension and held a special vote to
> permit development of a PAR. After some lively discussion it passed 12/0/2.
>
>
>
> In order for the EC to consider a PAR in November we will
> need to provided it 30 days before the November Plenary. We therefore need
> to vote on a version of the PAR at the September Wireless Interim. We can
> of course fine tune it between the Interim and the 30-day advance deadline
> sometime in October.
>
>
>
> We also need to answer a few critical questions before we
> can craft the PAR. Here are the ones I have thought of so far,
>
>
>
> 1. Is the communication link between TVWS devices wireless or wired?
>
> 2. Do we use a centralized or distributed decision process?
>
> 3. What adaptations should be provided (scheduling, bandwidth channel
> splitting, transmit power control, etc.)
>
>
>
> Please think about these questions and also identify what other questions I
> have overlooked.
>
>
>
> I would encourage everyone to focus any presentations on
> addressing these questions and any other questions we need to answer so we
> can develop a clear and focused PAR.
>
>
>
> Thanks for all your hard work at the Plenary meeting.
>
>
>
> We will be having conference calls. Here is a link to the
> schedule,
>
>
>
> http://ieee802.org/19/pub/calls.html
>
>
>
> And here is the table of calls.
>
>
>
> Day
>
> Date
>
> Start Time
>
> End Time
>
> Tuesday
>
> July 28
>
> 7 PM Eastern Time
>
> 8 PM Eastern Time
>
> Tuesday
>
> August 4
>
> 1 PM Eastern Time
>
> 2 PM Eastern Time
>
> Tuesday
>
> August 11
>
> 7 PM Eastern Time
>
> 8 PM Eastern Time
>
> Tuesday
>
> August 18
>
> 1 PM Eastern Time
>
> 2 PM Eastern Time
>
> Tuesday
>
> August 25
>
> 7 PM Eastern Time
>
> 8 PM Eastern Time
>
> Tuesday
>
> September 1
>
> 1 PM Eastern Time
>
> 2 PM Eastern Time
>
> Tuesday
>
> September 8
>
> 7 PM Eastern Time
>
> 8 PM Eastern Time
>
> Tuesday
>
> September 22
>
> 1 PM Eastern Time
>
> 2 PM Eastern Time
>
>
>
> Steve
>
>
>
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:WHITESPACE-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
>
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:STDS-802-19-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
>
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:STDS-802-19-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
>
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:WHITESPACE-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
>
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:WHITESPACE-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:WHITESPACE-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
>
> =============================================== You Can unsubscribe through
> the link below.
>
> Unsubscribe link: mailto:WHITESPACE-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
> ============================================================== IEEE.
> Fostering technological innovation and excellence for the benefit of
> humanity. ==============================================================
===============================================
You Can unsubscribe through the link below.
Unsubscribe link: mailto:STDS-802-19-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
==============================================================
IEEE. Fostering technological innovation and excellence for the benefit of humanity.
==============================================================