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:STDS-802-19-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
==============================================================
IEEE. Fostering technological innovation and excellence for the benefit of humanity.
==============================================================