Subject: [paws] Possible new use case: simulcasting

From: Peter McCann <[email-masked]>
Date: Tue, 13 Sep 2011 17:37:34 +0000

Hi,

I've been interacting with Zhu Lei off-list about his third use case,
and I think it would be a possible candidate for inclusion in the document
if it were properly explained.

Generally (as opposed to specifically for the LTE MBMS case), the 
problem is to find a common bit of spectrum that is
available over a wide area that can be used by multiple master BSs
to simultaneously broadcast the same signal to a set of receivers.
This is somewhat similar to the wide-area rural coverage scenario
currently described in the working group document; however, there
would be multiple Master BSs, each of which would independently query
the WSDB for available spectrum.  However, they need to coordinate
the assignment so that they all get the same spectrum over the whole
area.  As an implementation example, this could be achieved by each
BS reporting the same owner/operator and using a key or index value
to indicate that they wanted to coordinate the assignment.  Alternatively,
you might be able to elect one BS as the leader and collect location
information from all the other BSs and then coordinate the assignment
similar to the use case in 4.2; the difference would be that the
resulting assignment is for simultaneous (not TDD) use by all of the
BSs covering the wider area.

Does this sound like an interesting and novel use case?  If so I can
do a more detailed writeup and supply ASCII art for the draft.

--
Peter J. McCann
Huawei Technologies (USA)
[email-masked]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Sep 2011 22:46:49 -0400

I may be missing something, but it seems to me taht what you are 
describing is not the job of the database query protocol.  base station 
coordination is an interesting problem, but is it within scope for this 
WG?  (I do not think just specifying the same owner to the database will 
resolve the problem, and it makes the database state MUCH more complex.)

Yours,
Joel

On 9/13/2011 1:37 PM, Peter McCann wrote:
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 02:54:18 +0000

Pete,

I dont believe co-ordination between BS' is needed. 
Interference mitigation between BS' is an interesting problem no doubt. But it is not in the scope of the current charter.
Adjacent BS' (i.e Master WS devices) for example which query a database may receive the same channel information.
This could result in interference. However that is an issue which the PAWS WG is not chartered to solve. 
There is work on this happening in IEEE (802.19) but that aspect of cognitive radio is not something we are aiming to solve currently.

-Raj 
________________________________________
From: [email-masked] [[email-masked]] on behalf of ext Peter McCann [[email-masked]]
Sent: Tuesday, September 13, 2011 12:37 PM
To: [email-masked]
Subject: [paws] Possible new use case: simulcasting

Hi,

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Sep 2011 08:55:40 -0400

Correct.

Our charter very specifically DOES NOT include mechanisms for multiple secondary users to equitably share the available spectrum.  It only is scoped for mechanisms for the secondary users to avoid interference with primary users.  When we solve the current problem, if there is enough interest, we might be able to recharter to work on sharing among secondary users.

A narrowly scoped charter is a good thing in the IETF, but it means not all the interests of the participants may be covered.  Let's solve the current problem, and if we have enough interest, we can expand later.

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 12:58:28 +0000

Based on some of the existing use cases, it looks like the database
is keeping state even for the secondary users.  That is, it is acting
as a de-facto registry for users of the secondary spectrum and will
refuse to allocate the same spectrum to different users in overlapping
geographic regions.  Am I mistaken in this assumption?

-Pete

Joel M. Halpern wrote:
> describing is not the job of the database query protocol.  base
> station coordination is an interesting problem, but is it within scope
> for this WG?  (I do not think just specifying the same owner to the
> database will resolve the problem, and it makes the database state
> MUCH more
> complex.)
> 
> Yours,
> Joel
> 
>> I've been interacting with Zhu Lei off-list about his third use
>> case, and I think it would be a possible candidate for inclusion in
>> the document if it were properly explained.
>> 
>> problem is to find a common bit of spectrum that is available over a
>> wide area that can be used by multiple master BSs to simultaneously
>> broadcast the same signal to a set of receivers. This is somewhat
>> similar to the wide-area rural coverage scenario currently described in
>> the working group document; however, there would be multiple Master
>> BSs, each of which would independently query the WSDB for available
>> spectrum.  However, they need to coordinate the assignment so that they
>> all get the same spectrum over the whole area. As an implementation
>> example, this could be achieved by each BS reporting the same
>> owner/operator and using a key or index value to indicate that they
>> wanted to coordinate the assignment. Alternatively, you might be able
>> to elect one BS as the leader and collect location information from all
>> the other BSs and then coordinate the assignment similar to the use
>> case in 4.2; the difference would be that the resulting assignment is
>> for simultaneous (not TDD) use by all of the BSs covering the wider
>> area.
>>

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 13:04:16 +0000

Hi,

Thank you Peter & Lei for the more detailed description of the use case.
When I look at this case, the question is: can PAWS be used to allow
multiple Master devices to knowingly select the same channel for
operation. (The discussion of "why" and "is it a good idea" not undertaken
here as this likely wanders outside the scope of PAWS).

One of the proposed solutions is coordination among BSs (external to
PAWS). This is already described in section 4.3 Wide-Area or Rural
internet broadband access:

   >Some of the masters/BSs may be deployed and operated by a single
   >entity, i.e. there can be centralized coordination between these
   >masters/BSs,...

Further, you note the difference is in TDD:

   >The BS in this scenario use a TDD radio
   >Technology

Would it be appropriate and acceptable to WG members to add "typically"
such as:

   >The BS in this scenario typically uses a
   >TDD radio Technology...

Does this enable the use case you are describing?

Regards,
Scott

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 13:04:18 +0000

Hi,

Coexistence is a very interesting topic which I hope we can consider after
the first version of PAWS is complete.

Regards,
Scott

On 9/13/11 9:54 PM, "ext [email-masked]"
<[email-masked]> wrote:

>Interference mitigation between BS' is an interesting problem no doubt.
>But it is not in the scope of the current charter.
>Adjacent BS' (i.e Master WS devices) for example which query a database
>may receive the same channel information.
>There is work on this happening in IEEE (802.19) but that aspect of
>cognitive radio is not something we are aiming to solve currently.
>
>-Raj

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Sep 2011 09:11:02 -0400

Yes, you are mistaken.

If two queriers with the same location and input parameters query the database, they will get the same response.   Suppose two U.S. Mode I devices at essentially the same location (within 25 meters) query the database, and the first is told he may use TV channels 1-5, 9-11 and 25-33.  The second one will be told the same thing.

The database knows query patterns, but does not track use.  Specifically, it doesn't know what part of the spectrum the device actually chooses to use, when it starts using it, and when it ceases to use it.  

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 13:18:51 +0000

However, the location-based services use case clearly has the
white space database keeping state on the secondary user, at
least his location.  Step 7 of the Hotspot use case has the 
BS registering the spectrum that it selected for its use.
If the database is keeping state in this manner, it could easily
calculate the exclusion zones for the secondary users as well.

Or did these use cases as described exceed the mandate of the
charter?

-Pete

Rosen, Brian wrote:
> Yes, you are mistaken.
> 
> If two queriers with the same location and input parameters query the
> database, they will get the same response.   Suppose two U.S. Mode I
> devices at essentially the same location (within 25 meters) query the
> database, and the first is told he may use TV channels 1-5, 9-11 and
> 25-33.  The second one will be told the same thing.
> 
> The database knows query patterns, but does not track use.
> Specifically, it doesn't know what part of the spectrum the device
> actually chooses to use, when it starts using it, and when it ceases
> to use it.
> 
> Brian
> 
> 
>> Based on some of the existing use cases, it looks like the database is
>> keeping state even for the secondary users.  That is, it is acting as a
>> de-facto registry for users of the secondary spectrum and will refuse
>> to allocate the same spectrum to different users in overlapping
>>> MUCH more complex.)
>>>> case, and I think it would be a possible candidate for inclusion
>>>> in the document if it were properly explained.
>>>> 
>>>> similar to the wide-area rural coverage scenario currently described
>>>> in the working group document; however, there would be multiple
>>>> Master BSs, each of which would independently query the WSDB for
>>>> available spectrum.  However, they need to coordinate the assignment
>>>> so that they all get the same spectrum over the whole area. As an
>>>> implementation example, this could be achieved by each BS reporting
>>>> the same owner/operator and using a key or index value to indicate
>>>> that they wanted to coordinate the assignment. Alternatively, you
>>>> might be able to elect one BS as the leader and collect location

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 13:20:31 +0000

Hi, Scott,

[email-masked] wrote:
> operation. (The discussion of "why" and "is it a good idea" not
> undertaken here as this likely wanders outside the scope of PAWS).
> 

Maybe we could say:

The BS in this scenario typically use a TDD radio technology
or other means to coordinate use of the selected spectrum.

-Pete

>> and I think it would be a possible candidate for inclusion in the
>> document if it were properly explained.
>> 
>> Does this sound like an interesting and novel use case?  If so I can do
>> a more detailed writeup and supply ASCII art for the draft.
>> 
>> --
>> Peter J. McCann

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Sep 2011 09:25:40 -0400

It's beyond the charter.  This was discussed when we created the charter, and explicitly excluded it for this initial work.

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 13:26:32 +0000

So do these use cases in the accepted working group document
need to be modified, then?

-Pete

Rosen, Brian wrote:
> It's beyond the charter.  This was discussed when we created the
> charter, and explicitly excluded it for this initial work.
> 
> Brian
> 
>> However, the location-based services use case clearly has the white
>> space database keeping state on the secondary user, at least his
>> location.  Step 7 of the Hotspot use case has the BS registering the
>> spectrum that it selected for its use.
>> Or did these use cases as described exceed the mandate of the charter?
>> 
>> -Pete
>> 
>> Rosen, Brian wrote:
>>> Yes, you are mistaken.
>>> 
>>> actually chooses to use, when it starts using it, and when it
>>> ceases to use it.
>>> 
>>> Brian
>>> 
>>> 
>>>> Based on some of the existing use cases, it looks like the
>>>> database is keeping state even for the secondary users.  That is,
>>>> it is acting as a de-facto registry for users of the secondary
>>>> spectrum and will refuse to allocate the same spectrum to
>>>> different users in overlapping geographic regions.  Am I mistaken in this assumption?
>>>> 
>>>> -Pete
>>>> 
>>>> 
>>>> Joel M. Halpern wrote:
>>>>> station coordination is an interesting problem, but is it within
>>>>> scope for this WG?  (I do not think just specifying the same owner
>>>>> to the database will resolve the problem, and it makes the database
>>>>> state MUCH more complex.)
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>>> problem is to find a common bit of spectrum that is available over
>>>>>> a wide area that can be used by multiple master BSs to
>>>>>> simultaneously broadcast the same signal to a set of receivers.
>>>>>> would be multiple Master BSs, each of which would independently
>>>>>> query the WSDB for available spectrum.  However, they need to
>>>>>> coordinate the assignment so that they all get the same spectrum
>>>>>> over the whole area. As an implementation example, this could be
>>>>>> achieved by each BS reporting the same owner/operator and using a
>>>>>> key or index value to indicate that they wanted to coordinate the
>>>>>> assignment. Alternatively, you might be able to elect one BS as the
>>>>>> leader and collect location information from all the other BSs and
>>>>>> then coordinate the assignment similar to the use case in 4.2; the
>>>>>> difference would be that the resulting assignment is for
>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider
>>>>>> area.
>>>>>> 
>>>>>> Does this sound like an interesting and novel use case?  If so I
>>>>>> can do a more detailed writeup and supply ASCII art for the draft.
>>>>>> 
>>>>>> --
>>>>>> Peter J. McCann

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 14 Sep 2011 10:38:36 -0400

Peter, Brian,

My suggestion would be to leave this feature in.  It will not cost much to 
make room in the protocol for the TVBD to indicate to the database which 
channel it decided to operate on and it would provide easy extensibility to 
the protocol for an eventual consideration of the coexistence amongst the 
license-exempt devices.

I would agree, however, that the current step of the protocol development 
should be limited to protecting of the broadcast incumbents as stated in 
the scope.

Gerald

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Sep 2011 10:55:48 -0400

The problem is that this turns the transaction into multiple steps.  As it is now, you send a query and get a response.  

If the device needs to update with what it used, that's another step.  Also, what happens if it changes its mind?

Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Sep 2011 11:07:16 -0400

I can see many other problems in trying to extend the protocol in thsi 
regard.  Among other things, it changes the security model of the 
database, since it is now accepting update information as well as 
queries from the Internet.  And that is the tip of the iceberg.
The charter says we don't go there (my thanks to the chairs and ADs).
Lets not.

Yours,
Joel

PS: If we want to keep "interesting ideas" in the use case document, it 
seems to me they at least need to be clearly labelled as being out of 
scope.  Personally, I would just remove them as distraction.

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 14 Sep 2011 11:16:31 -0400

Brian,

Agreed.  A single transaction, to the DB and back to the TVBD, would be 
sufficient if the protocol is to be kept simple. Coexistence amongst the 
license-exempt devices would then be left to other processes such as the 
one being developed by the IEEE 802.19.1.

Gerald

At 10:55 14-09-11 -0400, Rosen, Brian wrote:
>The problem is that this turns the transaction into multiple steps.  As it 
>is now, you send a query and get a response.
>
>If the device needs to update with what it used, that's another 
>step.  Also, what happens if it changes its mind?
>
>Brian
>

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 15:40:18 +0000

Hi,

One of the key aspects of this protocol between device and database is
extensibility. The charter does recognize that the contents of the
database is defined external to PAWS. Thus hard to say that any single
specific value or information element is beyond the scope.

Also the charter allows for queries and responses, there is no restriction
that single transactions are mandated.

So IMHO the use cases already approved are still valid, no reasons to
exclude pieces.

Regards,
Scott

On 9/14/11 10:16 AM, "ext Gerald Chouinard" <[email-masked]>
wrote:

>> >>>>>> different users in overlapping geographic regions.  Am I
>>mistaken in
>> >> this assumption?
>> >>>>>>
>> >>>>>> -Pete
>> >>>>>>
>> >>>>>>
>> >>>>>> Joel M. Halpern wrote:

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 15:40:16 +0000

Hi Pete,

There is no coordination aspect to TDD is there? I added TDD initially to
indicate that a single channel is used for operation, contrasted to the 2
channel requirement for FDD.

I believe the use case under discussion is using the channel for full DL
broadcast. It's not so much as coordination, just 100% DL. Right?

Would help me if you could clarify what spectrum coordination is happening
in this case.

Regards,
Scott

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 16:13:45 +0000

TDD is a turn-taking mechanism for sharing the spectrum.  I would
call that a form of coordination between the various transmitters.
Someone needs to publish a schedule of who is allowed to transmit
when.

In the broadcast case, the coordination required is for all BS to
transmit exactly the same physical layer signal at the same time
so that receivers see constructive interference.

-Pete

[email-masked] wrote:
> Hi Pete,
> 
> There is no coordination aspect to TDD is there? I added TDD initially
> to indicate that a single channel is used for operation, contrasted to
> the 2 channel requirement for FDD.
> 
> I believe the use case under discussion is using the channel for full
> DL broadcast. It's not so much as coordination, just 100% DL. Right?
> 
> Would help me if you could clarify what spectrum coordination is
> happening in this case.
> 
> Regards,
> Scott
> 
> 
>>> Thank you Peter & Lei for the more detailed description of the use
>>> case. When I look at this case, the question is: can PAWS be used to
>>> allow multiple Master devices to knowingly select the same channel for
>>> One of the proposed solutions is coordination among BSs (external
>>> to PAWS). This is already described in section 4.3 Wide-Area or
>>> Rural internet broadband access:
>>> 
>>>> The BS in this scenario use a TDD radio Technology
>>> 
>>> Would it be appropriate and acceptable to WG members to add
>>> "typically" such as:
>>> 
>>>> The BS in this scenario typically uses a TDD radio Technology...
>>> 
>> The BS in this scenario typically use a TDD radio technology or other
>> means to coordinate use of the selected spectrum.
>> 
>> -Pete
>> 
>>> 
>>> 
>>> 
>>> Regards,
>>> Scott
>>> 
>>>

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 16:22:00 +0000

Hi, Scott,

The problem is when I see text like this in section 4.2 and 4.3:

  7.  The master/AP acknowledges to the database which of the available
       WS channels it has selected for its operation.  The database is
       updated with the information provided by the master/AP.

it makes me think that the database is tracking the use of spectrum
by the whitespace master devices.  When it says "database is updated"
that makes me think that the database of exclusion zones is updated
in a way that will impact the results of future queries.

There is also the location-based service use case where the database
is keeping state about the whitespace master device, namely its location:

   3.  The server queries the trusted white space database with the
       master identity provided by the application in the user's
       smartphone.

   4.  The trusted white space database replies to the server with the
       location of the master device.

If the database is to be truly stateless and passive with respect to
queries by whitespace devices, these kinds of statements should be
removed from the use cases.

-Pete

[email-masked] wrote:
> Also the charter allows for queries and responses, there is no
> restriction that single transactions are mandated.
> 
>> sufficient if the protocol is to be kept simple. Coexistence amongst
>> the license-exempt devices would then be left to other processes such
>> as the one being developed by the IEEE 802.19.1.
>> 
>> Gerald
>> 
>> 
>>> The problem is that this turns the transaction into multiple steps.
>>> As it is now, you send a query and get a response.
>>> 
>>> If the device needs to update with what it used, that's another step.
>>> Also, what happens if it changes its mind?
>>> 
>>> Brian
>>> 
>>>> My suggestion would be to leave this feature in.  It will not cost
>>>> much to make room in the protocol for the TVBD to indicate to the
>>>> database which channel it decided to operate on and it would provide
>>>> easy extensibility to the protocol for an eventual consideration of
>>>> the coexistence amongst the license-exempt devices.
>>>> 
>>>> I would agree, however, that the current step of the protocol
>>>> development should be limited to protecting of the broadcast
>>>> incumbents as stated in the scope.
>>>> 
>>>> Gerald
>>>> 
>>>> 
>>>>>> It's beyond the charter.  This was discussed when we created
>>>>>> the charter, and explicitly excluded it for this initial work.
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>>> white space database keeping state on the secondary user, at least
>>>>>>> his location.  Step 7 of the Hotspot use case has the BS
>>>>>>> registering the spectrum that it selected for its use. If the
>>>>>>> database is keeping state in this manner, it could easily
>>>>>>>> If two queriers with the same location and input parameters query
>>>>>>>> the database, they will get the same response.   Suppose two U.S.
>>>>>>>> Mode I devices at essentially the same location (within 25
>>>>>>>> meters) query the database, and the first is told he may use TV
>>>>>>>> channels 1-5, 9-11 and 25-33.  The second one will be told the
>>>>>>>> same thing.
>>>>>>>> 
>>>>>>>> Specifically, it doesn't know what part of the spectrum the
>>>>>>>> device actually chooses to use, when it starts using it, and
>>>>>>>> when it ceases to use it.
>>>>>>>> 
>>>>>>>> Brian
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> I may be missing something, but it seems to me taht what you
>>>>>>>>>> are describing is not the job of the database query protocol.
>>>>>>>>>> base station coordination is an interesting problem, but is it
>>>>>>>>>> within scope for this WG?  (I do not think just specifying the
>>>>>>>>>> same owner to the database will resolve the problem, and it
>>>>>>>>>> makes the database state MUCH more complex.)
>>>>>>>>>> 
>>>>>>>>>> Yours,
>>>>>>>>>> Joel
>>>>>>>>>> 
>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his third
>>>>>>>>>>> use case, and I think it would be a possible candidate for
>>>>>>>>>>> inclusion in the document if it were properly explained.
>>>>>>>>>>> 
>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS case),
>>>>>>>>>>> the problem is to find a common bit of spectrum that is
>>>>>>>>>>> available over a wide area that can be used by multiple master
>>>>>>>>>>> BSs to simultaneously broadcast the same signal to a set of
>>>>>>>>>>> receivers. This is somewhat similar to the wide-area rural
>>>>>>>>>>> coverage scenario currently described in the working group
>>>>>>>>>>> document; however, there would be multiple Master BSs, each of
>>>>>>>>>>> which would independently query the WSDB for available
>>>>>>>>>>> spectrum. However, they need to coordinate the assignment so
>>>>>>>>>>> that they all get the same spectrum over the whole area. As an
>>>>>>>>>>> implementation example, this could be achieved by each BS
>>>>>>>>>>> reporting the same owner/operator and using a key or index
>>>>>>>>>>> value to indicate that they wanted to coordinate the
>>>>>>>>>>> assignment. Alternatively, you might be able to elect one
> BS
>>> as the
>>>>>>>>>>> leader and collect location information from all the other BSs
>>>>>>>>>>> and then coordinate the assignment similar to the use case in
>>>>>>>>>>> 4.2; the difference would be that the resulting assignment is
>>>>>>>>>>> for simultaneous (not TDD) use by all of the BSs covering the
>>>>>>>>>>> wider area.
>>>>>>>>>>> 
>>>>>>>>>>> Does this sound like an interesting and novel use case? If so
>>>>>>>>>>> I can do a more detailed writeup and supply ASCII art for the
>>>>>>>>>>> draft.

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 14 Sep 2011 13:06:35 -0400

Scott, Peter,

One way to provide such a coordination would be to nominate one BS in an 
area as the master BS that would query the DB for itself and on behalf of 
the other 'slave' BSs.  Coordination could then be done locally by the 
master BS by sending a filtered version of the available channels list as 
received from the DB to the appropriate slave BS.

Unfortunately,it is still not clear whether the regulations in the various 
countries will allow such 'proxying' of TVBD's by other TVBD's and that 
this will not pose security problems.  If it is allowed everywhere and 
appropriate security can be achieved, then such coordination could be 
transparent to the DB since it would take place at the master BS without 
the DB having to know about it.  It would only know that a BS is asking for 
the channels availability on behalf of other BSs.

Gerald

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 17:13:30 +0000

Hi, Gerald,

I think what Scott is asking about is coordination in access to
the channel after it has been cleared for use by the WSDB.

It seems like you are asking about how to coordinate the assignment
of the channel among all the different BS.  I agree that one BS
could act as the "master", collecting information from the peer
BSs and presenting it all to the WSDB in a query for a vacant
channel.  Isn't this the same as the existing WRAN use case in
Section 4.3?  Or is there some difference due to the fact that
all the BSs are "Master" devices?

-Pete

Gerald Chouinard wrote:
> Scott, Peter,
> 
> One way to provide such a coordination would be to nominate one BS in
> an area as the master BS that would query the DB for itself and on
> behalf of the other 'slave' BSs.  Coordination could then be done
> locally by the master BS by sending a filtered version of the
> available channels list as received from the DB to the appropriate slave BS.
> 
> Unfortunately,it is still not clear whether the regulations in the
> various countries will allow such 'proxying' of TVBD's by other TVBD's
> and that this will not pose security problems.  If it is allowed
> everywhere and appropriate security can be achieved, then such
> coordination could be transparent to the DB since it would take place
> at the master BS without the DB having to know about it.  It would
> only know that a BS is asking for the channels availability on behalf
> of other BSs.
> 
> Gerald
> 
> 
>> There is no coordination aspect to TDD is there? I added TDD
>> initially to indicate that a single channel is used for operation,
>> contrasted to the 2 channel requirement for FDD.
>> 
>>>> allow multiple Master devices to knowingly select the same channel
>>>> for operation. (The discussion of "why" and "is it a good idea" not
>>>>> information from all the other BSs and then coordinate the
>>>>> assignment similar to the use case in 4.2; the difference would be
>>>>> that the resulting assignment is for simultaneous (not TDD) use by
>>>>> all of the BSs covering the wider area.
>>>>>

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 14 Sep 2011 13:19:44 -0400

Peter,

I guess you are referring to TDM (time-division multiplex) in your email
and not TDD (time-division duplex).  TDD refers to
bidirectional communications using the same channel in both
directions.  A unidirectional communication such as a broadcast
application is, by definition, not TDD.  However, if there are
multiple BSs that use the same channel, they can be using TDM to share
the channel or, if the information content is the same, they can even use
the same channel simultaneously under certain conditions to take
advantage of the redundancy in transmission signals.  The conditions
are that these transmissions need to be tightly synchronized in frequency
and  relatively closely synchronized in time so that, for
single-carrier modulation, the receivers can recover the signal after
proper echo equalization, and for multi-carrier modulation such as OFDM,
all the echoes created by these similar transmissions fall within the
guard interval (i.e., cyclic prefix) to avoid inter-symbol
interference.

Gerald

At 16:13 14-09-11 +0000, Peter McCann wrote:

TDD is a turn-taking mechanism for
sharing the spectrum.  I would

when.

-Pete

> There is no coordination aspect to TDD is there? I added TDD
initially

>>> On 9/13/11 12:37 PM, "ext Peter McCann"
<[email-masked]>

>>>> problem is to find a common bit of spectrum that is
available over a

>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor),
Bridgewater, NJ

>>>> 08807-2863 USA

paws mailing list

[email-masked]

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 17:22:33 +0000

Pete,

If multiple BS' co-ordinate among themselves (master-slave relationship)
and only the master BS sends the query, then that use-case is beyond the
scope of the PAWS charter.
The protocol that is being specified is the one between this master-BS (or
master WS device) and the database.
If a network has multiple BS' and there exists co-ordination between them,
with only one of the BS' having the authority to query the database that¹s
fine. Because it is invisible to the protocol that we are defining in
PAWS. 

-Raj

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 14 Sep 2011 13:30:20 -0400

Peter,

Yes, it is very similar to what we are trying to do in the WRAN use case 
where the BS would collect the geolocation information from all its CPEs 
and query the DB on their behalf.  The list of available channels for each 
CPE would then be collated by the BS and the decision as to what channel 
would be used by the WRAN cell would be made at the BS and transmitted to 
its CPEs.  No need to forward the list of available channels to the CPEs 
since they are slave to the BS and are bound to operate on the same channel 
to be part of the network.

The unknown is still whether this 'proxying' of DB request on behalf of the 
CPEs is acceptable to the regulators. I still have not been able to satisfy 
myself with the wording that exists in the FCC Part 15.700.  This will need 
to be clarified for this application as well as what I was proposing for 
the multiple BS case that need to coordinate the channel usage.  In this 
latter case, the master BS may need to forward the list of available 
channels to the appropriate BS in case they want to move to a different 
channel which is not the case for a WRAN cell.

Gerald

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 14 Sep 2011 13:32:50 -0400

I agree with Raj.

Gerald

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 17:41:24 +0000

Hi, Gerald,

Even in TDD there must at least be an agreement on which side
is allowed to transmit during which half of the frame interval.
That's the coordination to which I was referring.  And in a
point-to-multipoint system like TDD-LTE, you need to schedule
the uplink users in the time and frequency domain (resource blocks).
So I think the phrase "TDD radio technology or other means to 
coordinate use of the selected spectrum" would be appropriate
wording.

-Pete

Gerald Chouinard wrote:
> Peter,
> 
> I guess you are referring to TDM (time-division multiplex) in your
> email and not TDD (time-division duplex).  TDD refers to bidirectional
> communications using the same channel in both directions.  A
> unidirectional communication such as a broadcast application is, by
> definition, not TDD.  However, if there are multiple BSs that use the
> same channel, they can be using TDM to share the channel or, if the
> information content is the same, they can even use the same channel
> simultaneously under certain conditions to take advantage of the
> redundancy in transmission signals.  The conditions are that these
> transmissions need to be tightly synchronized in frequency and
> relatively closely synchronized in time so that, for single-carrier
> modulation, the receivers can recover the signal after proper echo
> equalization, and for multi-carrier modulation such as OFDM, all the
> echoes created by these similar transmissions fall within the guard
> interval (i.e., cyclic prefix) to avoid inter-symbol interference.
> 
> Gerald
> 
> 
> 	TDD is a turn-taking mechanism for sharing the spectrum.  I would 	call
> that a form of coordination between the various transmitters. 	Someone
> needs to publish a schedule of who is allowed to transmit 	when.
>

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 17:30:08 +0000

Hi, Raj,

I think my use case is covered by Section 4.3 with a small change
along the lines that Scott suggested.  Note there is this text
in step 8:

   8.  The slave or user device scans the TV bands to locate a WRAN
       transmission, and associates with the master/BS.  The slave/user
       device provides its geolocation to the BS which, in turn, queries
       the database for a list of channels available at the slaves'
       geolocation.

What I am suggesting is no different except for the fact that each
of the devices could have independent Internet access and be capable
of querying the database itself.  There could be one BS that handles
all the queries or the individual BSs could query themselves (each for
their own location) and they could compare notes to find a common
free channel.

As for the protocol between the BS and the WSDB, we may want to have
a requirement that the protocol carry multiple location elements (instead
of just one) so that we save the cost of multiple queries across the
Internet.  The WSDB, after doing the polygon intersection test at
each location, could additionally do a set intersection test on the
remaining free channels and return the results.  That's one concrete
way that this use case may impact the protocol specification.

-Pete

[email-masked] wrote:
> 
> Pete,
> 
> If multiple BS' co-ordinate among themselves (master-slave
> relationship) and only the master BS sends the query, then that use-
> case is beyond the scope of the PAWS charter.
> The protocol that is being specified is the one between this master-BS
> (or master WS device) and the database.
> If a network has multiple BS' and there exists co-ordination between
> them, with only one of the BS' having the authority to query the
> database that¹s fine. Because it is invisible to the protocol that we
> are defining in PAWS.
> 
> -Raj
> 
>> I think what Scott is asking about is coordination in access to the
>> channel after it has been cleared for use by the WSDB.
>> 
>> of the channel among all the different BS.  I agree that one BS could
>> act as the "master", collecting information from the peer BSs and
>> presenting it all to the WSDB in a query for a vacant channel.  Isn't
>> this the same as the existing WRAN use case in Section 4.3?  Or is
>> there some difference due to the fact that all the BSs are "Master"
>> devices?
>> 
>> -Pete
>> 
>> Gerald Chouinard wrote:
>>> Scott, Peter,
>>> 
>>> various countries will allow such 'proxying' of TVBD's by other
>>> TVBD's and that this will not pose security problems.  If it is
>>> allowed everywhere and appropriate security can be achieved, then
>>> such coordination could be transparent to the DB since it would
>>> take place at the master BS without the DB having to know about it.
>>> It would only know that a BS is asking for the channels
>>> availability on behalf of other BSs.
>>> 
>>> Gerald
>>> 
>>> 
>>>>>> case. When I look at this case, the question is: can PAWS be used
>>>>>> to allow multiple Master devices to knowingly select the same
>>>>>> channel for operation. (The discussion of "why" and "is it a good
>>>>>> idea" not undertaken here as this likely wanders outside the scope
>>>>>> of PAWS).
>>>>>> 
>>>>>> One of the proposed solutions is coordination among BSs
>>>>>> (external to PAWS). This is already described in section 4.3
>>>>>> Wide-Area or Rural internet broadband access:
>>>>>> 
>>>>>>> Some of the masters/BSs may be deployed and operated by a
>>>>>>> single entity, i.e. there can be centralized coordination
>>>>>>> between these masters/BSs,...
>>>>>> 
>>>>> The BS in this scenario typically use a TDD radio technology or
>>>>> other means to coordinate use of the selected spectrum.
>>>>> 
>>>>> -Pete
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> Scott
>>>>>> 
>>>>>> 
>>>>>>> case, and I think it would be a possible candidate for
>>>>>>> assignment. Alternatively, you might be able to elect one BS as
>>>>>>> the leader and collect location information from all the other BSs
>>>>>>> and then coordinate the assignment similar to the use case in 4.2;
>>>>>>> the difference would be that the resulting assignment is for

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 18:21:16 +0000

Hi All,

My comment was about the wording of the Wide-Area or Rural internet

Maybe we could say:

Specifically I don't see how TDD coordinates use of the spectrum; it
simply is one method of duplexing which allows use of single radio
frequency for bi-directional communication. The white space paradigm only
affords protection to the licensed primary user, no protection to any
licensed-exempt secondary user, i.e. use of the spectrum is not
coordinated (other than the database indicating which channels are
available for secondary use). Thus I suggest to strike "or other means to
coordinate use of the selected spectrum" from Pete's proposal.

Regarding the scenarios of coordination, PAWS is a protocol to transport
information. It should support Regulatory requirements globally, including
those from the FCC but not limited to the FCC requirements. I believe this
also means we  need to be open-minded and forward-thinking since other
Regulatory groups are actively reviewing white space paradigms, and their
requirements are yet to be seen.

Regards,
Scott

On 9/14/11 12:32 PM, "ext Gerald Chouinard" <[email-masked]>
wrote:

>>them,
>>TVBD's
>>to
>>other
>>reporting
>>can

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 18:23:18 +0000

Hi Pete,

Allowing PAWS to carry information back to the database as in 4.2 & 4.3 is
just a transport. We don't have to think about what the database does with
that. While FCC may not have regulations today which require this type of
transport, IMHO it is premature to assume that no regulator in the world
will have such need.

Similarly for location-based service use case, the only issue from PAWS
perspective is some message which allows a query of the database, based on
master identity. In addition to the location based service use case
already included in the I-D, another example is identification of a Master
who is causing interference. FCC does envision something very similar,
though not precisely same, to this scenario for determination of
interference.

Thus I believe these use cases are useful and reasonable.

Regards,
Scott

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 19:11:45 +0000

Hi, Scott,

I'm not proposing that the database provide the coordination or
protection for the secondary users.  I am just saying that there
could be some protocol, completely outside the scope of PAWS, by
which the multiple devices schedule their use of the selected 
spectrum.  This seems like an obvious requirement for a master
device that serves a collection of slave devices.  Similarly,
when all the BSs want to simulcast, there needs to be a protocol
that provides synchronization.

The text right now uses TDD as an example spectrum access protocol.
I am just saying we should generalize and allow for other means of
deciding who transmits what when.

-Pete

[email-masked] wrote:
> frequency for bi-directional communication. The white space paradigm
> only affords protection to the licensed primary user, no protection to
> any licensed-exempt secondary user, i.e. use of the spectrum is not
> available for secondary use). Thus I suggest to strike "or other means
> to coordinate use of the selected spectrum" from Pete's proposal.
> 
> Regarding the scenarios of coordination, PAWS is a protocol to
> transport information. It should support Regulatory requirements
> globally, including those from the FCC but not limited to the FCC
> requirements. I believe this also means we  need to be open-minded and
> forward-thinking since other Regulatory groups are actively reviewing
> white space paradigms, and their requirements are yet to be seen.
> 
> Regards,
> Scott
> 
> 
> 
>>> relationship) and only the master BS sends the query, then that
>>> use-case is beyond the scope of the PAWS charter. The protocol that is
>>> being specified is the one between this master- BS (or master WS
>>> device) and the database. If a network has multiple BS' and there
>>> exists co-ordination between them, with only one of the BS' having the
>>> authority to query the database that¹s fine. Because it is invisible
>>> to the protocol that we are defining in PAWS.
>>> 
>>> -Raj
>>> 
>>>> It seems like you are asking about how to coordinate the
>>>> assignment of the channel among all the different BS.  I agree
>>>> that one BS could act as the "master", collecting information from
>>>> the peer BSs and presenting it all to the WSDB in a query for a vacant channel.
>>>> Isn't this the same as the existing WRAN use case in Section 4.3?
>>>> Or is there some difference due to the fact that all the BSs are
>>>> "Master" devices?
>>>> 
>>>> -Pete
>>>> 
>>>> Gerald Chouinard wrote:
>>>>> Scott, Peter,
>>>>> 
>>>>> One way to provide such a coordination would be to nominate one BS
>>>>> in  an area as the master BS that would query the DB for itself and
>>>>> on  behalf of the other 'slave' BSs.  Coordination could then be
>>>>> done  locally by the master BS by sending a filtered version of the
>>>>> such coordination could be transparent to the DB since it would take
>>>>> place at the master BS without the DB having to know about it. It
>>>>> would only know that a BS is asking for the channels availability on
>>>>> behalf of other BSs.
>>>>> 
>>>>> Gerald
>>>>> 
>>>>> 
>>>>>> initially to indicate that a single channel is used for
>>>>>> operation, contrasted to the 2 channel requirement for FDD.
>>>>>> 
>>>>>> I believe the use case under discussion is using the channel for
>>>>>> full DL broadcast. It's not so much as coordination, just 100% DL.
>>>>>> Right?
>>>>>> 
>>>>>> Would help me if you could clarify what spectrum coordination
>>>>>> is happening in this case.
>>>>>> 
>>>>>> Regards,
>>>>>> Scott
>>>>>> 
>>>>>> 
>>>>>>>> Thank you Peter & Lei for the more detailed description of the
>>>>>>>> use case. When I look at this case, the question is: can PAWS be
>>>>>>>> used to allow multiple Master devices to knowingly select the
>>>>>>>> same channel for operation. (The discussion of "why" and "is it a
> good idea"
>>> not
>>>>>>>>> which would independently query the WSDB for available spectrum.
>>>>>>>>>  However, they need to coordinate the assignment so that they
>>>>>>>>> all get the same spectrum over the whole area. As an
>>>>>>>>> reporting the same owner/operator and using a key or index value
>>>>>>>>> to indicate that they wanted to coordinate the assignment.
>>>>>>>>> Alternatively, you might be able to elect one BS as the leader
>>>>>>>>> and collect location information from all the other BSs and then
>>>>>>>>> coordinate the assignment similar to the use case in 4.2; the

---

From: Paul Lambert <[email-masked]>
Date: Wed, 14 Sep 2011 12:11:20 -0700

Tracking changes in a devices usage of spectrum is a very different requirement than giving authority to use specific spectrum.

The devices will change bands and there is no requirement to have the database know every aspect of a device operation (current band, modulation, power etc.).

Coordination is a very different function that 'authorization' They happen to use similar data items - but we should not overload the protocol.  This coexistence would be an intereting task group of it's own.

Paul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, September 14, 2011 7:56 AM
To: Gerald Chouinard
Cc: [email-masked]; Peter McCann
Subject: Re: [paws] Possible new use case: simulcasting

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 19:05:41 +0000

Hi, Scott,

The text says "the database is updated."  That wording is at least
confusing.  It also says "the database replies with the location of
the master device".  Both of these imply that some state on a per-master
basis is being kept in the database.

We need to get clarity within the working group whether the database
can keep state about the devices that query it or whether it is designed
to be a completely passive repository of information.

-Pete

[email-masked] wrote:
> Hi Pete,
> 
> Allowing PAWS to carry information back to the database as in 4.2 &
> 4.3 is just a transport. We don't have to think about what the
> database does with that. While FCC may not have regulations today
> which require this type of transport, IMHO it is premature to assume
> that no regulator in the world will have such need.
> 
> Similarly for location-based service use case, the only issue from
> PAWS perspective is some message which allows a query of the database,
> based on master identity. In addition to the location based service
> use case already included in the I-D, another example is
> identification of a Master who is causing interference. FCC does
> envision something very similar, though not precisely same, to this
> scenario for determination of interference.
> 
>> There is also the location-based service use case where the database is
>> keeping state about the whitespace master device, namely its location:
>> 
>>>> Agreed.  A single transaction, to the DB and back to the TVBD, would
>>>> be sufficient if the protocol is to be kept simple. Coexistence
>>>> amongst the license-exempt devices would then be left to other
>>>> processes such as the one being developed by the IEEE 802.19.1.
>>>> 
>>>> Gerald
>>>> 
>>>> 
>>>>>> database which channel it decided to operate on and it would
>>>>>> provide easy extensibility to the protocol for an eventual
>>>>>> consideration of the coexistence amongst the license-exempt devices.
>>>>>> 
>>>>>>> So do these use cases in the accepted working group document need
>>>>>>> to be modified, then?
>>>>>>> 
>>>>>>> -Pete
>>>>>>> 
>>>>>>> Rosen, Brian wrote:
>>>>>>>>> BS registering the spectrum that it selected for its use. If
>>>>>>>>> the database is keeping state in this manner, it could easily
>>>>>>>>>> If two queriers with the same location and input parameters
>>>>>>>>>> query the database, they will get the same response.   Suppose
>>>>>>>>>> two U.S. Mode I devices at essentially the same location
>>>>>>>>>> (within 25 meters) query the database, and the first is told he
>>>>>>>>>> may use TV channels 1-5, 9-11 and 25-33.  The second one will
>>>>>>>>>> be told the same thing.
>>>>>>>>>> 
>>>>>>>>>>> database is keeping state even for the secondary users.
>>>>>>>>>>> That is, it is acting as a de-facto registry for users of
>>>>>>>>>>> the secondary spectrum and will refuse to allocate the same
>>>>>>>>>>> spectrum to different users in overlapping geographic
>>>>>>>>>>> regions. Am I
>>>>> mistaken in
>>>>>>> this assumption?
>>>>>>>>>>> 
>>>>>>>>>>> -Pete
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Joel M. Halpern wrote:
>>>>>>>>>>>> base station coordination is an interesting problem, but is
>>>>>>>>>>>> it within scope for this WG?  (I do not think just specifying
>>>>>>>>>>>> the same owner to the database will resolve the problem, and
>>>>>>>>>>>> it makes the database state MUCH more complex.)
>>>>>>>>>>>> 
>>>>>>>>>>>> Yours,
>>>>>>>>>>>> Joel
>>>>>>>>>>>> 
>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS
>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum that
>>>>>>>>>>>>> is available over a wide area that can be used by multiple
>>>>>>>>>>>>> master BSs to simultaneously broadcast the same signal to a
>>>>>>>>>>>>> set of receivers. This is somewhat similar to the wide- area
>>>>>>>>>>>>> rural coverage scenario currently described in the working
>>>>>>>>>>>>> group document; however, there would be multiple Master BSs,
>>>>>>>>>>>>> each of which would independently query the WSDB for
>>>>>>>>>>>>> available spectrum. However, they need to coordinate the
>>>>>>>>>>>>> assignment so that they all get the same spectrum over the
>>>>>>>>>>>>> whole area. As an implementation example, this could be
>>>>>>>>>>>>> achieved by each BS reporting the same owner/operator and
>>>>>>>>>>>>> using a key or index value to indicate that they wanted to
>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be able
>>>>>>>>>>>>> to elect one
>>> BS
>>>>> as the
>>>>>>>>>>>>> leader and collect location information from all the
>>>>>>>>>>>>> other BSs and then coordinate the assignment similar to
>>>>>>>>>>>>> the use case in 4.2; the difference would be that the
>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use by
>>>>>>>>>>>>> Does this sound like an interesting and novel use case?
>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII
>>>>>>>>>>>>> art for the draft.

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 19:51:46 +0000

Pete,

IMO we don't need to be concerned about whether the database is keeping
state.
Its upto the database. I agree that the text should not say anything about
what the database does if the Master WS device informs the database which
of the available channels were selected for use/operation.

There is no reason for the WS device to not send an acknowledgement back
to the database indicating which channels (from the list) are being used.

What the database does with this information is outside the scope of the
protocol itself.

-Raj

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 20:03:31 +0000

"no reason to not send" does not equal "reason to send."

-Pete

[email-masked] wrote:
> state. Its upto the database. I agree that the text should not say
> anything about what the database does if the Master WS device informs
> the database which of the available channels were selected for
> use/operation.
> 
> There is no reason for the WS device to not send an acknowledgement
> back to the database indicating which channels (from the list) are
> being used.
> 
> What the database does with this information is outside the scope of
> the protocol itself.
> 
> -Raj
> 
>> confusing.  It also says "the database replies with the location of the
>> master device".  Both of these imply that some state on a per-master
>> can keep state about the devices that query it or whether it is
>> designed to be a completely passive repository of information.
>> 
>> -Pete
>> 
>> 
>>> which require this type of transport, IMHO it is premature to
>>> assume that no regulator in the world will have such need.
>>> 
>>>>> One of the key aspects of this protocol between device and database
>>>>> is extensibility. The charter does recognize that the contents of
>>>>> the database is defined external to PAWS. Thus hard to say that any
>>>>> single specific value or information element is beyond the scope.
>>>>> 
>>>>> So IMHO the use cases already approved are still valid, no
>>>>> reasons to exclude pieces.
>>>>> 
>>>>> Regards,
>>>>> Scott
>>>>> 
>>>>> 
>>>>> 
>>>>>> Agreed.  A single transaction, to the DB and back to the TVBD,
>>>>>> would be sufficient if the protocol is to be kept simple.
>>>>>> Coexistence amongst the license-exempt devices would then be left
>>>>>> to other processes such as the one being developed by the IEEE
>>>>>> 802.19.1.
>>>>>> 
>>>>>> Gerald
>>>>>> 
>>>>>> 
>>>>>>> The problem is that this turns the transaction into multiple
>>>>>>> steps. As it is now, you send a query and get a response.
>>>>>>> 
>>>>>>>> My suggestion would be to leave this feature in.  It will not
>>>>>>>> cost  much to make room in the protocol for the TVBD to indicate
>>>>>>>> to the  database which channel it decided to operate on and it
>>>>>>>> would  provide easy extensibility to the protocol for an eventual
>>>>>>>>>>> least his location.  Step 7 of the Hotspot use case has the BS
>>>>>>>>>>>> (within 25 meters) query the database, and the first is told
>>>>>>>>>>>> he may use TV channels 1-5, 9-11 and 25-33.  The second one
>>>>>>>>>>>> will be told the same thing.
>>>>>>>>>>>> 
>>>>>>>>>>>>> database is keeping state even for the secondary users. That
>>>>>>>>>>>>> is, it is acting as a de-facto registry for users of the
>>>>>>>>>>>>> secondary spectrum and will refuse to allocate the same
>>>>>>>>>>>>>> I may be missing something, but it seems to me taht what
>>>>>>>>>>>>>> you are describing is not the job of the database query
>>>>>>>>>>>>>> protocol. base station coordination is an interesting
>>>>>>>>>>>>>> problem, but is it within scope for this WG?  (I do not
>>>>>>>>>>>>>> think just specifying the same owner to the database will
>>>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his
>>>>>>>>>>>>>>> third use case, and I think it would be a possible
>>>>>>>>>>>>>>> candidate for inclusion in the document if it were
>>>>>>>>>>>>>>> properly explained.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum
>>>>>>>>>>>>>>> that is available over a wide area that can be used by
>>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the same
>>>>>>>>>>>>>>> signal to a set of receivers. This is somewhat similar to
>>>>>>>>>>>>>>> the wide- area rural coverage scenario currently described
>>>>>>>>>>>>>>> in the working group document; however, there would be
>>>>>>>>>>>>>>> multiple Master BSs, each of which would independently
>>>>>>>>>>>>>>> query the WSDB for available spectrum. However, they need
>>>>>>>>>>>>>>> to coordinate the assignment so that they all get the same
>>>>>>>>>>>>>>> spectrum over the whole area. As an implementation
>>>>>>>>>>>>>>> example, this could be achieved by each BS reporting the
>>>>>>>>>>>>>>> same owner/operator and using a key or index value to
>>>>>>>>>>>>>>> indicate that they wanted to coordinate the assignment.
>>>>>>>>>>>>>>> Alternatively, you might be able to elect one
>>>>> BS
>>>>>>> as the
>>>>>>>>>>>>>>> leader and collect location information from all the other
>>>>>>>>>>>>>>> BSs and then coordinate the assignment similar to the use
>>>>>>>>>>>>>>> case in 4.2; the difference would be that the resulting
>>>>>>>>>>>>>>> assignment is for simultaneous (not TDD) use by all of the

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 20:07:52 +0000

Agree. 
Reason to send is from the perspective that such information may help in
future extensions or enhancements that would enable interference
mitigation (as an example) or other purposes.

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 20:10:45 +0000

Any such requirement has been ruled out of scope by the chair.

-Pete

[email-masked] wrote:
> 
> Agree.
> Reason to send is from the perspective that such information may help
> in future extensions or enhancements that would enable interference
>>> IMO we don't need to be concerned about whether the database is
>>> keeping state. Its upto the database. I agree that the text should not
>>> say anything about what the database does if the Master WS device
>>> informs the database which of the available channels were selected for
>>> use/operation.
>>> 
>>> What the database does with this information is outside the scope
>>> of the protocol itself.
>>> 
>>> -Raj
>>> 
>>>> confusing.  It also says "the database replies with the location
>>>> of the master device".  Both of these imply that some state on a
>>>> per-master basis is being kept in the database.
>>>> 
>>>>> PAWS perspective is some message which allows a query of the
>>>>> database, based on master identity. In addition to the location
>>>>> based service use case already included in the I-D, another example
>>>>> is identification of a Master who is causing interference. FCC does
>>>>>>       WS channels it has selected for its operation.  The database
>>>>>>       is updated with the information provided by the master/AP.
>>>>>> by the whitespace master devices.  When it says "database is
>>>>>> updated" that makes me think that the database of exclusion zones
>>>>>> is updated in a way that will impact the results of future queries.
>>>>>> 
>>>>>> There is also the location-based service use case where the
>>>>>> database is keeping state about the whitespace master device,
>>>>>> namely its
>>>>>> location:
>>>>>> 
>>>>>>   4.  The trusted white space database replies to the server
>>>>>> with
>>> the
>>>>>> If the database is to be truly stateless and passive with respect
>>>>>> to queries by whitespace devices, these kinds of statements should
>>>>>> be removed from the use cases.
>>>>>> 
>>>>>> -Pete
>>>>>> 
>>>>>> 
>>>>>>> One of the key aspects of this protocol between device and
>>>>>>> database is extensibility. The charter does recognize that the
>>>>>>> contents of the database is defined external to PAWS. Thus hard to
>>>>>>> say that any single specific value or information element is
>>>>>>> beyond the scope.
>>>>>>> 
>>>>>>>> Coexistence amongst the license-exempt devices would then be
>>>>>>>> left to other processes such as the one being developed by the
>>>>>>>> IEEE 802.19.1.
>>>>>>>> 
>>>>>>>> Gerald
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> My suggestion would be to leave this feature in.  It will
>>>>>>>>>> not cost  much to make room in the protocol for the TVBD to
>>>>>>>>>> indicate to the  database which channel it decided to
>>>>>>>>>> operate on and it would  provide easy extensibility to the
>>>>>>>>>> protocol for an eventual consideration of the coexistence
>>>>>>>>>> amongst the license-exempt devices.
>>>>>>>>>> 
>>>>>>>>>> I would agree, however, that the current step of the
>>>>>>>>>> protocol development should be limited to protecting of the
>>>>>>>>>> broadcast incumbents as stated in the scope.
>>>>>>>>>> 
>>>>>>>>>> Gerald
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> So do these use cases in the accepted working group
>>>>>>>>>>> document need to be modified, then?
>>>>>>>>>>> 
>>>>>>>>>>> -Pete
>>>>>>>>>>> 
>>>>>>>>>>> Rosen, Brian wrote:
>>>>>>>>>>>>> However, the location-based services use case clearly has
>>>>>>>>>>>>> the white space database keeping state on the secondary
>>>>>>>>>>>>> user, at least his location.  Step 7 of the Hotspot use case
>>>>>>>>>>>>> has the BS registering the spectrum that it selected for its
>>>>>>>>>>>>> use. If the database is keeping state in this manner, it
>>>>>>>>>>>>> could easily calculate the exclusion zones for the secondary
>>>>>>>>>>>>> users as well.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> query the database, they will get the same response.
>>>>>>>>>>>>>> Suppose two U.S. Mode I devices at essentially the same
>>>>>>>>>>>>>> location (within 25 meters) query the database, and the
>>>>>>>>>>>>>> first is told he may use TV channels 1-5, 9-11 and 25-33. 
>>>>>>>>>>>>>> The second one will be told the same thing.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> device actually chooses to use, when it starts using it,
>>>>>>>>>>>>>> and when it ceases to use it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Based on some of the existing use cases, it looks like
>>>>>>>>>>>>>>> the database is keeping state even for the secondary
>>>>>>>>>>>>>>> users. That is, it is acting as a de-facto registry for
>>>>>>>>>>>>>>> users of the secondary spectrum and will refuse to
>>>>>>>>>>>>>>> allocate the same spectrum to different users in
>>>>>>>>>>>>>>> overlapping geographic regions. Am I
>>>>>>>>> mistaken in
>>>>>>>>>>> this assumption?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Pete
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Joel M. Halpern wrote:
>>>>>>>>>>>>>>>>> signal to a set of receivers. This is somewhat similar
>>>>>>>>>>>>>>>>> to the wide- area rural coverage scenario currently
>>>>>>>>>>>>>>>>> described in the working group document; however, there
>>>>>>>>>>>>>>>>> would be multiple Master BSs, each of which would
>>>>>>>>>>>>>>>>> independently query the WSDB for available spectrum.
>>>>>>>>>>>>>>>>> However, they need to coordinate the assignment so that
>>>>>>>>>>>>>>>>> they all get the same spectrum over the whole area. As
>>>>>>>>>>>>>>>>> an implementation example, this could be achieved by
>>>>>>>>>>>>>>>>> each BS reporting the same owner/operator and using a
>>>>>>>>>>>>>>>>> key or index value to indicate that they wanted to
>>>>>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be
>>>>>>>>>>>>>>>>> able to elect one
>>>>>>> BS
>>>>>>>>> as the
>>>>>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use
>>>>>>>>>>>>>>>>> by all of the BSs covering the wider area.
>>>>>>>>>>>>>>>>>

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 20:17:41 +0000

True. And I am in sync with that.
However during the formation of this WG there has been discussion that the
WG could consider expanding the scope once the initial objective has been
met. 
Consequently we could simply focus on the request/response protocol for
now and extend it at a later date if the charter were to be revised and
the scope expanded.

However can we foresee a requirement by some regulatory entity that would
mandate the database being informed about the channels being used by a WS
device? Do we want such flexibility to be incorporated into the protocol
knowing that the regulatory domain w.r.t this technology is still in its
infancy?

-Raj

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 20:21:27 +0000

So what are the criteria for determining what can go into the use
cases document?  You seem to think we are not limited by the scope
of the current charter.

-Pete

[email-masked] wrote:
> However during the formation of this WG there has been discussion that
> the WG could consider expanding the scope once the initial objective
> has been met.
> Consequently we could simply focus on the request/response protocol
> for now and extend it at a later date if the charter were to be
> revised and the scope expanded.
> 
> However can we foresee a requirement by some regulatory entity that
> would mandate the database being informed about the channels being
> used by a WS device? Do we want such flexibility to be incorporated
> into the protocol knowing that the regulatory domain w.r.t this
> technology is still in its infancy?
> 
> -Raj
> 
> 
>>> Agree. Reason to send is from the perspective that such information
>>> may help in future extensions or enhancements that would enable
>>> interference mitigation (as an example) or other purposes.
>>> 
>>>>> keeping state. Its upto the database. I agree that the text
>>>>> should not say anything about what the database does if the
>>>>> Master WS device informs the database which of the available
>>>>> channels were selected for use/operation.
>>>>> 
>>>>>> the master device".  Both of these imply that some state on a
>>>>>> We need to get clarity within the working group whether the
>>>>>> database can keep state about the devices that query it or whether
>>>>>> it is designed to be a completely passive repository of information.
>>>>>> 
>>>>>> -Pete
>>>>>> 
>>>>>> 
>>>>>>> Allowing PAWS to carry information back to the database as in 4.2
>>>>>>> & 4.3 is just a transport. We don't have to think about what the
>>>>>>> based service use case already included in the I-D, another
>>>>>>> example is identification of a Master who is causing interference.
>>>>>>> FCC does envision something very similar, though not precisely
>>>>>>> same, to this scenario for determination of interference.
>>>>>>> 
>>>>>>>>       WS channels it has selected for its operation.  The
>>>>>>>>       database is updated with the information provided by the
> master/AP.
>>>>>>>> it makes me think that the database is tracking the use of
>>>>>>>> spectrum by the whitespace master devices.  When it says
>>>>>>>> "database is updated" that makes me think that the database of
>>>>>>>> exclusion zones is updated in a way that will impact the results
>>>>>>>> of future queries.
>>>>>>>> 
>>>>>>>> If the database is to be truly stateless and passive with
>>>>>>>> respect to queries by whitespace devices, these kinds of
>>>>>>>> statements should be removed from the use cases.
>>>>>>>> 
>>>>>>>> -Pete
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> contents of the database is defined external to PAWS. Thus hard
>>>>>>>>> to say that any single specific value or information element is
>>>>>>>>> beyond the scope.
>>>>>>>>> 
>>>>>>>>> Also the charter allows for queries and responses, there is
>>>>>>>>> no restriction that single transactions are mandated.
>>>>>>>>> 
>>>>>>>>>>> The problem is that this turns the transaction into
>>>>>>>>>>> multiple steps. As it is now, you send a query and get a response.
>>>>>>>>>>> 
>>>>>>>>>>> If the device needs to update with what it used, that's
>>>>>>>>>>> another step. Also, what happens if it changes its mind?
>>>>>>>>>>> 
>>>>>>>>>>> Brian
>>>>>>>>>>> 
>>>>>>>>>>>> not cost  much to make room in the protocol for the TVBD
>>>>>>>>>>>> to indicate to the  database which channel it decided to
>>>>>>>>>>>> protocol development should be limited to protecting of
>>>>>>>>>>>> the broadcast incumbents as stated in the scope.
>>>>>>>>>>>> 
>>>>>>>>>>>> Gerald
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>>> It's beyond the charter.  This was discussed when we
>>>>>>>>>>>>>> created  the charter, and explicitly excluded it for this
>>>>>>>>>>>>>> initial work.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> user, at least his location.  Step 7 of the Hotspot use
>>>>>>>>>>>>>>> case has the BS registering the spectrum that it selected
>>>>>>>>>>>>>>> for its use. If the database is keeping state in this
>>>>>>>>>>>>>>> manner, it could easily calculate the exclusion zones for
>>>>>>>>>>>>>>> the secondary users as well.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> If two queriers with the same location and input
>>>>>>>>>>>>>>>> parameters query the database, they will get the same
>>>>>>>>>>>>>>>> response. Suppose two U.S. Mode I devices at essentially
>>>>>>>>>>>>>>>> the same location (within 25 meters) query the database,
>>>>>>>>>>>>>>>> and the first is told he may use TV channels 1-5, 9-11
>>>>>>>>>>>>>>>> and 25- 33. The second one will be told the same thing.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> The database knows query patterns, but does not track
>>>>>>>>>>>>>>>> use. Specifically, it doesn't know what part of the
>>>>>>>>>>>>>>>> spectrum the device actually chooses to use, when it
>>>>>>>>>>>>>>>> starts using it, and when it ceases to use it.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I may be missing something, but it seems to me taht
>>>>>>>>>>>>>>>>>> what you are describing is not the job of the database
>>>>>>>>>>>>>>>>>> query protocol. base station coordination is an
>>>>>>>>>>>>>>>>>> interesting problem, but is it within scope for this
>>>>>>>>>>>>>>>>>> WG?  (I do not think just specifying the same owner to
>>>>>>>>>>>>>>>>>> the database will resolve the problem, and it makes the
>>>>>>>>>>>>>>>>>> database state MUCH more complex.)
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Yours,
>>>>>>>>>>>>>>>>>> Joel
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the
>>>>>>>>>>>>>>>>>>> same signal to a set of receivers. This is somewhat
>>>>>>>>>>>>>>>>>>> similar to the wide- area rural coverage scenario
>>>>>>>>>>>>>>>>>>> currently described in the working group document;
>>>>>>>>>>>>>>>>>>> however, there would be multiple Master BSs, each of
>>>>>>>>>>>>>>>>>>> spectrum. However, they need to coordinate the
>>>>>>>>>>>>>>>>>>> assignment so that they all get the same spectrum over
>>>>>>>>>>>>>>>>>>> the whole area. As an implementation example, this
>>>>>>>>>>>>>>>>>>> could be achieved by each BS reporting the same
>>>>>>>>>>>>>>>>>>> owner/operator and using a key or index value to
>>>>>>>>>>>>>>>>>>> indicate that they wanted to coordinate the
>>>>>>>>>>>>>>>>>>> leader and collect location information from all
>>>>>>>>>>>>>>>>>>> the other BSs and then coordinate the assignment
>>>>>>>>>>>>>>>>>>> similar to the use case in 4.2; the difference
>>>>>>>>>>>>>>>>>>> would be that the resulting assignment is for
>>>>>>>>>>>>>>>>>>> simultaneous (not
>>>>>>>>>>>>>>>>>>> TDD) use by all of the BSs covering the wider area.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Does this sound like an interesting and novel use
>>>>>>>>>>>>>>>>>>> case? If so I can do a more detailed writeup and
>>>>>>>>>>>>>>>>>>> supply ASCII art for the draft.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 14 Sep 2011 13:19:50 -0700

Raj,
> back to the database indicating which channels (from the list) are 

I disagree.  There are many reasons to not send the selected channel(s)
back to the database:
1) it's an extra unnecessary message
2) it's not useful unless any updates in usage are also sent
   the devices are likely to change channels, modulation, etc dynamically
   within the allowed parameters
3) the entity getting this coordination information is not
   necessarily the same as the database.  Local spectrum coordination
   is a different function than regulatory spectrum access.
   If we want coordination - we should do it right
4) the usage of such fields are out-of-scope, so why include them
   If there is no supporting text on usage.

Paul
> designed
> database,
> is
> updated"
> database is
> database is
> would
> steps.
> cost
> Suppose
> you
> third
> that
> able

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2011 14:23:30 -0600

> Any such requirement has been ruled out of scope by the chair.

Hi, this is your Area Director. I'd like to clarify one point. It's not
that the chairs can rule things in and out of scope on a whim. Their
decisions need to be based on the charter, which is the fundamental
contract between this working group and the broader IETF community
(represented by the IESG). There was quite a bit of discussion within
the IETF and the IESG about this working group as it was being formed.
As a result of those discussions, the charter is rather narrowly scoped.
This is intentional. The focus of this working group should be on the
items defined in the charter. That doesn't mean working group
participants can't talk about other topics, but as your Area Director I
would like to see progress on the core deliverables before the group
starts to work on additional use cases, extensions, etc. Naturally, it
might be reasonable to design extension points into the protocol, so the
group might want to take additional use cases into account as examples
of where extension points might be needed, but those extensions
themselves should not not the focus at this time.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter McCann <[email-masked]>
Date: Wed, 14 Sep 2011 20:38:48 +0000

> themselves should not not the focus at this time.

When you say we "might want to take additional use cases into account"
does that mean we might want to include them in the current use cases
draft?  I am asking because I was told by some working group members
that a use case I proposed was outside the scope of the charter and
therefore should not be included in the use cases draft.

If we are going to exclude out-of-scope use cases in the working
group draft then there is a lot in there now that needs to be removed.

-Pete

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 20:44:46 +0000

Hi Paul,

Yes. It is an extra message. Is it unnecessary? That depends on your PoV.
Is it a significant overhead? I do not believe that would be the case
either.

Having said that I do agree that an UPDATE message will need to be
carefully designed.
This could be done at a later time as well and does not impede the current
design of the protocol.

So unless a requirement for such pops up, I am fine with not including
such functionality at this time.

-Raj

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2011 16:05:50 -0600

> group draft then there is a lot in there now that needs to be removed.

As your Area Director, I would rather see the current use cases and
requirements document focus on addressing the goals of the charter.

(Naturally, it would be appropriate for that document to explain why the
scope is so sharply limited at this time. You might be able to borrow
some wording from RFC 6125 on the topic of limited scope.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 15 Sep 2011 11:12:03 -0400

I have a number of comments on the use cases proposed in the draft.

First the location based service seems too specific to an advertising
model as opposed to a more generic case of an edge device (slave)
requesting the location information about a serving master device from the
DB. There may well be other reasons for the slave to request information
about the master. One instance I can think of is to determine who owns the
master (registration information) it may be that the slave only trusts
certain masters or has a cost basis to chose one available master over
Another.

Second. The whole concept is predicated on an ability to provide access to
spectrum into the future. I believe that much spectrum (owned by emergency
services, defense agencies and others) will not be made available without
an ability to withdraw the permission should a predefined emergency
situation emerge. There are several ways to address this requirement but I
think
a use case that considers such a scenario is required.

Third, Access to spectrum, as a licensed or unlicensed device, may require
payment. It seems highly likely that government agencies (spectrum
holders) will need to be
persuaded to make spectrum available. This may be in the form of the
Agency/holder getting some compensation for the use of the spectrum. This
would
require that use of the spectrum be tracked such that some backend billing
or clearing house system could deal with payments.

Fourth, The concept of mobility is not described. Mobility could be
addressed by providing a vector or an area to the DB which would result in
a set of available channels being delivered.

Finally there is no "White Space" only shades of grey. So I think it is
important to consider
that not all spectrum is equal and that the DB may have to provide some
weighting or other
Criteria to describe suitability of the available channels for use. Note
that this is unrelated
to any Co-existence criteria.
Regards,
Peter Stanforth

---

From: <[email-masked]>
Date: Thu, 22 Sep 2011 19:01:36 +0000

Hi Peter,

Good comments. Reviewing them one by one...

First. We will re-write the location based service use case to be a
generic "regulatory requirement" use case, focusing on the registration
information as you suggest.

Second. Ability to withdraw permission is essentially same as the "kill
switch" described by Ofcom in their "Implementing Geolocation" document.
We proposed to add this either as a separate use case or included it to an
existing use case.

Third. We generally agree with the principle and would like to include the
capability. Probably the question will be asked if this is in scope. We
would like to identify a regulator who has indicated a need or desire for
this.

Fourth. We will include a new use case for mobility, FCC has already
identified this as a valid use case.

Regards,
Scott & Raj

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 22 Sep 2011 18:59:36 -0400

Thanks Scott
Your suggestions sound good to me. The third suggestion came from
conversations we have had with government agencies, it is not part of any
current White Space regulation. The politicians and the bureaucrats both
suggested that the way that government spectrum would be made available on
a secondary basis (similar to white space) would be if the agency got
compensated for it's use.
Peter S.

---

From: <[email-masked]>
Date: Tue, 27 Sep 2011 17:31:06 +0000

Hi Peter,

On 9/15/11 10:12 AM, "ext Peter Stanforth" <[email-masked]>
wrote:

>another.

The "4.6.  Location based service usage scenario" description in the I-D
illustrates the potential of using the information stored in the database,
and in this case it is location. The use case itself is orthogonal to the
actual scope of the protocol between a WS master device and a database. We
do agree that this use case does not have a direct impact on the PAWS
protocol.
However the point we are attempting to make with this use case is that the
information stored in a database associated with white space devices can
be utilized by other services.
We could extend the use-case to describe the slave device querying the
database to obtain information about the master; And the information
received could assist the device in choosing between multiple masters that
may be visible based on some policy/preference.
Do you perceive the slave device using the same protocol (as the one
between the master and database) for such a query?

>to any Co-existence criteria.

The weighting of the channels in a query response could be quite useful to
a master device. 
This could be a requirement on the PAWS protocol as follows:

Req: The database SHOULD provide the capability to qualify (with various
criteria such as relative priority or weight etc.) the list of available
channels in a response message

-Basavaraj

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 27 Sep 2011 13:39:06 -0400

Basavaraj
I had not thought through the details of how the slave would communicate
with the DB you got the intent right by saying "that the information can
be utilized by other services"
On the second point I also agree with the way you have described the
requirement as a means for a database to "Qualify" the list of channels.
Thanks,
Peter S.

---

From: <[email-masked]>
Date: Fri, 30 Sep 2011 12:12:01 +0000

Hi,

Here is draft text for the mobility use case.

================

In this use case, the user has a non-fixed (portable or mobile) device and
is riding in a vehicle. The user wants to have connectivity to another
device which is also moving. Typical deployment scenarios include urban
areas and rural areas where the user may connect to other users in
peer-to-peer or ad-hoc networks. This deployment scenario is typically
characterized by a master device with low antenna height, internet
connectivity by some connection that does not utilize TV white space, and
some means to predict its path of mobility. This knowledge of mobility
could be simple (GPS plus accelerometer), sophisticated (GPS plus routing
and mapping function) or completely specified by the user via
user-interface.

A simplified operational scenario utilizing TV white space to provide
peer-to-peer connectivity service in a mobility environment consists of
the following steps:

1. The mobile master device powers up with its WS radio in idle or listen
mode only (no active transmission on the WS frequency band).

2. The mobile master has internet connectivity and establishes a
connection to a trusted white space database (see use case "TVWS database
discovery above).

3. The mobile master registers its current geolocation, address contact
information, etc. associated with the owner/operator of the master with
the trusted database administrator (if not currently registered).

4. Following the registration process, the mobile master will send a query
to the trusted database requesting a list of available WS channels based
upon its current location and a prediction of its future location,
extrapolated from the motion or mobility of the device. The current
location is specified in latitude and longitude. The method to specify the
future location is TBD, potential methods include movement vector
(direction and velocity), a set of latitude/longitude points which specify
a closed polygon where the future location is within the polygon, or
similar.

5. If the mobile master has been previously authenticated, the database
responds with a list of available white space channels that the mobile
master may use, and optional information which may include (1) a duration
of time for the use of each channel (2) a maximum transmit power for each
channel.

6. Once the mobile master authenticates the WS channel list response
message from the database, the master selects an available WS channel from
the list for use.

7. The other user device in the peer-to-peer connection scans the TV bands
to locate a mobile master transmission, and associates with the mobile
master. The slave/user device queries the master for a channel list, based
on the slave's device identification, geolocation and optionally a
prediction of its future location.

8. If required by local regulation, the master device verifies the slave's
device identification with the database.

8. If allowed by local regulation (e.g. the slave's device identification
is verified by the database), the mobile master provides the list of
channels locally available to the slave/user device. If the channel that
the slave/user terminal is currently using is not included in the list of
locally available channels, the slave/user device ceases all operation on
its current channel. The slave/user device may scan for another Master's
transmission on a different channel.

================

This represents only one of many possible use case scenarios. Looking
forward to the group's discussion.

Regards,
Scott