Scott, Ray, The P.* are mostly MUST requirements for the protocol. That's fine. Except P.10, this is a MAY operational requirement. The protocol MUST support it.
I'm fine with the rest of it. Is noted somewhere that we (IETF) do our best to support as many regulator rules as possible, and leave setting up requirements for actual deployment up to the mandated authorities? This makes the O.* requirements informational. Thanks, Teco Op 22 feb. 2012, om 00:53 heeft <[email protected]> <[email protected]> het volgende geschreven: > Hello All, > > I have revised Section 6 of the I-D which describes the Data Model > Requirements, Protocol Requirements and Operational Requirements. This > includes the requirements from the threat model > (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). > > The requirements are ordered "top down" to follow the previous sections of > the document: requirements derived from discovery are followed by > requirements derived from registration are followed by requirements > derived from hotspot, etc... > > Please review the proposed text, we hope to have your comments by Feb 28th. > > Kind Regards, > > Raj & Scott > > > > > D. Data Model Requirements: > > > <Ed. Note>requirements related to discovery function</Ed. Note> > 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 for the location determination. The Data Model MUST support > both North American Datum of 1983 and WGS84. > > > D.2: The Data Model MUST support specifying the URI address of a white > space database. > > > D.3: The Data Model MUST support specifying the URI address of a national > listing service. > > > D.4: The Data Model MUST support specifying regulatory domain and its > corresponding data requirements. > > > > <Ed. Note>requirements related to registration function</Ed. Note> > D.5: 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. > > > > D.6: The Data Model MUST support specifying a manufacturer¹s serial number > for a master device. > > > D.7: The Data Model MUST support specifying the antenna and radiation > related parameters of the device, such as: > > - antenna height > > - antenna gain > > - maximum output power, EIRP (dBm) > > - antenna radiation pattern (directional dependence > of the strength of the radio signal from the antenna) > > - spectrum mask with lowest and highest possible frequency > > - spectrum mask in dBr from peak transmit power in EIRP, > with specific power limit at any frequency linearly > interpolated between adjacent points of the spectrum mask > measurement resolution bandwidth for EIRP measurements. > > > > D.8: The Data Model MUST support specifying owner and operator contact > information for a transmitter. This includes the name of the transmitter > owner, name of transmitter operator, postal address, email address and > phone number of the transmitter operator. > > > > > <Ed. Note>requirements related to hotspot use case</Ed. Note> > D.9: The Data Model MUST support specifying a list of available channels. > The Data Model MUST support specification of this information by channel > numbers and by start and stop frequencies. The Data Model MUST support a > channel availability schedule and maximum power level for each channel in > the list. > > > > <Ed. Note>requirements related to mobility use case</Ed. Note> > D.10: The Data Model MUST support specifying channel availability > information for a single location and an area (e.g. a polygon defined by > multiple location points or a geometric shape such as a circle). > > > > > > P. Protocol Requirements: > > > <Ed. Note>requirements related to discovery function</Ed. Note> > P.1: The protocol MUST provide a message sequence for the master device to > discover a white space database that provides service at its current > location. > > > P.2: The protocol MUST support access of a database directly. The protocol > MUST support access of a database using a listing approved by a national > regulator. > > > P.3: The protocol MUST support determination of regulatory domain > governing its current location. > > > <Ed. Note>requirements related to threat model</Ed. Note> > > > P.4: The protocol MUST provide the ability for the database to > authenticate the master device. > > > P.5: The protocol MUST provide the ability for the master device to verify > the authenticity of the database with which it is interacting. > > > P.6: The messages sent by the master device to the database MUST be > integrity protected. > > > P.7: The messages sent by the database to the master device MUST be > integrity protected. > > > P.8: The protocol MUST provide the capability for messages sent by the > master device and database to be encrypted. > > > > > > > <Ed. Note>requirements related to registration function</Ed. Note> > P.9: The protocol MUST support the master device registering with the > database. > > > P.10: The registration signaling MAY include the Device ID, manufacturer¹s > serial number, device location, device antenna characteristic information, > name of individual or business that owns the device, name, address, email > address and phone number of a contact person who is responsible for device > operation. > > > P.11: The protocol MUST support a registration acknowledgement including > appropriate result codes. > > > > > <Ed. Note>requirements related to hotspot use case</Ed. Note> > P.12: 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 device location, device ID, manufacturer¹s serial number, and > antenna characteristic information. > > > P.13: The protocol MUST support a channel query response from the database > to the master device. The channel query response message MUST include > parameters as required by local regulatory requirement. These parameters > MAY include available channels, duration of time for their use, associated > maximum power levels, any additional sensing requirements. > > > P.14: The protocol MUST support a channel query request from the slave > device to the master device. The channel query request message MUST > include parameters as required by local regulatory requirement. These > parameters MAY include device ID and slave device location. > > > P.15: The protocol MUST support a validation request from the master to > the database to validate a slave device. The validation request MUST > include the slave device ID. > > > P.16: The protocol MUST support a validation response from the database to > the master. The validation response MUST include a response code. > > > P.17: The protocol MUST support a channel query response from the master > device to the slave device. The channel query response message MUST > include parameters as required by local regulatory requirement, including > a response code and sufficient information to decode an enabling signal. > > > P.18: The protocol MUST support an enabling signal sent from the master to > the slave. This signal MUST allow the slave device to validate that a > previously received available channel list is still valid or not. This > signal MUST be encoded to allow the slave device to determine the identity > if the sending master device. > > > > P.19: The protocol between the master device and the database MUST support > the capability to change channel availability lists on short notice. > > > > <Ed. Note>requirements related to mobility use case</Ed. Note> > P.20: The protocol between the master device and the database MUST support > a channel availability request which specifies a geographic location as an > area as well as a point. > > > > > > O. Operational Requirements: > > > <Ed. Note>requirements related to discovery function</Ed. Note> > > O.1: The database and the master device MUST be connected to the Internet. > > > O.2: A master device MUST be able to determine its location including > uncertainty and confidence level. A fixed master device MAY use a location > programmed at installation or have the capability determine its location > to the required accuracy. A mobile master device MUST have the capability > to determine its location to the required accuracy. > > > O.3: The master device MUST identify a database for use. The master device > MAY select a database for service by discovery at runtime or the master > device MAY select a database for service by means of a pre-programmed URI > address. > > > 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). > > > O.5: The master device MUST obtain an indication 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Š > > > > > <Ed. Note>requirements related to registration function</Ed. Note> > O.6: The master device MAY register with the database according to local > regulatory policy. Not all master devices will be required to register. > Specific events will initiate registration, these events are determined by > regulator policy (e.g. at power up, after movement, etcŠ). > > > O.7: The master device MUST register with its most current and up-to-date > information. > > > > > <Ed. Note>requirements related to hotspot use case</Ed. Note> > O.8: A master device MUST query the database for the available channels > based on its current location before starting radio transmission in white > space. Parameters provided to the database MAY include device location, > accuracy of the location, antenna characteristic information, device > identifier of any slave device requesting channel information. > > > O.9: The database MUST respond to an available channel list request from > an authenticated and authorized device and MAY also provide time > constraints, maximum output power, start and stop frequencies for each > channel in the list and any additional requirements for sensing. > > > O.10: After connecting to a master device¹s radio network a slave device > MUST query the master device for a list of available channels. The slave > MUST include parameters required by local regulatory policy, e.g. device > ID, device location. > > > O.11: According to local regulatory policy, the master device MAY query > the database with parameters received from the slave device. > > > O.12: The database MUST respond to a query from the master device > containing parameters from a slave device. > > > O.13: After the master device has received a response from the database, > the master device MUST respond to the slave device. If all regulatory > requirements are met the response will contain an available channel list. > If regulatory requirements are not met, the response MUST contain at least > a response code. > > > O.14: If a master device has provided an available channel list to a slave > device the master device MAY send a periodic enabling signal to allow the > slave device to confirm it is still within reception range of the master > device. > > > O.15: The enabling signal MUST be encoded so that the receiving slave can > determine the identity of the sending master. > > > O.16: Periodically, at an interval according to local regulations, the > slave device MUST either receive and enabling signal or MUST successfully > repeat the channel request process or MUST cease transmission on the > channel. > > > O.17: A master device MUST repeat the query the database for the available > channels as often as required by the regulation (eg, FCC requires once per > day) to verify that the operating channels continue to remain available. > > > O.18: A master device which changes its location more than a threshold > distance specified by local regulatory policy during its operation, MUST > query the database for available operating channels each time it moves > more than the threshold distance (e.g., FCC specifies 100m) from the > location it previously made the query. > > > > <Ed. Note>requirements related to wran use case</Ed. Note> > O.19: If slave devices change their location during operation by more than > a limit specified by the local regulator, the slave device MUST query the > master device for available operating channels. > > > > <Ed. Note>requirements related to rapid deployed network use case</Ed. > Note> > O.20: According to local regulator policy, a master device may contact a > database via proxy service of another master device. > > > > <Ed. Note>requirements related to mobility use case</Ed. Note> > O.21: A master device MUST be able to query the whitespace database for > channel availability information for a specific expected coverage area > around its current location. > > > > <Ed. Note>requirements related to threat model</Ed. Note> > O.22: A Master device MAY not include its identity in > messages sent to the database when not required by the regulatory > > > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
