Monisha, Steve:
As pro-tem chair of the 802.11 TVWS SG, any comments I make regarding the direction of the group at this point would be out of order. This is a decision for the group. The first official meeting will be in Hawai’i in September, and this will be a high priority on that agenda.
I will let y’all know what the group decides.
Rich
Monisha,
Thanks for your comments.
I would expect 802.11 to consider portable devices. I am not sure if they will limit themselves to portable or allow both fixed and portable. They may not have even had a discussion about this yet. I copied Richard Kennedy on this response. He is chairing the 802.11 SG (TVWS11) and might have more information than me.
Steve
Cor brings up some very interesting applications, which, in my opinion, would be difficult, if not impossible, to enable under the current FCC rules that mandate databases in a way that one end of the communication link needs to be tethered, either through a wired or wireless link that is not TVWS. However, as Steve mentioned, if sensing-only devices were to be allowed in the future, stand-alone applications like these, and many others, would become possible. I don’t think the current rules would allow a device to use sensing only as a bootstrap mechanism at start-up. One solution, that we had proposed early on to the FCC, was to have a TV channel database downloaded into devices: this would work for a lot of cases since TV channel allocations do not change that frequently. Sensing would then be used to protect wireless microphones and as a back-up for TV as well. Of course, on a mountain top in California, with no power or other wires, the likelihood of a wireless mic being present is quite low to begin with.
Related question: is the 802.11 TVWS SG going to look only at the personal/portable (i.e. < 100 mw) applications?
Regards,
Monisha
------------------------------------------------------------------------
Monisha Ghosh
Principal Member Research Staff
Philips Research North America
345 Scarborough Road, Briarcliff Manor, NY 10510.
Phone: (914) 945-6415; Fax : (914) 945-6580
Hi Steve,
Thanks for clarifying - I still have the issue though, as many *fixed* devices
only have a wireless backhaul. Think about repeater sites on remote mountaintops.
That is a very common situation in California and likely in many other states.
Power is provided by sun or wind with generator backup and no wires or
alternative communication is available.
Few times per year the site is visited with a 4x4 or a snow scooter to bring
fuel for the genset and perform maintenance.
Another very common deployment these days is a "Mesh" type install
where only power is available (street light installs) and all communication
is arriving wireless.
That was the background of my question which I asked in a tele-conf,
unfortunately the issue seems to have been lost but it will surface as
soon as we start considering actual installation practices, so I suggest
that we try solving it before we find that TVWS devices are (too) limited
in their assumptions of database access.
Requiring an "alternative" wireless or wired access just to consult the
database and enable the TVWS radio sounds like a cludge to me and
will raise the price and installation requirements of the TVWS radios
(installing 2 antennas instead of one; allocating extra spectrum and
dealing with two network types instead of just the TVWS) so I think
this should only be considered if we fail to solve it via TVWS.
Thanks to Dan for re-posting the original question and his thoughts.
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: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Tuesday, July 21, 2009 7:11 AM
To: Thomas Kolze; WHITESPACE@xxxxxxxxxxxxxxxxx
Cc: STDS-802-19@xxxxxxxxxxxxxxxxx; Reuss, Ed; Cor van de Water; Benjamin A. Rolfe
Subject: RE: [802.19] Coexistence PAR
Tom and Cor,
I personally do not recall any official position on this question by either the EC SG or the 19 SG.
My PERSONAL OPINION is as follows,
· You can have wireless only access to the database as long as that is not TVWS-only wireless access. For example, you could have cellular access to get to the database. The FCC rules say “…must access a TV bands database over the Internet …” It does not day that all links in that access are wired.
· If your only access is TVWS wireless then I think you need to be certified as a sensing only device. I had not thought about it but I guess it could start as a sensing only device and then switch to database and sensing. That is something to think about. This of course only works for Portable devices. Fixed devices must have database access.
Regards,
Steve
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
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?
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
I agree with Ivan that this discussion could be very useful, so here's a contribution to keep it going.
----- Original Message -----
Sent: Sunday, July 19, 2009 6:08 AM
Subject: [802.19] Coexistence PAR
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 -----
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,
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. ==============================================================
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.