Rex,
What is not expressed in the doc is that maxTotalBW and maxNominalChannelBW
are responses from the Database to the Device as additional constraints.
As Cesar indicated earlier:
- maxTotalBW: Device can use a maximum of specified bandwidth, which can
be contiguous or not
- maxNominalChannelBW: The maximum width of any single contiguous block
of spectrum
(We might want to rename the second to maxContiguousBW)
For example:
1. Device asks for available spectrum, providing its location and device
descriptor fields (which can include technology ID, etc.)
2. Database returns available spectrum in terms of start and stop
frequencies and max allowable power levels within those frequencies.
Database response may also include the constraints:
- maxTotalBW
- maxNominalChannelBW
3. Devices selects spectrum it will use based on what's available and
these additional constraints.
Hope that makes more sense?
-vince
On Mon, Apr 8, 2013 at 11:15 AM, Rex Buddenberg <[email protected]>wrote:
> maxTotalBW
> maxNominalChannelBW
> ETSIENmaxLocationChange
>
>
> Please tell me what these parameters mean.
>
> I'm mentally bouncing the page against a use case where we have a
> broadband (500kHz or so) device that is attempting to get an allocation
> in a traditionally narrowband (e.g. VHF) space where (in US) the
> licenses are for 25kHz, 12.5KHz or 6.25KHz. The broadband device would
> need multiple narrowband allocations all cheek-by-jowl.
>
> A lot of the VHF space is allocated, but a good deal is not used much.
> For example, in the county where I live, the county has over 200
> narrowband VHF licenses. At some time in the future, it's entirely
> conceivable that white space governance could extend into this area ...
> beyond the existing mindset of TV spectrum.
>
> How would such a broadband device request a chunk of broadband spectrum?
> Can it be expressed with these parameters? Is PAWS at least extensible
> to accommodate such a request in the future?
>
>
>
>
>
>
> On Mon, 2013-04-08 at 16:57 +0000, Cesar Gutierrez wrote:
> > Vince and all,
> >
> >
> >
> > The attached is the list of the parameters that need to be
> > incorporated to existing IETF PAWS protocol functionalities in order
> > to cover the requirements in the current draft of the ETSI Harmonised
> > Standard. I would be grateful if IETF PAWS members could review and
> > comment.
> >
> >
> >
> > Please note that this list does not address support for the current
> > database discovery requirement in ETSI HS. It does not address either
> > the device update function (or kill switch, or PUSH) that was briefly
> > discussed at the meeting in Orlando. We are still discussing this
> > function in ETSI and the UK, and I expect to bring it to consideration
> > of IETF PAWS members in the coming weeks.
> >
> >
> >
> > Thanks and regards,
> >
> > Cesar
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: Vincent Chen [mailto:[email protected]]
> > Sent: 14 March 2013 05:17
> > To: Cesar Gutierrez; [email protected]
> > Subject: Extensibility for Ofcom
> >
> >
> >
> >
> > Cesar,
> >
> >
> >
> >
> > Thanks for joining the call for the IETF/PAWS.
> >
> >
> >
> >
> >
> > I want to follow up with you on the parameter names and values that we
> > should consider adding to the draft to support Ofcom White Space
> > rules. In particular:
> >
> >
> >
> >
> >
> > - What is the "unique device identifier" intended to be? Is there a
> > separate certification ID apart from the serial number?
> >
> >
> >
> >
> >
> > - What should be the parameter name for "device class"? What are the
> > possible values and what do they mean?
> >
> >
> >
> >
> >
> > - What should be the parameter name for "technology ID"? What are the
> > possible vales and what do they mean?
> >
> >
> >
> >
> >
> > Are you aware of other parameters that must be defined for Ofcom?
> >
> >
> >
> >
> >
> > Thanks for your help.
> >
> >
> >
> >
> >
> > --
> > -vince
> >
> >
> >
> >
> > ______________________________________________________________________
> >
> >
> ******************************************************************************************************************
> > For more information visit www.ofcom.org.uk
> >
> > This email (and any attachments) is confidential and intended for the
> > use of the addressee only.
> >
> > If you have received this email in error please notify the originator
> > of the message and delete it from your system.
> >
> > This email has been scanned for viruses. However, you open any
> > attachments at your own risk.
> >
> > Any views expressed in this message are those of the individual sender
> > and do not represent the views or opinions of Ofcom unless expressly
> > stated otherwise.
> >
> ******************************************************************************************************************
> > _______________________________________________
> > paws mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/paws
>
>
>
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
