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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
