Hi Brian, I agree we should be flexible enough to send device information with the spectrum query when requested by the local regulator. Does P.12 address this accurately?
Kind Regards, Scott On 2/27/12 3:38 PM, "ext Rosen, Brian" <[email protected]> wrote: ><as individual> >I have a small issue here. > >Device characteristics don't typically change, so having them in some >form of registration transaction makes sense in an engineering sense. >However, some regulators don't seem to understand that, and there are >circumstances where you have to send some of the device information with >the spectrum query. We should be flexible enough to handle that. > >Brian > >On Feb 27, 2012, at 3:46 PM, <[email protected]> ><[email protected]> wrote: > >> Hi Teco, >> >> We could change O.7 to something like: >> >> O.7: The master device MUST register with its most current and >>up-to-date >> information, and MUST include all variables mandated by local regulator >> policy. >> >> Would this work? >> >> Kind Regards, >> Scott >> >> >> >> On 2/27/12 2:25 PM, "ext Teco Boot" <[email protected]> wrote: >> >>> Hello Scott, >>> >>> I understand your point. But I want to keep things simple. The >>> P.* requirements are for the protocol, it MUST support optional >>> variables. >>> The O.* requirements explain how these are used. This is the MAY, >>> right? >>> >>> Having performed some tests today with an emergency responders >>> network, I saw some high traffic load. Something like this: >>> <self_explaining_variable_name> >>> 1 >>> <\self_explaining_variable_name> >>> I could think of an efficiency requirement, for the rapid deployed >>> network use case. >>> >>> Thanks, Teco >>> >>> >>> Op 27 feb. 2012, om 14:32 heeft <[email protected]> >>> <[email protected]> het volgende geschreven: >>> >>>> Hi Teco, >>>> >>>> If we look at P.9 and P.10 together, P.9 says that registration is a >>>> MUST >>>> -- the protocol supports registration without question. P.10 says the >>>> signaling for registration MAY contain any of several variables (also >>>> allows more variables to be included if required by local >>>>regulations). >>>> The list currently identifies all variables required for registration >>>>in >>>> the US. Now if we look at the Data Model requirements, each variable >>>> identified that the registration service MAY contain (these are in >>>>D.5, >>>> D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The >>>>protocol >>>> MUST support registration, and the Data Model in the protocol MUST >>>> support >>>> the variables identified for registration service. >>>> >>>> The current use of MUST in P.9 and MAY in P.10 has the effect that >>>>WSDs >>>> in >>>> the US are allowed to register (because the protocol supports >>>> registration) and are allowed to use the variables defined by the FCC >>>> (because the registration signaling MAY include those variables). This >>>> also has the effect that WSDs in the UK (or elsewhere in the world) >>>>are >>>> allowed to register if this is a local requirement (because the >>>>protocol >>>> supports registration) and are allowed to use (or not use) the >>>>variables >>>> defined by the FCC (because the registration signaling MAY include >>>>those >>>> variables). Nothing to prevent adding more variables if needed by >>>>Ofcom, >>>> IDA, etc... >>>> >>>> Another possibility is to change the wording of P.10 to read >>>> P.10: The registration signaling MUST include the following optional >>>> variables: 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. >>>> >>>> What do you think? >>>> >>>> Kind Regards, >>>> Scott >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 2/26/12 3:41 PM, "ext Teco Boot" <[email protected]> wrote: >>>> >>>>> Hi Scott, >>>>> >>>>> I still think it is a MUST for the protocol, and a MAY for usage. >>>>> >>>>> Thanks, Teco >>>>> >>>>> Op 24 feb. 2012, om 19:58 heeft <[email protected]> >>>>> <[email protected]> het volgende geschreven: >>>>> >>>>>> Hello Teco, >>>>>> >>>>>> Since PAWS is a global standard, registration for all regulatory >>>>>> domains >>>>>> must be supported. While the FCC does require all of the variables >>>>>> listed >>>>>> in P.10, other regulatory domains may not require each of those >>>>>> variables. >>>>>> So for requirements on the protocol, using MAY enables the FCC to >>>>>> require >>>>>> these variables while allowing other regulators to select a subset, >>>>>>or >>>>>> even different, variables. >>>>>> >>>>>> With this explanation, are you okay with MAY in P.10? >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> >>>>>> >>>>>> On 2/22/12 1:34 AM, "ext Teco Boot" <[email protected]> wrote: >>>>>> >>>>>>> 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 > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
