Pete, I don't think we can ignore the "Regulator". You may not need to know what a radio does or how it works but the database is logically tied to a Regulator. In all the cases we are aware of the Database will either be operated by the Regulator or by an entity (or entities) authorized by a Regulator. Spectrum use is tightly regulated - the regulator makes the rules. There are many examples of things that are included in this protocol that you could argue would not normally be required for a protocol. They are only there because Regulators require them. You raise a lot of questions on the requirements and these should probably be resolved before we expend much more effort on the protocol specifications. Peter S.
On MonOct/29/12 Mon Oct 29, 2:37 AM, "Pete Resnick" <[email protected]> wrote: >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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
