Folks,
Off the top, I want to sincerely apologize for the lateness of this
review. A bunch of day-job things followed by an ill-timed vacation
conspired to make this very late.
Overall, I want to say that while I have some issues with this document,
they are almost all of the form that there is *too much* information in
the document. Section 4 is 19 pages of the document, and for the life of
me I can't connect up the use cases in section 4 with the requirements
in section 6. I am inclined to seriously trim down the use cases so that
it is clear what use case corresponds to what requirement. There is also
quite a bit of material in sections 1 through 3 that are about
whitespace itself and the regulatory environment. As I've said before in
face-to-face meetings and on this list, this protocol, while it is being
used for access to a whitespace database, has scant little to do with
whitespace. You don't even need to know much about anything about radio
to implement this protocol; it's a database access protocol with a set
of fields returned that happen to have information about whitespace
usage. So please (to quote Douglas Adams), "Don't panic!" Take the below
comments as simply an attempt to remove extra unnecessary information;
as I said, for the most part, that is my main complaint. But I do think
we want to take a shot at clearing this up before Last Call, let alone
before IESG Evaluation. Other ADs will not be so kind! :-)
pr
------
Specifics:
1.1. Introduction to white space
Academia and Industry have studied
multiple cognitive radio mechanisms for use in such a scenario.
"Cognitive Radio" is undefined.
Spectrum useable for data communications, especially wireless
Internet communications, is scarce. ...
I think everything up to the last two sentences of this paragraph is
unnecessary and doesn't add to the document
Any entity that is assigned
spectrum that is not densely used may be asked to give it up in one
way or another for more intensive use. Providing a mechanism by
which additional users share the spectrum with the assigned user is
attractive in many bands in many countries.
That's fine
Television transmission until now has primarily been analog. ...
This paragraph and the figure are completely unneeded.
The fundamental issue is how to determine for a specific location and
specific time if any of the spectrum is available for additional use.
...
I'm not sure whether the above is necessary or not. I don't see what it
adds.
1.2.1. In Scope
This document applies only to communications required for basic
service in TV white spaces.
That sentence is just wrong. First, it's worded as if this document is
about *communications* in TV white spaces. It's obviously not about that
at all; it applies to *database access for discovery of whitespace
allocations*. But even there, it's also not at all clear that this
document applies only to TV white spaces. This protocol is applicable to
any shared spectrum, whether it is coming from TV white space or
otherwise. What I think you mean to say is, "This document lays out the
requirements for accessing a database of information about available
spectrum, with a specific eye to the use case of TV white spaces.
Requirements outside of that use case are not accounted for." We don't
want to say that this document *can't* be used for other such databases;
it just isn't taking those requirements into account.
2.2. Terminology
Database
In the context of white space and cognitive radio technologies,
the database is an entity which contains, but is not limited to,
You say, "not limited to". What other kinds of things might be in there?
current information as required by by the regulatory policies...
The phrase "as required by regulatory policies" is unneeded. The
information in the database might be required by regulators, or it might
not. Regulatory policies have nothing to do with the requirements of the
protocol.
Device Class
Identifies classes of devices defined by Regional Regulators,
...
Again, "defined by Regional Regulators" should be removed.
including fixed, mobile, portable, etc... May also indicate if
the device is indoor or outdoor.
Slave Device
A device which uses the spectrum made available by a master
device, and cannot query the database directly.
Do you mean "cannot" or "does not"? In other words, if a device has
direct Internet access and is able to communicate with the database, is
it by definition a master device?
3. Prior Work
I didn't find section 3 at all useful. Could someone explain what this
adds to the document? An understanding of this did not help me in
section 6, which is what I would expect.
4. Use cases and protocol services
There are many potential use cases that could be considered for the
TV white space spectrum. ...
So my basic issue with this section (and this paragraph) is that many of
the use cases are architecturally identical for purposes of the
requirements. I think a good deal of compression could be done in this
section.
4.1.1. White space database discovery
... The master device will need to discover a
trusted database in the relevant regulatory domain, using the
following steps:
"Regulatory domain" is unnecessary.
1. The master device is connected to the Internet by any means...
That's fine.
...other
than using the white space radio. A local regulator may identify
exception cases where a master may initialize over white space
(e.g. the FCC allows a master to initialize over the TV white
space in certain conditions).
The rest of this is out of band and not relevant to the protocol.
Optionally the radio device is pre-programmed with the Internet
address of at least one trusted database. The device can establish
contact with a trusted database using one of the pre-programmed
Internet addresses and establish a white space network (as described
in one of the following use cases).
OK.
Optionally the initial query will be made to a listing approved by
the national regulator for the domain of operation (e.g. a website
either hosted by or under control of the national regulator) which
maintains a list of WS databases and their Internet addresses. The
query results in the list of databases and their Internet addresses
being sent to the master, which then evaluates the response to
determine if a trusted database can be identified where the master
device is able to register and receive service from the database.
The above seems identical to the previous paragraph. Can't this
paragraph be removed?
4.1.2. Device registration with trusted Database
Registration may be preliminary to creating a radio network using
white space; in some regulatory domains, for some device types, it is
a prerequisite to the use cases below. The radio network is created
by a master device. Before the master device can transmit in white
space spectrum, it must contact a trusted database where the device
can learn if any channels are available for it to use.
The above is confusing to me. What does it mean to create the radio
network before transmitting? And again, why is this relevant to the
protocol?
\|/ ----------
| |Database|
| .---. /---------
|-|---------| ( ) /
\|/ | Master | / \
| / | |========( Internet )
| / |-----------| \ /
+-|----+ (AirIF) ( )
|Master| / (----)
| | /
+------+
Figure 2: Example illustration of registration requirement in white
space use-case
Master appears twice is this diagram. Are there two masters in this
model? I don't understand what this means.
A simplified operational scenario showing registration consists of
the following steps:
1. The master device must register with its most current and up-to-
date information. Typically the master device will register
prior to operating in white space for the first time after power
up, after changing location by a predetermined distance, and
after regular time intervals.
Is the above simply an authentication step?
2. The master device shall provide to the database during
registration all information required according to local
regulatory requirements. This information may include, but is
not limited to, the Device ID, serial number assigned by the
manufacturer the device's location, device antenna height above
ground, name of the individual or business that owns the device,
name of a contact person responsible for the device's operation
address for the contact person, email address for the contact
person and phone number of the contact person.
Is the above to be specified by the protocol, or is this simply a blob
of information that has only local meaning? For instance, will the
database announce the information it needs for registration, or will the
device simply have to know this out of band? I don't see anything in
section 6 regarding this.
3. The database shall respond to the registration request with an
acknowledgement code to indicate the success or failure of the
registration request. Additional information may be provided
according to local regulator requirements.
Are there semantics to the acknowldgement code beyond "Registered" and
"Not registered"? If so, is the IETF defining those?
4.2. Use cases
4.2.1. Hotspot: urban Internet connectivity service
First let me say that I can find no difference architecturally between
this use case and wide-area/rural deployment in 4.2.2. Indeed, the
diagrams are almost identical. So I see no need to separate this out
into two sections; they should at least be combined. That said:
In this use case Internet connectivity service is provided in a
"hotspot" to local users. Typical deployment scenarios include urban
areas where Internet connectivity is provided to local businesses and
residents, and campus environments where Internet connectivity is
provided to local buildings and relatively small outdoor areas.
The above seems unimportant. Whether it's a hotspot, or provider to
campus or local buildings, or wide-area/rural is not important to the
architecture. They key an Internet access point that wants to talk to
devices over whitespace spectrum discovering which spectrum to use by
querying the database.
This
deployment scenario is typically characterized by multiple masters
...
If this is typical, why is only one master shown in the figure. You'd
think that would be important to the diagram. However, I suspect it
isn't important to the architecture and that this discussion about
multiple masters can be removed.
(APs or hotspots) in close proximity, with low antenna height, cells
with relatively small radius (a few kilometers or less), and limited
numbers of available radio channels. Many of the masters/APs are
assumed to be individually deployed and operated, i.e. there is no
coordination between many of the masters/APs. The masters/APs in
this scenario use a TDD radio technology. Each master/AP has a
connection to the Internet and may provide Internet connectivity to
other master and slave devices.
TDD is undefined. AP is undefined. And again, I see nothing in the above
important to the architecture being discussed.
Figure 3:
Slaves are labeled as "device". That's confusing.
1. ...A local
regulator may identify exception cases where a master may
initialize over white space (e.g. the FCC allows a master to
initialize over TV white space in certain conditions).
This sounds like a different deployment scenario, not the same one.
3. The master/AP registers with the trusted database according to
regulatory domain requirements (see Section 4.1.2).
Regulatory domain requirement are irrelevent. You can strike that part.
4. ...The complete set of parameters to be provided
from the master to the database is specified by the local
regulator.
No, it's provided by database policy. Local regulators may specify their
particular database policy, but that's outside of the protocol.
5. If the master/AP has met all regulatory domain requirements
(e.g. been previously authenticated, etc)...
Is there anything beyond authentication here? Importantly, neither the
master nor the database can understand the semantics of "regulatory
domain requirements"can they? That's all out of band.
6. Once the master/AP has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from
the database, etc)...
Same as above.
...the AP selects one or more available WS
channels from the list. Prior to initiating transmission, if
required by local regulation...
It's not "local regulation", it's protocol that would require the
answer, right?
7-13.
Except for relaying information about the slaves to the database and how
frequencies/channels are determined, isn't everything thing else in 7-13
what a normal device/AP interaction would look like? This can all be
reduced to one or two points it seems to me.
4.2.2. Wide-Area or Rural Internet broadband access
As I said above, this appears architecturally identical to 4.2.1.
A typical deployment scenario is a wide area or rural area, where
Internet broadband access is provided to local businesses and
residents from a master (i.e., BS) connected to the Internet.
BS is undefined. Probably best to define it. :-)
4.2.3. Offloading: moving traffic to a white space network
This example is obfuscated by the mention of "3G" and "YouTube". First
of all, there is nothing about 3G that is unique to this scenario; the
desire to use white space instead of any kind of more costly internet
connection (metered wire service, metered wireless service, metered
satellite service) is what's relevant. Second, using a widget or an
online service is also irrelevant; the key is that a high-bandwidth or
other costly service is to be used. (The mention of "YouTube" is, I
think, especially inappropriate.) This entire section could use some
rewriting.
4.2.4. White space serving as backhaul
In this use case Internet connectivity service is provided to users
over a more common wireless standard such as Wi-Fi with white space
entities providing backhaul connectivity to the Internet. In a
typical deployment scenario an end user has a device with a radio
such as Wi-Fi. An Internet service provider or a small business
owner wants to provide Wi-Fi Internet connectivity service to their
customers. The location where Internet connectivity service via
Wi-Fi is to be provided is within the coverage area of a white space
master (e.g. Hotspot or Wide-Area/Rural network). The service
provider installs a white space slave device and connects it to the
Wi-Fi access point(s). Wi-Fi access points with an integrated white
space slave component may also be used. This deployment scenario is
typically characterized by a WS master/AP/BS providing local
coverage. The master/AP has a connection to the Internet and
provides Internet connectivity to slave devices that are within its
coverage area. The WS slave device is 'bridged' to a Wi-Fi network
thereby enabling Internet connectivity service to Wi-Fi devices. The
WS Master/AP/BS which has some form of Internet connectivity (wired
or wireless) queries the database and obtains available channel
information. It then provides service using those channels to slave
devices which are within its coverage area.
Figure 6 shows an example deployment of this scenario.
\|/ white \|/ \|/ Wi-Fi \|/
| space | | |
| | | |-|----|
|--------| |-|---------| |-|------|-| | Wi-Fi|
| | | Master | | Slave | | Dev |
|Internet|------| (AP/BS) | | Bridge | |------|
| | | | | to Wi-Fi |
|--------| |-----------| |----------| \|/
|
|-|----|
| Wi-Fi|
| Dev |
|------|
Figure 6: WS for backhaul
The description of this deployment scenario is not well written, and the
figure does nothing to help. Aren't the Wi-fi devices supposed to be
connected to the slave, and then the slave talks to the master? This
needs some help.
4.2.5. Rapid deployed network for emergency scenario
... This
approach does in no way imply such organizations for disaster relief
must compete on spectrum allocation with other white spaces users,
but they can. ...
That sentence seems unnecessary.
4.2.6. Mobility
How does this use case differ architecturally from 4.2.1? Why isn't this
case just a subcase of 4.2.1, like 4.2.2?
4.2.7. Indoor Networking
Isn't this just the same as 4.2.1 without geolocation? Again, seems like
it could be combined and shortened.
5. Problem Statement
In Figure 11, note that there could be multiple databases serving
white space devices. The databases are country specific since the
regulations and available spectrum may vary.
Location specific, not country specific, right? It may be that multiple
countries share a database, or it may be that a single country has
multiple databases for sub-locales, right? The architecture doesn't
depend on "country".
5.1. Global applicability
The use of TV white space spectrum is currently approved by the FCC
in the United States. However regulatory bodies in other countries
are also considering similar use of available spectrum. ...
Again, the mention of the regulatory bodies here is unnecessary as it
doesn't impact this protocol.
4. Address regulatory requirements - Each country is likely to have
regulations that are unique to that country. The messaging
interface needs to be flexible to accommodate the specific needs
of a regulatory body in the country where the white space device
is operating and connecting to the relevant database.
I would rewrite this to say: "4. Flexible and extensible data structures
- Different databases are likely to have different requirements for the
kinds of data required for registration as well as the kinds of data
returned with available white space. For instance, different regulatory
bodies might require different information to be passed between the
database and the device accessing it." Again, don't make the regulatory
body part of the problem statement; the need to accommodate different
data is the requirement.
5.4. Data model definition
...
Use of XML for specifying a data model is an attractive option. The
intent is to evaluate the best option that meets the need for use
between white space devices and databases.
The mention of XML here is premature. Give it as one example (perhaps
including JSON as another) if you think you need such an example.
6. Requirements
6.1. Normative Requirements
D. Data Model Requirements:
D.1: The Data Model MUST support specifying the location of the
WSD, the uncertainty in meters, the height & its
uncertainty, and confidence in percentage of the location
determination. ...
"Location" in the above is ambiguous. You mean the "geographic
location", right?
...The Data Model MUST support both North
American Datum of 1983 and WGS84.
Neither of these has a reference. Also, if NAD is really a requirement,
shouldn't there be others listed?
D.2: The Data Model MUST support specifying the regulatory domain
and its corresponding data requirements.
That is poorly written. I don't understand what needs to go in a
protocol from the above. Don't you just mean that the Data Model MUST be
extensible?
D.3: The Data Model MUST support specifying an ID of the
transmitter device. This ID would contain the ID of the
transmitter device that has been certified by a regulatory
body for its regulatory domain. The Data Model MUST support
a device class. The Data Model MUST support specifying
information about the type of RAT of the transmitter device.
What sort of data is an ID? You probably need to mention that. Also
"RAT" is undefined.
P. Protocol Requirements:
P.1: The protocol MUST provide a mechanism to enable WSD
discovery. In some environments, a listing of the approved
white space databases is maintained by the national
regulator. The protocol MUST support discovery of a
database using a listing approved by a national regulator.
The "national regulator" portion of the requirement is not the
requirement. What is it about the list a national regulator provides
that is different, protocol-wise, from any other list from which the WSD
is discovered?
P.3: The protocol MUST support determination of regulatory
domain governing its current location.
I don't know what that requirement means.
P.8: The protocol MUST support the master device registering
with the database.
What is "registering" independent of authentication/authorization?
P.10: The protocol MUST support a channel query request from the
master device to the database. The channel query request
message MUST include parameters as required by local
regulatory requirement. These parameters MAY include any
of the parameters and attributes required to be supported
in the Data Model Requirements.
Strike the second sentence. Unnecessary.
6.2. Non-normative requirements
I don't understand what a non-normative requirement is. Are these just
pre-requisites? Please explain.
I'm guessing that the 2119 language in this section is misused, but let
me understand what the section is meant to say first.
O.4: The master device MUST implement at least one connection
method to access the database. The master device MAY contact
a database directly for service (e.g. as defined by FCC) or
the master device MAY contact a listing server first followed
by contact to a database (e.g. as defined by Ofcom).
References needed for FCC and Ofcom if you insist on noting them. (I
don't think they're necessary.)
O.5: The master device MUST obtain an indication about the
regulatory domain governing operation at its current location,
i.e. the master device MUST know if it operates under
regulations from FCC, Ofcom, etc...
That would be completely out of band, correct?
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
