Subject: [paws] Spectrum encoding discussion

From: Andy Lee <[email-masked]>
Date: Wed, 18 Sep 2013 14:01:34 -0700

-- tl;dr  Moving this to separate discussion thread --

Hi Ray,

Certain people appear to want the entire UHF channel plan encoded in the
> PAWS response, using very low PSD values to represent permitted leakage
> into "unavailable channels".
> IMHO, this is a very US/FCC-centric model.
> In the ETSI model, each available channel is _explicitly_ listed, with a
> low and high frequency.  "Unavailable channels" are omitted, and there's no
> concept of needing to describe the channel plan.  Devices just do what
> they're told, and adjacent channel leakage into otherwise unusable channels
> is controlled by device approval regulations.

I humbly suggest a few alternate viewpoints:

a) AFAIK, in every regulatory domain, multiple device regulations are
simultaneously in effect at all times.  Just because a device is following
TV WS rules, does not excuse it from complying with other rules like EMI
leakage or electrical safety testing.

Just because a set of frequencies is not explicitly mentioned in one
section of the law does not mean that those frequencies are unregulated.
 Every piece of spectrum is controlled by at least one law.  There is no
such thing as completely unregulated spectrum.

b) In the case of the ETSI model, the emission limits on channel 38 can be
derived using the adjacent channel leakage ratios for each device class.
 From a technical standpoint, Ofcom must assume some kind of power limit
(interference threshold) on channel 38 in order to compute the white space
power limits on channels 37 and 39.  The power limit on channel 38 is the
same one that can (and should) be communicated to the device.  Not having
looked at Ofcom's data set yet, I think it's a little premature to say that
they will be silent or explicitly omit data for channel 38.

c) From a future-proofing perspective, I think it's important to
communicate these "band edge" requirements.  One of the great features of a
spectrum database is the ability to modify the rules over time.  Future
changes to the white space rules might involve shifts in the frequency
ranges, changes to power levels, or perhaps changes to the band edge roll
off.

The key is that the DB is responsible for protecting the primary spectrum
users, and by communicating the "left-over" spectrum envelope to white
space devices, you give them the chance to opportunistically use that
spectrum.  The way in which the white space spectrum is specified can
determine how effectively a WSD can search for opportunities within that
envelope.

I've put together some crude hypothetical examples in the following
illustrations:

Case 1: Old profile has "square" channel edge restrictions.  WSD needs to
narrow its in-band emissions to avoid causing interference on the adjacent
channel.

Case 2: New rules define a more realistic band edge rolloff, but also
lowers the emission limits on the left-most channel.  WSD peak emission
power remains the same, and its in-band emissions can be moved closer to
the channel edge because the new rules allow it.

Case 3: Consider what white space devices must do when they try to find
optimal channels to transmit on.  Specifying the channel edge emission
masks actually gives the device more information to work with.  The band
edges can and should be factored into the search for the optimum spectral
fit of a signal.  A legacy device does not know how the out-of-band rules
might change in the future, but with a fully defined profile, the device
can still do the right thing at the band edges even when the rules change.

Best regards,

Andy Lee | Google Inc. | [email-masked] | 408-230-0522

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Sep 2013 10:15:13 +0000

On 18 Sep 2013, at 22:01, Andy Lee <[email-masked]<mailto:[email-masked]>> wrote:

lots of interesting stuff... :)

Andy, your examples are good.  If the FCC regime folks want to specify channel edge emission masks that's OK with me, so long as it doesn't prohibit the ETSI approach at the same time.

However on this particular point:

Not having looked at Ofcom's data set yet, I think it's a little premature to say that they will be silent or explicitly omit data for channel 38.

I must disagree.  As mentioned last week, OFCOM have specifically said in their most recent consultation document in §5.93:

"Consequently, given the risk of harmful interference and the very stringent emission limits, we believe it would be prudent not to allow WSD operation in channel 38".

which we read as a very strong steer that they expect the WSD to specify (by omission, since that's the ETSI model) 0W (-Inf dBm) EIRP on channel 38.

kind regards,

Ray

---

From: Vincent Chen <[email-masked]>
Date: Thu, 19 Sep 2013 07:30:49 -0700

Ray,

Perhaps this is a terminology issue. There must be some specification for
emissions (intended or not) that the device must meet during certification
/ testing.
I believe you're focusing on intentional emissions, and Andy is speaking to
any emissions.

I don't think it's reasonable to state that a device it must have 0W -Inf
dBm emissions at channel 38, if it intends to use any channels nearby?

-vince

On Thu, Sep 19, 2013 at 3:15 AM, Ray Bellis <[email-masked]>wrote:

>
>  On 18 Sep 2013, at 22:01, Andy Lee <[email-masked]> wrote:
>
>  Andy, your examples are good.  If the FCC regime folks want to specify
> channel edge emission masks that's OK with me, so long as it doesn't
> prohibit the ETSI approach at the same time.
>
>  Not having looked at Ofcom's data set yet, I think it's a little
> premature to say that they will be silent or explicitly omit data for
> channel 38.
>
>
> I must disagree.  As mentioned last week, OFCOM have specifically said in
> their most recent consultation document in §5.93:
>
>  "Consequently, given the risk of harmful interference and the very
> stringent emission limits, we believe it would be prudent not to allow WSD
> operation in channel 38".
>
>  which we read as a very strong steer that they expect the WSD to specify
> (by omission, since that's the ETSI model) 0W (-Inf dBm) EIRP on channel 38.
>
>  kind regards,
>
>  Ray
>
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Sep 2013 14:55:23 +0000

On 19 Sep 2013, at 15:30, Vincent Chen <[email-masked]>
 wrote:

> Perhaps this is a terminology issue.

Perhaps :)

> There must be some specification for emissions (intended or not) that the device must meet during certification / testing.

Indeed.  The OFCOM / ETSI WSDB device<->DB interface only specifies intended in-block emissions.

All "Unintentional" out-of-block emissions are constrained by the ETSI draft specification.

> I believe you're focusing on intentional emissions, and Andy is speaking to any emissions.

That's my understanding.

> I don't think it's reasonable to state that a device it must have 0W -Inf dBm emissions at channel 38, if it intends to use any channels nearby?

I disagree - OFCOM are stating 0W -Inf dBm *intentional* in-block emissions at channel 38.

They are not requiring that there be absolutely no emissions into channel 38.  Leakage from adjacent channels will be managed through a combination of the device's emission class and OFCOM's rules on maximum permitted power levels in those nearby channels.

For example, in channels 37 and 39, OFCOM require Class 5 devices to transmit at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no constraints on Class 1 or 2.

OFCOM have proposed that this is sufficient to ensure that the unintentional leakage into channel 38 is not harmful to the PMSE devices operating in that channel.

kind regards,

Ray

---

From: Andy Lee <[email-masked]>
Date: Thu, 19 Sep 2013 08:21:33 -0700

Hi Ray,

For example, in channels 37 and 39, OFCOM require Class 5 devices to
> transmit at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no
> constraints on Class 1 or 2.

This actually shows that Ofcom has picked a power threshold on channel 38
of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5 devices,
you'll see they are 10 dB apart from each other and that they all work out
to be -33 dBm on channel 38.

The reason there are no limits for class 1 and 2 devices is because the
in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and
therefore the power on channel 38 will naturally be less than -33 dBm.

On Thu, Sep 19, 2013 at 7:55 AM, Ray Bellis <[email-masked]>wrote:

> > There must be some specification for emissions (intended or not) that
> the device must meet during certification / testing.
>
> > I don't think it's reasonable to state that a device it must have 0W
> -Inf dBm emissions at channel 38, if it intends to use any channels nearby?
>
> They are not requiring that there be absolutely no emissions into channel
> 38.  Leakage from adjacent channels will be managed through a combination
> of the device's emission class and OFCOM's rules on maximum permitted power
> levels in those nearby channels.
>
> For example, in channels 37 and 39, OFCOM require Class 5 devices to
> transmit at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no
> constraints on Class 1 or 2.
>
> OFCOM have proposed that this is sufficient to ensure that the
> unintentional leakage into channel 38 is not harmful to the PMSE devices
> operating in that channel.
>
> kind regards,
>
> Ray
>

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Sep 2013 15:30:02 +0000

On 19 Sep 2013, at 16:21, Andy Lee <[email-masked]>
 wrote:

> This actually shows that Ofcom has picked a power threshold on channel 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5 devices, you'll see they are 10 dB apart from each other and that they all work out to be -33 dBm on channel 38.
> 
> The reason there are no limits for class 1 and 2 devices is because the in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefore the power on channel 38 will naturally be less than -33 dBm.

The math bears that out, but nonetheless OFCOM are still effectively proposing that *no* in-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us to actually send that value of -33 dBm to a device.

Ray

---

From: Andy Lee <[email-masked]>
Date: Thu, 19 Sep 2013 09:09:26 -0700

>
> The math bears that out, but nonetheless OFCOM are still effectively
> proposing that *no* in-block transmissions are allowed in that channel.

Same is true for the FCC.  The FCC also assumes that "off" channels are not
used by WSDs.

Specifying a low power level like -33 dBm is effectively the same thing as
specifying no in-band emissions there.

Even if someone did try to put an in-band emission there (regardless of how
impractical that actually is), it would be too low to cause interference to
anyone and no harm has been done to the "RF environment".

The advantage of having an "well behaved" spectrum profile (contiguous and
without special values like -inf) is that the channel selection algorithm
on the WSDs becomes much simpler and logical.  There's no need to have lots
of special boundary condition checks and code paths that only get triggered
under special circumstances.  I'd like to avoid ambiguous interpretations
on the device side as much as possible.

On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <[email-masked]>wrote:

> > This actually shows that Ofcom has picked a power threshold on channel
> 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5
> devices, you'll see they are 10 dB apart from each other and that they all
> work out to be -33 dBm on channel 38.
> >
> The math bears that out, but nonetheless OFCOM are still effectively
> proposing that *no* in-block transmissions are allowed in that channel.
>
> Per OFCOM / ETSI device interface requirements it would be incorrect for
> us to actually send that value of -33 dBm to a device.
>
> Ray
>
>
>

---

From: Andy Lee <[email-masked]>
Date: Thu, 19 Sep 2013 09:11:36 -0700

> us to actually send that value of -33 dBm to a device.

I'd be interested in seeing the language for this.  Do you have a reference
I could look at?

Thanks

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 20 Sep 2013 03:07:07 -0700

On 9/19/2013 9:09 AM, Andy Lee wrote:
>
>     The math bears that out, but nonetheless OFCOM are still
>     effectively proposing that *no* in-block transmissions are allowed
>     in that channel.
>
>
> Same is true for the FCC.  The FCC also assumes that "off" channels 
> are not used by WSDs.
And that means NO intentional radiation in the channel.
>
> Specifying a low power level like -33 dBm is effectively the same 
> thing as specifying no in-band emissions there.

If you are reading this as "transmitted emissions in band should be 
lower than -33dBm" then, no, this is not the same as "no emissions" per 
FCC rules. If one were to intentionally transmit at -33dBm where no 
intentional emissions are allowed, that would not be the same as "no" 
under the rules.

>
> Even if someone did try to put an in-band emission there (regardless 
> of how impractical that actually is), it would be too low to cause 
> interference to anyone and no harm has been done to the "RF environment".
Should be a little careful here for a couple reasons.  I've designed and 
shipped communication systems that operate quite well with transmit 
power levels intentionally below -33dBm and do very useful things. It's 
pretty easy to design a receive with sensitivity better than -96dBm, so 
an intentional radiator at -33dBm near by will be noticed - at 900 MHz 
your 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above 
sensitivity at 100m, possibly. And when it comes to protecting their 
spectrum, people always use the best propagation model to calculate 
interfence impact on them :-).  I've probably misunderstood something 
badly, but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in the 
past  in regulatory discussions, and incumbent and/or protected users 
usually set the threshold closer to -120dBm and usually argue that even 
at really low TX power, the "aggregate impact" of multiple devices in 
the "RF Environment" is an unacceptable impact.   We had trouble with 
this argument when the intentional radiator TX limit was below the 
maximum unintentional emission limits for most non-transmitting devices 
(-41.3dBm).

So it would be fairly important to ensure a device does not interpret 
-33dBm as it's ok to use that channel so long as it's TX power is below 
-33dBm.

I may be off base here because of  how y'all see the DB providing and 
what I am expecting to support future needs. "protected users" includes 
more than TV stations in the US.

Not sure that helps, but hope so.

>
> The advantage of having an "well behaved" spectrum profile (contiguous 
> and without special values like -inf) is that the channel selection 
> algorithm on the WSDs becomes much simpler and logical.  There's no 
> need to have lots of special boundary condition checks and code paths 
> that only get triggered under special circumstances.  I'd like to 
> avoid ambiguous interpretations on the device side as much as possible.
Certainly ambiguous interpretations on the device side are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel 
that that can carry a 'wide'  data pipe. Other uses can fit many useful 
channels in one TV channel. In 802.15.4m we divide the TV channel up 
into multiple physical channels carrying low data rate signals.  Right 
now we assume a peak power level for the TV channel, and we get that 
value with the start frequency and width (or end frequency) from the 
database. However, I've heard it proposed to the FCC that we may get 
different power limits different parts of the TV channel, changing over 
time, as a protection mechanism for deal with narrow band protected 
users while allowing effective use of the rest of the TV channel.  For 
what we do, this is a good thing - our physical channel may be less than 
200kHz wide. There are a LOT of applications  in IoT that need < 200kHz 
channels,  and blocking an entire TV channel to protect a wireless 
microphone using < 200kHz of it means there are 28 other usable 
channels  not being used - not efficient use of the spectrum.

Hope this helps.

-Ben

>
>
> Andy Lee | 	 Google Inc. | 	[email-masked] 
> <mailto:[email-masked]> | 	 408-230-0522
>
>
>
> On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On 19 Sep 2013, at 16:21, Andy Lee <[email-masked]
>     <mailto:[email-masked]>>
>      wrote:
>
>     > This actually shows that Ofcom has picked a power threshold on
>     channel 38 of -33 dBm.  If you look at the ACLR numbers for class
>     3, 4, and 5 devices, you'll see they are 10 dB apart from each
>     other and that they all work out to be -33 dBm on channel 38.
>     >
>     > The reason there are no limits for class 1 and 2 devices is
>     because the in-band power on channels 37 and 39 cannot exceed +36
>     dBm/8MHz, and therefore the power on channel 38 will naturally be
>     less than -33 dBm.
>
>     The math bears that out, but nonetheless OFCOM are still
>     effectively proposing that *no* in-block transmissions are allowed
>     in that channel.
>
>     Per OFCOM / ETSI device interface requirements it would be
>     incorrect for us to actually send that value of -33 dBm to a device.
>
>     Ray
>
>
>
>
>

---

From: Andy Lee <[email-masked]>
Date: Fri, 20 Sep 2013 13:00:20 -0700

Hi Ben,

If you are reading this as "transmitted emissions in band should be lower
> than -33dBm" then, no, this is not the same as "no emissions" per FCC
> rules. If one were to intentionally transmit at -33dBm where no intentional
> emissions are allowed, that would not be the same as "no" under the rules.

There is certainly no intention to encourage any malicious behavior.  In
general, we expect devices to be trying to do the right thing and just need
some information to understand where the boundaries are.  These boundaries
include both intentional and unintentional emissions.

Various modulation types have known spectral profiles, including both
in-band and out-of-band emissions.  Knowing where the "shelf" is on the
adjacent channel makes it possible to match that with the "skirt" of the
intended modulation pattern.  The "skirt" is not part of the intended
emission, but is important in trying to avoid causing interference on
adjacent channels.

A crude example of this is shown in the following image:

Best regards,

On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe <[email-masked]>wrote:

>  Same is true for the FCC.  The FCC also assumes that "off" channels are
> not used by WSDs.
>
>  Specifying a low power level like -33 dBm is effectively the same thing
> as specifying no in-band emissions there.
>
>
> If you are reading this as "transmitted emissions in band should be lower
> than -33dBm" then, no, this is not the same as "no emissions" per FCC
> rules. If one were to intentionally transmit at -33dBm where no intentional
> emissions are allowed, that would not be the same as "no" under the rules.
>
>
>
>  Even if someone did try to put an in-band emission there (regardless of
> how impractical that actually is), it would be too low to cause
> shipped communication systems that operate quite well with transmit power
> levels intentionally below -33dBm and do very useful things. It's pretty
> easy to design a receive with sensitivity better than -96dBm, so an
> intentional radiator at -33dBm near by will be noticed - at 900 MHz your
> 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity
> at 100m, possibly. And when it comes to protecting their spectrum, people
> always use the best propagation model to calculate interfence impact on
> them :-).  I've probably misunderstood something badly, but -33dBm is
> certainly enough power to be noticed.
>
> I have tried the "too low to be noticed" argument a few times in the past
> in regulatory discussions, and incumbent and/or protected users usually set
> the threshold closer to -120dBm and usually argue that even at really low
> TX power, the "aggregate impact" of multiple devices in the "RF
> Environment" is an unacceptable impact.   We had trouble with this argument
> when the intentional radiator TX limit was below the maximum unintentional
> emission limits for most non-transmitting devices (-41.3dBm).
>
> I may be off base here because of  how y'all see the DB providing and what
> I am expecting to support future needs. "protected users" includes more
> than TV stations in the US.
>
> algorithm on the WSDs becomes much simpler and logical.  There's no need to
> have lots of special boundary condition checks and code paths that only get
> triggered under special circumstances.  I'd like to avoid ambiguous
> interpretations on the device side as much as possible.
>
> channels in one TV channel. In 802.15.4m we divide the TV channel up into
> multiple physical channels carrying low data rate signals.  Right now we
> assume a peak power level for the TV channel, and we get that value with
> the start frequency and width (or end frequency) from the database.
> However, I've heard it proposed to the FCC that we may get different power
> limits different parts of the TV channel, changing over time, as a
> protection mechanism for deal with narrow band protected users while
> allowing effective use of the rest of the TV channel.  For what we do, this
> is a good thing - our physical channel may be less than 200kHz wide. There
> are a LOT of applications  in IoT that need < 200kHz channels,  and
> blocking an entire TV channel to protect a wireless microphone using <
> 200kHz of it means there are 28 other usable channels  not being used - not
> efficient use of the spectrum.
>
> Hope this helps.
>
> -Ben
>
>
>
> paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
>

---

From: <[email-masked]>
Date: Fri, 20 Sep 2013 20:54:38 +0000

Aren't we talking past each other in this thread?
If the rules are supposed to specify what is the max intended power level a device can put into a channel (available or not), then I also think this is what the DB should communicate to the device.
If Ofcom specifies that the max leakage into an unavailable channel is -33dbm, I assume the device will not be certified if it leaks more. If the device supports multiple modulation types and one of them leaks more than what is permitted in that regulatory domain, then the device will need to know it, and in that regulatory domain avoid using that particular modulation type. How does the device come to know it? Andy proposes the DB to indicate that level for the unavailable channels. Others folks seem to suggest a device built to operate under a certain ruleset has to implicitly know it.
Another way of looking at it might be to say that the max level of permitted unintentional leakage into an adjacent channel is part of the rulesetInfo, and the spectrum response only lists the available channels. Could this be a way forward?

-          gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Andy Lee
Sent: Friday, September 20, 2013 1:00 PM
To: Benjamin A. Rolfe
Cc: Protocol to Access White Space database
Subject: Re: [paws] Spectrum encoding discussion

Hi Ben,

If you are reading this as "transmitted emissions in band should be lower than -33dBm" then, no, this is not the same as "no emissions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.

There is certainly no intention to encourage any malicious behavior.  In general, we expect devices to be trying to do the right thing and just need some information to understand where the boundaries are.  These boundaries include both intentional and unintentional emissions.

Various modulation types have known spectral profiles, including both in-band and out-of-band emissions.  Knowing where the "shelf" is on the adjacent channel makes it possible to match that with the "skirt" of the intended modulation pattern.  The "skirt" is not part of the intended emission, but is important in trying to avoid causing interference on adjacent channels.

Best regards,

Andy Lee |

 Google Inc. |

 [email-masked]<mailto:[email-masked]> |

 408-230-0522

On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe <[email-masked]<mailto:[email-masked]>> wrote:

Same is true for the FCC.  The FCC also assumes that "off" channels are not used by WSDs.
And that means NO intentional radiation in the channel.

Specifying a low power level like -33 dBm is effectively the same thing as specifying no in-band emissions there.

If you are reading this as "transmitted emissions in band should be lower than -33dBm" then, no, this is not the same as "no emissions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.

Even if someone did try to put an in-band emission there (regardless of how impractical that actually is), it would be too low to cause interference to anyone and no harm has been done to the "RF environment".
Should be a little careful here for a couple reasons.  I've designed and shipped communication systems that operate quite well with transmit power levels intentionally below -33dBm and do very useful things. It's pretty easy to design a receive with sensitivity better than -96dBm, so an intentional radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And when it comes to protecting their spectrum, people always use the best propagation model to calculate interfence impact on them :-).  I've probably misunderstood something badly, but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in the past  in regulatory discussions, and incumbent and/or protected users usually set the threshold closer to -120dBm and usually argue that even at really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable impact.   We had trouble with this argument when the intentional radiator TX limit was below the maximum unintentional emission limits for most non-transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dBm as it's ok to use that channel so long as it's TX power is below -33dBm.

I may be off base here because of  how y'all see the DB providing and what I am expecting to support future needs. "protected users" includes more than TV stations in the US.

The advantage of having an "well behaved" spectrum profile (contiguous and without special values like -inf) is that the channel selection algorithm on the WSDs becomes much simpler and logical.  There's no need to have lots of special boundary condition checks and code paths that only get triggered under special circumstances.  I'd like to avoid ambiguous interpretations on the device side as much as possible.
Certainly ambiguous interpretations on the device side are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel that that can carry a 'wide'  data pipe. Other uses can fit many useful channels in one TV channel. In 802.15.4m we divide the TV channel up into multiple physical channels carrying low data rate signals.  Right now we assume a peak power level for the TV channel, and we get that value with the start frequency and width (or end frequency) from the database. However, I've heard it proposed to the FCC that we may get different power limits different parts of the TV channel, changing over time, as a protection mechanism for deal with narrow band protected users while allowing effective use of the rest of the TV channel.  For what we do, this is a good thing - our physical channel may be less than 200kHz wide. There are a LOT of applications  in IoT that need < 200kHz channels,  and blocking an entire TV channel to protect a wireless microphone using < 200kHz of it means there are 28 other usable channels  not being used - not efficient use of the spectrum.

Hope this helps.

-Ben

Andy Lee |

 Google Inc. |

 [email-masked]<mailto:[email-masked]> |

 408-230-0522<tel:408-230-0522>

On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <[email-masked]<mailto:[email-masked]>> wrote:

Ray

paws mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 20 Sep 2013 17:35:12 -0400

We have, until know, always worked on the assumption that the device would be certified, or not, to comply with any out of band emissions. The FCC for instance specifically tests the more stringent rule around channel 37, as well as the more general case. The Database is not, and cannot be, the enforcement agency. So simply providing a list of channels that it can use is sufficient.
It should be of no consequence to a device why it cannot use a channel other than to behave with its compliant emissions.
I agree with Gabor, why are we overly complicating this?

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 20, 2013 4:54 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Spectrum encoding discussion

Aren’t we talking past each other in this thread?
If the rules are supposed to specify what is the max intended power level a device can put into a channel (available or not), then I also think this is what the DB should communicate to the device.
If Ofcom specifies that the max leakage into an unavailable channel is -33dbm, I assume the device will not be certified if it leaks more. If the device supports multiple modulation types and one of them leaks more than what is permitted in that regulatory domain, then the device will need to know it, and in that regulatory domain avoid using that particular modulation type. How does the device come to know it? Andy proposes the DB to indicate that level for the unavailable channels. Others folks seem to suggest a device built to operate under a certain ruleset has to implicitly know it.
Another way of looking at it might be to say that the max level of permitted unintentional leakage into an adjacent channel is part of the rulesetInfo, and the spectrum response only lists the available channels. Could this be a way forward?

-          gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Andy Lee
Sent: Friday, September 20, 2013 1:00 PM
To: Benjamin A. Rolfe
Cc: Protocol to Access White Space database
Subject: Re: [paws] Spectrum encoding discussion

Hi Ben,

Best regards,

Andy Lee |

 Google Inc. |

 408-230-0522

Hope this helps.

-Ben

Andy Lee |

 Google Inc. |

Ray

paws mailing list

---

From: Andy Lee <[email-masked]>
Date: Fri, 20 Sep 2013 16:11:44 -0700

I was actually hoping to simplify things for devices.

1) Having a fully specified spectrum profile without discontinuities and
without "special" values like -inf make it much easier to write the client
side code.  This minimizes the number of special edge cases that need to be
handled by the parsing logic and "emission fitting" code on the client.

2) We still seem to be thinking in terms of TV channels only.  PAWS is
designed for other frequency bands too, and there won't always be such a
distinct concept of on-channel vs. adjacent-channel emissions.

3) We don't know what future WSD technologies will be capable of.  Wi-Fi
already supports a long list of modulation types (e.g., BPSK, QPSK, DSSS,
FHSS, OFDM) and channel widths.  Software defined radios and other
technologies can dynamically choose modulation types, channel widths, and
power distribution.  These agile radio technologies need the full spectrum
profile to help them choose the right combination of emission parameters.
 WSDs are just a "black box" from the database's point of view.

On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth
<[email-masked]>wrote:

> We have, until know, always worked on the assumption that the device would
> be certified, or not, to comply with any out of band emissions. The FCC for
> instance specifically tests the more stringent rule around channel 37, as
> well as the more general case. The Database is not, and cannot be, the
> enforcement agency. So simply providing a list of channels that it can use
> is sufficient.
> It should be of no consequence to a device why it cannot use a channel
> other than to behave with its compliant emissions.
> From: "[email-masked]" <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
> Aren’t we talking past each other in this thread?****
>
> If the rules are supposed to specify what is the max intended power level
> a device can put into a channel (available or not), then I also think this
> is what the DB should communicate to the device.****
>
> If Ofcom specifies that the max leakage into an unavailable channel is
> -33dbm, I assume the device will not be certified if it leaks more. If the
> device supports multiple modulation types and one of them leaks more than
> what is permitted in that regulatory domain, then the device will need to
> know it, and in that regulatory domain avoid using that particular
> modulation type. How does the device come to know it? Andy proposes the DB
> to indicate that level for the unavailable channels. Others folks seem to
> suggest a device built to operate under a certain ruleset has to implicitly
> know it.****
>
> Another way of looking at it might be to say that the max level of
> permitted unintentional leakage into an adjacent channel is part of the
> rulesetInfo, and the spectrum response only lists the available channels.
> Could this be a way forward?****
>
> -          gabor****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *ext Andy Lee
> *Sent:* Friday, September 20, 2013 1:00 PM
> *To:* Benjamin A. Rolfe
> *Cc:* Protocol to Access White Space database
> *Subject:* Re: [paws] Spectrum encoding discussion****
>
> ** **
>
> Hi Ben,****
>
> ** **
>
> And that means NO intentional radiation in the channel.  ****
>
> ** **
>
> ****
> ** **
> include both intentional and unintentional emissions.****
>
> ** **
>
> adjacent channels.****
> ** **
> A crude example of this is shown in the following image:****
>
> ** **
>
> ****
>
> ** **
>
> Best regards,****
>
>
> ****
>
> ** **
>
> Andy Lee |****
>
>  Google Inc. |****
>
>  [email-masked] |****
>
>  408-230-0522****
>
> ** **
>
> On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe <[email-masked]>
> wrote:****
>
> ** **
>
> On 9/19/2013 9:09 AM, Andy Lee wrote:****
>
> proposing that *no* in-block transmissions are allowed in that channel.***
> *
>
> ** **
>
> not used by WSDs.****
> And that means NO intentional radiation in the channel.  ****
>
> ** **
>
> specifying no in-band emissions there.****
>
> ** **
>
> ****
> ****
> ** **
> interference to anyone and no harm has been done to the "RF environment".*
> ***
>
> Not sure that helps, but hope so.  ****
>
>
>
>
> ****
>
> ** **
>
> on the device side as much as possible.****
>
> ****
> ****
> ** **
> Andy Lee |****
>  Google Inc. |****
>  [email-masked] |****
>  408-230-0522****
> ** **
> On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <[email-masked]>
> wrote:****
>
>
> On 19 Sep 2013, at 16:21, Andy Lee <[email-masked]>****
>
>  wrote:
>
> therefore the power on channel 38 will naturally be less than -33 dBm.****
>
> ****
> ** **
> ** **
> _______________________________________________****
>
> paws mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Sat, 21 Sep 2013 00:15:21 +0000

All:

I know this is a long winded reply to an already laborious conversation.  But I think I can put a finger on the essential "disagreement", and even offer a compromise that will allow us to move forward.

Hint: the whole "option 1"/"option 2" debate is a bit of a misdirection, as those two options did NOT capture the two sides of the essential disagreement; the issue at hand is really about "is an out-of-band emission limit a good way to express that a channel is unavailable?"

There seems to be the camp that "out of band emission limits" are the SAME as "channel unavailable".  In my reading of the FCC rules, that is simply not the case.  There are times when FCC rules require me (as a Database) to say "this channel is unavailable" other than "a protected entity occupies this channel".  For example:

*         It is a channel categorically excluded from the Whitespace spectrum (e.g. US Channel 3 or Channel 37).

*         There is an ad-hoc (FCC provided) polygon establishing an ad-hoc exclusion zone.

*         A device is blacklisted.

To say that "Channel 37 is available at -36.8 dBm" is just not the same as "Channel 37 is unavailable", IMO.

To tell all devices in an ad-hoc exclusion zone that "all channels are available at -36.8 dBm" is just not the same as "all channels are unavailable".

To tell a blacklisted device that "all channels are available at -36.8 dBm" is just not the same as "all channels are unavailable".

In other words: If PAWS does not give me a way to say a channel is unequivocally "unavailable", then, in my opinion as a Database provider, it is not sufficiently expressive for me to meet the FCC rules.

If we DO use PAWS to encode out-of-band emissions limits, I have to say, I think it is farfetched that a device implemented today to today's rules will be able to - in the future - either "take advantage" of a less stringent "out-of-band mask" or comply to a more stringent mask.  As marvelous as SDRs are/can be, that degree of flexibility is just not common in consumer-grade mass market devices owing to cost.  That leads me to the conclusion that expecting to use PAWS that way is just not going to be that useful.

However, I realize we may differ on this point.  But the notion of "PAWS available-spectrum replies should encode out-of-band emissions limits" is just a separate notion from "PAWS must allow a way to encode 'channel unavailable'".  It is confounding those two concepts that - IMO - has lead to the current "disagreement".

OK, time for my proposed grand compromise:

*         Let's define a way to unequivocally encode "channel unavailable" that is NOT synonymous with "out of band emissions limits".  I need it as a Database provider.  (Again: I offer to recap several different ways to do this later.)

*         Once we have a way to unequivocally encode "channel unavailable", we can have a separate discussion as to whether or not it is ever used.  Perhaps different Databases will interpret their legal/regulatory obligations differently.  Or even, a given Database may use "-36.8 dBm" in some cases and "channel unavailable" in others.

The purpose of this WG is to produce a protocol that:

1.       Provides for interoperability (because it is sufficiently clear).

2.       Allows all parties to meet their legal/regulatory obligations as they interpret them.

I feel the above proposed compromise accomplishes both.

Dan Harasty

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Lee
Sent: Friday, September 20, 2013 7:12 PM
To: Peter Stanforth
Cc: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

1) Having a fully specified spectrum profile without discontinuities and without "special" values like -inf make it much easier to write the client side code.  This minimizes the number of special edge cases that need to be handled by the parsing logic and "emission fitting" code on the client.

2) We still seem to be thinking in terms of TV channels only.  PAWS is designed for other frequency bands too, and there won't always be such a distinct concept of on-channel vs. adjacent-channel emissions.

3) We don't know what future WSD technologies will be capable of.  Wi-Fi already supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, FHSS, OFDM) and channel widths.  Software defined radios and other technologies can dynamically choose modulation types, channel widths, and power distribution.  These agile radio technologies need the full spectrum profile to help them choose the right combination of emission parameters.  WSDs are just a "black box" from the database's point of view.

Andy Lee |

 Google Inc. |

 408-230-0522

On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
We have, until know, always worked on the assumption that the device would be certified, or not, to comply with any out of band emissions. The FCC for instance specifically tests the more stringent rule around channel 37, as well as the more general case. The Database is not, and cannot be, the enforcement agency. So simply providing a list of channels that it can use is sufficient.
It should be of no consequence to a device why it cannot use a channel other than to behave with its compliant emissions.
I agree with Gabor, why are we overly complicating this?

-          gabor

Hi Ben,

Best regards,

Andy Lee |

 Google Inc. |

Hope this helps.

-Ben

Andy Lee |

 Google Inc. |

Ray

paws mailing list

---

From: <[email-masked]>
Date: Sat, 21 Sep 2013 01:31:27 +0000

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.

2.       If one wants to be explicit on what the rules say for the leakage limits, then we can encode those into the rulesetInfo.

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.
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.

-          gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Harasty, Daniel J
Sent: Friday, September 20, 2013 5:15 PM
To: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

All:

Dan Harasty

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andy Lee
Sent: Friday, September 20, 2013 7:12 PM
To: Peter Stanforth
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum encoding discussion

Andy Lee |

 Google Inc. |

 408-230-0522

-          gabor

Hi Ben,

Best regards,

Andy Lee |

 Google Inc. |

Hope this helps.

-Ben

Andy Lee |

 Google Inc. |

Ray

paws mailing list

---

From: Vincent Chen <[email-masked]>
Date: Fri, 20 Sep 2013 19:00:46 -0700

All,

Thanks Dan for framing the discussion. We do not like a magic value, such
as "-inf" to indicate off, but simply leaving off the power would be
acceptable.
To make it more concrete, a Database that chooses to explicitly represent
"off" channels may be encoded as the following.

I've annotated the first profile with US channels. It is able to represent
only frequencies that are only in the band plan
and within the band plan, frequencies without a power is interpreted by the
device as OFF.

"spectra": [
  {
    "bandwidth": 6e6,
    "profiles": [
      [
        { "freqHz": 5.4e7 },  // channels 2-4 off
        { "freqHz": 7.2e7 },
      ],
      [
        { "freqHz": 7.6e7 },  // channels 5-6 off
        { "freqHz": 8.8e7 },
      ],
      [
        { "freqHz": 1.74e8 }, // channels 7-13 off
        { "freqHz": 2.16e8 },
      ],
      [
        { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14
        { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 },
        { "freqHz": 4.76e8 },  // channel 15-21 off
        { "freqHz": 5.18e8 },
        { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23
        { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
        { "freqHz": 5.30e8 },
        { "freqHz": 6.98e8 }
      ]
    ]
  },
  {
    "bandwidth": 1e5,
    "profiles": [
      [
        { "freqHz": 5.4e7 },
        { "freqHz": 7.2e7 },
      ],
      [
        { "freqHz": 7.6e7 },
        { "freqHz": 8.8e7 },
      ],
      [
        { "freqHz": 1.74e8 },
        { "freqHz": 2.16e8 },
      ],
      [
        { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 },
        { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 },
        { "freqHz": 4.76e8 },
        { "freqHz": 5.18e8 },
        { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
        { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
        { "freqHz": 5.30e8 },
        { "freqHz": 6.98e8 }
      ]
    ]
  }
]

I hope this is getting closer to addressing most of the concerns.

-vince

On Fri, Sep 20, 2013 at 6:31 PM, <[email-masked]> 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.****
>
> ** **
>
> **2.       **If one wants to be explicit on what the rules say for the
> leakage limits, then we can encode those into the rulesetInfo.****
>
> ** **
>
> **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.****
>
> 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.****
>
> ** **
>
> **-          **gabor****
>
> ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Harasty, Daniel J
> *Sent:* Friday, September 20, 2013 5:15 PM
> *To:* [email-masked]
>
> All:****
> I know this is a long winded reply to an already laborious conversation.
> But I think I can put a finger on the essential “disagreement”, and even
> offer a compromise that will allow us to move forward.****
>
> ** **
>
> Hint: the whole “option 1”/”option 2” debate is a bit of a misdirection,
> as those two options did NOT capture the two sides of the essential
> disagreement; the issue at hand is really about “is an out-of-band emission
> limit a good way to express that a channel is unavailable?”****
>
> ** **
>
> There seems to be the camp that “out of band emission limits” are the SAME
> as “channel unavailable”.  In my reading of the FCC rules, that is simply
> not the case.  There are times when FCC rules *require* me (as a
> Database) to say “this channel is unavailable” *other* than “a protected
> entity occupies this channel”.  For example:****
>
> ** **
>
> **·         **It is a channel categorically excluded from the Whitespace
> spectrum (e.g. US Channel 3 or Channel 37).****
>
> **·         **There is an ad-hoc (FCC provided) polygon establishing an
> ad-hoc exclusion zone.****
>
> **·         **A device is blacklisted.****
>
> ** **
>
> To say that “Channel 37 is available at -36.8 dBm” is just not the same as
> “Channel 37 is unavailable”, IMO.****
>
> ** **
>
> To tell all devices in an ad-hoc exclusion zone that “all channels are
> available at -36.8 dBm” is just not the same as “all channels are
> unavailable”.****
>
> ** **
>
> To tell a blacklisted device that “all channels are available at -36.8
> dBm” is just not the same as “all channels are unavailable”.****
>
> ** **
>
> *In other words: If PAWS does not give me a way to say a channel is
> unequivocally “unavailable”, then, in my opinion as a Database provider, it
> is not sufficiently expressive for me to meet the FCC rules.  *
>
> ** **
>
> If we DO use PAWS to encode out-of-band emissions limits, I have to say, I
> think it is farfetched that a device implemented today to today’s rules
> will be able to – in the future – either “take advantage” of a less
> stringent “out-of-band mask” or comply to a more stringent mask.  As
> marvelous as SDRs are/can be, that degree of flexibility is just not common
> in consumer-grade mass market devices owing to cost.  That leads me to the
> conclusion that expecting to use PAWS that way is just not going to be that
> useful.****
>
> ** **
>
> However, I realize we may differ on this point.  But the notion of “PAWS
> available-spectrum replies should encode out-of-band emissions limits” is
> just a separate notion from “PAWS must allow a way to encode ‘channel
> unavailable’”.  It is confounding those two concepts that – IMO – has lead
> to the current “disagreement”.****
>
> ** **
>
> OK, time for my proposed grand compromise:****
>
> ** **
>
> **·         **Let’s define a way to unequivocally encode “channel
> unavailable” that is NOT synonymous with “out of band emissions limits”. * I
> need it as a Database provider*.  (Again: I offer to recap several
> different ways to do this later.)****
>
> ** **
>
> **·         **Once we have a way to unequivocally encode “channel
> unavailable”, we can have a *separate* discussion as to whether or not it
> is ever used.  Perhaps different Databases will interpret their
> legal/regulatory obligations differently.  Or even, a given Database may
> use “-36.8 dBm” in some cases and “channel unavailable” in others.****
>
> ** **
>
> The purpose of this WG is to produce a protocol that:****
>
> ** **
>
> **1.       **Provides for interoperability (because it is sufficiently
> clear).****
>
> ** **
>
> **2.       **Allows all parties to meet their legal/regulatory
> obligations as they interpret them.****
>
> ** **
>
> I feel the above proposed compromise accomplishes both.****
>
> ** **
>
> ** **
>
> Dan Harasty****
>
> ** **
>
> ** **
>
> ** **
>
> *On Behalf Of *Andy Lee
> *Sent:* Friday, September 20, 2013 7:12 PM
> *To:* Peter Stanforth
> *Cc:* [email-masked]
> I was actually hoping to simplify things for devices.****
>
> ** **
>
> handled by the parsing logic and "emission fitting" code on the client.***
> *
>
> ** **
>
> distinct concept of on-channel vs. adjacent-channel emissions.****
>
> ** **
>
>  WSDs are just a "black box" from the database's point of view.****
>
> ** **
>
>
> ****
>
> ** **
>
> Andy Lee |****
>
>  Google Inc. |****
>
>  [email-masked] |****
>
>  408-230-0522****
>
> ** **
>
> On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <[email-masked]>
> wrote:****
>
> is sufficient.****
> other than to behave with its compliant emissions. ****
>
> I agree with Gabor, why are we overly complicating this?****
>
> ** **
>
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Friday, September 20, 2013 4:54 PM
> *To: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>****
>
>
> *Subject: *Re: [paws] Spectrum encoding discussion****
>
> ** **
>
> -Ben****
> Ray****

-- 
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Sat, 21 Sep 2013 11:23:35 -0400

Gabor in principle I think you and Andy are both right. It was called PAWS because it was supposed to be able to cover more than TVWS. But when we wrote the charter we only had the FCC as a guide. My preference is to stay within the charter and accept that there will be future versions of a the spec as new spectrum bands open up

On Sep 20, 2013, at 9:32 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> 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.

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.
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.

-          gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Harasty, Daniel J
Sent: Friday, September 20, 2013 5:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum encoding discussion

All:

I know this is a long winded reply to an already laborious conversation.  But I think I can put a finger on the essential “disagreement”, and even offer a compromise that will allow us to move forward.

Hint: the whole “option 1”/”option 2” debate is a bit of a misdirection, as those two options did NOT capture the two sides of the essential disagreement; the issue at hand is really about “is an out-of-band emission limit a good way to express that a channel is unavailable?”

There seems to be the camp that “out of band emission limits” are the SAME as “channel unavailable”.  In my reading of the FCC rules, that is simply not the case.  There are times when FCC rules require me (as a Database) to say “this channel is unavailable” other than “a protected entity occupies this channel”.  For example:

·         It is a channel categorically excluded from the Whitespace spectrum (e.g. US Channel 3 or Channel 37).

·         There is an ad-hoc (FCC provided) polygon establishing an ad-hoc exclusion zone.

·         A device is blacklisted.

To say that “Channel 37 is available at -36.8 dBm” is just not the same as “Channel 37 is unavailable”, IMO.

To tell all devices in an ad-hoc exclusion zone that “all channels are available at -36.8 dBm” is just not the same as “all channels are unavailable”.

To tell a blacklisted device that “all channels are available at -36.8 dBm” is just not the same as “all channels are unavailable”.

In other words: If PAWS does not give me a way to say a channel is unequivocally “unavailable”, then, in my opinion as a Database provider, it is not sufficiently expressive for me to meet the FCC rules.

If we DO use PAWS to encode out-of-band emissions limits, I have to say, I think it is farfetched that a device implemented today to today’s rules will be able to – in the future – either “take advantage” of a less stringent “out-of-band mask” or comply to a more stringent mask.  As marvelous as SDRs are/can be, that degree of flexibility is just not common in consumer-grade mass market devices owing to cost.  That leads me to the conclusion that expecting to use PAWS that way is just not going to be that useful.

However, I realize we may differ on this point.  But the notion of “PAWS available-spectrum replies should encode out-of-band emissions limits” is just a separate notion from “PAWS must allow a way to encode ‘channel unavailable’”.  It is confounding those two concepts that – IMO – has lead to the current “disagreement”.

·         Let’s define a way to unequivocally encode “channel unavailable” that is NOT synonymous with “out of band emissions limits”.  I need it as a Database provider.  (Again: I offer to recap several different ways to do this later.)

·         Once we have a way to unequivocally encode “channel unavailable”, we can have a separate discussion as to whether or not it is ever used.  Perhaps different Databases will interpret their legal/regulatory obligations differently.  Or even, a given Database may use “-36.8 dBm” in some cases and “channel unavailable” in others.

Dan Harasty

Andy Lee |

 Google Inc. |

 408-230-0522

-          gabor

Hi Ben,

Best regards,

Andy Lee |

 Google Inc. |

Hope this helps.

-Ben

Andy Lee |

 Google Inc. |

Ray

paws mailing list

---

From: Ray Bellis <[email-masked]>
Date: Mon, 23 Sep 2013 09:20:16 +0000

On 21 Sep 2013, at 02:31, [email-masked]<mailto:[email-masked]> wrote:

Few things to consider:

+1

+1

Agreed!   [but with the caveat, as I've been arguing all along, that encoding option #2 doesn't permit that]

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

---

From: <[email-masked]>
Date: Mon, 23 Sep 2013 19:56:08 +0000

Vince,
This proposal of yours below could potentially become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power levels, which are btw, not available channels.

So far, we have 4 proposed ways to indicate unavailable channels:

a)      Not listing it, implicit unavailability

b)      List unavailable channels and specify the power limit, eg -56dbm

c)       List unavailable channels and specify -inf as power limit

d)      List unavailable channels and do not specify any power limit

So far, we have majority in favour of a), few people who could live or prefer c) and sort of consensus to strike out option b) from the list above.

We'll wait for more input on the list before declaring rough consensus for the question above; then we'll go back to the original question on whether the encoding of spectrum profile should be option 1 or option 2.

p.s. It looks to me, that if we want to specify unavailable channels, we may need to modify the names of the paws messages to 'Spectrum schedule' or sg along these lines.

-          Gabor

From: ext Vincent Chen [mailto:[email-masked]]
Sent: Friday, September 20, 2013 7:01 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Harasty, Daniel J; [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

All,

Thanks Dan for framing the discussion. We do not like a magic value, such as "-inf" to indicate off, but simply leaving off the power would be acceptable.
To make it more concrete, a Database that chooses to explicitly represent "off" channels may be encoded as the following.

I've annotated the first profile with US channels. It is able to represent only frequencies that are only in the band plan
and within the band plan, frequencies without a power is interpreted by the device as OFF.

"spectra": [
  {
    "bandwidth": 6e6,
    "profiles": [
      [

-vince

On Fri, Sep 20, 2013 at 6:31 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Few things to consider:

-          gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Harasty, Daniel J
Sent: Friday, September 20, 2013 5:15 PM
To: [email-masked]<mailto:[email-masked]>

All:

Dan Harasty

Andy Lee |

 Google Inc. |

-          gabor

Hi Ben,

Best regards,

Andy Lee |

 Google Inc. |

Hope this helps.

-Ben

Andy Lee |

 Google Inc. |

Ray

paws mailing list

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Mon, 23 Sep 2013 18:19:45 -0700

Gabor,

I agree on possible renaming, if we want to specify unavailable channels.

Please see comments inline.

On Mon, Sep 23, 2013 at 12:56 PM, <[email-masked]> wrote:

>  Vince,****
>
> This proposal of yours below could potentially become very confusing. The
> message itself is named Available Spectrum Request, and you propose the
> Available Spectrum Response to include a bunch of channels with unspecified
> power levels, which are btw, not available channels. ****
>
> ** **
>
> ** **
>
> So far, we have 4 proposed ways to indicate unavailable channels:****
>
> **a)      **Not listing it, implicit unavailability
>
This has the drawback of not distinguishing between being silent about a
channel that is within the database's purview (channel off), and being
silent about a channel that is outside the database's purview (out of scope
for given ruleset).

> ****
>
> **b)      **List unavailable channels and specify the power limit, eg
> -56dbm
>
Since the protocol should stand on its own, independent of any particular
regulatory rule, do we really want to rule this out? In our interpretations
of the FCC rules, for example, a Database is not prevented from doing this.

> ****
>
> **c)       **List unavailable channels and specify –inf as power limit
>

"-Inf" is not really workable, because JSON does not allow Infinity or NaNs
(http://tools.ietf.org/html/rfc4627), hence the d) proposal.

****
>
> **d)      **List unavailable channels and do not specify any power limit
>
****
>
> ** **
>
> So far, we have majority in favour of a), few people who could live or
> prefer c) and sort of consensus to strike out option b) from the list above.
> ****
>
> ** **
>
> We’ll wait for more input on the list before declaring rough consensus for
> the question above; then we’ll go back to the original question on whether
> the encoding of spectrum profile should be option 1 or option 2.****
>
> ** **
>
> p.s. It looks to me, that if we want to specify unavailable channels, we
> may need to modify the names of the paws messages to ‘Spectrum schedule’ or
> sg along these lines.****
>
> ** **
>
> **-          **Gabor****
>
> **
>

---

From: Don Joslyn <[email-masked]>
Date: Tue, 24 Sep 2013 13:57:27 -0400

Vince,
Please see my comments below (Marked with [DJ]).
Thanks,
Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Monday, September 23, 2013 9:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

Gabor,

On Mon, Sep 23, 2013 at 12:56 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Vince,
This proposal of yours below could potentially become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power levels, which are btw, not available channels.
 So far, we have 4 proposed ways to indicate unavailable channels:

a)      Not listing it, implicit unavailability
This has the drawback of not distinguishing between being silent about a channel that is within the database's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

[DJ - Why should the database care about channels that are outside the scope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missing something?]

b)      List unavailable channels and specify the power limit, eg -56dbm
Since the protocol should stand on its own, independent of any particular regulatory rule, do we really want to rule this out? In our interpretations of the FCC rules, for example, a Database is not prevented from doing this.

[DJ - I'm still in favor of just using the implicit unavailability method described above in a). What value is there in providing a power level for an unavailable channel? If I'm the radio, I can't use the channel, and I'm not going to intentionally transmit in that channel. This comment also applies to c) and d).]

"-Inf" is not really workable, because JSON does not allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.

-          Gabor

---

From: Paul Lambert <[email-masked]>
Date: Tue, 24 Sep 2013 11:48:22 -0700

In line below … speaking strongly in favor of "b"

Gabor,

[DJ – Why should the database care about channels that are outside the scope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missing something?]

The rules have strict adjacent channel requirements.  Meeting the spectral mask for the adjacent channels  is one of the hardest parts for fielding real equipment.  If the rules allow relative measurement of the adjacent channel energy, you can simply lower your transmit power to the point that you can meet the adjacent requirements.

For a general White Spaces solution – it is critical to have knowledge for the full spectrum mask.  The full spectrum mask includes adjacent non-allowed channels.

RF channel usage are NOT a binary on/off or a simple transmit level.  The mask has a specific contour that extends beyond the "allowed" channel.  Transmitters will always send energy in more than the allowed channel!

Paul

[DJ – I’m still in favor of just using the implicit unavailability method described above in a). What value is there in providing a power level for an unavailable channel? If I’m the radio, I can’t use the channel, and I’m not going to intentionally transmit in that channel. This comment also applies to c) and d).]

c)       List unavailable channels and specify –inf as power limit

We’ll wait for more input on the list before declaring rough consensus for the question above; then we’ll go back to the original question on whether the encoding of spectrum profile should be option 1 or option 2.

p.s. It looks to me, that if we want to specify unavailable channels, we may need to modify the names of the paws messages to ‘Spectrum schedule’ or sg along these lines.

-          Gabor

---

From: Vincent Chen <[email-masked]>
Date: Tue, 24 Sep 2013 11:57:32 -0700

Thanks for the comments Don. Answers inline, marked with [V]

Gabor,****
>
> ** **
>
> I agree on possible renaming, if we want to specify unavailable channels.*
> ***
>
> ** **
>
> Please see comments inline. ****
>
> ** **
>
> On Mon, Sep 23, 2013 at 12:56 PM, <[email-masked]> wrote:****
>
> Vince,****
>
> a)      Not listing it, implicit unavailability****
>
> for given ruleset).****
> [DJ – Why should the database care about channels that are outside the
> scope of the ruleset specified by the radio? For example, if the specified
> ruleset is FCC-related, then why would I need to include Ofcom-related
> channels in the response? Am I missing something?]
>

[V] In my latest proposal, frequencies mentioned, but with no power is
interpreted to be "within purview, but you should not use it". Gaps in the
frequency (unmentioned) means "out of scope". My comment simply says that
using a), you cannot distinguish between the two cases, not that we propose
to say something about the "out of scope" frequencies.

****
>
>  ****
>
> b)      List unavailable channels and specify the power limit, eg -56dbm**
> **
>
> [DJ – I’m still in favor of just using the implicit unavailability method
> described above in a). What value is there in providing a power level for
> an unavailable channel? If I’m the radio, I can’t use the channel, and I’m
> not going to intentionally transmit in that channel. This comment also
> applies to c) and d).]
>

See Paul's comment....from the perspective of a radio :)

> ****
>
>  ****
>
> c)       List unavailable channels and specify –inf as power limit****
>
> ** **
>
> "-Inf" is not really workable, because JSON does not allow Infinity or
> NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.****
>
> ** **
>
> d)      List unavailable channels and do not specify any power limit ****
>
>  ****
>
> -          Gabor****

-- 
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 25 Sep 2013 08:01:53 -0400

Lowering the power to meet the mask is the easy way you get a radio certified – thus permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parameters are acceptable within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset defines the box the device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the location, time, and type of device making the request. All with respect to the specific list of entities the database has been told to protect at that location at that time.

One final comment and then I will rest my case. I have had conversations with several Regulators about this recently, and they do not like any notion that the database is "thinking" about the answer.
In every case they have said something along the lines of "if the database does not explicitly give a device permission to use a channel the device is not allowed to use it".
In every case they have gone somewhat further stating that if the database operation goes beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe me – go ask them!
Which brings me back to my soap box. We want to get PAWS done so we can enable white space. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.
Peter S.

From: Paul Lambert <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <[email-masked]<mailto:[email-masked]>>, Vincent Chen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Spectrum encoding discussion

Gabor,

Paul

-          Gabor

---

From: Vincent Chen <[email-masked]>
Date: Wed, 25 Sep 2013 09:09:57 -0700

Thanks for sharing your insights Peter.

This is an opportunity to have the protocol be a bit more forward thinking
than what current regulators are thinking.

Let's try to focus on Gabor's question again of how to express
"unavailability", but phrasing it differently.

If we were to take the view that the Database provides responses for
frequencies where the device may operate, then

 - Any frequency ranges missing for the response means the device "is not
granted permission" to operate in those frequencies under the rules
implemented by the Database

Then is it still useful to distinguish why permission is not granted? (off
vs outside band plan)

If not, then Option a), simply having gaps in the frequency ranges would
satisfy this use case.

Is this a good compromise?

-vince

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth
<[email-masked]>wrote:

>  Lowering the power to meet the mask is the easy way you get a radio
> certified – thus permission to operate. How is that anything to do with the
> database - which is simply managing Regulator policy?
> The ruleset is going to tell you what masks and other operating parameters
> are acceptable within a regulatory domain. I can't imagine a Regulator
> allowing a database operator to manipulate the unintentional interference
> in adjacent channels. If it did why stop there? Why couldn't the database
> manipulate co-channel interference to nearby protected entities?
> I thought we had a fairly elegant and simple solution. The ruleset defines
> the box the device can operate in and the database provides a specific set
> of permitted channels/frequencies within that box based on the location,
> time, and type of device making the request. All with respect to the
> specific list of entities the database has been told to protect at that
> location at that time.
>
> One final comment and then I will rest my case. I have had conversations
> with several Regulators about this recently, and they do not like any
> notion that the database is "thinking" about the answer.
> In every case they have said something along the lines of "if the database
> does not explicitly give a device permission to use a channel the device is
> not allowed to use it".
> In every case they have gone somewhat further stating that if the database
> operation goes beyond this simple approach they think it highly unlikely
> that they will get cooperation from incumbents. If you don't believe me –
> go ask them!
> Which brings me back to my soap box. We want to get PAWS done so we can
> enable white space. In my humble opinion, the more time we spend
> pontificating and the more complex we make it we are likely to achieve the
> opposite.
> Peter S.
>
>
> From: Paul Lambert <[email-masked]>
> To: Don Joslyn <[email-masked]>, Vincent Chen <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>
> The rules have strict adjacent channel requirements.  Meeting the spectral
> mask for the adjacent channels  is one of the hardest parts for fielding
> real equipment.  If the rules allow relative measurement of the adjacent
> channel energy, you can simply lower your transmit power to the point that
> you can meet the adjacent requirements.
>
> For a general White Spaces solution – it is critical to have knowledge for
> the full spectrum mask.  The full spectrum mask includes adjacent
> non-allowed channels.
>
> RF channel usage are NOT a binary on/off or a simple transmit level.  The
> mask has a specific contour that extends beyond the "allowed" channel.
>  Transmitters will always send energy in more than the allowed channel!
>
>
>
> Paul
>
>
> ****
>
>  ****
>
> applies to c) and d).]****
>
>  ****
>

-- 
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 25 Sep 2013 14:04:56 -0400

Thanks Vince, I am not trying to grind an axe or be a luddite.  I am concerned that the battle for spectrum sharing is far from over and the more tangible progress we can make with PAWS the better prepared we are. So I am trying to be pragmatic in suggesting we try to get a PAWS standard completed quickly and one that minimizes the push back from the incumbents. This means we need to be able to get the Regulators to  be able to continue to support us.
If I understand what you are suggesting, as a US TVWS database, then my band plan would be channels 2-51 and I would return a list of 2-51 channels.  If the list of 2-51 was populated by either "off" or a "permitted use" then I have logically addressed the regulator concern. By implication anything outside of that list is outside my band plan. Therefore I have not only told you what channels you can use I have informed you why you can't use anything else (off = no permission, anything else is out of band plan).  That seems like a reasonable compromise to me.
Peter S.

From: Vincent Chen <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 25, 2013 12:09 PM
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>
Cc: Paul Lambert <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Spectrum encoding discussion

This is an opportunity to have the protocol be a bit more forward thinking than what current regulators are thinking.

Let's try to focus on Gabor's question again of how to express "unavailability", but phrasing it differently.

If we were to take the view that the Database provides responses for frequencies where the device may operate, then

 - Any frequency ranges missing for the response means the device "is not granted permission" to operate in those frequencies under the rules implemented by the Database

Then is it still useful to distinguish why permission is not granted? (off vs outside band plan)

If not, then Option a), simply having gaps in the frequency ranges would satisfy this use case.

-vince

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
 Lowering the power to meet the mask is the easy way you get a radio certified – thus permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parameters are acceptable within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset defines the box the device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the location, time, and type of device making the request. All with respect to the specific list of entities the database has been told to protect at that location at that time.

Gabor,

Paul

-          Gabor

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Wed, 25 Sep 2013 11:28:48 -0700

Peter,

Ah, I needed an example. You are articulating our preferred solution, but
we have not been able to agree on how to represent "off".

So I was actually trying to take a step back (toward your position).

Using your example
 - My band plan is channels 2-51
 - I return information about (only) channels 3, 23, 24

I've told you that you are permitted to use 3, 23, and 24. E.g., I have not
granted you permission to use any other channels whether or not they are
inside the band plan, under my set of rules.

So we have the following two options to work out first:

 1) Allow gaps in the frequency ranges to indicate "no permission granted"
as opposed to "must not use"

 2) Must list all frequencies in a bland plan and continue to work on how
to represent "off"

-vince

On Wed, Sep 25, 2013 at 11:04 AM, Peter Stanforth
<[email-masked]>wrote:

> Thanks Vince, I am not trying to grind an axe or be a luddite.  I am
> concerned that the battle for spectrum sharing is far from over and the
> more tangible progress we can make with PAWS the better prepared we are. So
> I am trying to be pragmatic in suggesting we try to get a PAWS standard
> completed quickly and one that minimizes the push back from the incumbents.
> This means we need to be able to get the Regulators to  be able to continue
> to support us.
> If I understand what you are suggesting, as a US TVWS database, then my
> band plan would be channels 2-51 and I would return a list of 2-51
> channels.  If the list of 2-51 was populated by either "off" or a
> "permitted use" then I have logically addressed the regulator concern. By
> implication anything outside of that list is outside my band plan.
> Therefore I have not only told you what channels you can use I have
> informed you why you can't use anything else (off = no permission, anything
> else is out of band plan).  That seems like a reasonable compromise to me.
> Peter S.
>
> From: Vincent Chen <[email-masked]>
> To: Peter Stanforth <[email-masked]>
> Cc: Paul Lambert <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>
> On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]
> > wrote:
>
>> The ruleset is going to tell you what masks and other operating
>> parameters are acceptable within a regulatory domain. I can't imagine a
>> Regulator allowing a database operator to manipulate the unintentional
>> interference in adjacent channels. If it did why stop there? Why couldn't
>> the database manipulate co-channel interference to nearby protected
>> entities?
>> I thought we had a fairly elegant and simple solution. The ruleset
>> defines the box the device can operate in and the database provides a
>> specific set of permitted channels/frequencies within that box based on the
>> location, time, and type of device making the request. All with respect to
>> the specific list of entities the database has been told to protect at that
>> location at that time.
>>
>> In every case they have said something along the lines of "if the
>> database does not explicitly give a device permission to use a channel the
>> device is not allowed to use it".
>> In every case they have gone somewhat further stating that if the
>> database operation goes beyond this simple approach they think it highly
>> unlikely that they will get cooperation from incumbents. If you don't
>> believe me – go ask them!
>> The rules have strict adjacent channel requirements.  Meeting the
>> spectral mask for the adjacent channels  is one of the hardest parts for
>> fielding real equipment.  If the rules allow relative measurement of the
>> adjacent channel energy, you can simply lower your transmit power to the
>> point that you can meet the adjacent requirements.
>>
>> For a general White Spaces solution – it is critical to have knowledge
>> for the full spectrum mask.  The full spectrum mask includes adjacent
>> non-allowed channels.
>>
>> b)      List unavailable channels and specify the power limit, eg -56dbm*
>> ***
>>
>> We’ll wait for more input on the list before declaring rough consensus
>> for the question above; then we’ll go back to the original question on
>> whether the encoding of spectrum profile should be option 1 or option 2.*
>> ***
>>
>>  ****
>>

-- 
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Wed, 25 Sep 2013 20:39:27 +0000

As a Database provider, I think it is VERY IMPORTANT to have the ability to state either of these unambiguously:

*         These are the handful of channels that are available until 6pm.

o   (Implicitly: if you want to know about stuff after 6pm, send another request between now and then - preferable closer to 6pm.)

*         These are the handful of channels that are available until 6pm, and I'm telling you NOW that NOTHING is available starting at 6pm for the next 18 hours.

o   (Implicitly: I've told you everything I can about all availability until Noon tomorrow; don't bother sending me another request until close to Noon tomorrow.)

This is close - but not exactly the same as Gabor's sentiment:
This has the drawback of not distinguishing between being silent about a channel that is within the database's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).
In other words, sometimes the server is "being silent" because "certain frequencies are outside the database's purview".  But another reason to "be silent" is that the database is only telling the Device about events up to a certain time.

This is the very concept I was trying to get at when I tried to formulate an example where "being silent" (Gabor's term) or "no mention" (my term - same concept) confers "no information".  In my example, I was NOT saying "the Database has no information about the future"; rather I was giving and example where the message had "no information" about use of the channel at some future time.  (I apologize if I was not clear in my point at that time.)

>From a Device's perspective - there are really THREE states that a given channel might be in:
a) I've been told I can use it,
b) I've been told it is unavailable,
c) I haven't been told either.

I think we ALL agree:
                The device CAN'T USE THE CHANNEL if it is in either case "b" or "c" above.

But the point I've been trying to make is:
                The device NEED NOT ASK AGAIN if it knows that the channel is in case "a" or "b" above.

That is why case "b" and "c" are not synonymous.  All along, that's been my objection to "no mention" being synonymous with the Database declaring that a channel is "is unavailable".

And that's why I think it is important for the Database to have a way to EXPLICTLY state a "channel unavailable".  If it is a weakness in PAWS - with impact to the Database -  if I can't express the difference between "b" and "c".

Dan Harasty

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Wednesday, September 25, 2013 12:10 PM
To: Peter Stanforth
Cc: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

-vince

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
 Lowering the power to meet the mask is the easy way you get a radio certified - thus permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parameters are acceptable within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset defines the box the device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the location, time, and type of device making the request. All with respect to the specific list of entities the database has been told to protect at that location at that time.

One final comment and then I will rest my case. I have had conversations with several Regulators about this recently, and they do not like any notion that the database is "thinking" about the answer.
In every case they have said something along the lines of "if the database does not explicitly give a device permission to use a channel the device is not allowed to use it".
In every case they have gone somewhat further stating that if the database operation goes beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe me - go ask them!
Which brings me back to my soap box. We want to get PAWS done so we can enable white space. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.
Peter S.

In line below ... speaking strongly in favor of "b"

Gabor,

For a general White Spaces solution - it is critical to have knowledge for the full spectrum mask.  The full spectrum mask includes adjacent non-allowed channels.

Paul

-          Gabor

--
-vince

---

From: Andy Lee <[email-masked]>
Date: Wed, 25 Sep 2013 13:56:45 -0700

Hi Peter,

> I can't imagine a Regulator allowing a database operator to manipulate the
> unintentional interference in adjacent channels. If it did why stop there?
> Why couldn't the database manipulate co-channel interference to nearby
> protected entities?

The recent discussions have been about data encoding and nothing more.  The
premise is that *IF* there is some information the database wants to
communicate to the white space device, *HOW* is that data encoded into the
message.

As a case in point, section 15.709(c)(1) of the rules clearly defines what
the "off" channel power limits must be.  The rules originally called for a
"relative" OOB emission limit, but after some industry discussion, the FCC
settled on these "absolute" OOB emission limits instead.  The values are
clearly defined, but its not clear whether a database would want to
communicate these parameters to the device or not.

On one hand, the database can assume that the device has these values
hard-coded into its firmware and therefore does not need to send that
information over PAWS.

On the other hand, these power levels are part of the TVWS rules and
perhaps is something that the database should communicate to the WSD.
 There are potentially beneficial things that a WSD could do with that
information if it was provided at run-time (e.g., for future-proofing the
device, or choosing operating channels more intelligently).

*PAWS does not need to address WHY a particular parameter should or should
not be sent over the protocol.*  There are many regulatory, business, or
technological reasons why these choices might change, and those decisions
are beyond the scope of the protocol itself.

However, *PAWS can and should address HOW data gets encoded IF a device or
database decides to send it.*  i.e.,

IF you want to encode [X], then you SHALL use [encoding X]
IF you want to encode [Y], then you SHALL use [encoding Y]
etc.

I can identify at least three distinct concepts that have been discussed so
far, which I would categorize as follows:

   - (i) Explicit "on", Implicit "off"
      - Anything not explicitly specified as "on" would implicitly be
      treated as "off"
      - The recipient must have apriori knowledge about how to comply with
      the "off" channel, "special" channel (e.g., channel 37), and "band-edge"
      protection ratios
      - There is no distinction between "off" channels, "special" channels,
      and "band-edge" constraints in the message itself
      - This requires a way to encode gaps or discontinuities in the
      spectrum profile
      - This is equivalent to Gabor's option (a)

   - (ii) Explicit "on", Explicit "off" with no power level given
      - Every channel would be either explicitly "on" or explicitly "off"
      - Any frequency blocks that are not explicitly "on" or explicitly
      "off" are considered to be "out-of-scope" for the current database or
      ruleset, and this implicitly gives the "band-edge" boundaries
      - The recipient must have apriori knowledge about how to comply with
      the "off" channel, "special" channel, and "band-edge" protection ratios
      - The recipient can infer from the message when to apply "off"
      channel constraints and when to apply "band-edge" constraints
      - This requires a way to encode gaps or discontinuities in the
      spectrum profile AND requires a way to encode explicit "off"
channels with
      no specified power value
      - This is equivalent to Gabor's options (c) and (d)

   - (iii) Explicit "on", Explicit "off" with power level given
      - Every channel would be either explicitly "on" or explicitly "off"
      - Any frequency blocks that are not explicitly "on" or explicitly
      "off" are considered to be "out-of-scope" for the current database or
      ruleset, and this implicitly gives the "band-edge" boundaries
      - The "off" channel, "special" channel, and "band-edge" protection
      ratios are explicitly provided in the message, and a device has
the option
      of either using that information or ignoring it (default back to apriori
      knowledge of the protection ratios)
      - This requires a way to encode gaps or discontinuities in the
      spectrum profile
      - This is equivalent to Gabor's option (b)

I think all three types of encoding have their uses, and PAWS should
probably allow all three possibilities.

It looks like all three encoding types need a way to express gaps or
discontinuities in the spectrum profile.  I think the latest proposal from
Vince, using a list of lists, addresses this problem nicely.

It also looks like encodings for (i) and (iii) are logically equivalent,
with the only real difference being that encoding (iii) includes more data
points in the spectrum profile than encoding (i).  I don't think anything
else needs to be added to the spec to support both of these encodings.

That leaves us with encoding (ii), where we need to add something new to
the spec to encode explicitly "off" frequency blocks that have no power
level given.  For this, we have two proposals:

Option (c): Use -inf as the power value in a spectrum profile element
Option (d): Leave the power value blank in a spectrum profile element

I'd suggest maybe considering yet another proposal:

Option (e): Use normal encoding (i) for explicit "on" channels, and then
have a separate list of frequency start/stop pairs indicating the
authoritative bands for which the database operates.  Anything that is
inside the authoritative bands but not in an explicitly "on" chunk is
effectively saying it's explicitly "off".  Anything outside of the list of
authoritative bands is considered "out-of-scope" for the database and this
essentially lists the "band-edge" boundaries.

Best regards,

---

From: Andy Lee <[email-masked]>
Date: Wed, 25 Sep 2013 14:23:49 -0700

Hi Dan,

 **These are the handful of channels that are available until 6pm.
> ****o   **(Implicitly: if you want to know about stuff after 6pm, send
> another request between now and then – preferable closer to 6pm.)
> ****·         **These are the handful of channels that are available
> until 6pm, and I’m telling you NOW that NOTHING is available starting at
> 6pm for the next 18 hours.
> ****o   **(Implicitly: I’ve told you everything I can about all
> availability until Noon tomorrow; don’t bother sending me another request
> until close to Noon tomorrow.)

Thanks for the nice example.

This sounds like a new concept to me.  To me it's suggesting a distinction
of a channel "on-to-off" transition as being either "hard" (off permanently
as far as the database is aware) or "soft" (ask me again later and the
channel might come back "on").  Do you have any suggestions on how to
encode that?

*From a Device’s perspective* – there are really THREE states that a given
> channel might be in:
> ****a) I’ve been told I can use it,
> b) I’ve been told it is unavailable,
> c) I haven’t been told either.

I agree.

I'm not sure this does anything to address the "temporal stickiness" of the
channel on/off information you had in your example.

Best regards,

On Wed, Sep 25, 2013 at 1:39 PM, Harasty, Daniel J
<[email-masked]>wrote:

> As a Database provider, I think it is VERY IMPORTANT to have the ability
> to state either of these unambiguously:****
>
> **·         **These are the handful of channels that are available until
> 6pm.****
>
> **o   **(Implicitly: if you want to know about stuff after 6pm, send
> another request between now and then – preferable closer to 6pm.)****
>
> **·         **These are the handful of channels that are available until
> 6pm, and I’m telling you NOW that NOTHING is available starting at 6pm for
> the next 18 hours.****
>
> **o   **(Implicitly: I’ve told you everything I can about all
> availability until Noon tomorrow; don’t bother sending me another request
> until close to Noon tomorrow.)****
>
> ** **
>
> This is close – but not exactly the same as Gabor’s sentiment:****
>
> In other words, sometimes the server is “being silent” because “certain
> frequencies are outside the database’s purview”.  But another reason to “be
> silent” is that the database is only telling the Device about events up to
> a certain time.****
>
> ** **
>
> This is the very concept I was trying to get at when I tried to formulate
> an example where “being silent” (Gabor’s term) or “no mention” (my term –
> same concept) confers “no information”.  In my example, I was NOT saying
> “the Database has no information about the future”; rather I was giving and
> example where the *message* had “no information” about use of the channel
> at some future time.  (I apologize if I was not clear in my point at that
> time.)****
>
> ** **
>
> *From a Device’s perspective* – there are really THREE states that a
> given channel might be in: ****
>
> a) I’ve been told I can use it, ****
>
> b) I’ve been told it is unavailable, ****
>
> c) I haven’t been told either.****
>
> ** **
>
> I think we ALL agree:****
>
>                 The device CAN’T USE THE CHANNEL if it is in either case
> “b” or “c” above.****
>
> ** **
>
> But the point I’ve been trying to make is:****
>
>                 The device NEED NOT ASK AGAIN if it knows that the channel
> is in case “a” or “b” above.****
>
> ** **
>
> That is why case “b” and “c” are *not synonymous*.  All along, that’s
> been my objection to “no mention” being synonymous with the Database
> declaring that a channel is “is unavailable”.  ****
>
> ** **
>
> And that’s why I think it is important for the Database to have a way to
> EXPLICTLY state a “channel unavailable”.  If it is a weakness in PAWS –
> with impact to the Database –  if I can’t express the difference between
> “b” and “c”.****
>
> ** **
>
> ** **
>
> Dan Harasty****
>
> ** **
>
> ** **
>
> ** **
>
> Of *Vincent Chen
> *Sent:* Wednesday, September 25, 2013 12:10 PM
> *To:* Peter Stanforth
> *Cc:* [email-masked]
>
> Thanks for sharing your insights Peter.****
>
> ** **
>
> than what current regulators are thinking.****
>
> ** **
>
> "unavailability", but phrasing it differently.****
>
> ** **
>
> frequencies where the device may operate, then****
>
> ** **
>
> implemented by the Database****
>
> ** **
>
> vs outside band plan)****
>
> ** **
>
> satisfy this use case.****
>
> ** **
>
> Is this a good compromise?****
>
> ** **
>
> -vince****
>
> ** **
>
> On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]>
> wrote:****
>
> database - which is simply managing Regulator policy?****
>
> manipulate co-channel interference to nearby protected entities?****
>
> location at that time.****
>
> ** **
>
> notion that the database is "thinking" about the answer.****
>
> not allowed to use it".****
>
> go ask them!****
> opposite.****
> Peter S.****
> *From: *Paul Lambert <[email-masked]>
> *Date: *Tuesday, September 24, 2013 2:48 PM
> *To: *Don Joslyn <[email-masked]>, Vincent Chen <
> [email-masked]" <[email-masked]>****
>
>
> In line below … speaking strongly in favor of "b" ****
>
> ** **
>
> ** **
>
> Gabor,****
>
>  ****
>
> channels in the response? Am I missing something?]****
>
> ** **
>
> you can meet the adjacent requirements.  ****
>
> ** **
>
> non-allowed channels.****
>
> ** **
>
>  Transmitters will always send energy in more than the allowed channel!***
> *
>
> ** **
>
> ** **
>
> ** **
>
> Paul****
>
> ** **
>
> ** **
>
>  ****
>
> -vince ****

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 22:56:29 +0000

Andy,

This option (e) proposal sounds like you may want to encode two things which could be separated; the available channels, and the authoritative bands.
We could leave the available spectrum req/resp unchanged, and eg have a separate req/resp for the authoritative bands.
And we could also encode the power leakage limits eg inside the ruleset info, so that devices would not necessarily need to be hard-coded with those, to satisfy everyone.
Could this be an agreeable way forward?

-          Gabor

From: ext Andy Lee [mailto:[email-masked]]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

Hi Peter,

I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?

The recent discussions have been about data encoding and nothing more.  The premise is that IF there is some information the database wants to communicate to the white space device, HOW is that data encoded into the message.

As a case in point, section 15.709(c)(1) of the rules clearly defines what the "off" channel power limits must be.  The rules originally called for a "relative" OOB emission limit, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead.  The values are clearly defined, but its not clear whether a database would want to communicate these parameters to the device or not.

On one hand, the database can assume that the device has these values hard-coded into its firmware and therefore does not need to send that information over PAWS.

On the other hand, these power levels are part of the TVWS rules and perhaps is something that the database should communicate to the WSD.  There are potentially beneficial things that a WSD could do with that information if it was provided at run-time (e.g., for future-proofing the device, or choosing operating channels more intelligently).

PAWS does not need to address WHY a particular parameter should or should not be sent over the protocol.  There are many regulatory, business, or technological reasons why these choices might change, and those decisions are beyond the scope of the protocol itself.

However, PAWS can and should address HOW data gets encoded IF a device or database decides to send it.  i.e.,

I can identify at least three distinct concepts that have been discussed so far, which I would categorize as follows:

  *   (i) Explicit "on", Implicit "off"

     *   Anything not explicitly specified as "on" would implicitly be treated as "off"
     *   The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel (e.g., channel 37), and "band-edge" protection ratios
     *   There is no distinction between "off" channels, "special" channels, and "band-edge" constraints in the message itself
     *   This requires a way to encode gaps or discontinuities in the spectrum profile
     *   This is equivalent to Gabor's option (a)

  *   (ii) Explicit "on", Explicit "off" with no power level given

     *   Every channel would be either explicitly "on" or explicitly "off"
     *   Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries
     *   The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel, and "band-edge" protection ratios
     *   The recipient can infer from the message when to apply "off" channel constraints and when to apply "band-edge" constraints
     *   This requires a way to encode gaps or discontinuities in the spectrum profile AND requires a way to encode explicit "off" channels with no specified power value
     *   This is equivalent to Gabor's options (c) and (d)

  *   (iii) Explicit "on", Explicit "off" with power level given

     *   Every channel would be either explicitly "on" or explicitly "off"
     *   Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries
     *   The "off" channel, "special" channel, and "band-edge" protection ratios are explicitly provided in the message, and a device has the option of either using that information or ignoring it (default back to apriori knowledge of the protection ratios)
     *   This requires a way to encode gaps or discontinuities in the spectrum profile
     *   This is equivalent to Gabor's option (b)

I think all three types of encoding have their uses, and PAWS should probably allow all three possibilities.

It looks like all three encoding types need a way to express gaps or discontinuities in the spectrum profile.  I think the latest proposal from Vince, using a list of lists, addresses this problem nicely.

It also looks like encodings for (i) and (iii) are logically equivalent, with the only real difference being that encoding (iii) includes more data points in the spectrum profile than encoding (i).  I don't think anything else needs to be added to the spec to support both of these encodings.

That leaves us with encoding (ii), where we need to add something new to the spec to encode explicitly "off" frequency blocks that have no power level given.  For this, we have two proposals:

Option (e): Use normal encoding (i) for explicit "on" channels, and then have a separate list of frequency start/stop pairs indicating the authoritative bands for which the database operates.  Anything that is inside the authoritative bands but not in an explicitly "on" chunk is effectively saying it's explicitly "off".  Anything outside of the list of authoritative bands is considered "out-of-scope" for the database and this essentially lists the "band-edge" boundaries.

Best regards,

Andy Lee |

 Google Inc. |

 408-230-0522

Gabor,

Paul

-          Gabor

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 25 Sep 2013 19:53:29 -0400

Dan,
 I understand your desire to be more specific about why, and when spectrum may be available but I am struggling to understand why we can't do that today, and maybe that is why I missed the subtlety in your original post.
We have a, per channel, start and stop time in spectrum availability  (Sections 5.10 and 5.11) and my understanding is that this would allow you to say a channel is available from now until 6pm, or conversely it is not available until 6pm.  Is this what you are trying to accomplish in your example below?

Part of your concern seems to be that if we use "off" that this may offer a qualification like, you are not permitted to use it ever, you are just not allowed to use it now, it is out of my domain.
That may be good information to convey but are all of these examples still relevant  within the context of start and stop time – assuming I got it right?

As a side I have been wondering how relevant future  is when Ofcom is proposing spectrum "leases" be for 15 minutes and the waiver just granted by the FCC for a low power fixed device to use adjacent channels requires leases of no more than 30 minutes.

From: <Harasty>, Daniel J <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 25, 2013 4:39 PM
To: Vincent Chen <[email-masked]<mailto:[email-masked]>>, Peter Stanforth <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] Spectrum encoding discussion

·         These are the handful of channels that are available until 6pm.

o   (Implicitly: if you want to know about stuff after 6pm, send another request between now and then – preferable closer to 6pm.)

·         These are the handful of channels that are available until 6pm, and I’m telling you NOW that NOTHING is available starting at 6pm for the next 18 hours.

o   (Implicitly: I’ve told you everything I can about all availability until Noon tomorrow; don’t bother sending me another request until close to Noon tomorrow.)

This is close – but not exactly the same as Gabor’s sentiment:
This has the drawback of not distinguishing between being silent about a channel that is within the database's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).
In other words, sometimes the server is “being silent” because “certain frequencies are outside the database’s purview”.  But another reason to “be silent” is that the database is only telling the Device about events up to a certain time.

This is the very concept I was trying to get at when I tried to formulate an example where “being silent” (Gabor’s term) or “no mention” (my term – same concept) confers “no information”.  In my example, I was NOT saying “the Database has no information about the future”; rather I was giving and example where the message had “no information” about use of the channel at some future time.  (I apologize if I was not clear in my point at that time.)

>From a Device’s perspective – there are really THREE states that a given channel might be in:
a) I’ve been told I can use it,
b) I’ve been told it is unavailable,
c) I haven’t been told either.

I think we ALL agree:
                The device CAN’T USE THE CHANNEL if it is in either case “b” or “c” above.

But the point I’ve been trying to make is:
                The device NEED NOT ASK AGAIN if it knows that the channel is in case “a” or “b” above.

That is why case “b” and “c” are not synonymous.  All along, that’s been my objection to “no mention” being synonymous with the Database declaring that a channel is “is unavailable”.

And that’s why I think it is important for the Database to have a way to EXPLICTLY state a “channel unavailable”.  If it is a weakness in PAWS – with impact to the Database –  if I can’t express the difference between “b” and “c”.

Dan Harasty

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Wednesday, September 25, 2013 12:10 PM
To: Peter Stanforth
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum encoding discussion

-vince

Gabor,

Paul

-          Gabor

--
-vince

---

From: Andy Lee <[email-masked]>
Date: Wed, 25 Sep 2013 18:08:49 -0700

Hi Gabor,

Thanks for the suggestion.

Just to be clear, the encoding of information about the "off" channels is *
OPTIONAL*.  The current FCC rules give specific values for what should
happen on the "special" channel 37 as well as "off" channels in the TV
band, but the rules do not require the databases to send those details to
the device as part of the spectrum query.  If one assumes that a WSD has
implicit knowledge of these "off" channel rules, then there's no need for a
database to send this information.

*IF* the database decides to include this information in its message, then
I think it makes the most sense to include the information directly in the
spectrum profile itself.  Many of these special rules for channel 37 or
band edges are unique to the frequencies where they apply.  It seems like a
very natural fit to simply encode the data with the spectrum profile in the
frequency context where they belong.

I think it would be difficult to encode these things with the ruleset part
of the message because there can be different behaviors unique to each
frequency or band edge.  I can't think of a good way to generically encode
this with the ruleset.

Best regards,

On Wed, Sep 25, 2013 at 3:56 PM, <[email-masked]> wrote:

>  Andy,****
>
> ** **
>
> This option (e) proposal sounds like you may want to encode two things
> which could be separated; the available channels, and the authoritative
> bands.****
>
> We could leave the available spectrum req/resp unchanged, and eg have a
> separate req/resp for the authoritative bands. ****
>
> And we could also encode the power leakage limits eg inside the ruleset
> info, so that devices would not necessarily need to be hard-coded with
> those, to satisfy everyone.****
>
> Could this be an agreeable way forward?****
>
> ** **
>
> **-          **Gabor****
>
> ** **
>
> *From:* ext Andy Lee [mailto:[email-masked]]
> *Sent:* Wednesday, September 25, 2013 1:57 PM
> *To:* Peter Stanforth
> *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley);
> [email-masked]
>
> Hi Peter,****
> protected entities?****
> The recent discussions have been about data encoding and nothing more.
>  The premise is that *IF* there is some information the database wants to
> communicate to the white space device, *HOW* is that data encoded into
> the message.****
>
> ** **
>
> communicate these parameters to the device or not.****
>
> ** **
>
> information over PAWS.****
>
> ** **
>
> device, or choosing operating channels more intelligently).****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *PAWS does not need to address WHY a particular parameter should or
> should not be sent over the protocol.*  There are many regulatory,
> business, or technological reasons why these choices might change, and
> those decisions are beyond the scope of the protocol itself.****
>
> ** **
>
> However, *PAWS can and should address HOW data gets encoded IF a device
> or database decides to send it.*  i.e.,****
>
> ** **
>
> IF you want to encode [X], then you SHALL use [encoding X]****
>
> IF you want to encode [Y], then you SHALL use [encoding Y]****
>
> etc.****
>
> ** **
>
> I can identify at least three distinct concepts that have been discussed
> so far, which I would categorize as follows:****
>
>    - (i) Explicit "on", Implicit "off"****
>
>
>       treated as "off"****
>       - The recipient must have apriori knowledge about how to comply
>       with the "off" channel, "special" channel (e.g., channel 37), and
>       "band-edge" protection ratios****
>       - There is no distinction between "off" channels, "special"
>       channels, and "band-edge" constraints in the message itself****
>       spectrum profile****
>       - This is equivalent to Gabor's option (a)****
>
>  ** **
>
>    - (ii) Explicit "on", Explicit "off" with no power level given****
>
>
>     - Every channel would be either explicitly "on" or explicitly "off"***
>       *
>       ruleset, and this implicitly gives the "band-edge" boundaries****
>       - The recipient must have apriori knowledge about how to comply
>       with the "off" channel, "special" channel, and "band-edge" protection ratios
>       ****
>       channel constraints and when to apply "band-edge" constraints****
>       spectrum profile AND requires a way to encode explicit "off" channels with
>       no specified power value****
>       - This is equivalent to Gabor's options (c) and (d)****
>
>  ** **
>
>    - (iii) Explicit "on", Explicit "off" with power level given****
>
>
>     - Every channel would be either explicitly "on" or explicitly "off"***
>       *
>       ruleset, and this implicitly gives the "band-edge" boundaries****
>       ratios are explicitly provided in the message, and a device has the option
>       knowledge of the protection ratios)****
>       spectrum profile****
>       - This is equivalent to Gabor's option (b)****
>
>  ** **
>
> ** **
>
> probably allow all three possibilities.****
>
> ** **
>
> Vince, using a list of lists, addresses this problem nicely.****
>
> ** **
>
> else needs to be added to the spec to support both of these encodings.****
>
> ** **
>
> ** **
>
> ** **
>
> level given.  For this, we have two proposals:****
>
> ** **
>
> Option (c): Use -inf as the power value in a spectrum profile element****
>
> Option (d): Leave the power value blank in a spectrum profile element****
>
> ** **
>
> I'd suggest maybe considering yet another proposal:****
>
> ** **
>
> essentially lists the "band-edge" boundaries.****
>
> ** **
>
> ** **
>
> ** **
>
> Best regards,****
>
>
> ****
>
> ** **
>
> Andy Lee |****
>
>  Google Inc. |****
>
>  [email-masked] |****
>
>  408-230-0522****
>
> ** **
>
>  Since the protocol should stand on its own, independent of any
> particular regulatory rule, do we really want to rule this out? In our
> interpretations of the FCC rules, for example, a Database is not prevented
> from doing this.****
>
>  ****
>

---

From: "Stine, John A." <[email-masked]>
Date: Thu, 26 Sep 2013 10:14:51 +0000

For what it is worth I have been working on methods to model spectrum use that can be used to give guidance to radios. (We have just started to standardize these methods in IEEE 1900.5.2.)  We have two different kinds of guidance, permissive and restrictive.  They are sent in separate lists.  The permissive (aka authorization) list identifies channels a device or system can operate and if combined with a restrictive (aka constraint) list then so long as the user does not violate a listed restriction.  Each of these lists use spectrum and time at two levels.  The top level indicates the band and time period the list is comprehensive.  The second level indicates the particular channels and time periods of availability or restriction.  I would imagine that TVWS would only need the authorization list.  Future applications where spectrum owners add spectrum to the database and coexistence is managed will require both.

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, September 25, 2013 6:56 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

Andy,

-          Gabor

From: ext Andy Lee [mailto:[email-masked]]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum encoding discussion

Hi Peter,

I can identify at least three distinct concepts that have been discussed so far, which I would categorize as follows:
*         (i) Explicit "on", Implicit "off"
o    Anything not explicitly specified as "on" would implicitly be treated as "off"
o    The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel (e.g., channel 37), and "band-edge" protection ratios
o    There is no distinction between "off" channels, "special" channels, and "band-edge" constraints in the message itself
o    This requires a way to encode gaps or discontinuities in the spectrum profile
o    This is equivalent to Gabor's option (a)

*         (ii) Explicit "on", Explicit "off" with no power level given
o    Every channel would be either explicitly "on" or explicitly "off"
o    Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries
o    The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel, and "band-edge" protection ratios
o    The recipient can infer from the message when to apply "off" channel constraints and when to apply "band-edge" constraints
o    This requires a way to encode gaps or discontinuities in the spectrum profile AND requires a way to encode explicit "off" channels with no specified power value
o    This is equivalent to Gabor's options (c) and (d)

*         (iii) Explicit "on", Explicit "off" with power level given
o    Every channel would be either explicitly "on" or explicitly "off"
o    Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries
o    The "off" channel, "special" channel, and "band-edge" protection ratios are explicitly provided in the message, and a device has the option of either using that information or ignoring it (default back to apriori knowledge of the protection ratios)
o    This requires a way to encode gaps or discontinuities in the spectrum profile
o    This is equivalent to Gabor's option (b)

Best regards,

Andy Lee |

 Google Inc. |

 408-230-0522

Gabor,

Paul

-          Gabor

---

From: Vincent Chen <[email-masked]>
Date: Thu, 26 Sep 2013 17:36:08 -0700

John,

Thanks for your input. It aligns nicely with Andy's suggestion of
specifying "authoritative bands" separately. Taking your suggestion of also
expressing "authoritative time range", we could have an encoding example
like the following:

{
  "rulesetInfo": { ... },
  "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ],
  "frequencyRanges": [
    [5.4e7, 7.2e7],   // channels 2-4
    [7.6e7, 8.8e7],   // channels 5-6
    [1.74e8, 2.16e8], // channels 7-13
    [4.70e8, 6.98e8], // channels 14-51
  ],
  "spectrumSchedules": [
    {
      "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ],
      "spectra" [
       {
         "psdBandwidthHz": 6e6,
         [
          { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14
          { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 },
          { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23
          { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
         ]
       },
       {
         "psdBandwidthHz": 1e5,
         [
          { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 },  // channel 14
          { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 },
          { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },  // channel 22
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },  // channel 23
          { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
         ]
       }
      ]
    },
    {
      "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ],
      ...
    },
    ...
  ],
  ...
}

Features

   - Explicit indication of authoritative time ranges and frequency ranges
   associated with the response
   - Within a spectrum list, missing frequencies now can be interpreted
   unambiguously as unavailable without magic values
   - If there are gaps in time intervals, it also may be interpreted
   unambiguously as no available frequencies
   - Still allows the protocol to express of full mask where allowed

Thoughts?

-vince

On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A. <[email-masked]> wrote:

>  For what it is worth I have been working on methods to model spectrum
> use that can be used to give guidance to radios. (We have just started to
> standardize these methods in IEEE 1900.5.2.)  We have two different kinds
> of guidance, permissive and restrictive.  They are sent in separate lists.
> The permissive (aka authorization) list identifies channels a device or
> system can operate and if combined with a restrictive (aka constraint) list
> then so long as the user does not violate a listed restriction.  Each of
> these lists use spectrum and time at two levels.  The top level indicates
> the band and time period the list is comprehensive.  The second level
> indicates the particular channels and time periods of availability or
> restriction.  I would imagine that TVWS would only need the authorization
> list.  Future applications where spectrum owners add spectrum to the
> database and coexistence is managed will require both.****
>
> ** **
>
> John****
>
> ** **
>
> Of [email-masked]
> *Sent:* Wednesday, September 25, 2013 6:56 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
>
> *From:* ext Andy Lee [mailto:[email-masked] <[email-masked]>]
> **·         **(i) Explicit "on", Implicit "off"****
>
> **o    **Anything not explicitly specified as "on" would implicitly be
> treated as "off"****
>
> **o    **The recipient must have apriori knowledge about how to comply
> **o    **There is no distinction between "off" channels, "special"
> **o    **This requires a way to encode gaps or discontinuities in the
> spectrum profile****
>
> **o    **This is equivalent to Gabor's option (a)****
>
> ** **
>
> **·         **(ii) Explicit "on", Explicit "off" with no power level given
> ****
>
> **o    **Every channel would be either explicitly "on" or explicitly "off"
> ****
>
> **o    **Any frequency blocks that are not explicitly "on" or explicitly
> **o    **The recipient must have apriori knowledge about how to comply
> **o    **The recipient can infer from the message when to apply "off"
> **o    **This requires a way to encode gaps or discontinuities in the
> **o    **This is equivalent to Gabor's options (c) and (d)****
>
> ** **
>
> **·         **(iii) Explicit "on", Explicit "off" with power level given**
> **
>
> **o    **Every channel would be either explicitly "on" or explicitly "off"
> ****
>
> **o    **Any frequency blocks that are not explicitly "on" or explicitly
> **o    **The "off" channel, "special" channel, and "band-edge" protection
> **o    **This requires a way to encode gaps or discontinuities in the
> spectrum profile****
>
> **o    **This is equivalent to Gabor's option (b)****
>
> ** **
>
> ** **
>

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 26 Sep 2013 20:29:26 -0700

Let me try that example again....missing a nested list segments.

Features

Example:

{
  "rulesetInfo": { ... },
         "segments": [
            { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }
         "segments": [
            { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }

On Thu, Sep 26, 2013 at 5:36 PM, Vincent Chen <[email-masked]> wrote:

>    - Explicit indication of authoritative time ranges and frequency
>    ranges associated with the response
>> I can't imagine a Regulator allowing a database operator to manipulate
>> the unintentional interference in adjacent channels. If it did why stop
>> there? Why couldn't the database manipulate co-channel interference to
>> nearby protected entities?****
>>
>>  ** **
>>
>>  The premise is that *IF* there is some information the database wants
>> to communicate to the white space device, *HOW* is that data encoded
>> into the message.****
>>
>> ** **
>>
>> As a case in point, section 15.709(c)(1) of the rules clearly defines
>> what the "off" channel power limits must be.  The rules originally called
>> for a "relative" OOB emission limit, but after some industry discussion,
>> the FCC settled on these "absolute" OOB emission limits instead.  The
>> values are clearly defined, but its not clear whether a database would want
>> to communicate these parameters to the device or not.****
>>
>> ** **
>>
>> **·         **(ii) Explicit "on", Explicit "off" with no power level
>> given****
>>
>> **o    **Every channel would be either explicitly "on" or explicitly
>> "off"****
>>
>> **·         **(iii) Explicit "on", Explicit "off" with power level given*
>> ***
>>
>> **o    **Every channel would be either explicitly "on" or explicitly
>> "off"****
>>
>> **o    **The "off" channel, "special" channel, and "band-edge"
>> protection ratios are explicitly provided in the message, and a device has
>> the option of either using that information or ignoring it (default back to
>> apriori knowledge of the protection ratios)****
>>
>> On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <
>> [email-masked]> wrote:****
>>
>> entities?****
>> device is not allowed to use it".****
>>
>> believe me – go ask them!****
>>
>> point that you can meet the adjacent requirements.  ****
>>
>> ** **
>>
>>  Transmitters will always send energy in more than the allowed channel!**
>> **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> Paul****
>>
>> ** **
>>
>> ** **
>>
>>      ****
>>

-- 
-vince