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
From: Ghosh, Monisha
[mailto:monisha.ghosh@xxxxxxxxxxx]
Sent: Tuesday, July 21, 2009 6:47 AM
To: Cor van de Water; Shellhammer, Steve; Thomas Kolze;
WHITESPACE@xxxxxxxxxxxxxxxxx
Cc: STDS-802-19@xxxxxxxxxxxxxxxxx; Reuss, Ed; Benjamin A. Rolfe
Subject: RE: [802.19] Coexistence PAR
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
email :
monisha.ghosh@xxxxxxxxxxx
From: whitespace@xxxxxxxx
[mailto:whitespace@xxxxxxxx] On Behalf Of Cor van de Water
Sent: 2009 Jul 21 5:12 AM
To: Shellhammer, Steve; Thomas Kolze; WHITESPACE@xxxxxxxxxxxxxxxxx
Cc: STDS-802-19@xxxxxxxxxxxxxxxxx; Reuss, Ed; Benjamin A. Rolfe
Subject: RE: [802.19] Coexistence PAR
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
From: Thomas Kolze
[mailto:tkolze@xxxxxxxxxxxx]
Sent: Monday, July 20, 2009 2:11 PM
To: WHITESPACE@xxxxxxxxxxxxxxxxx
Cc: STDS-802-19@xxxxxxxxxxxxxxxxx; Reuss, Ed; Cor van de Water;
Shellhammer, Steve; Benjamin A. Rolfe
Subject: RE: [802.19] Coexistence PAR
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?
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 -----
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,
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.
==============================================================
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.