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]
<mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[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]>
[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of
[email protected] <mailto:[email protected]>
Sent: Thursday, June 20, 2013 2:18 AM
To: [email protected] <mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[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
