Subject: Re: [paws] Possible new use case: simulcasting

From: <[email-masked]>
Date: Wed, 12 Oct 2011 22:23:09 +0000

Pete,
If your use case is covered by 4.3, but the requirements may be different, please feel free to propose your protocol requirement to the list.
-Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Peter McCann
Sent: Wednesday, September 14, 2011 10:30 AM
To: Patil Basavaraj (Nokia-CIC/Dallas); [email-masked]; Probasco Scott (Nokia-CIC/Dallas)
Cc: [email-masked]
Subject: Re: [paws] Possible new use case: simulcasting

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
> 
> On 9/14/11 12:13 PM, "ext Peter McCann" <[email-masked]> wrote:
> 
>> 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
>>> 
>>> 
>>> At 15:40 14-09-11 +0000, [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
>>>> 
>>>> 
>>>> On 9/14/11 8:20 AM, "ext Peter McCann" <[email-masked]>
>>>> wrote:
>>>> 
>>>>> Hi, Scott,
>>>>> 
>>>>> [email-masked] wrote:
>>>>>> 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?
>>>>> 
>>>>> 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
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> Scott
>>>>>> 
>>>>>> 
>>>>>> On 9/13/11 12:37 PM, "ext Peter McCann"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>> 
>>>>>>> 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

_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Peter McCann <[email-masked]>
Date: Thu, 13 Oct 2011 21:23:50 +0000

Hi, Gabor,

I think the requirement could be expressed as a refinement of what you
mean by "location" in requirement D.3:

D.3: The Data Model MUST support specifying the location of the subject and accuracy
of location determination.  Here, "location" can be a single point or a set of points.

-Pete

[email-masked] wrote:
> Pete,
> If your use case is covered by 4.3, but the requirements may be
> different, please feel free to propose your protocol requirement to
> the list.
> -Gabor
> 
> 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:
> 
> 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
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 13 Oct 2011 17:27:07 -0400

We don't use the term "accuracy" when talking about location.  We use "uncertainty" and "confidence", as in "the location is within 10 meters of X,Y with 95% confidence", which is a circular uncertainty area.

Brian

---

From: Peter McCann <[email-masked]>
Date: Thu, 13 Oct 2011 21:37:11 +0000

The "accuracy" term comes from the list of requirements already proposed
by Gabor.  I just added the second sentence.  However we define it, I'd
like to make sure that the WS device can report its location as several
points (with whatever uncertainty/confidence measures for each one).
The database should find spectrum that is open at all of the given points.

-Pete

Rosen, Brian wrote:
> We don't use the term "accuracy" when talking about location.  We use
> "uncertainty" and "confidence", as in "the location is within 10
> meters of X,Y with 95% confidence", which is a circular uncertainty area.
> 
> Brian
> 
>> D.3: The Data Model MUST support specifying the location of the subject
>> and accuracy of location determination.  Here, "location" can be a
>> single point or a set of points.
>> 
>> -Pete
>> 
>>>       device provides its geolocation to the BS which, in turn,
>>>       queries the database for a list of channels available at the
>>>       slaves' geolocation.
>>> 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.
>>>

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 22:00:53 +0000

Pete,

Would D.6/D.7 cover your requirement:
D.6: The Data Model MUST support specifying channel availability information for multiple locations.
D.7: The Data Model MUST support specifying channel availability information for an area around a specified location.

-Gabor

-----Original Message-----
From: ext Peter McCann [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 2:24 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj (Nokia-CIC/Dallas); [email-masked]; Probasco Scott (Nokia-CIC/Dallas)
Cc: [email-masked]
Subject: RE: [paws] Possible new use case: simulcasting

Hi, Gabor,

I think the requirement could be expressed as a refinement of what you mean by "location" in requirement D.3:

D.3: The Data Model MUST support specifying the location of the subject and accuracy of location determination.  Here, "location" can be a single point or a set of points.

-Pete

[email-masked] wrote:
> their own location) and they could compare notes to find a common free channel.
>

---

From: Peter McCann <[email-masked]>
Date: Fri, 14 Oct 2011 11:50:44 +0000

D.6 comes close, but also seems to allow returning the union
set of all channels available at the multiple locations.  I
want to make sure the WSDB can do a set intersection of the
available channels at each of the listed locations.

-Pete

[email-masked] wrote:
> D.7: The Data Model MUST support specifying channel availability
> information for an area around a specified location.
> 
> -Gabor
> 
> -----Original Message----- From: ext Peter McCann
> [mailto:[email-masked]] Sent: Thursday, October 13, 2011 2:24
> PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj (Nokia-
> CIC/Dallas); [email-masked]; Probasco Scott (Nokia-CIC/Dallas)
> Cc: [email-masked] Subject: RE: [paws] Possible new use case: simulcasting
> 
> Hi, Gabor,
> 
> D.3: The Data Model MUST support specifying the location of the
> subject and accuracy of location determination.  Here, "location" can
> be a single point or a set of points.
> 
> -Pete
> 
>> 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:
>> 
>> 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
>> 
> 
>

---

From: <[email-masked]>
Date: Fri, 14 Oct 2011 13:03:01 +0100

Peter, Brian

I agree that "uncertainty" and "confidence" are better terms, but "location accuracy" is also used by Ofcom in their consultation proposals. They allow the location accuracy to be varied in database queries to include the transmissions of the slaves, for example a 500m cell could be catered for by specifying the master location plus an accuracy of 600m, made up of 500m for the cell radius and 100m for the actual location uncertainty of the measurement made by the master device.

We are close to being able to propose two new use cases on the reflector and also have additional requirements that fall from those, particularly addressing the UK/Ofcom needs. 

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter McCann
Sent: 13 October 2011 22:37
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [paws] Possible new use case: simulcasting

The "accuracy" term comes from the list of requirements already proposed by Gabor.  I just added the second sentence.  However we define it, I'd like to make sure that the WS device can report its location as several points (with whatever uncertainty/confidence measures for each one).
The database should find spectrum that is open at all of the given points.

-Pete

Rosen, Brian wrote:
>> I think the requirement could be expressed as a refinement of what 
>> you mean by "location" in requirement D.3:
>> 
>>> along the lines that Scott suggested.  Note there is this text in 
>>> step
>>> 8:
>>> 
>>> 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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Oct 2011 08:39:29 -0400

<as individual>
While I recognize that regulators are not bound by the laws of physics, engineers generally are.   There are no measurement mechanisms I am aware of that will yield a lat/lon/altitude that do not have some form of confidence factor.  We have lots of experience with these issues in the U.S. cell phone emergency call system.  If you don't specify confidence, someone can give you an uncertainty of 10 meters, and just not tell you that confidence is 20%.  More specifically, we actually did experience some measurements with 65% confidence being compared to some measurements with 95% confidence but the same uncertainty.  Big difference.

So, while a regulator can choose to ignore confidence, the protocol cannot, IMHO.  There is no definition of "accuracy" that I'm aware of in the context of measured lat/lon which meets any engineering rigor.  If the regulator says "accuracy", I would propose that the protocol translate that to "uncertainty" and if "confidence" is unspecified, I would default to 95%.

Brian

---

From: <[email-masked]>
Date: Fri, 14 Oct 2011 14:27:38 +0100

Brian

I've gone back to Ofcom's original consultation and it does say the accuracy should be specified to a 95% certainty, so the rules of physics have been allowed for. Sorry I didn't include that in the earlier mail. They then allow for the accuracy to be varied to account for slave devices. Some of the language is probably a bit lax, but the protocol may need to cater for varying confidence levels across regulatory domains as you say. With the caveat that this is only one paragraph from Ofcom's consultation and not the full story, and their views may have moved on, their text on varying the location accuracy says:

The slave devices will be some distance from the master device. As a result, they
may be closer to a licensed receiver than the master and when they transmit they
may cause interference. To prevent this occurring the master device needs to inform
the database of the possible distance away that slave devices may be located and
the database can then take this information into account when assigning frequencies
and power levels.
We propose that an effective way for the master device to do this is to increase its
location uncertainty by an amount related to the maximum expected range between
the master and slave device. Hence, if the master device knew its location accuracy
to 100m and it knew that the maximum range to a slave device was 500m it would
report a location accuracy of 600m to the database. The database would then search
across all pixels within the possible location circle and return a result based on the
minimum power level across all pixels for each frequency.

(Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/summary/geolocation.pdf)

Regards

Andy

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: 14 October 2011 13:39
To: Sago,AJ,Andy,COD R
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] Possible new use case: simulcasting

<as individual>

Brian

On Oct 14, 2011, at 8:03 AM, <[email-masked]> wrote:

>>> subject and accuracy of location determination.  Here, "location" 
>>> can be a single point or a set of points.
>>> 
>>> -Pete
>>> 
>>>> 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
>>>> 
>>> 
>>>

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 14 Oct 2011 10:19:27 -0400

Andy,

As shown in the excerpt that you included below, Ofcom seem to use the 
terms "accuracy" and "uncertainty" interchangeably. The IETF-PAWS should 
align with the intent but use the more correct term "uncertainty" in its 
proceedings.  "Uncertainty" can then be extended to include a larger 
"uncertainty" radius around a location to take into account of the 
existence of the slave devices.

Gerald

At 14:27 14-10-11 +0100, [email-masked] wrote:
>Brian
>
>I've gone back to Ofcom's original consultation and it does say the 
>accuracy should be specified to a 95% certainty, so the rules of physics 
>have been allowed for. Sorry I didn't include that in the earlier mail. 
>They then allow for the accuracy to be varied to account for slave 
>devices. Some of the language is probably a bit lax, but the protocol may 
>need to cater for varying confidence levels across regulatory domains as 
>you say. With the caveat that this is only one paragraph from Ofcom's 
>consultation and not the full story, and their views may have moved on, 
>their text on varying the location accuracy says:
>
>(Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at 
>http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/summary/geolocation.pdf)
>
>Regards
>
>Andy
>
>While I recognize that regulators are not bound by the laws of physics, 
>engineers generally are.   There are no measurement mechanisms I am aware 
>of that will yield a lat/lon/altitude that do not have some form of 
>confidence factor.  We have lots of experience with these issues in the 
>U.S. cell phone emergency call system.  If you don't specify confidence, 
>someone can give you an uncertainty of 10 meters, and just not tell you 
>that confidence is 20%.  More specifically, we actually did experience 
>some measurements with 65% confidence being compared to some measurements 
>with 95% confidence but the same uncertainty.  Big difference.
>
>So, while a regulator can choose to ignore confidence, the protocol 
>cannot, IMHO.  There is no definition of "accuracy" that I'm aware of in 
>the context of measured lat/lon which meets any engineering rigor.  If the 
>regulator says "accuracy", I would propose that the protocol translate 
>that to "uncertainty" and if "confidence" is unspecified, I would default 
>to 95%.
>
>Brian
>
> > I agree that "uncertainty" and "confidence" are better terms, but 
> "location accuracy" is also used by Ofcom in their consultation 
> proposals. They allow the location accuracy to be varied in database 
> queries to include the transmissions of the slaves, for example a 500m 
> cell could be catered for by specifying the master location plus an 
> accuracy of 600m, made up of 500m for the cell radius and 100m for the 
> actual location uncertainty of the measurement made by the master device.
> >
> > We are close to being able to propose two new use cases on the 
> reflector and also have additional requirements that fall from those, 
> particularly addressing the UK/Ofcom needs.
> >
> > Andy
> >
> > The "accuracy" term comes from the list of requirements already 
> proposed by Gabor.  I just added the second sentence.  However we define 
> it, I'd like to make sure that the WS device can report its location as 
> several points (with whatever uncertainty/confidence measures for each one).

---

From: Peter McCann <[email-masked]>
Date: Fri, 14 Oct 2011 14:27:21 +0000

Slave devices (or peer master devices engaged in simulcasting) may not
be arranged in a circular area and enlarging the uncertainty radius to
include all of them may result in a geographic footprint that is way
too large.  It should be possible to include multiple points/uncertainty
radii and have the WSDB return spectrum that is free in all of the 
circles.

-Pete

Gerald Chouinard wrote:
> terms "accuracy" and "uncertainty" interchangeably. The IETF-PAWS
> should align with the intent but use the more correct term
> "uncertainty" in its proceedings.  "Uncertainty" can then be extended
> to include a larger "uncertainty" radius around a location to take
> into account of the existence of the slave devices.
> 
> Gerald
> 
> 
>> accuracy should be specified to a 95% certainty, so the rules of
>> physics have been allowed for. Sorry I didn't include that in the
>> earlier mail. They then allow for the accuracy to be varied to account
>> for slave devices. Some of the language is probably a bit lax, but the
>> protocol may need to cater for varying confidence levels across
>> regulatory domains as you say. With the caveat that this is only one
>> paragraph from Ofcom's consultation and not the full story, and their
>> views may have moved on, their text on varying the location accuracy
>> says:
>> 
>> The slave devices will be some distance from the master device. As a
>> result, they may be closer to a licensed receiver than the master and
>> when they transmit they may cause interference. To prevent this
>> occurring the master device needs to inform the database of the
>> possible distance away that slave devices may be located and the
>> database can then take this information into account when assigning
>> frequencies and power levels. We propose that an effective way for the
>> master device to do this is to increase its location uncertainty by an
>> amount related to the maximum expected range between the master and
>> slave device. Hence, if the master device knew its location accuracy to
>> 100m and it knew that the maximum range to a slave device was 500m it
>> would report a location accuracy of 600m to the database. The database
>> would then search across all pixels within the possible location circle
>> and return a result based on the minimum power level across all pixels
>> for each frequency.
>> 
>> http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/s u
>> m mary/geolocation.pdf)
>> 
>> Regards
>> 
>> Andy
>> 
>> <as individual> While I recognize that regulators are not bound by the
>> laws of physics, engineers generally are.   There are no measurement
>> mechanisms I am aware of that will yield a lat/lon/altitude that do not
>> have some form of confidence factor.  We have lots of experience with
>> these issues in the U.S. cell phone emergency call system.  If you
>> don't specify confidence, someone can give you an uncertainty of 10
>> meters, and just not tell you that confidence is 20%.  More
>> specifically, we actually did experience some measurements with 65%
>> confidence being compared to some measurements with 95% confidence but
>> the same uncertainty.  Big difference.
>> 
>> cannot, IMHO.  There is no definition of "accuracy" that I'm aware of
>> in the context of measured lat/lon which meets any engineering rigor.
>> If the regulator says "accuracy", I would propose that the protocol
>> translate that to "uncertainty" and if "confidence" is unspecified, I
>> would default to 95%.
>> 
>> Brian
>> 
>> reflector and also have additional requirements that fall from
>> those, particularly addressing the UK/Ofcom needs.
>>> 
>>> Andy
>>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Peter McCann Sent: 13
>>> October 2011 22:37 To: Rosen, Brian Cc: [email-masked] Subject: Re:
>>> [paws] Possible new use case: simulcasting
>>> 
>> proposed by Gabor.  I just added the second sentence.  However we
>> define it, I'd like to make sure that the WS device can report its
>> location as several points (with whatever uncertainty/confidence
> measures for each one).
>>>>>> different, please feel free to propose your protocol
>>>>>> requirement to the list.
>>>>>> -Gabor
>>>>>> 
>>>>>> To: Patil Basavaraj (Nokia-CIC/Dallas);
>>>>>> [email-masked]; Probasco Scott (Nokia-CIC/Dallas)
>>>>>> Cc: [email-masked]
>>>>>> step 8:
>>>>>>      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.

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 14 Oct 2011 10:33:31 -0400

Peter,

In the 802.22 WRAN model, the process of intersection is done at the base 
station because the base station should be able to decide whether to accept 
association with a new user terminal or not, depending on the extent this 
new terminal limits the number of available channels.  This would not be 
possible if this is done at the database.

The base station (or the master in more general terms) should maintain a 
local table of available channel sets (or maximum allowed EIRP per channel) 
to have all the information necessary to continuously optimize its use of 
the RF spectrum. One can imagine a new terminal that asks to be associated 
that may reduce the number of available channels to only a few but, by 
disassociating another terminal in a different location, the local network 
would regain even more available channels, as a result of the intersection 
process.  The base station could then decide to stop its association with 
this second terminal and associate the first terminal.  This intelligence 
should not be relegated to the database but should be kept local at the 
base station.

Whether the base station queries the database for each of its associated 
terminals one at a time or in 'batch' mode for all its terminals, the 
complete information should be obtained from the database so that the 
process of 'intersection' can take place at the base station.

Gerald

---

From: <[email-masked]>
Date: Fri, 14 Oct 2011 15:34:56 +0100

Agreed. I brought up the idea of 'varying the uncertainty radius' as another option, already put forward by Ofcom, it is not necessarily ideal for the simulcasting use case. Maybe I should have started a new thread.

Andy

-----Original Message-----
From: Peter McCann [mailto:[email-masked]] 
Sent: 14 October 2011 15:27
To: Gerald Chouinard; Sago,AJ,Andy,COD R; [email-masked]
Cc: [email-masked]
Subject: RE: [paws] Possible new use case: simulcasting

Slave devices (or peer master devices engaged in simulcasting) may not be arranged in a circular area and enlarging the uncertainty radius to include all of them may result in a geographic footprint that is way too large.  It should be possible to include multiple points/uncertainty radii and have the WSDB return spectrum that is free in all of the circles.

-Pete

Gerald Chouinard wrote:
>> earlier mail. They then allow for the accuracy to be varied to 
>> account for slave devices. Some of the language is probably a bit 
>> lax, but the protocol may need to cater for varying confidence levels 
>> across regulatory domains as you say. With the caveat that this is 
>> only one paragraph from Ofcom's consultation and not the full story, 
>> and their views may have moved on, their text on varying the location 
>> accuracy
>> says:
>> 
>> frequencies and power levels. We propose that an effective way for 
>> the master device to do this is to increase its location uncertainty 
>> by an amount related to the maximum expected range between the master 
>> and slave device. Hence, if the master device knew its location 
>> accuracy to 100m and it knew that the maximum range to a slave device 
>> was 500m it would report a location accuracy of 600m to the database. 
>> The database would then search across all pixels within the possible 
>> location circle and return a result based on the minimum power level 
>> across all pixels for each frequency.
>> 
>> http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/s 
>> u m mary/geolocation.pdf)
>> 
>> Regards
>> 
>> Andy
>> 
>> mechanisms I am aware of that will yield a lat/lon/altitude that do 
>> not have some form of confidence factor.  We have lots of experience 
>> with these issues in the U.S. cell phone emergency call system.  If 
>> you don't specify confidence, someone can give you an uncertainty of 
>> 10 meters, and just not tell you that confidence is 20%.  More 
>> confidence being compared to some measurements with 95% confidence 
>> but the same uncertainty.  Big difference.
>> 
>> queries to include the transmissions of the slaves, for example a 
>> 500m cell could be catered for by specifying the master location plus 
>> an accuracy of 600m, made up of 500m for the cell radius and 100m for 
>> the actual location uncertainty of the measurement made by the master
> device.
>>> 
>>>> We don't use the term "accuracy" when talking about location.  We 
>>>> use "uncertainty" and "confidence", as in "the location is within 
>>>> 10 meters of X,Y with 95% confidence", which is a circular 
>>>> uncertainty area.
>>>> 
>>>> Brian
>>>> 
>>>>>> different, please feel free to propose your protocol requirement 
>>>>>> to the list.
>>>>>> -Gabor
>>>>>> 
>>>>>> What I am suggesting is no different except for the fact that 
>>>>>> each of the devices could have independent Internet access and be 
>>>>>> 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

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 14 Oct 2011 10:37:52 -0400

Peter,

I guess what Ofcom was referring to is something similar to the Mode I 
devices in the US that do not need to be geolocated since they are assumed 
to be close to the master device. In the case where these slave devices 
need to be geolocated, I agree with you that their actual locatiohn should 
be used rather than arbitrarily extending the radius of an imaginary circle 
around the master device.

Gerald

---

From: Peter McCann <[email-masked]>
Date: Fri, 14 Oct 2011 14:50:40 +0000

Hi, Gerald,

I think doing the intersection at the master device might be
acceptable, as long as the "batch" location mode is supported.
However, it might lead to a lot of redundant data being
sent back from the WSDB if there are many channels free in 
all given locations.  Perhaps some sort of compression could
be defined so that the common channels are sent only once?
That would be roughly equivalent to doing an intersection
but you would also send the additional information about the
channels that were free only in specific locations.  This
would allow the master device to do the kind of computations
you outline below.

-Pete

Gerald Chouinard wrote:
> Peter,
> 
> In the 802.22 WRAN model, the process of intersection is done at the
> base station because the base station should be able to decide whether
> to accept association with a new user terminal or not, depending on
> the extent this new terminal limits the number of available channels.
> This would not be possible if this is done at the database.
> 
> The base station (or the master in more general terms) should maintain
> a local table of available channel sets (or maximum allowed EIRP per
> channel) to have all the information necessary to continuously
> optimize its use of the RF spectrum. One can imagine a new terminal
> that asks to be associated that may reduce the number of available
> channels to only a few but, by disassociating another terminal in a
> different location, the local network would regain even more available
> channels, as a result of the intersection process.  The base station
> could then decide to stop its association with this second terminal
> and associate the first terminal.  This intelligence should not be
> relegated to the database but should be kept local at the base station.
> 
> Whether the base station queries the database for each of its
> associated terminals one at a time or in 'batch' mode for all its
> terminals, the complete information should be obtained from the
> database so that the process of 'intersection' can take place at the
> base station.
> 
> Gerald
> 
> 
>> D.6 comes close, but also seems to allow returning the union set of all
>> channels available at the multiple locations.  I want to make sure the
>> WSDB can do a set intersection of the available channels at each of the
>> listed locations.
>> 
>> -Pete
>> 
>>> [mailto:[email-masked]] Sent: Thursday, October 13, 2011
>>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj
>>> (Nokia- CIC/Dallas); [email-masked]; Probasco Scott
>>> (Nokia-CIC/Dallas)
>>>> Pete, If your use case is covered by 4.3, but the requirements may be
>>>> the list. -Gabor

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 14 Oct 2011 11:08:58 -0400

Pete,

Agreed.  A simple compression scheme could be proposed in the PAWS protocol 
and that is to query only only on a 'differential' basis, i.e., the 
database would only send what has changed since the last query. This could 
also be applied to the query message from the base station, i.e., sending 
only the information that would have changed since the last query (e.g., 
new terminal, changed geoposition, etc.).

Gerald

---

From: Paul Lambert <[email-masked]>
Date: Fri, 14 Oct 2011 10:45:15 -0700

I think we may be over designing.  The union is interesting - but it limits a device from using all available channels in any particular location.

Paul

Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gerald Chouinard
> Sent: Friday, October 14, 2011 8:09 AM
> To: Peter McCann; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> to
> have

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 14 Oct 2011 15:51:31 -0400

Paul,

Obviously, the 'union', as you call it, assumes that all the devices 
included form a network and need to operate on the same channel. If a 
device wants to operate on a different channel, it no longer belongs to the 
same wireless network and needs to query the database for itself, either 
directly or through another master device as 15.711(3)(e) of the MO&O 
allows.  In such case, the process of intersection of the lists of 
available channels would not apply.

Gerald

At 10:45 14-10-11 -0700, Paul Lambert wrote:
>I think we may be over designing.  The union is interesting - but it 
>limits a device from using all available channels in any particular location.
>
>Paul
>
>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 14 Oct 2011 13:01:14 -0700

Masters in multiple locations might not all operate on the same channel.  There is no need for them to all be in the same channel.  They may all be connected in a mesh or other type of typology.

I feel it would be better to have simple set of queries/operations that can be combined by clients into more complex operations than attempt to accommodate all possible complex processing that we can envision in a database.  

Paul

> From: Gerald Chouinard [mailto:[email-masked]]
> Sent: Friday, October 14, 2011 12:52 PM
> To: Paul Lambert; Peter McCann; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> > > database would only send what has changed since the last query.
> This
> > > could
> > > > > In the 802.22 WRAN model, the process of intersection is done
> at
> > > the
> > > > > a local table of available channel sets (or maximum allowed
> EIRP
> > > per
> > > > > database so that the process of 'intersection' can take place
> at
> > > the
> > > > > base station.
> > > > >
> > > > > Gerald
> > > > >
> > > > >
> set
> > > of all
> > > > >> channels available at the multiple locations.  I want to make
> sure
> > > the
> > > > >> WSDB can do a set intersection of the available channels at
> each
> > > of the
> > > > >> listed locations.
> > > > >>
> > > > >> -Pete
> > > > >>
> > > > >>> D.6: The Data Model MUST support specifying channel
> availability
> > > > >>> information for multiple locations.
> > > > >>>> Pete, If your use case is covered by 4.3, but the
> requirements
> > > may be
> requirement
> > > > >>>> From: [email-masked] [mailto:[email-masked]]
> On
> > > > >>>> Behalf Of ext Peter McCann
> > > > >>>> 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
> > > > >>>> each of the devices could have independent Internet access
> and
> > > be
> > > > >>>> test at each location, could additionally do a set
> intersection
> > > test
> > > > >>>> on the remaining free channels and return the results.
> That's
> > > one

---

From: Peter McCann <[email-masked]>
Date: Fri, 14 Oct 2011 20:49:49 +0000

I think all that is being suggested is the ability to "batch" several
simple requests into one message, such as when the master knows the locations
of several other nodes (they could be slaves or other masters) and the
database then independently processes each query.  It is only for efficiency
that the responses could be processed together to remove redundancy.  Think
of it as a compression algorithm that runs on the list of XML responses being
returned.

-Pete

Paul Lambert wrote:
> Masters in multiple locations might not all operate on the same
> channel.  There is no need for them to all be in the same channel.
> They may all be connected in a mesh or other type of typology.
> 
> I feel it would be better to have simple set of queries/operations
> that can be combined by clients into more complex operations than
> attempt to accommodate all possible complex processing that we can
> envision in a database.
> 
> Paul
> 
>> included form a network and need to operate on the same channel. If
>> a device wants to operate on a different channel, it no longer
>> belongs to the same wireless network and needs to query the database
>> for itself, either directly or through another master device as
>> 15.711(3)(e) of the MO&O allows.  In such case, the process of
>> intersection of the lists of available channels would not apply.
>> 
>> Gerald
>> 
>> 
>>>> [mailto:[email-masked]] On Behalf Of Gerald Chouinard Sent:
>>>> Friday, October 14, 2011 8:09 AM To: Peter McCann;
>>>> [email-masked]; [email-masked];
>>>> [email-masked] Cc: [email-masked] Subject: Re: [paws]
>>>> Possible new use case: simulcasting
>>>> 
>>>> Pete,
>>>> 
>>>> Agreed.  A simple compression scheme could be proposed in the PAWS
>>>> protocol and that is to query only only on a 'differential' basis,
>>>> i.e., the database would only send what has changed since the last
>>>> query. This could also be applied to the query message from the base
>>>> station, i.e., sending only the information that would have changed
>>>> since the last query (e.g., new terminal, changed geoposition, etc.).
>>>> 
>>>> Gerald
>>>> 
>>>>> However, it might lead to a lot of redundant data being sent back
>>>>> from the WSDB if there are many channels free in all given
>>>>> locations.  Perhaps some sort of compression could be defined so
>>>>> that the common channels are sent only once? That would be roughly
>>>>> equivalent to doing an intersection but you would also send the
>>>>> additional information about the channels that were free only in
>>>>> specific locations.  This would allow the master device to do the
>>>>> kind of computations you outline below.
>>>>> 
>>>>> -Pete
>>>>> 
>>>>> 
>>>>> Gerald Chouinard wrote:
>>>>>> Peter,
>>>>>> 
>>>>>> base station because the base station should be able to
> decide
>>>> whether
>>>>>> the extent this new terminal limits the number of available
>>>>>> channels. This would not be possible if this is done at the
>>>>>> database.
>>>>>> 
>>>>>> The base station (or the master in more general terms) should
>>>>>> maintain a local table of available channel sets (or maximum allowed
>> EIRP
>>>> per
>>>>>> channels to only a few but, by disassociating another
> terminal
>> in a
>>>>>> different location, the local network would regain even more
>>>>>> available channels, as a result of the intersection process.  The
>>>>>> base station could then decide to stop its association with this
>>>>>> second terminal and associate the first terminal.  This
>>>>>> intelligence should not be relegated to the database but should be
>>>>>> kept local at the
> base
>>>> station.
>>>>>> 
>>>>>>>> Would D.6/D.7 cover your requirement: D.6: The Data Model MUST
>>>>>>>> support specifying channel availability information for multiple
>>>>>>>> locations. D.7: The Data Model MUST support specifying channel
>>>>>>>> availability information for an area around a specified location.
>>>>>>>> 
>>>>>>>> -Gabor
>>>>>>>> 
>>>>>>>> [mailto:[email-masked]] Sent: Thursday, October
> 13,
>> 2011
>>>>>>>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil
>>>>>>>> Basavaraj (Nokia- CIC/Dallas); [email-masked]; Probasco
>>>>>>>> Scott (Nokia-CIC/Dallas) Cc: [email-masked] Subject: RE: [paws]
>>>>>>>> Possible new use case: simulcasting
>>>>>>>> 
>>>>>>>> Hi, Gabor,
>>>>>>>> 
>>>>>>>> I think the requirement could be expressed as a refinement of
>>>>>>>> what you mean by "location" in requirement D.3:
>>>>>>>> 
>>>>>>>>> [mailto:[email-masked]] On Behalf Of ext Peter McCann
>>>>>>>>> Sent: Wednesday, September 14, 2011 10:30 AM To: Patil Basavaraj
>>>>>>>>> (Nokia-CIC/Dallas); [email-masked]; Probasco Scott
>>>>>>>>> (Nokia-CIC/Dallas) Cc: [email-masked] Subject: Re: [paws]
>>>>>>>>> Possible new use case: simulcasting
>>>>>>>>> 
>>>>>>>>> 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:
>>>>>>>>> 
>>>>>>>>>        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.
>>>>>>>>> As for the protocol between the BS and the WSDB, we may
>>>>>>>>> want
>> to
>>>> have
>>>>>>>>> (instead of just one) so that we save the cost of multiple

---

From: <[email-masked]>
Date: Fri, 14 Oct 2011 20:54:21 +0000

Pete,

How would it be different from a query by a mobile master device which
requests channel availability information at a set of locations that it
may potentially be moving across rather than just its current location?

-Raj

---

From: Peter McCann <[email-masked]>
Date: Fri, 14 Oct 2011 20:58:13 +0000

Right, I don't think the protocol needs to care why the multiple
locations are being given.  Hopefully the protocol will satisfy
the simulcasting and mobility scenarios with the same mechanisms.

-Pete

[email-masked] wrote:
> requests channel availability information at a set of locations that
> it may potentially be moving across rather than just its current location?
> 
> -Raj
> 
>> simple requests into one message, such as when the master knows the
>> locations of several other nodes (they could be slaves or other
>> masters) and the database then independently processes each query. It
>> is only for efficiency that the responses could be processed together
>> to remove redundancy. Think of it as a compression algorithm that runs
>> on the list of XML responses being returned.
>> 
>> -Pete
>> 
>> Paul Lambert wrote:
>>>> device wants to operate on a different channel, it no longer belongs
>>>> to the same wireless network and needs to query the database for
>>>> itself, either directly or through another master device as
>>>>> I think we may be over designing.  The union is interesting - but
>>>>> it limits a device from using all available channels in any
>>>>> particular location.
>>>>> 
>>>>> Paul
>>>>> 
>>>>> 
>>>>>> query. This could also be applied to the query message from the
>>>>>> base station, i.e., sending only the information that would have
>>>>>> changed since the last query (e.g., new terminal, changed
>>>>>> geoposition, etc.).
>>>>>> 
>>>>>> Gerald
>>>>>> 
>>>>>>>> to accept association with a new user terminal or not, depending
>>>>>>>> on the extent this new terminal limits the number of available
>>>>>>>> optimize its use of the RF spectrum. One can imagine a new
>>>>>>>> terminal that asks to be associated that may reduce the number
>>>>>>>> of available channels to only a few but, by disassociating
>>>>>>>> another
>>> terminal
>>>> in a
>>>>>>>> available channels, as a result of the intersection process.
>>>>>>>> The base station could then decide to stop its association
>>>>>>>> with this second terminal and associate the first terminal.
>>>>>>>> This intelligence should not be relegated to the database but
>>>>>>>> should be kept local at the
>>> base
>>>>>> station.
>>>>>>>> 
>>>>>>>> associated terminals one at a time or in 'batch' mode for all
>>>>>>>> its terminals, the complete information should be obtained
>>>>>>>> from the database so that the process of 'intersection' can
>>>>>>>> take place
>>>> at
>>>>>> the
>>>>>>>> base station.
>>>>>>>> 
>>>>>>>> Gerald
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> support specifying channel availability information for
>>>>>>>>>> multiple locations. D.7: The Data Model MUST support specifying
>>>>>>>>>> channel availability information for an area around a specified
>>>>>>>>>> location.
>>>>>>>>>> 
>>>>>>>>>> -Gabor
>>>>>>>>>> 
>>>>>>>>>> Basavaraj (Nokia- CIC/Dallas); [email-masked];
>>>>>>>>>> Probasco Scott (Nokia-CIC/Dallas) Cc: [email-masked] Subject:
>>>>>>>>>> RE: [paws] Possible new use case: simulcasting
>>>>>>>>>> 
>>>>>>>>>> Hi, Gabor,
>>>>>>>>>> 
>>>>>>>>>> I think the requirement could be expressed as a refinement
>>>>>>>>>> of what you mean by "location" in requirement D.3:
>>>>>>>>>> 
>>>>>>>>>> subject and accuracy of location determination.  Here,
>>>>>>>>>> "location" can be a single point or a set of points.
>>>>>>>>>> 
>>>>>>>>>> -Pete
>>>>>>>>>> 
>>>>>>>>>>> Sent: Wednesday, September 14, 2011 10:30 AM To: Patil
>>>>>>>>>>> Basavaraj (Nokia-CIC/Dallas); [email-masked];
>>>>>>>>>>> Probasco Scott
>>>>>>>>>>> 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.
>>>>>>>>>>> 
>>>>>>>>>>> a requirement that the protocol carry multiple location
>>>>>>>>>>> multiple queries across the Internet.  The WSDB, after doing
>>>>>>>>>>> the polygon intersection test at each location, could
>>>>>>>>>>> additionally do a
> set
>>>> intersection
>>>>>> test

---

From: Paul Lambert <[email-masked]>
Date: Fri, 14 Oct 2011 14:12:32 -0700

It may not be processing efficient for a server to combine the results of multiple queries.  Queries should be considered atomic and the answers should be associated with a particular query.  
Looking up channels for a simple region is a much different processing than combining multiple results that may have other constraints (like different validity times).
Multiple queries could also be for different spectral masks or operating modes.  Sometimes they could be combined and sometimes not.

Now ... I'm not a fan of overly complex geo shapes ... but what you're asking for sounds more like a request for polygon or line based regions (e.g. NY to Boston).

Paul

> Sent: Friday, October 14, 2011 1:50 PM
> To: Paul Lambert; Gerald Chouinard; [email-masked];
> locations
> it
> on
> The
> its
> multiple
> Probasco
> "location"
> Basavaraj
> elements

---

From: "M.K.Sajeev sajeev" <[email-masked]>
Date: Fri, 14 Oct 2011 20:13:33 -0700 (PDT)

Hi,

I agree with this comment. Compression/decompression, etc. can make the whole transaction slow, and complex too. Net bandwidth now should be able to accommodate data without compression (which is going to improve too in coming days). Differential response and catching looks like good option..
 
Best Regards,
Sajeev Manikkoth

________________________________
From: Paul Lambert <[email-masked]>
To: Gerald Chouinard <[email-masked]>; Peter McCann <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, 14 October 2011, 23:15
Subject: Re: [paws] Possible new use case: simulcasting

Paul

> protocol
> channels.
> maintain
> available
> what
> change
> queries