Peter, That's what makes the Option 2, perhaps, more generic:
List of [frequencyHz, maxPowerDBm] in that you can start to build piece-wise linear shapes.... It would make the protocol more future-proof, even if we don't use it initially to capture such shapes. I guess the trade-off is, at what point the protocol becomes too complex..... -vince On Wed, Jul 24, 2013 at 11:20 AM, Peter McCann <[email protected]>wrote: > 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 > > > > > > > > > > > > > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
