Hello Lei, I do support the concept you describe below, where a device may function to coordinate the operation of multiple masters. Thinking strictly about the connections required to implement this service, I believe requirement O.20 may support the concept you describe.
Reviewing the operational system framework you describe below, this seems to me to be very similar to previous discussions in this work group which were determined to be out of scope. Before considering if additional use cases or requirements are appropriate, I propose to ask the working group leaders to comment on the scope of this framework. Kind Regards, Scott On 2/22/12 12:40 AM, "ext ZhuLei" <[email protected]> wrote: >I had a comment on framework of it and probably discuss it before >touching timeline. > >It is a easy to think about the distributed or hierarchical >implementation of paws for some reasons. One is that the database >dominated by a regulator which may distribute responsibilities of >different areas or regions to branches of her. This need allows subset of >database working by maintaining available channel lists database in >particular area or for some purposes. > >As discussed in this mail list, database is in charge of storing and >maintaining white space channel information for a large area (e.g. a >country) and it may be operated by regulatory body, in the current system >architecture all the master devices query white space directly from >database, but in if an entity is added between master device and >database, and this entity is in charge of allocating white space for >master devices, the application of white space will be more flexible. For >example, a white space user owns a lot of master devices and it wants to >establish wireless network using these master device, it can set a >coordinating database which gets white space in its area from database >and all of its master devices query white space from the coordinating >database, because the master devices don’t query white space from >database so the burden of database will be reduced, and because the white >space user owns the coordinating database so it can implement its policy >of using spectrum. > >Master device can get white space from the coordinating database just >like getting white space from database; the coordinating database can be >maintained and operated by regulatory body (e.g. FCC). > >So, here, an optional system framework is proposed, compared with the >commonly discussed one a named coordinating database is added. > +-------------+ > +-------------+ |Coordinatin | +-----------+ > |Master Device+--+----+Database +----+---+Database | > +-------------+ WS +-------------+ WS +-----------+ > >Figure 1 An additional architecture of white space database querying >system > > +----------------------------+ > | +-------+ | > | +--------+ |Master | | > | |Database| |Devices| | > | +--------+ +-------+ | > |Coordinating Database | > +----------------------------+ >Figure 2 Logical Function of Coordinating Database > >Best regards, >Zhu Lei >HUAWEI TECHNOLOGIES CO.,LTD. > >Address: Huawei Building, No3 Xinxi Road >ShangDi Information Indurstry Base, Haidian District >Beijing 100085, China >Tel: +86-10-82836301 >Fax: +86-10-82836920 >Mobile: +86-13910157020 >E-mail: [email protected] >www.huawei.com >-------------------------------------------------------------------------- >----------------------------------------------------------- >This e-mail and its attachments contain confidential information from >HUAWEI, which >is intended only for the person or entity whose address is listed above. >Any use of the >information contained herein in any way (including, but not limited to, >total or partial >disclosure, reproduction, or dissemination) by persons other than the >intended >recipient(s) is prohibited. If you receive this e-mail in error, please >notify the sender by >phone or email immediately and delete it! > > >-----邮件原件----- >发件人: [email protected] [mailto:[email protected]] 代表 >[email protected] >发送时间: 2012年2月22日 7:54 >收件人: [email protected] >主题: [paws] UC&R I-D: Requirements > >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
