Sungjin, All,
Actually, the max power must be associated with each available-frequency
range, since it can be different
for different ranges.
The list of {startHz, stopHz, maxPowerDBm} "roughly" defines a spectral
mask. So there might be one
for wide-band and a different mask for narrow band operations.
There was a question, though, of whether the "mask" should be encoded
differently, e.g.,
Option 1: List of {startHz, maxStartPowerDBm, stopHz, maxStopPowerDBm}
Option 2: List of {frequencyHz, maxPowerDBm} sorted by frequencyHz
Does anyone have any thoughts on this?
-vince
On Wed, Jul 24, 2013 at 12:24 AM, Sungjin Yoo <[email protected]> wrote:
> Vince and all,
>
> Thanks for the explanation.
> I understand what you mean.
>
> I think current encoding format may cause a misunderstanding. Because
> maximum power informations for the same frequency may be distributed to
> multiple object. I think it's clearer if "bandwidth" is coupled with
> "maxPowerDBm".
>
> How about the following format?
>
> "spectra": [
> {
> "maxPower":[
> {"bandwidthHz":6e6, "maxPowerDBm":30.0},
> {"bandwidthHz":1e5, "maxPowerDBm":27.0}
> ]
> "frequencyRanges": [
> {"startHz":5.18e8, "stopHz":5.36e8},
> ...
> ]
>
>
> Regards,
> Sungjin
>
>
> On 07/24/2013 11:14 AM, Vincent Chen wrote:
>
> Sungjin,
>
> Sorry for the delay and the confusion.
>
> Assuming we have the response that contains:
>
> "spectra": [
> {
> "bandwidth": 6e6,
> "frequencyRanges": [
> {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0},
> ...
> ]
> },
> {
> "bandwidth": 1e5,
> "frequencyRanges": [
> {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0},
> ...
> ]
> }
>
>
> This specifies that the frequencies in the range [518MHz, 536MHz) are
> available, and the device must satisfy two conditions:
>
> - Within any 6MHz in that range, total power may not exceed 30.0 dBm
> AND
> - Within any 100kHz in that range, total power may not exceed 27 dBm
>
> In this example, it means that the device may fit two 100kHz
> "sub-channels" at 27dBm within any 6MHz channel.
>
> (There are many other possibilities.)
>
> Does this make sense? If so, I'll update the draft to make this more
> clear.
>
> Thanks.
>
> -vince
>
>
>
> On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo <[email protected]> wrote:
>
>> Vince,
>>
>> Comment is in line.
>>
>>
>> On 07/19/2013 02:17 PM, Vincent Chen wrote:
>>
>> Sunglin,
>>
>> Some clarification: The maxPowerDbm is total power. It is not a
>> spectral density.
>>
>> I agree. But (maxPowerDBm / bandwidth) defines the spectral density.
>>
>>
>> Thus, if a 6MHz channel is available, the Device may choose to put,
>> say, ten 100kHz sub-channels within that channel.
>> The total power summed over those 10 sub-channels cannot exceed 27dBm.
>>
>> So here is one way the Device may use the response.
>> - The Device determines first if it wants to be a narrow band (1e5) or
>> wideband (6e6) device
>> - It selects the Spectrum specification, based on its mode
>>
>> I think "bandwidth" parameter does not limit the operation bandwidth
>> of the device, it is just reference bandwidth to define permissible power
>> levels and that is equivalent to define spectral density. I think
>> "maxContiguousBwHz" parameter(4.4.2) limit the operation bandwidth, and
>> "bandwidth" parameter does not.
>>
>> I understand the "bandwidth" parameter from following paragraphs.
>>
>> 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed
>> from the start and stop frequencies) MAY be different from the"bandwidth"
>> value.
>>
>> 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum
>> permitted EIRP spectral density."
>>
>> 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a
>> constraint on the maximum contiguous bandwidth (in Hertz) allowed."
>>
>>
>>
>>
>> -vince
>>
>>
>> On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <[email protected]> wrote:
>>
>>> Vince,
>>>
>>> Comment is in line.
>>>
>>>
>>> On 07/19/2013 10:16 AM, Vincent Chen wrote:
>>>
>>> Sungjin,
>>>
>>>
>>> On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <[email protected]> wrote:
>>>
>>>> Vince,
>>>>
>>>> I understand "bandwidth" parameter is just for defining permissible
>>>> power or spectral density and
>>>> it dose not represent the operation bandwidth. (see 4.4.5.
>>>> SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
>>>> If I misunderstand, please correct me.
>>>>
>>>
>>> Oh, I understand what you're saying. The example does not make sure
>>> the math works out to be equivalent.
>>> I thought, though, some regulators actually wants different power
>>> spectral density for narrow band, so it's not always
>>> guaranteed to be the same.
>>>
>>>
>>> If master device receive the message in the example, it will be
>>> confused. Assume the master device decides to use the spectrum from 5.18e8
>>> Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the
>>> master device may be confused to interpret permissible maximum power. First
>>> one in the example represents 30.0 dBm, but second one represents about
>>> 44.78 dBm(=27dBm + 17.78dB). The master device don't know which one is
>>> correct.
>>> So I think it will be clear if "frequencyRanges" in the second one(for
>>> "bandwidth" : 1e5) is modified to different frequency from first one(for
>>> "bandwidth" : 1e5)
>>>
>>>
>>> And I found another typos.
>>>> "jsonrpc": "2.0", should be added to all examples.
>>>>
>>>
>>> Thanks. I will incorporate this.
>>>
>>>
>>>>
>>>> Regards,
>>>> Sungjin
>>>>
>>>>
>>>> On 07/16/2013 06:56 AM, Vincent Chen wrote:
>>>>
>>>> Sungjin,
>>>>
>>>> Sorry for the long delay (vacation). Answers inline.
>>>>
>>>>
>>>> On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <[email protected]> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I have found two typos.
>>>>>
>>>>> At example "getSpectrum" JSON-RPC in 6.4.1. :
>>>>> "id": "xxxxxx", --> Comma should be deleted.
>>>>> At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
>>>>> "id": "xxxxxx", --> Comma should be deleted.
>>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>>
>>>>>
>>>>> I have a comment about example "getSpectrum" JSON-RPC response in
>>>>> 6.4.2 and 6.5.2.
>>>>> There are two spectrum information parameters for the same frequency
>>>>> range.
>>>>> One is for bandwidth 6e6, and the other is for bandwidth 1e5.
>>>>> But spectral density of 6e6 is different from that of 1e5 in the same
>>>>> frequency range.
>>>>> It will be more nice if the spectral density of the same frequency
>>>>> range is same.
>>>>> Or it will be also nice if frequency ranges are modified to be
>>>>> different from each other.
>>>>>
>>>>
>>>> This is intended to represent the permissible maximum power in which
>>>> "wide-band" and "narrow-band" operations are permitted.
>>>> The available frequencies do not change (hence, the same start/stop
>>>> frequencies), just the permissible power.
>>>>
>>>>
>>>> Does that make sense?
>>>>
>>>> -vince
>>>>
>>>>
>>>>
>>>>> Thank you.
>>>>>
>>>>> BR,
>>>>> Sungjin
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email protected] [mailto:[email protected]] On Behalf
>>>>> Of [email protected]
>>>>> Sent: Thursday, June 20, 2013 2:18 AM
>>>>> To: [email protected]
>>>>> Subject: [paws] WGLC on
>>>>> http://tools.ietf.org/html/draft-ietf-paws-protocol-06
>>>>>
>>>>>
>>>>> All,
>>>>>
>>>>> The Editor of the document posted a new version and indicated that all
>>>>> open issues raised on the list were resolved, and that there are no more
>>>>> open issues he is aware of.
>>>>> Therefore, I'd like to issue a wg last call on the document. We need
>>>>> reviews and feedback in order to be able to progress the document.
>>>>>
>>>>> Please read through the draft and send any comments you may have to
>>>>> the list in the next 2-3 weeks.
>>>>> If you review the draft and have no comments, send a note to the list
>>>>> that the draft is good as it is, we need these notes as much as we need
>>>>> the
>>>>> actual comments.
>>>>>
>>>>> Thanks, Gabor
>>>>> _______________________________________________
>>>>> paws mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>> _______________________________________________
>>>>> paws mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -vince
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> -vince
>>>
>>>
>>> Regards,
>>> Sungjin
>>>
>>>
>>
>>
>> --
>> -vince
>>
>>
>>
>
>
> --
> -vince
>
>
>
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
