Subject: [paws] New indoor and M2M use cases, revision of DB discovery use case

From: <[email-masked]>
Date: Mon, 17 Oct 2011 09:49:34 +0100

Hi Scott, all

I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-00.txt proposes revision of the database discovery use case, two new use cases for indoor networking and machine to machine communications, and a set of requirements that drop out of all the use cases included so far in the working document. These especially address the UK Ofcom requirements as currently known. Also, a definition is proposed for the term 'device ID' which we suggest should be used throughout the use cases and requirements for consistency in place of terms such as 'model ID' and 'FCC ID'. This Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Carlos Zuniga (Interdigital). We would welcome comments made to the reflector on these proposals. We are willing to present in Taipei if it would be helpful in providing further explanation to the content in the document.

Regards

Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital)

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 11:00:05 +0100

Thanks very much for your comments which give food for thought. I've considered these in the context of the requirements for a protocol for TVWS database systems, the subject of this reflector.

Taking your points one by one:

1)      Defining the master device location - yes the regulator wants to know the location of the radiating antenna of the master device. For consumer installed equipment, such as an access point for home networking, the location of any  GPS receive antenna will be pretty close to (or potentially could share an antenna with) the TVWS antenna. Bearing in mind the granularity of the protection contours provided for the TV transmissions and the use of 100m pixels in UK, this will be more than adequate. I don't know what system would have a master device located miles from its transmitting antenna (an example you gave), but we can expect that such a system would be professionally installed, and the installer would configure the device location to be that of the antenna. Mostly this is of concern to the regulator and is outside the scope of PAWS, as the protocol just sends the lat-long coordinates to the database.

2)      Determining a master's location - yes I can envisage that professionally installed rural broadband systems (for example) could have their locations entered by an installer, triangulated over other wireless technologies or derived from other known location data or by other means. GSP is not mandated. In my view these are all covered by the process of a master device "determining" its location. Where location is entered manually, the potential for deliberate or accidental entry of incorrect information needs to be guarded against in system design (but is outside the scope of PAWS).

3)      No entity really "knows its location" - you are getting philosophical now! Yes it's estimated, but see my answer to (1) for the accuracy required.

4)      Security - thanks for the pointers. I am highly confident that there are appropriate security solutions out there, which the PAWS protocol can point to. We can address this when we get to the solution phase.

Andy

From: Richard Roy [mailto:[email-masked]]
Sent: 18 October 2011 08:39
To: Sago,AJ,Andy,COD R; [email-masked]; [email-masked]
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use case

I read with great interest your IETF draft.  I had a few thoughts I thought I'd share with you:

1)     How is the location of the master device defined?  Is it the location of the GPS antenna, the box itself, or perhaps the location of the TVWS transmitting antenna (its phase center actually).  I claim behind door three is the prize.  No regulator cares where the GPS antenna is located.  It's not transmitting anything ... yet.  No one cares where the master box is located; in can be miles from the transmitting antenna.  It's the location of the TVWS transmitting antenna that counts.
2)     Why does a master box have to be able to "determine" its location? (See 1)) It should be sufficient to just "know it" by any means not specified in any standard.
3)     No entity really "knows its location".  It estimates its location relative to some previously agreed upon coordinate system (including the fourth dimension of time a la GPS) and should also be estimating the covariance matrix of the estimation error as do all GPS systems.  It is this covariance matrix (really the upper triangular part of the square root of the covariance matrix if you want to get down to the details) that is the critical statistical information that needs to be transmitted along with the estimated location.
4)     FYI ... the security system described in this use case is the same as the one being developed by IEEE 1609.2/ETSI TCITS WG5/TC204 WG17 SWG7 and standards have been and are being written.  You might want to contact these groups for more info.

I hope this is helpful.

Cheers,

RR

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, October 17, 2011 1:50 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Scott, all

Regards

---

From: Andrew Gowans <[email-masked]>
Date: Wed, 19 Oct 2011 10:44:07 +0000

Hi Scott, all,

Although I am not a co-signatory of this document, myself and colleagues from Ofcom have made comments to the authors of this submission during the drafting process. As we in Ofcom are still in the process of confirming the details of our proposed requirements for the interaction between the WSD and the Geo-location Databases we felt it was not right at this time for us to be co-signatory on this document as some of our requirements may vary slightly from those presented in the document after our final analysis is completed. I am hoping that myself or a colleague will be in a position to provide a formal update of our progress on the proposed requirements to the IETF PAWS group in the near future.

Best Regards

Andy Gowans

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 17 October 2011 09:50
To: [email-masked]; [email-masked]
Subject: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Scott, all

Regards

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: <[email-masked]>
Date: Tue, 25 Oct 2011 20:38:36 +0000

Hi Andy, Mike & Juan Carlos,

Thank you for providing the I-D. After review I have a few comments.

1. The proposed revision to the database discovery use case does simplify the text and introduces the "listing" method from the UK. These changes make sense to me. The revision also removes the option for a pre-programmed address of a trusted database. I believe this is an important option and should remain in the I-D. A possible remedy is to remove  "In the simplest case…" which might mistakenly imply some preference to this solution, and note this to be an option.

2. In the Indoor Networking use case, I suggest to remove step 7 which describes updating the database with the selections made by the master device. I personally see merit in this capability. However, following previous discussions on this mail list, and after review of our Charter, I believe this step to update the database with information is not within our current scope; I am planning to remove similar steps from other use cases in the next update. The issue of scope is merely my personal opinion.

3. In the M2M use case, would you consider the following revisions:

[First paragraph]
"In this use case, each "machine" includes a white space slave device and can be located anywhere, fixed or on the move. Each machine needs to have connectivity to the internet and or to other machines in the vicinity. Machine communication over a TVWS channel, whether to a master device or to another machine (slave device), is under the control of a master device. This deployment scenario is typically characterized by a master device with internet connectivity by some connection that does not utilize TV white space. Figure 2…"

[Step 6]
6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. Further signaling can take place outside  scope of PAWS to establish direct links among those slave devices that have associated with the master device.

[Step 7]
Propose to remove this step for same reasons as discussed in Indoor Networking use case.

Regards,
Scott

From: "ext [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 17 Oct 2011 09:49:34 +0100
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Database Device <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, Juan Zuniga <[email-masked]<mailto:[email-masked]>>
Subject: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Scott, all

I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-00.txt proposes revision of the database discovery use case, two new use cases for indoor networking and machine to machine communications, and a set of requirements that drop out of all the use cases included so far in the working document. These especially address the UK Ofcom requirements as currently known. Also, a definition is proposed for the term ‘device ID’ which we suggest should be used throughout the use cases and requirements for consistency in place of terms such as ‘model ID’ and ‘FCC ID’. This Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Carlos Zuniga (Interdigital). We would welcome comments made to the reflector on these proposals. We are willing to present in Taipei if it would be helpful in providing further explanation to the content in the document.

Regards

---

From: <[email-masked]>
Date: Tue, 25 Oct 2011 20:41:56 +0000

Hello Andy,

Thank you for commenting to the authors and participation in the development of the PAWS specifications. Your input is appreciated and will help ensure PAWS may be deployed on a global scale. I look forward to a formal update from Ofcom in the near future.

Kind Regards,
Scott

From: ext Andrew Gowans <[email-masked]<mailto:[email-masked]>>
Date: Wed, 19 Oct 2011 10:44:07 +0000
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Database Device <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Scott, all,

Best Regards

Andy Gowans

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 17 October 2011 09:50
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Scott, all

Regards

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 14:39:37 +0000

Scott

Thanks for your comments on our joint submission. Unfortunately I am not in full agreement with your position, please see my comments in-line.

Regards

Andy

From: [email-masked] [mailto:[email-masked]]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; [email-masked]
Cc: Fitch,MR,Michael,DES8 R; [email-masked]
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

1. The proposed revision to the database discovery use case does simplify the text and introduces the "listing" method from the UK. These changes make sense to me. The revision also removes the option for a pre-programmed address of a trusted database. I believe this is an important option and should remain in the I-D. A possible remedy is to remove  "In the simplest case..." which might mistakenly imply some preference to this solution, and note this to be an option.

[Andy Sago] The text in our submission mainly addresses the UK requirements, which don't currently anticipate a fixed IP address or url for a database. Personally I feel a fixed address would have some drawbacks so I didn't include this method in the submission. As you are stating you require it, I'm happy for it to remain as an option.

[Andy Sago] I have to disagree, both with removing this step here and with removing similar steps in other use cases. Firstly, as I understand it FCC and Canada already require the database to know the details of some links (e.g. rural broadband) and this requirement could be fulfilled by having the master device report back directly to the database. The recent 802.22 requirements posted to the reflector also ask for this. Secondly, UK may require this facility too - at present we don't yet have their final list of requirements. Thirdly, a database operator may require this facility in order to offer value added services. The operators in the UK are currently unknown (no but my company could be a prospective database operator, so I am requesting this facility. This is certainly within the scope of PAWS (fulfilling the requirements of database operators is specifically mentioned in the Charter, viz. "the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors").

[First paragraph]
"In this use case, each "machine" includes a white space slave device and can be located anywhere, fixed or on the move. Each machine needs to have connectivity to the internet and or to other machines in the vicinity. Machine communication over a TVWS channel, whether to a master device or to another machine (slave device), is under the control of a master device. This deployment scenario is typically characterized by a master device with internet connectivity by some connection that does not utilize TV white space. Figure 2..."

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

[Andy Sago] Disagree, for same reasons as for the Indoor Networking use case.

Regards,
Scott

Hi Scott, all

Regards

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 15:28:18 +0000

Hi Andy,

Thank you for your reply. As said, I do favor to keep the possibility for devices to update information in the database, my concern is merely to operate within our guidelines. You mention below that FCC and Canada require the database to know the details of some links, are you able to cite a reference? My personal opinion is that PAWS should accommodate all regulatory requirements.

The updated I-D must be uploaded in a few hours, unfortunately not much time remains to include discussions from the email list in this draft.

Regards,
Scott

From: "ext [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 31 Oct 2011 14:39:37 +0000
To: Database Device <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, Juan Zuniga <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use case

Scott

Regards

Andy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; [email-masked]<mailto:[email-masked]>
Cc: Fitch,MR,Michael,DES8 R; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

[Andy Sago] The text in our submission mainly addresses the UK requirements, which don’t currently anticipate a fixed IP address or url for a database. Personally I feel a fixed address would have some drawbacks so I didn’t include this method in the submission. As you are stating you require it, I’m happy for it to remain as an option.

[Andy Sago] I have to disagree, both with removing this step here and with removing similar steps in other use cases. Firstly, as I understand it FCC and Canada already require the database to know the details of some links (e.g. rural broadband) and this requirement could be fulfilled by having the master device report back directly to the database. The recent 802.22 requirements posted to the reflector also ask for this. Secondly, UK may require this facility too – at present we don’t yet have their final list of requirements. Thirdly, a database operator may require this facility in order to offer value added services. The operators in the UK are currently unknown (no but my company could be a prospective database operator, so I am requesting this facility. This is certainly within the scope of PAWS (fulfilling the requirements of database operators is specifically mentioned in the Charter, viz. “the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors”).

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

---

From: Andrew Gowans <[email-masked]>
Date: Mon, 31 Oct 2011 16:06:18 +0000

Scott/All,

I can confirm that Andy Sago is correct in that Ofcom have not confirmed what our final requirements may be regarding the need for a return channel as a regulatory requirement or not. I would say at this stage there is no harm in keeping it in the document being taken forward as it seems that it will be within your guidelines if any regulator requires it in the future. I take it these elements can be treated like other requirements that may be region or country specific. I say this in the knowledge that the current proposals from Ofcom will require different requirements from that of the US proposals hence there will have to a master set of requirements which will more than likely be reduced to a subset of the requirements dependent upon each regulatory domain.

Best regards

Andy  Gowans

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 31 October 2011 15:28
To: [email-masked]; [email-masked]
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Andy,

Regards,
Scott

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 31 Oct 2011 12:50:34 -0400

Andy,
In reference to 2. below,  The FCC does not have any rule  that a radio report it's channel use to a DB. There has been no comment/concern about this in our TVWS database trial. I agree that it is nice to have and could be the basis of value added services, but it is not explicitly required. I could not find any "requirement" in the Canadian proposal either.
Regards,
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 31 Oct 2011 10:39:37 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 16:51:15 +0000

Scott

So Ofcom has confirmed below that there could be a potential UK requirement, which shouldn't be shut out at this stage. As for providing a reference for the US and Canadian requirements, I am hardly the best placed person on this reflector to comment, but my understanding is that the FCC document on the Part 0 and Part 15 rules for "Unlicensed Operation in the TV Broadcast Bands; Final Rule" http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf specifically expects databases may perform additional functions such as "tracking active channel use if reported by the TV bands device", hence the PAWS protocol should enable this. I reproduce below the relevant paragraph:

Additional Service Features
73. Decision. Database administrators
may perform additional functions
besides those required by the rules, such
as tracking active channel use if
reported by the TV bands device, or
sending additional information to a TV
bands device to enable it to determine
the ''best'' available channel to use. Such
functions are not prohibited by the
rules, and the ability to add additional
functionality could allow multiple
database operators to distinguish their
services and could be useful in the
development of industry standards to
enable more efficient spectrum sharing.

I'm even less of an expert on Canada, but their August consultation at http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) "To meet these requirements, each white space device will need to provide data, including its location, to a database. This data would be retained for a period of time in order to provide a capability for after-the fact data audits of suspected interference cases." I think that, when this requirement is fully unpacked, the data needing to be retained by the database for audit purposes will include actual channel frequency used. Also, they are consulting on whether to move future high power Remote Rural Broadband Systems (RRBS) from the current licensed model to use of TV band devices with the geolocation database (p.17, "it is anticipated that white space devices could be readily adapted for operation under the current rules for RRBS"). These would require protection from other TVWS devices to provide a similar service to existing RRBS, so in practice the actual channel in use would need to be reported back to the database.

Regards

Andy

From: Andrew Gowans [mailto:[email-masked]]
Sent: 31 October 2011 16:06
To: [email-masked]; Sago,AJ,Andy,COD R; [email-masked]
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use case

Scott/All,

Best regards

Andy  Gowans

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 31 October 2011 15:28
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

Hi Andy,

Regards,
Scott

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

******************************************************************************************************************
For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk>

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 31 Oct 2011 12:58:14 -0400

Some other thoughts on the use cases discussion that this trail is related to.  (https://datatracker.ietf.org/doc/draft-zuniga-paws-uk-use-cases-and-requirements/)
Peter S.

3.2:   indoor networking
Step 3:  In the US, and probably Canada, there is no requirement for location uncertainty so this may have to be optional or have a default value. This impacts 4.1.7
step 7:  (radio reporting channel use to the DB) is not specified in any of the regulations we are aware of so this may have to be optional. 4.1.11 seems to contradict this statement.

3.3:  I can see a general concern with this Use Case from the Broadcasters. In the simple Master/Slave Use Cases there is a perceived coverage area of the master, based on it's power etc, which can be calculated into a buffer to ensure that neither the master or the slaves will interfere with an incumbent. However in the M2M case there is the implication of multi-hopping which could dramatically increase the distance of a slave from a master. Unless hopping is limited and the function of hopping is known there is no way to accurately compute the likely interference from the multi hopping slaves.

4.1: Requirements
10: In most cases the slave does not have location capability so how is it going to know that it has changed location? I don't know how a master can determine it's coverage area in a way that a slave can resolve this.  I also think this is irrelevant in many cases. If you consider a set of Access Points (masters) in a building a slave should be able to roam around and associate with any, or all of the Masters without having to go through a channel discovery process as all the channels it will use are validated by the masters.

4.2: Database
Most regulators include some requirement that the DB validate or authenticate a Device before providing it with a channel list. The FCC also requires that the DB be able to black list specific devices. This implies that a device may get a "no channels available" message because it is not permitted to use either the DB or TVWS. I know you cover security in 4.2, but the implication of failure is no channel list returned to the device.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 31 Oct 2011 12:51:15 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

Scott

So Ofcom has confirmed below that there could be a potential UK requirement, which shouldn’t be shut out at this stage. As for providing a reference for the US and Canadian requirements, I am hardly the best placed person on this reflector to comment, but my understanding is that the FCC document on the Part 0 and Part 15 rules for “Unlicensed Operation in the TV Broadcast Bands; Final Rule” http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf specifically expects databases may perform additional functions such as “tracking active channel use if reported by the TV bands device”, hence the PAWS protocol should enable this. I reproduce below the relevant paragraph:

the ‘‘best’’ available channel to use. Such

I’m even less of an expert on Canada, but their August consultation at http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) “To meet these requirements, each white space device will need to provide data, including its location, to a database. This data would be retained for a period of time in order to provide a capability for after-the fact data audits of suspected interference cases.” I think that, when this requirement is fully unpacked, the data needing to be retained by the database for audit purposes will include actual channel frequency used. Also, they are consulting on whether to move future high power Remote Rural Broadband Systems (RRBS) from the current licensed model to use of TV band devices with the geolocation database (p.17, “it is anticipated that white space devices could be readily adapted for operation under the current rules for RRBS”). These would require protection from other TVWS devices to provide a similar service to existing RRBS, so in practice the actual channel in use would need to be reported back to the database.

Regards

Andy

From: Andrew Gowans [mailto:[email-masked]]
Sent: 31 October 2011 16:06
To: [email-masked]<mailto:[email-masked]>; Sago,AJ,Andy,COD R; [email-masked]<mailto:[email-masked]>
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use case

Scott/All,

Best regards

Andy  Gowans

Hi Andy,

Regards,
Scott

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 17:02:00 +0000

Peter

Thanks, our emails crossed and I have suggested some indications from FCC and IC which might lead to this facility being needed. I think the fact that US has some databases up and running and implementing the minimum FCC rules shouldn't restrict the work in PAWS to develop a flexible and innovative protocol that is capable of addressing current and future requirements worldwide. I realise that is an impossible task when regulators are mostly still in consultation mode (or not even at that point yet), but we should read between the lines as much as possible.

Regards

Andy

From: Peter Stanforth [mailto:[email-masked]]
Sent: 31 October 2011 16:51
To: Sago,AJ,Andy,COD R; [email-masked]; [email-masked]
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

Andy,

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 31 Oct 2011 13:30:39 -0400

<as chair>
Whenever you start work, in the IETF and most standards groups, you need to start with a restricted goal, or you don't get anything done when it is needed.  Sometimes, you have to deal with the fact that the simple goal isn't as comprehensive as one would like, but it does get you to something faster.

Our charter controls what we do, and the notion of sharing the spectrum among secondary (WS device) users was discussed, and explicitly ruled out of scope for our first charter.

That limits us.  If it limits us too much (like we can't really meet anyones needs), then we can go to the IESG and request our charter to be expanded.  I don't believe we are at this stage.

So, for now, any mechanisms that attempt to share available spectrum among secondary users is OUT OF SCOPE.  We can anticipate future use and make sure our protocols and data structures are extensible to meet that need, but as of now, this whole subject is out of scope.

The way to get these discussions revved up again is to quickly meet our initial milestones (that is, get a database query protocol and data structures finalized) and then recharter to include this additional scope.

Could we therefore please focus our attention on requirements that don't include this notion.

Brian

On Oct 31, 2011, at 1:02 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Peter

Thanks, our emails crossed and I have suggested some indications from FCC and IC which might lead to this facility being needed. I think the fact that US has some databases up and running and implementing the minimum FCC rules shouldn’t restrict the work in PAWS to develop a flexible and innovative protocol that is capable of addressing current and future requirements worldwide. I realise that is an impossible task when regulators are mostly still in consultation mode (or not even at that point yet), but we should read between the lines as much as possible.

Regards

Andy

From: Peter Stanforth [mailto:[email-masked]]
Sent: 31 October 2011 16:51
To: Sago,AJ,Andy,COD R; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

Andy,

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

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

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 18:51:33 +0000

Thanks Peter, some comments inline (avoiding topics ruled out of scope by the Chair):

Regards

Andy

From: Peter Stanforth [mailto:[email-masked]]
Sent: 31 October 2011 16:58
To: Sago,AJ,Andy,COD R; [email-masked]; [email-masked]
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case

3.2:   indoor networking
Step 3:  In the US, and probably Canada, there is no requirement for location uncertainty so this may have to be optional or have a default value. [Andy Sago] Agreed, optional would be sensible. This impacts 4.1.7
step 7:  (radio reporting channel use to the DB) is not specified in any of the regulations we are aware of so this may have to be optional. 4.1.11 seems to contradict this statement.

3.3:  I can see a general concern with this Use Case from the Broadcasters. In the simple Master/Slave Use Cases there is a perceived coverage area of the master, based on it's power etc, which can be calculated into a buffer to ensure that neither the master or the slaves will interfere with an incumbent. However in the M2M case there is the implication of multi-hopping which could dramatically increase the distance of a slave from a master. Unless hopping is limited and the function of hopping is known there is no way to accurately compute the likely interference from the multi hopping slaves.
[Andy Sago] The key here is in Step 6. "The devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. Further signalling can then take place to establish direct links among those machines that have associated with the master device." So all slave devices are within range of a master, and the master can expand the location uncertainty (a method described by Ofcom for the UK case) to account for the area of coverage that encompasses all the slaves. Only after that, can the slaves talk slave-to-slave. It is implicit that the machines (perhaps utility meters) are not going to move far. Potentially mobile devices could be required to always maintain contact (listen only) with a master device, whilst transferring data slave-to-slave, or there could be other mechanisms to detect motion. These are policy issues for the regulator and not the domain of PAWS.

4.1: Requirements
10: In most cases the slave does not have location capability so how is it going to know that it has changed location? I don't know how a master can determine it's coverage area in a way that a slave can resolve this.  I also think this is irrelevant in many cases. If you consider a set of Access Points (masters) in a building a slave should be able to roam around and associate with any, or all of the Masters without having to go through a channel discovery process as all the channels it will use are validated by the masters.[Andy Sago]  See comment to 3.3 above.

4.2: Database
Most regulators include some requirement that the DB validate or authenticate a Device before providing it with a channel list. The FCC also requires that the DB be able to black list specific devices. This implies that a device may get a "no channels available" message because it is not permitted to use either the DB or TVWS. I know you cover security in 4.2, but the implication of failure is no channel list returned to the device.[Andy Sago]  Agreed. There might be an "Access Denied"  message. Databases might cover particular specialisms, e.g. rural broadband, so accessing the 'wrong' database might return "Access Denied" if there is no commercial agreement to use that database, at which point the master tries another database from the Ofcom list.

Scott

Regards

Andy

Scott/All,

Best regards

Andy  Gowans

Hi Andy,

Regards,
Scott

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 31 Oct 2011 15:57:05 -0400

Andy,
I understand your P2P use case (3.3) better now and your explanation deals with my concern. I have to think a little longer on the slave roaming around a cluster of masters (4.1) as it relates to slaves knowing, or needing to know, their location.
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 31 Oct 2011 14:51:33 -0400
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use case

Regards

Andy

3.2:   indoor networking

3.3:  I can see a general concern with this Use Case from the Broadcasters. In the simple Master/Slave Use Cases there is a perceived coverage area of the master, based on it's power etc, which can be calculated into a buffer to ensure that neither the master or the slaves will interfere with an incumbent. However in the M2M case there is the implication of multi-hopping which could dramatically increase the distance of a slave from a master. Unless hopping is limited and the function of hopping is known there is no way to accurately compute the likely interference from the multi hopping slaves.
[Andy Sago] The key here is in Step 6. “The devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. Further signalling can then take place to establish direct links among those machines that have associated with the master device.” So all slave devices are within range of a master, and the master can expand the location uncertainty (a method described by Ofcom for the UK case) to account for the area of coverage that encompasses all the slaves. Only after that, can the slaves talk slave-to-slave. It is implicit that the machines (perhaps utility meters) are not going to move far. Potentially mobile devices could be required to always maintain contact (listen only) with a master device, whilst transferring data slave–to-slave, or there could be other mechanisms to detect motion. These are policy issues for the regulator and not the domain of PAWS.

4.1: Requirements

4.2: Database
Most regulators include some requirement that the DB validate or authenticate a Device before providing it with a channel list. The FCC also requires that the DB be able to black list specific devices. This implies that a device may get a "no channels available" message because it is not permitted to use either the DB or TVWS. I know you cover security in 4.2, but the implication of failure is no channel list returned to the device.[Andy Sago]  Agreed. There might be an “Access Denied”  message. Databases might cover particular specialisms, e.g. rural broadband, so accessing the ‘wrong’ database might return “Access Denied” if there is no commercial agreement to use that database, at which point the master tries another database from the Ofcom list.

Scott

Regards

Andy

Scott/All,

Best regards

Andy  Gowans

Hi Andy,

Regards,
Scott

Scott

Regards

Andy

[First paragraph]

[Andy Sago] Agreed

[Step 6]

[Andy Sago] Agreed

[Step 7]

Regards,
Scott

Hi Scott, all

Regards