The PAWS concept of "rulesets" seems to be principally based on the idea that different locations might have a specific "ruleset" (singular) that applies. Like Mike, I have wondered if this is laying the groundwork for PAWS to handle multiple "rulesets" (plural) at a particular location.
I think we should tease out TWO separate impacts if that is expected (or at least allowed): * If a Device doesn't know which of its supported rulesets apply at a given location, should we support a way for the Database to inform the Device? o Actually we need the overlap of THREE sets: rulesets supported by the Device, rulesets allowed (by the regulatory authority) at this location, and the rulesets supported by the Database. o Thus, this seems like a natural "extension" to the "ruleset negotiation" we contemplated in an early email. Maybe this should be handled at INIT_REQ time? * If multiple rulesets are allowed at a given location, should we support a way to make a SINGLE AVAIL_SPECTRUM_REQ to get both? o That sounds logical, and not too difficult to define in the spec.... o .... however, I'd like to not "force" the implementation on the Database that it must implement "all rulesets for a given location on every server that supports that location." o Said other way: I think a Database should be allowed to implement different rulesets at different URLs, and use the redirect mechanism to get specific AVAIL_SPECTRUM_REQs (with a specific ruleset) to the "right" server instance in its federation. o Can we adapt PAWS to accommodate this? It is tricky: how would a server instance "half reply" to a message, yet "half redirect" it? o If this is too difficult to specify, then I'd suggest we simply stick with the model that AVAIL_SPECTRUM_REQs only contain one "ruleset" at a time, and the device send independent ones. I think the downsides are pretty slight. One more comment: I'm 100% comfortable sidestepping the possibility that "multiple authorities may claim authority at a given location". I'm fine if PAWS has the model "one location, one authority". - Dan Harasty From: [email protected] [mailto:[email protected]] On Behalf Of Vincent Chen Sent: Wednesday, July 24, 2013 1:38 PM To: Michael Head Cc: [email protected] Subject: Re: [paws] Supporting multiple authorities / rulesets in a PAWS response? Mike, Ah, good point. To support responses for multiple rulesets requires additional layering of the response. This seems to be a relatively slight modification to the AVAIL_SPECTRUM_RESP (and associated batch response) to have a list of (rulesetInfo, SpectrumSchedule list) objects. Does that sound right? All, should I update the response message to support this? -vince On Wed, Jul 24, 2013 at 2:44 AM, Michael Head <[email protected]<mailto:[email protected]>> wrote: >From my reading, a device can only get information about spectrum under a >single ruleset at a time. (I suppose there is one way around this if a device >opts to skip the Init operation and the database opts not to include the >rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in the >spirit of the protocol). Now, there may be multiple rulesets that govern a particular location. For example, in disputed territories where two governments claim authority (or even just near an undisputed border, the device may want/need to know the spectrum available on both sides of the border). Even within a particular domain, there may be different rulesets governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices might be built to support both and may need to consult a database to get information about all bands. What should devices and databases do? I suppose it can be done by having the device send multiple, independent querys. In the first case, it would send a spectrum request with a DeviceDescriptor with a restricted set of ruleset ids to cover the regulatory domains it cares about (but then, how would it know which domains are useful at a given lat/lon?). For the second case, the device could fire separate requests with DeviceCapabilities set to cover the different bands it supports, which seems a little more workable. Still, it would be nice if these could be handled in a single request/response. Furthermore, certain databases might want to give additional information about spectrum at a location, but the spec doesn't have a standard way of allowing for that. Of course, the database is free to add any fields, anywhere it likes, but it would be nice if there were a structured way to allow a PAWS response to include independent spectrum reports. -- mike -- ---------------------------------- Michael R Head <[email protected]<mailto:[email protected]>> http://www.cs.binghamton.edu/~mike +1-201-BLISTER _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
