Subject: [paws] New ID including further use cases for PAWS WG

From: zhulei 41317 <[email-masked]>
Date: Mon, 25 Jul 2011 21:38:10 +0800

Hello Folks,

This is Zhu Lei from Huawei, and submitted a new ID including additional use cases which are on the background in our company. 

I'd like to participate PAWS following meetings and discussions in mail list which may help clarify the database and query protocol for this PAWS purposes.

The content of this ID is about the use cases extending existing general scenarios and could have a lot of discussions here. 

http://www.ietf.org/id/draft-lei-paws-overview-usecases-00.txt

So, please read use cases, and provide the comments if they make sense for you.

Best regards,
Lei

---

From: Teco Boot <[email-masked]>
Date: Mon, 25 Jul 2011 16:39:22 +0200

Lei,

Thanks for the additional use cases. I see a lot of cut&paste, without reference to probasco-paws-overview-usecases. Is your draft competing? Or, as in your mail, pure additional? If so, include some words on alignment in the draft?

Anyway, thanks for introducing the ad hoc network use case. I support including this. It is an important one, that can also be used for PPDR *) / military networks. Those communities are moving slowly towards more dynamic spectrum management.

I wonder if you have thoughts on changes on listed requirements, seen you have additional use cases. I can imagine that having a mobile master has consequences. Requirement Master #5 doesn't fit, does it? This is for stationary nodes, in that is it doesn't go out of its home area. A fix would be making the 100m radius a parameter, set to larger (or smaller) values for mobile nodes. The 100m would be a valid parameter for fixed nodes, although I don't see why a node would not set it to a much smaller value. Another consequence of mobile nodes would be a need for a restriction on clients, in that they are not allowed to use assigned channel if the move out of a certain area. This needs another radius parameter, or reuse the proposed master radius for all nodes in the cluster.

Thanks, Teco

*) PPDR: Public Protection and Disaster Relief

Op 25 jul 2011, om 15:38 heeft zhulei 41317 het volgende geschreven:

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

---

From: <[email-masked]>
Date: Mon, 25 Jul 2011 18:41:40 +0000

Hi Lei,

Thanks for documenting these use cases. It is important that we include a
broad selection of use cases that are supported by the industry, in this
way we ensure that our list of requirements for PAWS is complete.

>From the Indoor usage of TVWS use case, the following potential
requirements seem needed:
	* PAWS must not be tied to a specific frequency band
	* Master devices should support power control
	* Slave devices should support power control

The Ad-hoc network use case I believe is already possible from the
Hot-spot use case, but certainly ad-hoc is an important use case and the
necessary requirements must be included in our list.

The TVWS based TD-LTE MBMS use case seems to be very specific to LTE and
MBMS. IMHO we should be abstract in our work, so that PAWS is a suitable
solution regardless of any specific radio technology. Would be good to see
this use case revised to be independent of any specific technology (LTE,
MBMS). There does seem to be a requirement in step two where a service
controller can query the database (additional information needed on what
is needed from the database). There are synergies between this use case
and "Offloading: moving traffic to a white space network" and also
"Location based service usage scenario" use cases.

Regards,
Scott

On 7/25/11 8:38 AM, "ext zhulei 41317" <[email-masked]> wrote:

>Hello Folks,
>
>This is Zhu Lei from Huawei, and submitted a new ID including additional
>use cases which are on the background in our company.
>
>I'd like to participate PAWS following meetings and discussions in mail
>list which may help clarify the database and query protocol for this PAWS
>purposes.
>
>The content of this ID is about the use cases extending existing general
>scenarios and could have a lot of discussions here.
>

---

From: <[email-masked]>
Date: Mon, 25 Jul 2011 18:42:00 +0000

Hi Teco,

Requirement Master #5 applies to all Masters, especially mobile Masters,
yes? A Master (mobile or fixed) can create a network. The fixed Master
will never move and thus never need to query the database because of
change in location. The mobile Master creates a network (e.g. a hot-spot),
and must check for channel availability when this hot-spot network moves
by some pre-determined distance. IMHO the value should not be fixed in
PAWS (100 m is specific to US FCC requirements), but somehow configurable
to support regulations from different parts of the world. Adding a
restriction on clients (or slaves) is slightly difficult, as one
definition of the slave (Mode I device in US) is that it (the Mode I or
slave device) does not have geo-location capability.

Regards,
Scott

On 7/25/11 9:39 AM, "ext Teco Boot" <[email-masked]> wrote:

>Lei,
>
>Thanks for the additional use cases. I see a lot of cut&paste, without
>reference to probasco-paws-overview-usecases. Is your draft competing?
>Or, as in your mail, pure additional? If so, include some words on
>alignment in the draft?
>
>Anyway, thanks for introducing the ad hoc network use case. I support
>including this. It is an important one, that can also be used for PPDR *)
>/ military networks. Those communities are moving slowly towards more
>dynamic spectrum management.
>
>I wonder if you have thoughts on changes on listed requirements, seen you
>have additional use cases. I can imagine that having a mobile master has
>consequences. Requirement Master #5 doesn't fit, does it? This is for
>stationary nodes, in that is it doesn't go out of its home area. A fix
>would be making the 100m radius a parameter, set to larger (or smaller)
>values for mobile nodes. The 100m would be a valid parameter for fixed
>nodes, although I don't see why a node would not set it to a much smaller
>value. Another consequence of mobile nodes would be a need for a
>restriction on clients, in that they are not allowed to use assigned
>channel if the move out of a certain area. This needs another radius
>parameter, or reuse the proposed master radius for all nodes in the
>cluster.
>
>Thanks, Teco
>
>
>> This is Zhu Lei from Huawei, and submitted a new ID including
>>additional use cases which are on the background in our company.
>> 
>>list which may help clarify the database and query protocol for this
>>PAWS purposes.
>> 
>> The content of this ID is about the use cases extending existing
>>general scenarios and could have a lot of discussions here.
>>

---

From: Teco Boot <[email-masked]>
Date: Mon, 25 Jul 2011 22:49:47 +0200

Scott,

There could be a need a set of special requirements for ad hoc nodes. 
One reason for this is that there is no clear separation between masters 
and slaves, where slaves stop transmitting when no master is within 
range. However, I like the PAWS master-slave model, where a master
node allocates channels, because this node has a backhaul link.

So what a master could do is delegate the assigned channels, with its
restrictions such as (maximum) antenna height, area where to operate 
and so on. Ad hoc nodes must have geo positioning and obey the 
restrictions. This approach would minimize impact on the PAWS protocol 
for ad hoc nodes.

Would FCC and others move towards such a direction some day?   

Thanks, Teco

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 25 Jul 2011 16:56:14 -0400

I wouldn't call it master/slave.  You need a device that has an independent path to the Internet in order to query the database.  That node passes the channel list to other nodes, provided they are in close proximity to each other.  Another model would be that there is relaying of the request through some number of intermediaries to one which has the Internet connection, which then queries the database.

I don't think either of these has actual different requirements with respect to our work as currently chartered, but if you think so, let's get them on the list and into the document.

I wouldn't care to speculate on what a regulator might do in the future.  The FCC has specifically prohibited chained requests (my latter model), but a "tower" can query on behalf of it and all of its clients, which effectively is a one hop indirect.

Brian

---

From: <[email-masked]>
Date: Tue, 26 Jul 2011 04:36:56 +0000

Hi Teco,

Perhaps we need to define more clearly what we mean by "ad-hoc" nodes and
networks. I believe a traditional definition includes two main aspects:
1. Lack of fixed infrastructure
2. Additional routing schemes or mechanisms (e.g. each node in the ad-hoc
NW is capable of forwarding packets)

In the case of PAWS, routing schemes & mechanisms are beyond our scope. So
when I think of "ad-hoc" (in scope of PAWS) I think of a radio network
where a portable device has initiated the network, i.e. a portable Master
"emulates" a fixed Master, and the other nodes in the ad-hoc network are
portable and may or may not have geo-location capability. Thus the ad-hoc
case is quite similar to the hot-spot case. I do support this ad-hoc use
case, and by extension necessary requirements to enable ad-hoc.

Regarding changes to FCC regulations, we can only act on the facts
available today. If any changes do occur to the current regulations, we
can at least expect a reasonable advance warning (lengthy delay) before
changes are approved.

Regards,
Scott

On 7/25/11 3:49 PM, "ext Teco Boot" <[email-masked]> wrote:

>Op 25 jul 2011, om 20:42 heeft <[email-masked]>
><[email-masked]> het volgende geschreven:
>
>> Hi Teco,
>>

---

From: <[email-masked]>
Date: Tue, 26 Jul 2011 04:39:39 +0000

>
>I don't think either of these has actual different requirements with
>respect to our work as currently chartered, but if you think so, let's
>get them on the list and into the document.
>
I agree, let's define the necessary requirements.

Regards,
Scott

On 7/25/11 3:56 PM, "ext Rosen, Brian" <[email-masked]> wrote:

>I wouldn't call it master/slave.  You need a device that has an
>independent path to the Internet in order to query the database.  That
>node passes the channel list to other nodes, provided they are in close
>proximity to each other.  Another model would be that there is relaying
>of the request through some number of intermediaries to one which has the
>Internet connection, which then queries the database.
>
>I don't think either of these has actual different requirements with
>respect to our work as currently chartered, but if you think so, let's
>get them on the list and into the document.
>
>I wouldn't care to speculate on what a regulator might do in the future.
>The FCC has specifically prohibited chained requests (my latter model),
>but a "tower" can query on behalf of it and all of its clients, which
>effectively is a one hop indirect.
>
>Brian
>
>>>>> So, please read use cases, and provide the comments if they make
>>>>>sense
>>>>> for you.
>>>>> 
>>>>> Best regards,
>>>>> Lei

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 26 Jul 2011 08:33:37 -0400

I have to agree with Scott. Ad hoc in the sense of mesh or multi hopping
architectures is beyond the scope and is currently not allowed by the FCC
rules.
Ad Hoc in the sense of a next generation smart phone wanting to become a
"tether" for other nodes is realistic as is the case of a mobile hotspot
in a car or on public transportation, like a bus.
Regards,
Peter Stanforth
CTO
Spectrum Bridge Inc
(co founder of MeshNetworks)

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 26 Jul 2011 09:06:19 -0700

The rules are still being made up.  And in US, not just by the FCC.  

Consider the 700MHz (aka D block) allocation going on.
	
The bill before Congress right now is to allocate this chunk of spectrum
for emergency services.  I have not read the legislation closely enough
to see whether 'exclusive' is in the language.  

If the 700MHz chunk is reserved for exclusive emergency services use ...
and actually gets used ... then we will have a dual-infrastructure
situation where intra-EMS comms is in the 700MHz spectrum, but EMS <-->
public and public <--> public comms is somewhere else.  
	
If, however, the 700MHz chunk is earmarked for priority use by emergency
services, then it might, when unused, be within the PAWS allocation
domain.  

Requirement observation: this is a case where ability of a priority user
(EMS) to pre-empt an existing allocation is necessary.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 26 Jul 2011 12:39:00 -0400

Are you kidding?

The public safety guys refused to allow this to be shared with the carriers, with them getting it on a priority basis.
The original idea was that a carrier would win an auction, build an LTE network, and let public safety use it on a priority basis (there were lots of variations - public safety gets priority use on all of it with consumer use of all of it on a non priority basis, public safety gets exclusive use of some and priority use of the rest,…).  Not acceptable.

They demand exclusive use.  They would never agree to shared use, and especially unlicensed shared use.

That being said, our charter is for band-independent, phy-independent, nation-independent protocols.  So, non-700Mhz is in scope.  Non-US is definitely in scope.  Mesh, insofar as the protocol between a device and a database is affected by the fact that it's mesh, is in scope, and the limitations of the FCC rules isn't relevant.  The protocol can allow much more than a regulator allows, so long as policy in the database always results in a compliant available spectrum response.

What are the requirements?  That's what we need to concentrate on.  

What requirements on the protocol does mesh or ad hoc or any other variation have on the protocol that we have not yet captured?

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 26 Jul 2011 13:32:34 -0400

+1  Brian is politically correct.  :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Tuesday, July 26, 2011 12:39 PM
To: Rex Buddenberg
Cc: [email-masked]
Subject: Re: [paws] New ID including further use cases for PAWS WG

Are you kidding?

The public safety guys refused to allow this to be shared with the carriers,
with them getting it on a priority basis.
The original idea was that a carrier would win an auction, build an LTE
network, and let public safety use it on a priority basis (there were lots
of variations - public safety gets priority use on all of it with consumer
use of all of it on a non priority basis, public safety gets exclusive use
of some and priority use of the rest,.).  Not acceptable.

They demand exclusive use.  They would never agree to shared use, and
especially unlicensed shared use.

That being said, our charter is for band-independent, phy-independent,
nation-independent protocols.  So, non-700Mhz is in scope.  Non-US is
definitely in scope.  Mesh, insofar as the protocol between a device and a
database is affected by the fact that it's mesh, is in scope, and the
limitations of the FCC rules isn't relevant.  The protocol can allow much
more than a regulator allows, so long as policy in the database always
results in a compliant available spectrum response.

What requirements on the protocol does mesh or ad hoc or any other variation
have on the protocol that we have not yet captured?

Brian

On Jul 26, 2011, at 12:06 PM, Rex Buddenberg wrote:

>>>>>> including this. It is an important one, that can also be used for
PPDR
>>>>>> *)

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 26 Jul 2011 13:42:22 -0400

Given the way the FCC works you can be absolutely certain of a "lengthy
delay" or in other terms 'comment period' before any changes are made.  

Very similar to the way the IETF works these days. 

Regards,
Scott

---

From: Teco Boot <[email-masked]>
Date: Tue, 26 Jul 2011 23:39:20 +0200

Op 26 jul 2011, om 18:39 heeft Rosen, Brian het volgende geschreven:

snip

> What requirements on the protocol does mesh or ad hoc or any other variation have on the protocol that we have not yet captured?

Let's start with the ad hoc network use case, e.g. emergency scenario 
with failing infrastructure and using PAWS for first responders. From 
that, we check the list of requirements. Using licensed / unlicensed 
spectrum for this use case is not our business. It is about using 
spectrum more dynamically, and how PAWS can help. My experience is 
that regulators are keen on this use case. Others are more the 
followers.

Teco