On 21 Sep 2013, at 02:31, [email protected]<mailto:[email protected]> wrote:
Few things to consider: 1. I think we first have to agree whether we need at all to encode an ‘unavailable channel’. Current draft section 4.4.2 says: “The response message for the Available Spectrum Query contains a schedule of available spectrum for the Device.” To me this means that channels which are not listed are implicitly unavailable and leakage into unavailable spectrum has to conform to the rules. +1 2. If one wants to be explicit on what the rules say for the leakage limits, then we can encode those into the rulesetInfo. +1 3. If we take on Andy’s argument that PAWS could be used outside TVWS, *and* leakage limits may potentially be different for different bands within the same regulatory domain, then encoding all those bands and leakage limits into rulesetInfo might just complement what is missing from the available spectrum response and we may be better off just encoding everything into available spectrum response. 1 and 2 doesn’t require an encoding for unavailable channel. Simply not listing it as available does the job. Agreed! [but with the caveat, as I've been arguing all along, that encoding option #2 doesn't permit that] 3 would require us to agree how to encode unavailable channel, but the WSD would still need to know what the emission limits are in that regulatory domain for the unavailable channels. I believe Andy wants to encode "band edge info" (i.e. to supply information about the four non-contiguous frequency ranges that the US TV channels fit into). Would that fit in your proposed rulesetInfo enhancement in point #3? kind regards, Ray
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
