Subject: Re: [paws] Proposed text: Spectrum encoding

From: <[email-masked]>
Date: Sun, 1 Dec 2013 17:39:53 +0000

We have not received much feedback on Vince's proposal for spectrum encoding, except changing some of the terminologies, which is up to the editor to decide.

This lack of feedback may mean folks are ok with the proposed text, but it may also mean that people simply got tired of the impasse and eagerly seek progress and be willing to settle on any encoding. Since I believe the proposed text reflects the agreement from the f2f, and because of lack of additional feedback, I'd ask the editor to implement these changes into a new version of the draft. Once the draft is made available, we'll have a wg last call, where people get another chance to send to the list the problems they see with the draft.

- Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Friday, November 15, 2013 2:52 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] Proposed text: Spectrum encoding

Folks,

During last week's f2f, it was agreement in the room to add encoding for the slopes, with the conditions Vince listed below.
Based on the comments received during the f2f, Vince came up with text and encoding proposal.
Please read through the proposal below and let the list know if you agree with it, or you would like some other wording/encoding. We need to make progress on the document, so your timely answer is appreciated.
If there won't be any objection to the proposal below, the text will be incorporated into the new version of the document.

-Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Vincent Chen
Sent: Wednesday, November 06, 2013 6:20 PM
To: [email-masked]
Subject: [paws] Proposed text: Spectrum encoding

All,

At the F2F, it was agreed that allowing slopes to be encoded in the
available-spectrum response is acceptable if:
 - It is not required
 - It is used to represent the "availability mask" and NOT any "transmission masks"

There was some concern about the point-wise representation.

It turns out that the IEEE 1900.5 working group for "Dynamic Spectrum
Access Network" has also been working on data models, and their data
models does use (frequency, power) point-wise representation for
spectrum masks.

So, in the interest of remaining aligned, I'm including proposed text that
uses the point-wise representation.

It is a rather long excerpt, but hopefully it provides a complete picture.

-- 
-vince 

----------------------------

5.11.  Spectrum

   Available spectrum can be characterized by an ordered list of
   spectrum profiles that defines permissible power levels over a set of
   frequency ranges.  Each Spectrum element defines permissible power
   levels as maximum power spectral densities over a specified
   resolution bandwidth, "psdBandwidthHz".  Note that the spectrum
   profiles represent the "availability mask", as defined by the
   governing rule set; they are not intended to encode device-level
   transmission-mask requirements.

   o  To support regulatory rules that define different "wide-band" and
      "narrow-band" power levels, PAWS allows multiple Spectrum elements
      to be included in the available-spectrum response, each with a
      different resolution bandwidth.
   o  When multiple Spectrum elements are included in the response, they
      represent a logical AND condition, such that the Device MUST
      satisfy all the conditions.
   o  Each Spectrum element MUST cover the range of frequencies governed
      by a ruleset, rather than splitting the frequencies across
      multiple Spectrum elements for the same resolution bandwidth.
   o  Each spectrum profile represents the maximum permissible power
      spectral density over a contiguous range of frequencies.
   o  When multiple spectrum profiles are included, they MUST be
      disjoint and SHOULD be ordered in non-decreasing frequency value.
   o  Gaps in frequencies between consecutive spectrum profiles
      represent unavailability for those frequencies.

   The following figure illustrates the Spectrum element and the
   SpectrumProfile list.

   +-------------------------------+
   |Spectrum                       |
   +---------------------+---------+
   |psdBandwidthHz:float |required |
   |profiles:list        |required |---+
   +---------------------+---------+   |  0..*
                                       V
                 +-----------------------------+
                 |SpectrumProfile              |
                 +-------------------+---------+
                 |points:list        |required |
                 +-------------------+---------+
                                       |
                                       V 2..*
                 +------------------------------+
                 |freqHz:float        |required |
                 |powerDbmPerBw:float |required |
                 +--------------------+---------+

   Parameters:

   psdBandwidthHz:  This parameter is REQUIRED to define the resolution
      bandwidth (in Hertz) over which permissible power spectral density
      is defined.  For example, FCC regulation would require one
      spectrum specification at a bandwidth of 6MHz, and ETSI regulation
      would require two specifications, at 0.1MHz and 8MHz.  This
      parameter MAY be empty if there is no available spectrum.
   profiles:   A SpectrumProfile (Section 5.12) list is REQUIRED to
      specify permissible power levels over a set of frequency ranges.
      The list MAY be empty if there is no available spectrum.

   Consider the following example with different permitted power
   spectral densities for the same set of frequencies over different
   resolution bandwidths (for illustrative purposes only):

   [
     "spectrum": {
       "psdBandwidthHz": 6e6,
       "profiles": [
         [
           {"freqHz": 5.18e8, "powerDbmPerBw": 30.0},
           {"freqHz": 5.24e8, "powerDbmPerBw": 30.0},
         ],
         ...
       ]
     },
     "spectrum": {
       "psdBandwidthHz": 1e5,
       "profiles": [
         [
           {"freqHz": 5.18e8, "powerDbmPerBw": 27.0},
           {"freqHz": 5.24e8, "powerDbmPerBw": 27.0},
         ],
         ...
       ]
     }
   ]

   This is interpreted as:

   o  Over any 6MHz within the frequency range, [518MHz, 524MHz),
      maximum permitted power is 30.0dBm (1000mW), and
   o  Over any 100 kHz within the frequency range, [518MHz, 524MHz),
      maximum permitted power is 27.0dBm (500mW)

   This would allow, for example, operating two 100kHz sub-channels
   within the indicated 6MHz range at 500mW each, totaling 1000mW.  Of
   course, many combinations are possible, as long as they satisfy both
   conditions.

   The following example illustrates multiple spectrum profiles that has
   a gap from 530 MHz to 536 MHz:

   [
     "spectrum": {
       "psdBandwidthHz": 6e6,
       "profiles": [
         [
           {"freqHz": 5.18e8, "powerDbmPerBw": 30.0},
           {"freqHz": 5.24e8, "powerDbmPerBw": 30.0},
           {"freqHz": 5.24e8, "powerDbmPerBw": 36.0},
           {"freqHz": 5.30e8, "powerDbmPerBw": 36.0},
         ],
         [
           {"freqHz": 5.36e8, "powerDbmPerBw": 30.0},
           {"freqHz": 5.42e8, "powerDbmPerBw": 30.0},
         ],
         ...
       ]
     },
     "spectrum": {
       "psdBandwidthHz": 1e5,
       "profiles": [
         [
           {"freqHz": 5.18e8, "powerDbmPerBw": 27.0},
           {"freqHz": 5.24e8, "powerDbmPerBw": 27.0},
           {"freqHz": 5.24e8, "powerDbmPerBw": 30.0},
           {"freqHz": 5.30e8, "powerDbmPerBw": 30.0},
         ],
         [
           {"freqHz": 5.36e8, "powerDbmPerBw": 27.0},
           {"freqHz": 5.42e8, "powerDbmPerBw": 27.0},
         ],
         ...
       ]
     }
   ]

5.12.  SpectrumProfile

   A spectrum profile is characterized by an ordered list of (frequency,
   power) points that represents the shape of maximum permissible power
   levels over a range of frequencies.

   o  It MUST contain a minimum of two entries.
   o  The entries in the list MUST be ordered in non-decreasing
      frequency values.
   o  Two consecutive points MAY have the same frequency value to
      represent a "step function".
   o  Three or more points MAY NOT share the same frequency value.
   o  The first frequency is inclusive; the last frequency is exclusive.

   The following figure defines the SpectrumProfile element.

   +-------------------------------+
   |SpectrumProfile                |
   +---------------------+---------+
   |points:list          |required |---+
   +---------------------+---------+   |  2..*
                                       V
                 +------------------------------+
                 |freqHz:float        |required |
                 |powerDbmPerBw:float |required |
                 +--------------------+---------+

   Parameters of each point in the profile:

   freqHz:  The frequency, in Hertz, at which the power level is
      defined.
   powerDbmPerBw:   The power level, express as dBm per resolution
      bandwidth, as defined by the "psdBandwidthHz" element of the
      enclosing Spectrum (Section 5.11) element.

---

From: Vincent Chen <[email-masked]>
Date: Mon, 2 Dec 2013 15:15:53 -0800

Thanks Gabor,

I uploaded a new draft:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

I believe this reflects the agreement from the F2F and on the list.

Diffs:
https://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-06&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-07

-vince

On Sun, Dec 1, 2013 at 9:39 AM, <[email-masked]> wrote:

> We have not received much feedback on Vince's proposal for spectrum
> encoding, except changing some of the terminologies, which is up to the
> editor to decide.
>
> This lack of feedback may mean folks are ok with the proposed text, but it
> may also mean that people simply got tired of the impasse and eagerly seek
> progress and be willing to settle on any encoding. Since I believe the
> proposed text reflects the agreement from the f2f, and because of lack of
> additional feedback, I'd ask the editor to implement these changes into a
> new version of the draft. Once the draft is made available, we'll have a wg
> last call, where people get another chance to send to the list the problems
> they see with the draft.
>
> - Gabor
>
>
>
>
> During last week's f2f, it was agreement in the room to add encoding for
> the slopes, with the conditions Vince listed below.
> Please read through the proposal below and let the list know if you agree
> with it, or you would like some other wording/encoding. We need to make
> progress on the document, so your timely answer is appreciated.
> If there won't be any objection to the proposal below, the text will be
> incorporated into the new version of the document.
>
> -Gabor
>
>

-- 
-vince