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 protected]> 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
>
>
>
>
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Bajko Gabor (Nokia-CIC/SiliconValley)
> Sent: Friday, November 15, 2013 2:52 PM
> To: [email protected]; [email protected]
> 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 protected] [mailto:[email protected]] On Behalf Of
> ext Vincent Chen
> Sent: Wednesday, November 06, 2013 6:20 PM
> To: [email protected]
> 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.
>
>
>


-- 
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws

Reply via email to