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