Subject: [paws] Further explanation of partitioned data models

From: "Stine, John A." <[email-masked]>
Date: Mon, 27 Feb 2012 21:13:17 +0000

>From the lack of response to my email last week, I assume folks just don't understand why I am recommending the division of the data model.  Please let me explain in a different way.

Last December, at the SDR Forum, Julius Knapp, the Director of the OET at the FCC, hosted a panel attended by five of the ten database administrators.  In that panel, he asked the panelists what was in it for them.  Several responded that they hoped they could provide a service to those looking for spectrum and to help broker these arrangements.  

This is not the model of TVWS.  At present, the urgency of the paws effort surrounds a narrower goal of enabling TVWS devices to obtain channels they can use.  I do not want to make any suggestions that would prevent us from achieving this goal first.  I do want to make an effort to prevent what is done from becoming an impediment to a bigger role for whitespace database administration in the future, one of managing coexistence and brokering spectrum reuse.

In all methods of using a database where a device negotiates with a database, the types of messages that will be used are likely to be similar: 
- This is who I am, what rules should I apply in negotiating for spectrum?  
- This is the spectrum I am looking for, what do you have? 
- This is the spectrum that meets your query criteria.  
- etc.
The methods developed for trust are also reusable.  This is the reason for having a portion of the data model remain the same for all expansions.

The differences between a TVWS scenario and a brokering scenario are likely to be additional messaging and different data, both for the business of brokering and for defining the spectrum authorization.  For example, in the brokering use case there needs to be a spectrum data model that allows a primary spectrum user to release spectrum into the market, (e.g., provide their contours ) and to specify the terms of use.  My concern is that if the data model of TVWS comingles the data of messaging, administration, and spectrum; that this sort of expansion of paws would require increasing the size of the data model and would make expanding its capability more difficult both because of the impact of this expansion on legacy uses and because of the confusion of using large schemas that have similar but different data elements.  

My solution is to divide the data model into three parts.  The data document of messages would use the namespace of three schemas.  In the TVWS edition, this would also allow different administrative and spectrum schemas for different regulatory domains.  In end, the data for TVWS management would not be any different, it would just be defined in three schemas

In the initial exchanges between a device and a database, there would be agreement on which schemas to use.  This is equivalent to resolving the regulatory domain.  The messaging that follows would be the exact same, with the exact same data as the messaging if a comingled data model were used.

If the division is done well, then, in the long term, others can create schemas for administration and spectrum definition that meets their business needs without having to do so through paws.  They would be able expand the way the paws protocol is used without having to revise paws.

I hope this better explains my intent.  It would also be helpful to understand why anyone thinks this should not be done.

John

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 27 Feb 2012 16:25:58 -0500

John,
I may be guilty of being one of those panelists you mention, and we also
run a secondary marketplace for spectrum, so I speak as someone who has a
vested interest in what happens beyond TVWS.
I agree with your insight on the potential, both for access to additional
spectrum as well as for different business models. I also agree with your
summary of the type of negotiation that is likely. Speaking for Spectrum
Bridge we can see a way to address those opportunities within the current
PAWS construct and don't necessarily need to break anything out. I would
want to understand this proposal better as I have two concerns. First it
seems difficult to achieve this without significantly complicating the
process. Second I am not sure that the result may be worse than where we
are today, in that it might confine me to certain modes of operation or
not. The only quick, and simple, analogy I can give is Boingo. They have a
revenue generating service offered on top of unlicensed WiFi. They do so
without any impact on the underlying WiFi MAC/PHY protocols. Our (SBI)
concern has been that the PAWS protocol/requirements do not preclude us
from being able to offer enhanced and differentiated services and so far
we have not been able to identify an issue.  I would be happy to continue
the discussion in parallel to the initial PAWS effort and would not rule
out such a breakup in the future but I think the majority are hoping to
get something finished to address TVWS without too much expansion.
Regards
Peter Stanforth
CTO
Spectrum Bridge Inc.

On MonFeb/27/12 Mon Feb 27, 4:13 PM, "Stine, John A." <[email-masked]>
wrote:

>From the lack of response to my email last week, I assume folks just
>don't understand why I am recommending the division of the data model.
>Please let me explain in a different way.
>
>Last December, at the SDR Forum, Julius Knapp, the Director of the OET at
>the FCC, hosted a panel attended by five of the ten database
>administrators.  In that panel, he asked the panelists what was in it for
>them.  Several responded that they hoped they could provide a service to
>those looking for spectrum and to help broker these arrangements.
>
>This is not the model of TVWS.  At present, the urgency of the paws
>effort surrounds a narrower goal of enabling TVWS devices to obtain
>channels they can use.  I do not want to make any suggestions that would
>prevent us from achieving this goal first.  I do want to make an effort
>to prevent what is done from becoming an impediment to a bigger role for
>whitespace database administration in the future, one of managing
>coexistence and brokering spectrum reuse.
>
>In all methods of using a database where a device negotiates with a
>database, the types of messages that will be used are likely to be
>similar: 
>The methods developed for trust are also reusable.  This is the reason
>for having a portion of the data model remain the same for all expansions.
>
>The differences between a TVWS scenario and a brokering scenario are
>likely to be additional messaging and different data, both for the
>business of brokering and for defining the spectrum authorization.  For
>example, in the brokering use case there needs to be a spectrum data
>model that allows a primary spectrum user to release spectrum into the
>market, (e.g., provide their contours ) and to specify the terms of use.
>My concern is that if the data model of TVWS comingles the data of
>messaging, administration, and spectrum; that this sort of expansion of
>paws would require increasing the size of the data model and would make
>expanding its capability more difficult both because of the impact of
>this expansion on legacy uses and because of the confusion of using large
>schemas that have similar but different data elements.
>
>My solution is to divide the data model into three parts.  The data
>document of messages would use the namespace of three schemas.  In the
>TVWS edition, this would also allow different administrative and spectrum
>schemas for different regulatory domains.  In end, the data for TVWS
>management would not be any different, it would just be defined in three
>schemas
>
>In the initial exchanges between a device and a database, there would be
>agreement on which schemas to use.  This is equivalent to resolving the
>regulatory domain.  The messaging that follows would be the exact same,
>with the exact same data as the messaging if a comingled data model were
>used.
>
>If the division is done well, then, in the long term, others can create
>schemas for administration and spectrum definition that meets their
>business needs without having to do so through paws.  They would be able
>expand the way the paws protocol is used without having to revise paws.
>
>I hope this better explains my intent.  It would also be helpful to
>understand why anyone thinks this should not be done.
>
>John
>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 27 Feb 2012 16:36:23 -0500

<As chair>
Discussions of spectrum coexistence is explicitly out of scope, and we have a big enough job to do without increasing scope.
The scope is also limited to the problem of a device requesting spectrum, and discussions of provisioning ("releasing new spectrum") is out of scope.  Only the device-to-database query and its response is in scope.

<as individual>
If we ever get to coexistence work, the additional messaging is some form of <DB to device>"use this explicit spectrum, I'm suggesting that you use it, even if you could use other spectrum" or <device to db>"of the choices you gave me, I'll use this part, and please try and keep other users out of my way".  Either is a simple expansion of the basic query (location and band in, spectrum choices out).  As such, I don't think we have to do anything in anticipation of such a future capability.

I do think the notion of authentication of the device and the database is in scope, and I certainly think exchange of  credentials or equivalent precedes spectrum query, so I suspect we're separating that part anyway.  I certainly think we're trying to return spectrum choices that depend on location, device characteristics and things like time of day, and we're trying to design a protocol that will work for any country that decides to open spectrum for whitespace use and on any band they decide to do so.  So long as we have enough data elements in the query to allow any of the algorithms that the regulators decide on to determine the available spectrum from the input query and provisioning information in the database, as well as have sufficient flexibility in the response of available spectrum to cover all the limits the regulators want to have, we should be okay.  So far, I don't see any problems staying within the model we have been talking about.

Brian

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 21:57:41 +0000

Hi John,

What you write below is a potential path that white space technology and
dynamic spectrum allocation could take.
However it is still pretty nascent at this time.
What the FCC has approved for now is the availability of some spectrum
(TVWS) for use as per the guidelines/regulations specified. Use of this
spectrum requires a device to query a database to determine available
channels prior to use. This is a clear scoped problem that can be solved
via the device-2-database protocol that PAWS is working on.

As Brian (co-chair) said, it is better to focus on this narrow scope and
get it done. Subsequently the working group may consider expanding its
charter to look at the bigger picture of co-existence, spectrum
negotiation/brokering etc.

-Raj

---

From: "Stine, John A." <[email-masked]>
Date: Mon, 27 Feb 2012 22:11:12 +0000

-----Original Message-----
From: Stine, John A. 
Sent: Monday, February 27, 2012 5:03 PM
To: 'Peter Stanforth'
Subject: RE: [paws] Further explanation of partitioned data models

Peter,

Thank you for the response.  I fully understand the groups intent to get something done right away so that the TVWS market can start moving.  I made this suggestion thinking it would be a very mild change not really contributing to a lot of work.  I am not advocating adding capabilities outside the scope of this initial effort, just promoting the division of the data model to make later expansion easier.  The only additional effort I can think of would be to provide the means within PAWS for a database administrator to specify the particular schemas to use.  That is it.

Your opinion that the PAWS work would not affect your business model carries a lot of weight.  It would be interesting to know the amount of communications you would have with customers that would not involve PAWS at all.  Considering your overlay view of building on top of PAWS, if coexistence management were found to be necessary for effective use of whitespace, would your approach allow you to collaborate with the other database administrators for that objective.

John

-----Original Message-----
From: Peter Stanforth [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 4:26 PM
To: Stine, John A.; [email-masked]
Subject: Re: [paws] Further explanation of partitioned data models

John,

---

From: "Stine, John A." <[email-masked]>
Date: Mon, 27 Feb 2012 22:47:40 +0000

Brian,

	I want to make it very clear that I am not advocating that in this go around that you add anything that increase the scope toward managing coexistence or adding spectrum to the database.  I used those as examples of future upgrades.  I am just making recommendations that you don't do something now that makes it more difficult to do something different in the future.

	I agree with your personal comment that most of your messaging would remain the same.  However, I do not believe the administrative (i.e., regulatory )data and spectrum use data that you will come up with for TV whitespace will be rich enough to account for the many ways of sharing spectrum in the future and the coordination that must take place.  Trying to make it so now will cause the very problem you are objecting to. It will complicate this first effort.  Proceeding on the assumption that it can be upgraded easily, I believe, will be the original sin of PAWS and make upgrade very difficult.  The first iteration of PAWS will affect other standards and those standards will serve as inertia to upgrades.  Creating a PAWS standard that allows for the use of different data models simply keeps this from being a problem.  The legacy data model can be used with the legacy standard.  A new data model can be used with a new standard or a different band or different regulations.

	Consider this problem.  In future upgrades, if coexistence were ever managed, how would the different database administrators collaborate in defining the boundaries between the TVWS users?  Right now it is going to be the wild west.  Short range unlicensed is a different problem than long range unlicensed.  With the larger spaces of the TVWS frequencies there will be greater potential for overlap of users and so interference among users.  

John

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 4:36 PM
To: Stine, John A.
Cc: [email-masked]
Subject: Re: [paws] Further explanation of partitioned data models

<As chair>

<as individual>

Brian

---

From: <[email-masked]>
Date: Tue, 28 Feb 2012 04:41:02 +0000

Hi,

As a way forward, how about two additional requirements

D.X The Data Model MUST be extensible.

P.X The protocol MUST be extensible.

This captures the desire to extend both the Data Model and the protocol in
the future, without identifying a specific solution at this time.

Kind Regards,
Scott

On 2/27/12 4:47 PM, "ext Stine, John A." <[email-masked]> wrote:

>Brian,
>
>	I want to make it very clear that I am not advocating that in this go
>around that you add anything that increase the scope toward managing
>coexistence or adding spectrum to the database.  I used those as examples
>of future upgrades.  I am just making recommendations that you don't do
>something now that makes it more difficult to do something different in
>the future.
>
>	I agree with your personal comment that most of your messaging would
>remain the same.  However, I do not believe the administrative (i.e.,
>regulatory )data and spectrum use data that you will come up with for TV
>whitespace will be rich enough to account for the many ways of sharing
>spectrum in the future and the coordination that must take place.  Trying
>to make it so now will cause the very problem you are objecting to. It
>will complicate this first effort.  Proceeding on the assumption that it
>can be upgraded easily, I believe, will be the original sin of PAWS and
>make upgrade very difficult.  The first iteration of PAWS will affect
>other standards and those standards will serve as inertia to upgrades.
>Creating a PAWS standard that allows for the use of different data models
>simply keeps this from being a problem.  The legacy data model can be
>used with the legacy standard.  A new data model can be used with a new
>standard or a different band or different regulations.
>
>	Consider this problem.  In future upgrades, if coexistence were ever
>managed, how would the different database administrators collaborate in
>defining the boundaries between the TVWS users?  Right now it is going to
>be the wild west.  Short range unlicensed is a different problem than
>long range unlicensed.  With the larger spaces of the TVWS frequencies
>there will be greater potential for overlap of users and so interference
>among users.  
>
>John
>
>Discussions of spectrum coexistence is explicitly out of scope, and we
>have a big enough job to do without increasing scope.
>The scope is also limited to the problem of a device requesting spectrum,
>and discussions of provisioning ("releasing new spectrum") is out of
>scope.  Only the device-to-database query and its response is in scope.
>
><as individual>
>If we ever get to coexistence work, the additional messaging is some form
>of <DB to device>"use this explicit spectrum, I'm suggesting that you use
>it, even if you could use other spectrum" or <device to db>"of the
>choices you gave me, I'll use this part, and please try and keep other
>users out of my way".  Either is a simple expansion of the basic query
>(location and band in, spectrum choices out).  As such, I don't think we
>have to do anything in anticipation of such a future capability.
>
>I do think the notion of authentication of the device and the database is
>in scope, and I certainly think exchange of  credentials or equivalent
>precedes spectrum query, so I suspect we're separating that part anyway.
>I certainly think we're trying to return spectrum choices that depend on
>location, device characteristics and things like time of day, and we're
>trying to design a protocol that will work for any country that decides
>to open spectrum for whitespace use and on any band they decide to do so.
> So long as we have enough data elements in the query to allow any of the
>algorithms that the regulators decide on to determine the available
>spectrum from the input query and provisioning information in the
>database, as well as have sufficient flexibility in the response of
>available spectrum to cover all the limits the regulators want to have,
>we should be okay.  So far, I don't see any problems staying within the
>model we have been talking about.
>
>Brian
>
>> Last December, at the SDR Forum, Julius Knapp, the Director of the OET
>>at the FCC, hosted a panel attended by five of the ten database
>>administrators.  In that panel, he asked the panelists what was in it
>>for them.  Several responded that they hoped they could provide a
>>service to those looking for spectrum and to help broker these
>>arrangements.  
>> 
>>this expansion on legacy uses and because of the confusion of using
>>large schemas that have similar but different data elements.
>> 
>>TVWS edition, this would also allow different administrative and
>>spectrum schemas for different regulatory domains.  In end, the data for
>>TVWS management would not be any different, it would just be defined in
>>three schemas
>> 
>> In the initial exchanges between a device and a database, there would
>>be agreement on which schemas to use.  This is equivalent to resolving
>>the regulatory domain.  The messaging that follows would be the exact
>>same, with the exact same data as the messaging if a comingled data
>>model were used.
>>

---

From: ZhuLei <[email-masked]>
Date: Tue, 28 Feb 2012 09:28:56 +0000

Hi all,

I think that I picked up this concept of protocol design a couple of months before. What I want to recall is that I assumed the framework of protocol is extensible.

Br,
Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2012年2月28日 12:41
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [paws] Further explanation of partitioned data models

Hi,

Kind Regards,
Scott

---

From: "Stine, John A." <[email-masked]>
Date: Tue, 28 Feb 2012 11:11:55 +0000

Hi,

	For now this should be fine.  I hope I have made my point well so extensibility does not become interpreted to mean add more messaging and add more elements to the data model.  Modularity is a powerful means to enable extensibility.

John 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 11:41 PM
To: Stine, John A.; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] Further explanation of partitioned data models

Hi,

Kind Regards,
Scott

---

From: <[email-masked]>
Date: Tue, 28 Feb 2012 17:44:56 +0000

Inline:

>the future, without identifying a specific solution at this time.

The above requirements are overly broad and tends to result in protocol
bloat. 
Extensibility is something to be kept in mind with the cognizance that the
WS technology will evolve but I would refrain from adding the above
requirements to the I-D.

-Raj

---

From: "Stine, John A." <[email-masked]>
Date: Tue, 28 Feb 2012 18:02:12 +0000

How about this

D.X  The data model MUST provide a modular design separating out messaging specific, administrative specific, and spectrum specific parts into separate modules.

P.X  The protocol MUST support determination of which administrative specific and spectrum specific modules are used.

This is very specific and it is NOT requiring any increase in scope.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2012 12:45 PM
To: [email-masked]; Stine, John A.; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] Further explanation of partitioned data models

Inline:

-Raj

---

From: <[email-masked]>
Date: Tue, 28 Feb 2012 18:16:41 +0000

Hi John,

Rather than stating that the data model MUST be modular or the protocol
MUST support determination of which administrative and spectrum specific
modules are used, I would propose these to be included as guidelines to be
used in the design of the data model and protocol.
In addition to having a set of requirements, we could add guidelines as
well to abet the solutions.

-Raj

On 2/28/12 12:02 PM, "ext Stine, John A." <[email-masked]> wrote:

>How about this
>
>D.X  The data model MUST provide a modular design separating out
>messaging specific, administrative specific, and spectrum specific parts
>into separate modules.
>
>P.X  The protocol MUST support determination of which administrative
>specific and spectrum specific modules are used.
>

---

From: "Stine, John A." <[email-masked]>
Date: Tue, 28 Feb 2012 18:38:23 +0000

Hi Raj,

	That would be fine.  

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2012 1:17 PM
To: Stine, John A.
Cc: [email-masked]
Subject: Re: [paws] Further explanation of partitioned data models

Hi John,

-Raj

---

From: <[email-masked]>
Date: Tue, 28 Feb 2012 21:51:36 +0000

How about adding the following as a subsection to the requirements section:

"
Sec x.y Guidelines for protocol and data model design

The current scope of the working group is limited and are reflected in
the requirements captured in Section y.z. However white space
technology itself is expected to evolve and address other aspects such
as co-existence and interference avoidance, spectrum brokering,
alternative spectrum bands, etc. The design of the data model and
protocol should be cognizant of the evolving nature of white space
technology and consider the following set of guidelines in the
development of the data model and protocol:

1. The data model SHOULD provide a modular design separating out
   messaging specific, administrative specific, and spectrum specific
   parts into separate modules.

2. The protocol SHOULD support determination of which administrative
   specific and spectrum specific modules are used.

"

-Raj

---

From: "Stine, John A." <[email-masked]>
Date: Tue, 28 Feb 2012 22:07:58 +0000

Raj,

That is great!  Thank you.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2012 4:52 PM
To: Stine, John A.
Cc: [email-masked]
Subject: Re: [paws] Further explanation of partitioned data models

"

"

-Raj