Do we need to talk about the slope of the filter mask that caps the
out-of-band emissions?
-Pete
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
>
>
>
>
>
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
