From michael.fitch@bt.com Mon Aug 1 08:42:32 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6B821F8C42 for ; Mon, 1 Aug 2011 08:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfV-UAOzDS8c for ; Mon, 1 Aug 2011 08:42:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id DED1521F8C41 for ; Mon, 1 Aug 2011 08:42:29 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 1 Aug 2011 16:42:35 +0100 Received: from EVMHT35-UKDY.domain1.systemhost.net (193.113.31.60) by EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 1 Aug 2011 16:42:35 +0100 Received: from EMV35-UKDY.domain1.systemhost.net ([169.254.1.110]) by EVMHT35-UKDY.domain1.systemhost.net ([193.113.31.60]) with mapi; Mon, 1 Aug 2011 16:42:35 +0100 From: To: Date: Mon, 1 Aug 2011 16:42:33 +0100 Thread-Topic: draft-lei-paws-overview-usecases-00.txt Thread-Index: AcxQYaFdJtjaH9IGS0OW4FVa2jr0jA== Message-ID: <69A7E364B918F949829C3CD4FF25994E09A6EEC905@EMV35-UKDY.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_69A7E364B918F949829C3CD4FF25994E09A6EEC905EMV35UKDYdoma_" MIME-Version: 1.0 Subject: [paws] draft-lei-paws-overview-usecases-00.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:42:32 -0000 --_000_69A7E364B918F949829C3CD4FF25994E09A6EEC905EMV35UKDYdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all This is the first contribution to the mailing list from ourselves at BT, so= please forgive any mistakes with the 'protocol'. We refer to the document 'draft-lei-paws-overview-usecases-00.txt' and woul= d like to make some comments. We are also happy to become involved in the f= urther drafting of the document if appropriate. 1. Introduction The use-cases mentioned here are Rural Broadband Access and location-based = services, but these are not the ones expanded upon in section 3. We need so= me better alignment here I think. We are happy to propose some text. We wo= uld rather avoid the use of 'WiFi' 'super-WiFi' in this document, as it imp= lies a particular use of WiFi protocols and the document shouldn't pronounc= e on such things. 2. Terminology - the database should return a list of available chann= els and maximum transmit powers [and optionally directional information] 3. Use Cases. The use-cases of interest to us are Rural Broadband (no= t-spots), Dynamic Backhaul (for traditional WiFi hot spots or for femto-cel= ls / micro-cells), indoor networking (called in this document super-WiFi) = and Machine to Machine. These should be expanded in later parts of section = 3, ie 3.1, 3.2 etc. , except we should drop the super-WiFi tag. At present, 3.1 addresses indoor networking, 3.2 is TVWS ad-hoc networking= and 3.3 is TD-LTE MBMS. These last two are not even mentioned in the intro= duction (section 1) or in the introductory paragraph of section 3. I propose we have the following expanded structure: 3.1 - Rural Broadband 3.2 - Indoor Networking 3.3 - Dynamic Backhaul 3.4 - Machine to machine 3.5 - Ad-hoc networking 3.6 - MBMS (or more broadly, cellular extension ?) We offer to contribute text to the new sections 3.1, 3.2, 3.3, 3.4. 4. Requirements We need to add a confidence interval to the location accuracy. Currently, G= PS has only 70% at 50m I believe. We should take into account directivity of antennas at the master and slave= stations Other countries will use this (not just the US) so we need to expand beyond= FCC We should not tie the document to GPS, as there are other techniques for de= termining location. Best wishes Michael Fitch and Richard MacKenzie BT --_000_69A7E364B918F949829C3CD4FF25994E09A6EEC905EMV35UKDYdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

This = is the first contribution to the mailing list from ourselves at BT, so plea= se forgive any mistakes with the ‘protocol’.

 

We refer to the = document ‘draft-lei-paws-overview-usecases-00.txt’ and would li= ke to make some comments. We are also happy to become involved in the furth= er drafting of the document if appropriate.

 

1.   =     Introduction

The use-cases mentioned here are Rural Broadband Acc= ess and location-based services, but these are not the ones expanded upon i= n section 3. We need some better alignment here I think. We are happy to pr= opose some text.  We would rather avoid the use of ‘WiFi’ = ‘super-WiFi’ in this document, as it implies a particular use o= f WiFi protocols and the document shouldn’t pronounce on such things.=

 

<= ![if !supportLists]>2.       = Terminology – the database should return a list of availabl= e channels and maximum transmit powers [and optionally directional informat= ion]

3.  &nbs= p;    Use Cases. The use-cases of in= terest to us are Rural Broadband (not-spots), Dynamic Backhaul (for traditi= onal WiFi hot spots or for femto-cells / micro-cells),  indoor network= ing (called in this document super-WiFi) and Machine to Machine. These shou= ld be expanded in later parts of section 3, ie 3.1, 3.2 etc. , except we sh= ould drop the super-WiFi tag.  

 At present, 3.1 addresses= indoor networking, 3.2 is TVWS ad-hoc networking and 3.3 is TD-LTE MBMS. T= hese last two are not even mentioned in the introduction (section 1) or in = the introductory paragraph of section 3.
I propose we have the followin= g expanded structure:

3.1   – Rural Bro= adband

3.2&n= bsp;  – Indoor Networking

=

3.3   – Dynamic Backhaul

3.4   – = Machine to machine

3.5   – Ad-hoc networking

3.6  = ; – MBMS (or more broadly, cellular extension= ?)

&n= bsp;

We offer to= contribute text to the new sections 3.1, 3.2, 3.3, 3.4.

 

4. = ;      Requirements

We need to add a confidence interval to= the location accuracy. Currently, GPS has only 70% at 50m I believe.<= /o:p>

We should take into account directivit= y of antennas at the master and slave stations

Other countries will use this (not just the US) so we need to= expand beyond FCC

We should not= tie the document to GPS, as there are other techniques for determining loc= ation.

 

 

Be= st wishes

 

Michael Fitch and Richard MacKenzie

BT

&nb= sp;

= --_000_69A7E364B918F949829C3CD4FF25994E09A6EEC905EMV35UKDYdoma_-- From gerald.chouinard@crc.ca Tue Aug 2 05:37:31 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCCE21F8C3D for ; Tue, 2 Aug 2011 05:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8oFUji0h5jt for ; Tue, 2 Aug 2011 05:37:31 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id C14EB21F8C36 for ; Tue, 2 Aug 2011 05:37:30 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id C84D46B043D; Tue, 2 Aug 2011 08:37:35 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id B8E416B03B6; Tue, 2 Aug 2011 08:37:35 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id AA4116B03D4; Tue, 2 Aug 2011 08:37:35 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 31BD16B03B6; Tue, 2 Aug 2011 08:37:35 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id C3F096B1249; Tue, 2 Aug 2011 08:37:34 -0400 (EDT) Message-Id: <5.1.0.14.2.20110801173731.02a3e748@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Aug 2011 08:37:13 -0400 To: From: Gerald Chouinard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Cc: paws@ietf.org, Apurva Mody Subject: [paws] Rural Network use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:37:31 -0000 Scott, I appreciated your presentation on the Use Cases document last week in Quebec City. However, there is one thing that I am not fully comfortable with in the Rural Network case. Your assumption is that the rural networks will have been planned beforehand and frequencies will have been pre-assigned. This does not correspond to the assumption that we used in the development of the IEEE 802.22 Standard. The reason is that, in the context of a "license-exempt" ("unlicensed" in the US) environment where any competitor can come in and implement his base station and CPEs, a planned network implementation is possible in practice. Such pre-planning would apply to a frequency band licensed to a specific operator. Furthermore, protected low-power devices (e.g., wireless microphones) could pop up anywhere in the area and disable the frequencies that had been pre-planned for the network. No pre-planned frequency assignment of the networks in an area would allow an easy adaptation to such an event. Recognizing such limitation, a technique by which the various cells will be able to talk to each other through a self-coexistence mechanism to exchange information on the frequencies that they use and that they have as backup channels in case their current channel is disabled all of a sudden has been included in the 802.22 Standard (see Clause 7.20 "Self-coexistence" in the 802.22 Standard). Additionally, information on how the same channel can be shared by a number of cells, in case where no other channel is available in the area, is exchanged between these cells to share the transmission capacity among 802.22 WRAN cells on a frame-based TDM mechanism. This should be reflected in either modifying the current rural case by removing the assumption of a pre-planned network or adding a new rural case where a self-coexistence mechanism would be assumed, while keepnig the current rural case for "licensed band" type operation. Hope this helps. Regards, Gerald From brian.rosen@neustar.biz Tue Aug 2 06:07:44 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4221F8B95 for ; Tue, 2 Aug 2011 06:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss6QseHEs1i3 for ; Tue, 2 Aug 2011 06:07:43 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6433321F8B5B for ; Tue, 2 Aug 2011 06:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312290466; x=1627634445; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=indezBcqfIb7DA7fc29yI jwrmA1+ajXOwfQr4HK6VhA=; b=CAfP0WSubG4M5yS87qBwxayOntGcQ46I5xZMR UWpka0r/k2KyFdtGVM8XDNy2QBcv0Yli5ZysAJXMlxwKjgjdQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.48016940; Tue, 02 Aug 2011 09:07:44 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 2 Aug 2011 09:07:44 -0400 From: "Rosen, Brian" To: Gerald Chouinard Date: Tue, 2 Aug 2011 09:07:43 -0400 Thread-Topic: [paws] Rural Network use case Thread-Index: AcxRFSqhXDACNhzaSySiT9A+hn1Usg== Message-ID: <6DDF5647-79AA-40D4-9EA9-F5D6871D5067@neustar.biz> References: <5.1.0.14.2.20110801173731.02a3e748@imap.crc.ca> In-Reply-To: <5.1.0.14.2.20110801173731.02a3e748@imap.crc.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: a6Fs4bsWyfFDDG9u0eVw+g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Apurva Mody Subject: Re: [paws] Rural Network use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:07:44 -0000 While use cases can discuss co-existence, that aspect is out of scope for o= ur work at this time. =20 Of course, preplanned use of frequencies wouldn't require a database query,= so that would seem to be out of scope also. I personally don't think there is much difference between urban, suburban a= nd rural access in the part of the problem we are looking at in this work g= roup. The number of available channels might be larger, and the number of = protected devices might be smaller, but that is just a scale issue: the dat= abase query would be the same, and the response would be the same (modulo t= he length of the available spectrum response). Brian On Aug 2, 2011, at 8:37 AM, Gerald Chouinard wrote: > Scott, >=20 > I appreciated your presentation on the Use Cases document last week in=20 > Quebec City. However, there is one thing that I am not fully comfortable= =20 > with in the Rural Network case. Your assumption is that the rural networ= ks=20 > will have been planned beforehand and frequencies will have been=20 > pre-assigned. This does not correspond to the assumption that we used in= =20 > the development of the IEEE 802.22 Standard. The reason is that, in the= =20 > context of a "license-exempt" ("unlicensed" in the US) environment where= =20 > any competitor can come in and implement his base station and CPEs, a=20 > planned network implementation is possible in practice. Such pre-planning= =20 > would apply to a frequency band licensed to a specific operator.=20 > Furthermore, protected low-power devices (e.g., wireless microphones) cou= ld=20 > pop up anywhere in the area and disable the frequencies that had been=20 > pre-planned for the network. No pre-planned frequency assignment of the=20 > networks in an area would allow an easy adaptation to such an event. >=20 > Recognizing such limitation, a technique by which the various cells will = be=20 > able to talk to each other through a self-coexistence mechanism to exchan= ge=20 > information on the frequencies that they use and that they have as backup= =20 > channels in case their current channel is disabled all of a sudden has be= en=20 > included in the 802.22 Standard (see Clause 7.20 "Self-coexistence" in th= e=20 > 802.22 Standard). Additionally, information on how the same channel can = be=20 > shared by a number of cells, in case where no other channel is available = in=20 > the area, is exchanged between these cells to share the transmission=20 > capacity among 802.22 WRAN cells on a frame-based TDM mechanism. >=20 > This should be reflected in either modifying the current rural case by=20 > removing the assumption of a pre-planned network or adding a new rural ca= se=20 > where a self-coexistence mechanism would be assumed, while keepnig the=20 > current rural case for "licensed band" type operation. >=20 > Hope this helps. >=20 > Regards, >=20 > Gerald >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@crc.ca Tue Aug 2 08:53:09 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE34411E8084 for ; Tue, 2 Aug 2011 08:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCLx0Kabao0T for ; Tue, 2 Aug 2011 08:53:07 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 8E42C11E8082 for ; Tue, 2 Aug 2011 08:53:06 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id EA13C6B043E; Tue, 2 Aug 2011 11:53:09 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id D00136B03B6; Tue, 2 Aug 2011 11:53:09 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id C38CE6B03A6; Tue, 2 Aug 2011 11:53:09 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 8F42F6B03A6; Tue, 2 Aug 2011 11:53:05 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id 21B566B121F; Tue, 2 Aug 2011 11:53:05 -0400 (EDT) Message-Id: <5.1.0.14.2.20110802113720.02c43ed8@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Aug 2011 11:52:50 -0400 To: "Rosen, Brian" From: Gerald Chouinard In-Reply-To: <6DDF5647-79AA-40D4-9EA9-F5D6871D5067@neustar.biz> References: <5.1.0.14.2.20110801173731.02a3e748@imap.crc.ca> <5.1.0.14.2.20110801173731.02a3e748@imap.crc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Cc: "paws@ietf.org" , Apurva Mody Subject: Re: [paws] Rural Network use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:53:09 -0000 Brian, I agree with you that co-existence is not currently part of the mandate of the PAWS Working Group, although the protocol that you are developing could be used for this purpose as an add-on if the proper parameters are included (see my earlier reference to the work that the IEEE 802.19.1 is doing to deal with this aspect). My main point was that, in a license-exempt/unlicensed environment, assuming a pre-planned rural network does not hold because of the possible changes in the use of the spectrum by the primary users. The fact that competing operations looking for the same spectrum can happen is another reason for not assuming a static pre-planned frequency assignment for a rural network. By the way, all the material that I presented last week on the database interface primitives that the IEEE 802.22 Working Group has developed is contained in Clause 10.6 of the recently published IEEE Std 802.22-2011. You will probably find that what I included in my presentation is most likely all what is needed to be considered by the IETF-PAWS in its work. Gerald At 09:07 02-08-11 -0400, Rosen, Brian wrote: >While use cases can discuss co-existence, that aspect is out of scope for >our work at this time. > >Of course, preplanned use of frequencies wouldn't require a database >query, so that would seem to be out of scope also. > >I personally don't think there is much difference between urban, suburban >and rural access in the part of the problem we are looking at in this work >group. The number of available channels might be larger, and the number >of protected devices might be smaller, but that is just a scale issue: the >database query would be the same, and the response would be the same >(modulo the length of the available spectrum response). > >Brian > >On Aug 2, 2011, at 8:37 AM, Gerald Chouinard wrote: > > > Scott, > > > > I appreciated your presentation on the Use Cases document last week in > > Quebec City. However, there is one thing that I am not fully comfortable > > with in the Rural Network case. Your assumption is that the rural > networks > > will have been planned beforehand and frequencies will have been > > pre-assigned. This does not correspond to the assumption that we used in > > the development of the IEEE 802.22 Standard. The reason is that, in the > > context of a "license-exempt" ("unlicensed" in the US) environment where > > any competitor can come in and implement his base station and CPEs, a > > planned network implementation is possible in practice. Such pre-planning > > would apply to a frequency band licensed to a specific operator. > > Furthermore, protected low-power devices (e.g., wireless microphones) > could > > pop up anywhere in the area and disable the frequencies that had been > > pre-planned for the network. No pre-planned frequency assignment of the > > networks in an area would allow an easy adaptation to such an event. > > > > Recognizing such limitation, a technique by which the various cells > will be > > able to talk to each other through a self-coexistence mechanism to > exchange > > information on the frequencies that they use and that they have as backup > > channels in case their current channel is disabled all of a sudden has > been > > included in the 802.22 Standard (see Clause 7.20 "Self-coexistence" in the > > 802.22 Standard). Additionally, information on how the same channel > can be > > shared by a number of cells, in case where no other channel is > available in > > the area, is exchanged between these cells to share the transmission > > capacity among 802.22 WRAN cells on a frame-based TDM mechanism. > > > > This should be reflected in either modifying the current rural case by > > removing the assumption of a pre-planned network or adding a new rural > case > > where a self-coexistence mechanism would be assumed, while keepnig the > > current rural case for "licensed band" type operation. > > > > Hope this helps. > > > > Regards, > > > > Gerald > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From michael.fitch@bt.com Tue Aug 2 09:22:08 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC411E808A for ; Tue, 2 Aug 2011 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq1h0cUH0WxK for ; Tue, 2 Aug 2011 09:22:06 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E58E311E8083 for ; Tue, 2 Aug 2011 09:22:05 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 2 Aug 2011 17:22:06 +0100 Received: from EVMHT32-UKDY.domain1.systemhost.net (193.113.31.42) by EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 2 Aug 2011 17:22:05 +0100 Received: from EMV35-UKDY.domain1.systemhost.net ([169.254.1.110]) by EVMHT32-UKDY.domain1.systemhost.net ([193.113.31.42]) with mapi; Tue, 2 Aug 2011 17:22:05 +0100 From: To: , Date: Tue, 2 Aug 2011 17:22:04 +0100 Thread-Topic: [paws] Rural Network use case Thread-Index: AcxRFSqhXDACNhzaSySiT9A+hn1UsgAGtzqA Message-ID: <69A7E364B918F949829C3CD4FF25994E09A6EECB08@EMV35-UKDY.domain1.systemhost.net> References: <5.1.0.14.2.20110801173731.02a3e748@imap.crc.ca> <6DDF5647-79AA-40D4-9EA9-F5D6871D5067@neustar.biz> In-Reply-To: <6DDF5647-79AA-40D4-9EA9-F5D6871D5067@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org, apurva.mody@BAESYSTEMS.COM Subject: Re: [paws] Rural Network use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:22:08 -0000 Dear Brian Agreed, we would not want to assume that the rural case will have pre-plann= ed channels.=20 Michael -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: 02 August 2011 14:08 To: Gerald Chouinard Cc: paws@ietf.org; Apurva Mody Subject: Re: [paws] Rural Network use case While use cases can discuss co-existence, that aspect is out of scope for o= ur work at this time. =20 Of course, preplanned use of frequencies wouldn't require a database query,= so that would seem to be out of scope also. I personally don't think there is much difference between urban, suburban a= nd rural access in the part of the problem we are looking at in this work g= roup. The number of available channels might be larger, and the number of = protected devices might be smaller, but that is just a scale issue: the dat= abase query would be the same, and the response would be the same (modulo t= he length of the available spectrum response). Brian On Aug 2, 2011, at 8:37 AM, Gerald Chouinard wrote: > Scott, >=20 > I appreciated your presentation on the Use Cases document last week in=20 > Quebec City. However, there is one thing that I am not fully comfortable= =20 > with in the Rural Network case. Your assumption is that the rural networ= ks=20 > will have been planned beforehand and frequencies will have been=20 > pre-assigned. This does not correspond to the assumption that we used in= =20 > the development of the IEEE 802.22 Standard. The reason is that, in the= =20 > context of a "license-exempt" ("unlicensed" in the US) environment where= =20 > any competitor can come in and implement his base station and CPEs, a=20 > planned network implementation is possible in practice. Such pre-planning= =20 > would apply to a frequency band licensed to a specific operator.=20 > Furthermore, protected low-power devices (e.g., wireless microphones) cou= ld=20 > pop up anywhere in the area and disable the frequencies that had been=20 > pre-planned for the network. No pre-planned frequency assignment of the=20 > networks in an area would allow an easy adaptation to such an event. >=20 > Recognizing such limitation, a technique by which the various cells will = be=20 > able to talk to each other through a self-coexistence mechanism to exchan= ge=20 > information on the frequencies that they use and that they have as backup= =20 > channels in case their current channel is disabled all of a sudden has be= en=20 > included in the 802.22 Standard (see Clause 7.20 "Self-coexistence" in th= e=20 > 802.22 Standard). Additionally, information on how the same channel can = be=20 > shared by a number of cells, in case where no other channel is available = in=20 > the area, is exchanged between these cells to share the transmission=20 > capacity among 802.22 WRAN cells on a frame-based TDM mechanism. >=20 > This should be reflected in either modifying the current rural case by=20 > removing the assumption of a pre-planned network or adding a new rural ca= se=20 > where a self-coexistence mechanism would be assumed, while keepnig the=20 > current rural case for "licensed band" type operation. >=20 > Hope this helps. >=20 > Regards, >=20 > Gerald >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Tue Aug 2 23:08:32 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD93811E8070 for ; Tue, 2 Aug 2011 23:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+FGA44WiCFd for ; Tue, 2 Aug 2011 23:08:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02BFE21F8788 for ; Tue, 2 Aug 2011 23:08:31 -0700 (PDT) Received: by fxe6 with SMTP id 6so623480fxe.31 for ; Tue, 02 Aug 2011 23:08:39 -0700 (PDT) Received: by 10.223.159.137 with SMTP id j9mr9481227fax.64.1312351719632; Tue, 02 Aug 2011 23:08:39 -0700 (PDT) Received: from [10.87.47.157] ([80.187.219.21]) by mx.google.com with ESMTPS id g20sm296629fai.21.2011.08.02.23.08.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 23:08:38 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 3 Aug 2011 08:08:28 +0200 References: To: paws@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 06:08:32 -0000 Hi Scott, I have written down an practical use case for PAWS in an ad hoc network for emergency scenario's. Please comment. Thanks, Teco 3.x. Rapid deployed network for emergency scenarios Organizations involved in handling emergency operations often have a fully owned and controlled infrastructure, with dedicated spectrum, for day to day operation. However, lessons learned from recent disasters show such infrastructures are often highly affected by the disaster itself. To set up a replacement quickly, there is a need for fast reallocation of spectrum, where in certain cases spectrum can be freed for disaster relief. To utilize free or freed spectrum quickly and reliable, automation of allocation, assignment and configuration is needed. A preferred option is make use of a robust protocol, already adopted by radio manufacturers. This approach does in no way imply such organizations for disaster relief must compete on spectrum allocation with other white spaces users, but they can. A typical network topology would include wireless access links to the public Internet or private network, wireless ad hoc network radios working independent of a fixed infrastructure and satellite links for backup where lack of coverage, overload or outage of wireless access links occur. \|/ | ad hoc | |-|-------------| | Master node | |------------| \|/ | with | | Whitespace | | ad hoc /| backhaul link | | Database | | /-----/ |---------------| |------------| --|-------------/ | \ / | Master node | | | (--/--) | without | | ------( ) | backhaul link | | Wireless / Private \ ---------------\- | Access ( net or ) \ | \ Internet ) \ \|/ | -------( /\ \ | ad hoc | | (------) \--------- \ | | / | Other | \--|------------- /Satellite | nodes | | Master node | / Link ---------- | with |/ | backhaul link | ----------------- Figure x: Rapid deployed network with partly connected nodes In the ad hoc network, all nodes are master nodes in a way that they allocate RF channels from the white space database. However, the backhaul link could not be available to all nodes, such as depicted for the left node in figure x. To handle RF channel allocation for such nodes, a master node with a backhaul link relays or proxies the database query for them. So master nodes without a backhaul link follow the procedure as defined for clients. The ad hoc network radios utilise the provided RF channels. Details on forming and maintenance of the ad hoc network, including repair of segmented networks caused by segments operating on different RF channels, is out of scope of spectrum allocation. From brian.rosen@neustar.biz Wed Aug 3 05:38:43 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC4721F87D6 for ; Wed, 3 Aug 2011 05:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-jhoaPU0SlG for ; Wed, 3 Aug 2011 05:38:42 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DF21F87C6 for ; Wed, 3 Aug 2011 05:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312375133; x=1627715265; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=egg3mnJtX6Ds75lQoigE/ fNqRRX54cr9NtfGYflY2/A=; b=TwgsAqFHvRoS3EmsfMiVxlI85ZnryCAmiOXOG GE2WynwSLAyqFsaY9OCTuZSzVxgZDz+GicEXlj188T2Qc4NGQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.25466213; Wed, 03 Aug 2011 08:38:52 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 3 Aug 2011 08:38:52 -0400 From: "Rosen, Brian" To: Teco Boot Date: Wed, 3 Aug 2011 08:38:51 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxR2kyVmtrFIPK0QGm7zwXrHiCKDw== Message-ID: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: vJ8PKL5NLL2Zf9N+xe973Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:38:43 -0000 I think this is a good use case and brings up a new requirement: The protocol must cater for a query from one entity on behalf of another en= tity. =20 In many circumstances, this would be invisible to the protocol - the relay = client would simply relay packets or use some private protocol. However, i= n some circumstances we may need to know the identity of the requester as w= ell as the real client, so the actual requirement is to be able to carry tw= o identities. Brian On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > Hi Scott, >=20 > I have written down an practical use case for PAWS in an ad hoc > network for emergency scenario's. Please comment. >=20 > Thanks, Teco >=20 >=20 >=20 > 3.x. Rapid deployed network for emergency scenarios >=20 > Organizations involved in handling emergency operations often have=20 > a fully owned and controlled infrastructure, with dedicated spectrum,=20 > for day to day operation. However, lessons learned from recent=20 > disasters show such infrastructures are often highly affected by the=20 > disaster itself. To set up a replacement quickly, there is a need for=20 > fast reallocation of spectrum, where in certain cases spectrum can be=20 > freed for disaster relief. >=20 > To utilize free or freed spectrum quickly and reliable, automation of > allocation, assignment and configuration is needed. A preferred=20 > option is make use of a robust protocol, already adopted by radio > manufacturers. This approach does in no way imply such organizations > for disaster relief must compete on spectrum allocation with other=20 > white spaces users, but they can. >=20 > A typical network topology would include wireless access links to=20 > the public Internet or private network, wireless ad hoc network=20 > radios working independent of a fixed infrastructure and satellite=20 > links for backup where lack of coverage, overload or outage of=20 > wireless access links occur. >=20 > \|/ > | ad hoc > | > |-|-------------| > | Master node | |------------| > \|/ | with | | Whitespace | > | ad hoc /| backhaul link | | Database | > | /-----/ |---------------| |------------| > --|-------------/ | \ / > | Master node | | | (--/--) > | without | | ------( ) > | backhaul link | | Wireless / Private \ > ---------------\- | Access ( net or ) > \ | \ Internet ) > \ \|/ | -------( /\ > \ | ad hoc | | (------) \--------- > \ | | / | Other | > \--|------------- /Satellite | nodes | > | Master node | / Link ---------- > | with |/ > | backhaul link | > ----------------- >=20 >=20 > Figure x: Rapid deployed network with partly connected nodes >=20 >=20 > In the ad hoc network, all nodes are master nodes in a way that > they allocate RF channels from the white space database. However, > the backhaul link could not be available to all nodes, such as > depicted for the left node in figure x. To handle RF channel=20 > allocation for such nodes, a master node with a backhaul link=20 > relays or proxies the database query for them. So master nodes=20 > without a backhaul link follow the procedure as defined for=20 > clients. >=20 > The ad hoc network radios utilise the provided RF channels. Details=20 > on forming and maintenance of the ad hoc network, including repair=20 > of segmented networks caused by segments operating on different=20 > RF channels, is out of scope of spectrum allocation. >=20 >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Wed Aug 3 05:59:27 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2510421F87F0 for ; Wed, 3 Aug 2011 05:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0ePnnnAVQFz for ; Wed, 3 Aug 2011 05:59:26 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7D31821F85A1 for ; Wed, 3 Aug 2011 05:59:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SgohQ7kBkYAkBcE2+UXXWLK3ysdCunCi+/jFYEZA295xf77G2YjCYqlMosEVotc3; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qob2r-0003y7-D0; Wed, 03 Aug 2011 08:59:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: Date: Wed, 3 Aug 2011 05:59:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Teco Boot , Brian Rosen , scott.probasco@nokia.com X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad869aacc65c5063dc2f3d9d194f628740a0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:59:27 -0000 On Aug 2, 2011, at 11:08 PM, Teco Boot wrote: > Hi Scott, > > I have written down an practical use case for PAWS in an ad hoc > network for emergency scenario's. Please comment. > > Thanks, Teco > > > > 3.x. Rapid deployed network for emergency scenarios > > Organizations involved in handling emergency operations often have > a fully owned and controlled infrastructure, with dedicated spectrum, > for day to day operation. However, lessons learned from recent > disasters show such infrastructures are often highly affected by the > disaster itself. To set up a replacement quickly, there is a need for > fast reallocation of spectrum, where in certain cases spectrum can be > freed for disaster relief. > > To utilize free or freed spectrum quickly and reliable, automation of > allocation, assignment and configuration is needed. A preferred > option is make use of a robust protocol, already adopted by radio > manufacturers. This approach does in no way imply such organizations > for disaster relief must compete on spectrum allocation with other > white spaces users, but they can. > > A typical network topology would include wireless access links to > the public Internet or private network, wireless ad hoc network > radios working independent of a fixed infrastructure and satellite > links for backup where lack of coverage, overload or outage of > wireless access links occur. > > \|/ > | ad hoc > | > |-|-------------| > | Master node | |------------| > \|/ | with | | Whitespace | > | ad hoc /| backhaul link | | Database | > | /-----/ |---------------| |------------| > --|-------------/ | \ / > | Master node | | | (--/--) > | without | | ------( ) > | backhaul link | | Wireless / Private \ > ---------------\- | Access ( net or ) > \ | \ Internet ) > \ \|/ | -------( /\ > \ | ad hoc | | (------) \--------- > \ | | / | Other | > \--|------------- /Satellite | nodes | > | Master node | / Link ---------- > | with |/ > | backhaul link | > ----------------- > > > Figure x: Rapid deployed network with partly connected nodes > > > In the ad hoc network, all nodes are master nodes in a way that > they allocate RF channels from the white space database. However, > the backhaul link could not be available to all nodes, such as > depicted for the left node in figure x. To handle RF channel > allocation for such nodes, a master node with a backhaul link > relays or proxies the database query for them. So master nodes > without a backhaul link follow the procedure as defined for > clients. > > The ad hoc network radios utilise the provided RF channels. Details > on forming and maintenance of the ad hoc network, including repair > of segmented networks caused by segments operating on different > RF channels, is out of scope of spectrum allocation. > > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Wed Aug 3 06:03:26 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC94621F8B4C for ; Wed, 3 Aug 2011 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYu6dAQO22Ln for ; Wed, 3 Aug 2011 06:03:25 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 68BB921F8B4B for ; Wed, 3 Aug 2011 06:03:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=eWwuhLaB3HaULDUePYlu5SUyMkFP6Z9Df9C6b5skyn9cEXUfMXIuroSzoXJznjdB; h=Received:From:Mime-Version:Content-Type:Subject:Date:References:Cc:To:Message-Id:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qob6j-0000FL-4V; Wed, 03 Aug 2011 09:03:33 -0400 From: Nancy Bravin Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--938037179 Date: Wed, 3 Aug 2011 06:03:31 -0700 References: <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> To: Brian Rosen , scott.probasco@nokia.com, Teco Boot Message-Id: <309E6A2A-2628-4E10-96C7-8240024708F2@earthlink.net> X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8649569f480d0028f06f1f8ef0531e9950350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] Fwd: PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:03:26 -0000 --Apple-Mail-2--938037179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry for the missing info on the last email=85here you go. N Begin forwarded message: > From: Nancy Bravin > Date: August 3, 2011 5:58:02 AM PDT > To: "Rosen, Brian" > Subject: Re: [paws] PAWS use case: ad hoc network for emergency = scenario's >=20 > Brian, Scott and Teco,=20 > What happens when the systems WS or otherwise are overloaded with = calls, emails from around the world and the database can not handle the = traffic > let alone the priority for first responders=85is there no transfer to = other regions for 1. Information that someone is alive, a posting as it = were? 2. NO power > or no infrastucture left? 3. Two identities are an important = ingredient, but maybe HAM operators should be part of this as they have = been in the past > picking up others by voice and transferring that information? Should = they not have an identifier?=20 > If you look at any disaster in Northern Japan, Indonesia, flooding = around the world, how will this work? What will the backhaul be and > a fixed or replaced or temporary system can take a while if conditions = make getting to locations impossible? ANd should some have to move to = higher ground > and abandon any working equipment assuming power and something to = receive the signal?=20 > I think this has some great thoughts, but seems to be more relative in = the US, or EU, what about developing countries, will this work as well? > Thanks for your time, SIncerely, Nancy=20 >=20 >=20 > On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote: >=20 >> I think this is a good use case and brings up a new requirement: >> The protocol must cater for a query from one entity on behalf of = another entity. =20 >>=20 >> In many circumstances, this would be invisible to the protocol - the = relay client would simply relay packets or use some private protocol. = However, in some circumstances we may need to know the identity of the = requester as well as the real client, so the actual requirement is to be = able to carry two identities. >>=20 >> Brian >>=20 >> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>=20 >>> Hi Scott, >>>=20 >>> I have written down an practical use case for PAWS in an ad hoc >>> network for emergency scenario's. Please comment. >>>=20 >>> Thanks, Teco >>>=20 >>>=20 >>>=20 >>> 3.x. Rapid deployed network for emergency scenarios >>>=20 >>> Organizations involved in handling emergency operations often have=20= >>> a fully owned and controlled infrastructure, with dedicated = spectrum,=20 >>> for day to day operation. However, lessons learned from recent=20 >>> disasters show such infrastructures are often highly affected by the=20= >>> disaster itself. To set up a replacement quickly, there is a need = for=20 >>> fast reallocation of spectrum, where in certain cases spectrum can = be=20 >>> freed for disaster relief. >>>=20 >>> To utilize free or freed spectrum quickly and reliable, automation = of >>> allocation, assignment and configuration is needed. A preferred=20 >>> option is make use of a robust protocol, already adopted by radio >>> manufacturers. This approach does in no way imply such organizations >>> for disaster relief must compete on spectrum allocation with other=20= >>> white spaces users, but they can. >>>=20 >>> A typical network topology would include wireless access links to=20 >>> the public Internet or private network, wireless ad hoc network=20 >>> radios working independent of a fixed infrastructure and satellite=20= >>> links for backup where lack of coverage, overload or outage of=20 >>> wireless access links occur. >>>=20 >>> \|/ >>> | ad hoc >>> | >>> |-|-------------| >>> | Master node | |------------| >>> \|/ | with | | Whitespace | >>> | ad hoc /| backhaul link | | Database | >>> | /-----/ |---------------| |------------| >>> --|-------------/ | \ / >>> | Master node | | | (--/--) >>> | without | | ------( ) >>> | backhaul link | | Wireless / Private \ >>> ---------------\- | Access ( net or ) >>> \ | \ Internet ) >>> \ \|/ | -------( /\ >>> \ | ad hoc | | (------) \--------- >>> \ | | / | Other | >>> \--|------------- /Satellite | nodes | >>> | Master node | / Link ---------- >>> | with |/ >>> | backhaul link | >>> ----------------- >>>=20 >>>=20 >>> Figure x: Rapid deployed network with partly connected nodes >>>=20 >>>=20 >>> In the ad hoc network, all nodes are master nodes in a way that >>> they allocate RF channels from the white space database. However, >>> the backhaul link could not be available to all nodes, such as >>> depicted for the left node in figure x. To handle RF channel=20 >>> allocation for such nodes, a master node with a backhaul link=20 >>> relays or proxies the database query for them. So master nodes=20 >>> without a backhaul link follow the procedure as defined for=20 >>> clients. >>>=20 >>> The ad hoc network radios utilise the provided RF channels. Details=20= >>> on forming and maintenance of the ad hoc network, including repair=20= >>> of segmented networks caused by segments operating on different=20 >>> RF channels, is out of scope of spectrum allocation. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 --Apple-Mail-2--938037179 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Sorry = for the missing info on the last email=85here you go. = N

Begin forwarded message:

From: Nancy Bravin <nbravin@earthlink.net>
Date: August 3, 2011 5:58:02 AM PDT
To: "Rosen, Brian" = <Brian.Rosen@neustar.biz>
Subject: Re: [paws] PAWS use case: ad hoc network for = emergency scenario's

Brian, Scott and Teco, =
What happens when the systems WS or otherwise are overloaded with = calls, emails from around the world and the database can not handle the = traffic
let alone the priority for first responders=85is there no = transfer to other regions for 1. Information that someone is alive, a = posting as it were? 2. NO power
or no infrastucture left? 3. Two = identities are an important ingredient, but maybe HAM operators should = be part of this as they have been in the past
picking up others by = voice and transferring that information? Should they not have an = identifier?
If you look at any disaster in Northern Japan, = Indonesia, flooding around the world, how will this work? What will the = backhaul be and
a fixed or replaced or temporary system can take a = while if conditions make getting to locations impossible? ANd should = some have to move to higher ground
and abandon any working equipment = assuming power and something to receive the signal?
I think this has = some great thoughts, but seems to be more relative in the US, or EU, = what about developing countries, will this work as well?
Thanks for = your time, SIncerely, Nancy


On Aug 3, 2011, at 5:38 AM, = Rosen, Brian wrote:

I think this is a = good use case and brings up a new = requirement:
The protocol must = cater for a query from one entity on behalf of another entity. =  

In many = circumstances, this would be invisible to the protocol - the relay = client would simply relay packets or use some private protocol. =  However, in some circumstances we may need to know the identity of = the requester as well as the real client, so the actual requirement is = to be able to carry two identities.

Brian

On Aug 3, 2011, = at 2:08 AM, Teco Boot wrote:

Hi Scott,

I have written down an practical = use case for PAWS in an ad hoc
network for emergency = scenario's. Please comment.

Thanks, = Teco



3.x.  Rapid deployed = network for emergency scenarios

Organizations involved in = handling emergency operations often have =
a fully owned and controlled infrastructure, with = dedicated spectrum,
for day to day operation. = However, lessons learned from recent =
disasters show such infrastructures are often highly = affected by the
disaster itself. To set up a = replacement quickly, there is a need for =
fast reallocation of spectrum, where in certain cases = spectrum can be
freed for disaster = relief.

To utilize free or freed = spectrum quickly and reliable, automation = of
allocation, assignment and configuration is needed. A = preferred
option is make use of a robust = protocol, already adopted by = radio
manufacturers. This approach does in no way imply such = organizations
for disaster relief must compete = on spectrum allocation with other =
white spaces users, but they = can.

A typical network topology would = include wireless access links to =
the public Internet or private network, wireless ad hoc = network
radios working independent of a = fixed infrastructure and satellite =
links for backup where lack of coverage, overload or = outage of
wireless access links = occur.

=             &n= bsp;           \|/<= br>
=             &n= bsp;           &nbs= p;| ad hoc
=             &n= bsp;           &nbs= p;|
=             &n= bsp;          |-|-------= ------|
=             &n= bsp;          | Master = node   | =       |------------|
\|/ =             &n= bsp;       | with =          | =       | Whitespace = |
| ad hoc =             &n= bsp;/| backhaul link |       | Database =   |
| =             &n= bsp;/-----/ |---------------| =       |------------|
--|-------------/ =             &n= bsp;  |      \ =           /
| = Master node   | =             &n= bsp;  |       | =      (--/--)
| without =       | =             &n= bsp;  |       ------( =       )
| backhaul link | =             &n= bsp;  |  Wireless  / Private = \
---------------\- =             &n= bsp;  |    Access (   net or =  )
=             &n= bsp; \ =             &n= bsp;  | =            \ = Internet )
=             &n= bsp;  \    \|/ =        | =      -------( =        /\
=
=             &n= bsp;   \    | ad hoc  | =      | =       (------) =  \---------
=             &n= bsp;    \   | =         | =      / =             &n= bsp;   | Other =  |
=             &n= bsp;     \--|-------------  /Satellite =         | nodes =  |
=             &n= bsp;     | Master node   | / Link =             &n= bsp;----------
=             &n= bsp;     | with =          |/
<= /blockquote>
=             &n= bsp;     | backhaul link = |
=             &n= bsp;     -----------------


  Figure x: Rapid = deployed network with partly connected = nodes


In the ad hoc network, all nodes = are master nodes in a way that
they allocate RF channels from = the white space database. = However,
the backhaul link could not be = available to all nodes, such as
depicted for the left node in = figure x. To handle RF channel
allocation for such nodes, a = master node with a backhaul link =
relays or proxies the database query for them. So master = nodes
without a backhaul link follow the procedure as defined = for
clients.

The ad hoc network radios = utilise the provided RF channels. Details =
on forming and maintenance of the ad hoc network, = including repair
of segmented networks caused by = segments operating on different =
RF channels, is out of scope of spectrum = allocation.




_______________________________________________
paws = mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws


= = --Apple-Mail-2--938037179-- From brian.rosen@neustar.biz Wed Aug 3 06:25:32 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5821F8B56 for ; Wed, 3 Aug 2011 06:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7kgs8H629-g for ; Wed, 3 Aug 2011 06:25:31 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2F08421F8B46 for ; Wed, 3 Aug 2011 06:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312377941; x=1627728948; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=AjfDXgtlhMnfv1rHhMvuz WE+tjrxS4joby8jDNu4qEk=; b=B49NAJK85vx3gc7osO7sFfC5cTPsm8lA0tpUL AcflgNAkjyb4B0+sdBh6seawCC7FMPiVvOPzNvKzjvrJxt3bA== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.41634793; Wed, 03 Aug 2011 09:25:39 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 3 Aug 2011 09:25:39 -0400 From: "Rosen, Brian" To: Nancy Bravin Date: Wed, 3 Aug 2011 09:25:38 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxR4NWp1AOE8V3+QlSWYBIZu4Q6yQ== Message-ID: References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> In-Reply-To: <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Ggyr75arDliDC2CelWnL3Q== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:25:32 -0000 Nancy In any standards work, it's essential to stay within the agreed upon scope.= If you don't, then you can't finish. The issues you raise here are no doubt interesting and important, but they = are not in scope of this work. If you wish to work on solving them, then s= tart an effort to do so. If that involves protocol work, the IETF has a pr= etty easy process to get work going, assuming there is a large enough group= of people in the organization who want to solve that problem with you. For this work, our scope is a protocol between a white space device and a d= atabase that asks what spectrum is available for the type, location and oth= er parameters the white space device is in. Teco has provided another use = case that fits that. =20 We are always obligated to consider attacks of various forms on the protoco= l, as well as any unusual requirements for overload conditions. I don't th= ink there are many here, but if you don't agree, then please suggest requir= ements. Given how these databases work, I don't think a priority access me= chanism has much value: often we find that the work to identify and priorit= ize use is more work than serving all responses. I think that would be the= case here. In any event, we will need some sort of identity for getting a= ccess to the database, and the database could take that identity into accou= nt when servicing the response, including some priority mechanism. We don'= t need any standards for that. HAM operators would seem to have no role in the protocol, and thus no need = of identifiers. Likewise, I don't see any protocol requirements to support disaster situati= ons. What would we need to do IN THE PROTOCOL to have it work in disaster = situations? Finally, this work seems to be applicable to any country that has spectrum = congestion. You don't need to share spectrum if there is room for all play= ers, but even in developing countries, spectrum is relatively scarce. I do= n't think the size or location of the country has any bearing on the protoc= ol. If you think otherwise, please state what requirement we need. Brian On Aug 3, 2011, at 8:58 AM, Nancy Bravin wrote: > Scott and Teco,=20 > What happens when the systems WS or otherwise are overloaded with calls, = emails from around the world and the database can not handle the traffic > let alone the priority for first responders=85is there no transfer to oth= er regions for 1. Information that someone is alive, a posting as it were? = 2. NO power > or no infrastucture left? 3. Two identities are an important ingredient, = but maybe HAM operators should be part of this as they have been in the pas= t > picking up others by voice and transferring that information? Should they= not have an identifier?=20 > If you look at any disaster in Northern Japan, Indonesia, flooding around= the world, how will this work? What will the backhaul be and > a fixed or replaced or temporary system can take a while if conditions ma= ke getting to locations impossible? ANd should some have to move to higher = ground > and abandon any working equipment assuming power and something to receive= the signal?=20 > I think this has some great thoughts, but seems to be more relative in th= e US, or EU, what about developing countries, will this work as well? > Thanks for your time, SIncerely, Nancy=20 >=20 >=20 > On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote: >=20 >> I think this is a good use case and brings up a new requirement: >> The protocol must cater for a query from one entity on behalf of another= entity. =20 >>=20 >> In many circumstances, this would be invisible to the protocol - the rel= ay client would simply relay packets or use some private protocol. However= , in some circumstances we may need to know the identity of the requester a= s well as the real client, so the actual requirement is to be able to carry= two identities. >>=20 >> Brian >>=20 >> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>=20 >>> Hi Scott, >>>=20 >>> I have written down an practical use case for PAWS in an ad hoc >>> network for emergency scenario's. Please comment. >>>=20 >>> Thanks, Teco >>>=20 >>>=20 >>>=20 >>> 3.x. Rapid deployed network for emergency scenarios >>>=20 >>> Organizations involved in handling emergency operations often have=20 >>> a fully owned and controlled infrastructure, with dedicated spectrum,=20 >>> for day to day operation. However, lessons learned from recent=20 >>> disasters show such infrastructures are often highly affected by the=20 >>> disaster itself. To set up a replacement quickly, there is a need for=20 >>> fast reallocation of spectrum, where in certain cases spectrum can be=20 >>> freed for disaster relief. >>>=20 >>> To utilize free or freed spectrum quickly and reliable, automation of >>> allocation, assignment and configuration is needed. A preferred=20 >>> option is make use of a robust protocol, already adopted by radio >>> manufacturers. This approach does in no way imply such organizations >>> for disaster relief must compete on spectrum allocation with other=20 >>> white spaces users, but they can. >>>=20 >>> A typical network topology would include wireless access links to=20 >>> the public Internet or private network, wireless ad hoc network=20 >>> radios working independent of a fixed infrastructure and satellite=20 >>> links for backup where lack of coverage, overload or outage of=20 >>> wireless access links occur. >>>=20 >>> \|/ >>> | ad hoc >>> | >>> |-|-------------| >>> | Master node | |------------| >>> \|/ | with | | Whitespace | >>> | ad hoc /| backhaul link | | Database | >>> | /-----/ |---------------| |------------| >>> --|-------------/ | \ / >>> | Master node | | | (--/--) >>> | without | | ------( ) >>> | backhaul link | | Wireless / Private \ >>> ---------------\- | Access ( net or ) >>> \ | \ Internet ) >>> \ \|/ | -------( /\ >>> \ | ad hoc | | (------) \--------- >>> \ | | / | Other | >>> \--|------------- /Satellite | nodes | >>> | Master node | / Link ---------- >>> | with |/ >>> | backhaul link | >>> ----------------- >>>=20 >>>=20 >>> Figure x: Rapid deployed network with partly connected nodes >>>=20 >>>=20 >>> In the ad hoc network, all nodes are master nodes in a way that >>> they allocate RF channels from the white space database. However, >>> the backhaul link could not be available to all nodes, such as >>> depicted for the left node in figure x. To handle RF channel=20 >>> allocation for such nodes, a master node with a backhaul link=20 >>> relays or proxies the database query for them. So master nodes=20 >>> without a backhaul link follow the procedure as defined for=20 >>> clients. >>>=20 >>> The ad hoc network radios utilise the provided RF channels. Details=20 >>> on forming and maintenance of the ad hoc network, including repair=20 >>> of segmented networks caused by segments operating on different=20 >>> RF channels, is out of scope of spectrum allocation. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 From teco@inf-net.nl Wed Aug 3 06:44:52 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563DB21F88DD for ; Wed, 3 Aug 2011 06:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTq9d7fhOohb for ; Wed, 3 Aug 2011 06:44:50 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1FE21F8574 for ; Wed, 3 Aug 2011 06:44:49 -0700 (PDT) Received: by wwg11 with SMTP id 11so3463049wwg.1 for ; Wed, 03 Aug 2011 06:45:01 -0700 (PDT) Received: by 10.227.172.199 with SMTP id m7mr8275160wbz.85.1312379101293; Wed, 03 Aug 2011 06:45:01 -0700 (PDT) Received: from [172.16.4.81] ([188.205.88.52]) by mx.google.com with ESMTPS id o19sm699618wbh.9.2011.08.03.06.44.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 06:44:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16--935550993 From: Teco Boot In-Reply-To: <309E6A2A-2628-4E10-96C7-8240024708F2@earthlink.net> Date: Wed, 3 Aug 2011 15:44:57 +0200 Message-Id: <0F34A214-5F5A-4661-91C4-03FF7E240FE0@inf-net.nl> References: <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> <309E6A2A-2628-4E10-96C7-8240024708F2@earthlink.net> To: Nancy Bravin X-Mailer: Apple Mail (2.1084) Cc: paws@ietf.org Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:44:52 -0000 --Apple-Mail-16--935550993 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nancy, Thanks for the questions !!! I'll try to answer, but as Brian already answered, much is not in scope = of this WG. Op 3 aug 2011, om 15:03 heeft Nancy Bravin het volgende geschreven: > Sorry for the missing info on the last email=85here you go. N >=20 > Begin forwarded message: >=20 >> From: Nancy Bravin >> Date: August 3, 2011 5:58:02 AM PDT >> To: "Rosen, Brian" >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency = scenario's >>=20 >> Brian, Scott and Teco,=20 >> What happens when the systems WS or otherwise are overloaded with = calls, emails from around the world and the database can not handle the = traffic >> let alone the priority for first responders=85 First thought: the PAWS request will be delayed, or dropped somewhere. But often, such organizations have dedicated infrastructure for = emergency cases. For example, a PAWS database server could be easily = replicated (it is query-only) and access links using satcom can be used = for accessing these servers.=20 So a requirement is that the PAWS protocol should be capable to be used = in a distributed, fault tolerant system.=20 >> is there no transfer to other regions for 1. Information that someone = is alive, a posting as it were? I understand the importance of such function. PAWS can help to fulfill. = But PAWS is just a piece of the puzzle. And more puzzles are on the = table. >> 2. NO power >> or no infrastucture left? Again, the dedicated infrastructure can be allocated for emergency = situations. Often, it is added to normal day-to-day infrastructure. = Electric generators are important. But relation to PAWS is minimal, I = think. >> 3. Two identities are an important ingredient, but maybe HAM = operators should be part of this as they have been in the past >> picking up others by voice and transferring that information? You are right. They can do that also. >> Should they not have an identifier? Not sure what you mean. Identifiers for their equipment? IP addresses? = Names? I think they should have such. And they have. >> If you look at any disaster in Northern Japan, Indonesia, flooding = around the world, how will this work? This is not the WG to make the whole design. My opinion is that PAWS can = help. Help a lot. >> What will the backhaul be and >> a fixed or replaced or temporary system can take a while if = conditions make getting to locations impossible? This is out of scope for PAWS, I think.=20 Assume satcom link to a backbone, or a local replicate of a PAWS = database. >> ANd should some have to move to higher ground >> and abandon any working equipment assuming power and something to = receive the signal? A bit out of scope for this WG. >> I think this has some great thoughts, but seems to be more relative = in the US, or EU, what about developing countries, will this work as = well? I think the developing countries do not have the years of experience of = regulators as in US, UK or elsewhere. But they do have lots of white = spaces!!=20 I guess PAWS will have fast adoption in development countries. We will = see. Thanks, Teco >> Thanks for your time, SIncerely, Nancy=20 >>=20 >>=20 >> On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote: >>=20 >>> I think this is a good use case and brings up a new requirement: >>> The protocol must cater for a query from one entity on behalf of = another entity. =20 >>>=20 >>> In many circumstances, this would be invisible to the protocol - the = relay client would simply relay packets or use some private protocol. = However, in some circumstances we may need to know the identity of the = requester as well as the real client, so the actual requirement is to be = able to carry two identities. >>>=20 >>> Brian >>>=20 >>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>=20 >>>> Hi Scott, >>>>=20 >>>> I have written down an practical use case for PAWS in an ad hoc >>>> network for emergency scenario's. Please comment. >>>>=20 >>>> Thanks, Teco >>>>=20 >>>>=20 >>>>=20 >>>> 3.x. Rapid deployed network for emergency scenarios >>>>=20 >>>> Organizations involved in handling emergency operations often have=20= >>>> a fully owned and controlled infrastructure, with dedicated = spectrum,=20 >>>> for day to day operation. However, lessons learned from recent=20 >>>> disasters show such infrastructures are often highly affected by = the=20 >>>> disaster itself. To set up a replacement quickly, there is a need = for=20 >>>> fast reallocation of spectrum, where in certain cases spectrum can = be=20 >>>> freed for disaster relief. >>>>=20 >>>> To utilize free or freed spectrum quickly and reliable, automation = of >>>> allocation, assignment and configuration is needed. A preferred=20 >>>> option is make use of a robust protocol, already adopted by radio >>>> manufacturers. This approach does in no way imply such = organizations >>>> for disaster relief must compete on spectrum allocation with other=20= >>>> white spaces users, but they can. >>>>=20 >>>> A typical network topology would include wireless access links to=20= >>>> the public Internet or private network, wireless ad hoc network=20 >>>> radios working independent of a fixed infrastructure and satellite=20= >>>> links for backup where lack of coverage, overload or outage of=20 >>>> wireless access links occur. >>>>=20 >>>> \|/ >>>> | ad hoc >>>> | >>>> |-|-------------| >>>> | Master node | |------------| >>>> \|/ | with | | Whitespace | >>>> | ad hoc /| backhaul link | | Database | >>>> | /-----/ |---------------| |------------| >>>> --|-------------/ | \ / >>>> | Master node | | | (--/--) >>>> | without | | ------( ) >>>> | backhaul link | | Wireless / Private \ >>>> ---------------\- | Access ( net or ) >>>> \ | \ Internet ) >>>> \ \|/ | -------( /\ >>>> \ | ad hoc | | (------) \--------- >>>> \ | | / | Other | >>>> \--|------------- /Satellite | nodes | >>>> | Master node | / Link ---------- >>>> | with |/ >>>> | backhaul link | >>>> ----------------- >>>>=20 >>>>=20 >>>> Figure x: Rapid deployed network with partly connected nodes >>>>=20 >>>>=20 >>>> In the ad hoc network, all nodes are master nodes in a way that >>>> they allocate RF channels from the white space database. However, >>>> the backhaul link could not be available to all nodes, such as >>>> depicted for the left node in figure x. To handle RF channel=20 >>>> allocation for such nodes, a master node with a backhaul link=20 >>>> relays or proxies the database query for them. So master nodes=20 >>>> without a backhaul link follow the procedure as defined for=20 >>>> clients. >>>>=20 >>>> The ad hoc network radios utilise the provided RF channels. Details=20= >>>> on forming and maintenance of the ad hoc network, including repair=20= >>>> of segmented networks caused by segments operating on different=20 >>>> RF channels, is out of scope of spectrum allocation. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 --Apple-Mail-16--935550993 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Nancy,

Thanks for the questions !!!
I'll = try to answer, but as Brian already answered, much is not in scope of = this WG.

Op 3 aug 2011, om 15:03 = heeft Nancy Bravin het volgende geschreven:

Sorry for the missing info on = the last email=85here you go. N

Begin forwarded = message:

From: Nancy Bravin <nbravin@earthlink.net>
Date: August 3, 2011 5:58:02 AM PDT
To: "Rosen, Brian" = <Brian.Rosen@neustar.biz>
Subject: Re: [paws] PAWS use case: ad hoc network for = emergency scenario's

Brian, Scott and Teco, =
What happens when the systems WS or otherwise are overloaded with = calls, emails from around the world and the database can not handle the = traffic
let alone the priority for first = responders=85
First = thought: the PAWS request will be delayed, or dropped = somewhere.
But often, such organizations have dedicated = infrastructure for emergency cases. For example, a PAWS database server = could be easily replicated (it is query-only) and access links using = satcom can be used for accessing these servers. 
So a = requirement is that the PAWS protocol should be capable to be used in a = distributed, fault tolerant system. 

is there no transfer to other regions for 1. = Information that someone is alive, a posting as it = were?
I understand the = importance of such function. PAWS can help to fulfill. But PAWS is just = a piece of the puzzle. And more puzzles are on the = table.

2. NO = power
or no infrastucture = left?
Again, the = dedicated infrastructure can be allocated for emergency situations. = Often, it is added to normal day-to-day infrastructure. Electric = generators are important. But relation to PAWS is minimal, I = think.

3. Two identities are an important ingredient, but = maybe HAM operators should be part of this as they have been in the = past
picking up others by voice and transferring that information? =
You are right. They can = do that also.

Should they not = have an identifier?
Not = sure what you mean. Identifiers for their equipment? IP addresses? = Names?
I think they should have such. And they = have.

If you look at = any disaster in Northern Japan, Indonesia, flooding around the world, = how will this work? =
This is not the WG to = make the whole design. My opinion is that PAWS can help. Help a = lot.

What will the = backhaul be and
a fixed or replaced or temporary system can take a = while if conditions make getting to locations impossible? =
This is out of scope = for PAWS, I think. 
Assume satcom link to a backbone, or = a local replicate of a PAWS database.

ANd should some have to move to higher ground
and = abandon any working equipment assuming power and something to receive = the signal?
A bit out of = scope for this WG.

I think this has some great thoughts, but seems to = be more relative in the US, or EU, what about developing countries, will = this work as well?
I = think the developing countries do not have the years of experience of = regulators as in US, UK or elsewhere. But they do have lots of white = spaces!! 
I guess PAWS will have fast adoption in = development countries. We will see.

Thanks, = Teco

Thanks for your time, SIncerely, Nancy


On = Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote:

I think this is a good use case and brings up a new = requirement:
The protocol must = cater for a query from one entity on behalf of another entity. =  

In many = circumstances, this would be invisible to the protocol - the relay = client would simply relay packets or use some private protocol. =  However, in some circumstances we may need to know the identity of = the requester as well as the real client, so the actual requirement is = to be able to carry two identities.

Brian

On Aug 3, 2011, = at 2:08 AM, Teco Boot wrote:

Hi Scott,

I have written down an practical = use case for PAWS in an ad hoc
network for emergency = scenario's. Please comment.

Thanks, = Teco



3.x.  Rapid deployed = network for emergency scenarios

Organizations involved in = handling emergency operations often have =
a fully owned and controlled infrastructure, with = dedicated spectrum,
for day to day operation. = However, lessons learned from recent =
disasters show such infrastructures are often highly = affected by the
disaster itself. To set up a = replacement quickly, there is a need for =
fast reallocation of spectrum, where in certain cases = spectrum can be
freed for disaster = relief.

To utilize free or freed = spectrum quickly and reliable, automation = of
allocation, assignment and configuration is needed. A = preferred
option is make use of a robust = protocol, already adopted by = radio
manufacturers. This approach does in no way imply such = organizations
for disaster relief must compete = on spectrum allocation with other =
white spaces users, but they = can.

A typical network topology would = include wireless access links to =
the public Internet or private network, wireless ad hoc = network
radios working independent of a = fixed infrastructure and satellite =
links for backup where lack of coverage, overload or = outage of
wireless access links = occur.

=             &n= bsp;           \|/<= br>
=             &n= bsp;           &nbs= p;| ad hoc
=             &n= bsp;           &nbs= p;|
=             &n= bsp;          |-|-------= ------|
=             &n= bsp;          | Master = node   | =       |------------|
\|/ =             &n= bsp;       | with =          | =       | Whitespace = |
| ad hoc =             &n= bsp;/| backhaul link |       | Database =   |
| =             &n= bsp;/-----/ |---------------| =       |------------|
--|-------------/ =             &n= bsp;  |      \ =           /
| = Master node   | =             &n= bsp;  |       | =      (--/--)
| without =       | =             &n= bsp;  |       ------( =       )
| backhaul link | =             &n= bsp;  |  Wireless  / Private = \
---------------\- =             &n= bsp;  |    Access (   net or =  )
=             &n= bsp; \ =             &n= bsp;  | =            \ = Internet )
=             &n= bsp;  \    \|/ =        | =      -------( =        /\
=
=             &n= bsp;   \    | ad hoc  | =      | =       (------) =  \---------
=             &n= bsp;    \   | =         | =      / =             &n= bsp;   | Other =  |
=             &n= bsp;     \--|-------------  /Satellite =         | nodes =  |
=             &n= bsp;     | Master node   | / Link =             &n= bsp;----------
=             &n= bsp;     | with =          |/
<= /blockquote>
=             &n= bsp;     | backhaul link = |
=             &n= bsp;     -----------------


  Figure x: Rapid = deployed network with partly connected = nodes


In the ad hoc network, all nodes = are master nodes in a way that
they allocate RF channels from = the white space database. = However,
the backhaul link could not be = available to all nodes, such as
depicted for the left node in = figure x. To handle RF channel
allocation for such nodes, a = master node with a backhaul link =
relays or proxies the database query for them. So master = nodes
without a backhaul link follow the procedure as defined = for
clients.

The ad hoc network radios = utilise the provided RF channels. Details =
on forming and maintenance of the ad hoc network, = including repair
of segmented networks caused by = segments operating on different =
RF channels, is out of scope of spectrum = allocation.




_______________________________________________
paws = mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws


=
= --Apple-Mail-16--935550993-- From jmh@joelhalpern.com Wed Aug 3 06:46:07 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D518E21F8B74 for ; Wed, 3 Aug 2011 06:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0e4a55Fyr8k for ; Wed, 3 Aug 2011 06:46:07 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id DE12B21F8B6B for ; Wed, 3 Aug 2011 06:46:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 23BFD325BF6D; Wed, 3 Aug 2011 06:46:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.71.0.17] (rrcs-208-105-237-226.nys.biz.rr.com [208.105.237.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 95EE93245901; Wed, 3 Aug 2011 06:46:17 -0700 (PDT) Message-ID: <4E395126.8000307@joelhalpern.com> Date: Wed, 03 Aug 2011 09:46:14 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Rosen, Brian" References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> In-Reply-To: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:46:07 -0000 As I read Teco's note, he is asking for a system that allocates spectrum. As I understand the PAWS work, it specifically does not allocate spectrum. It gives all equivalent requesters in the same place the same answer. So if 10 emergency teams set up there PAWS oriented gear in the same place, they will all get the same list of available spectrum. That does not appear to meet Teco's stated requrement. There is also in implicit requirement that the database be subject to fairly fast update, so that spectrum taht would normally be reserved can be freed up for emergency use if the primary user is suddenly off-line. There are interesting validation issues for this, particularly since the party responsible for those licensed uses may be unreachable due to the same disaster. And DB management and update is, as far as I know, also outside of the PAWS charter. Yours, Joel PS: That is not to say that what Teco describes is uninteresting. It is an interesting and important problem. But it seems not to be PAWS. On 8/3/2011 8:38 AM, Rosen, Brian wrote: > I think this is a good use case and brings up a new requirement: > The protocol must cater for a query from one entity on behalf of another entity. > > In many circumstances, this would be invisible to the protocol - the relay client would simply relay packets or use some private protocol. However, in some circumstances we may need to know the identity of the requester as well as the real client, so the actual requirement is to be able to carry two identities. > > Brian > > On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > >> Hi Scott, >> >> I have written down an practical use case for PAWS in an ad hoc >> network for emergency scenario's. Please comment. >> >> Thanks, Teco >> >> >> >> 3.x. Rapid deployed network for emergency scenarios >> >> Organizations involved in handling emergency operations often have >> a fully owned and controlled infrastructure, with dedicated spectrum, >> for day to day operation. However, lessons learned from recent >> disasters show such infrastructures are often highly affected by the >> disaster itself. To set up a replacement quickly, there is a need for >> fast reallocation of spectrum, where in certain cases spectrum can be >> freed for disaster relief. >> >> To utilize free or freed spectrum quickly and reliable, automation of >> allocation, assignment and configuration is needed. A preferred >> option is make use of a robust protocol, already adopted by radio >> manufacturers. This approach does in no way imply such organizations >> for disaster relief must compete on spectrum allocation with other >> white spaces users, but they can. >> >> A typical network topology would include wireless access links to >> the public Internet or private network, wireless ad hoc network >> radios working independent of a fixed infrastructure and satellite >> links for backup where lack of coverage, overload or outage of >> wireless access links occur. >> >> \|/ >> | ad hoc >> | >> |-|-------------| >> | Master node | |------------| >> \|/ | with | | Whitespace | >> | ad hoc /| backhaul link | | Database | >> | /-----/ |---------------| |------------| >> --|-------------/ | \ / >> | Master node | | | (--/--) >> | without | | ------( ) >> | backhaul link | | Wireless / Private \ >> ---------------\- | Access ( net or ) >> \ | \ Internet ) >> \ \|/ | -------( /\ >> \ | ad hoc | | (------) \--------- >> \ | | / | Other | >> \--|------------- /Satellite | nodes | >> | Master node | / Link ---------- >> | with |/ >> | backhaul link | >> ----------------- >> >> >> Figure x: Rapid deployed network with partly connected nodes >> >> >> In the ad hoc network, all nodes are master nodes in a way that >> they allocate RF channels from the white space database. However, >> the backhaul link could not be available to all nodes, such as >> depicted for the left node in figure x. To handle RF channel >> allocation for such nodes, a master node with a backhaul link >> relays or proxies the database query for them. So master nodes >> without a backhaul link follow the procedure as defined for >> clients. >> >> The ad hoc network radios utilise the provided RF channels. Details >> on forming and maintenance of the ad hoc network, including repair >> of segmented networks caused by segments operating on different >> RF channels, is out of scope of spectrum allocation. >> >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From brian.rosen@neustar.biz Wed Aug 3 07:10:44 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8021F863A for ; Wed, 3 Aug 2011 07:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dlMnnTgNLII for ; Wed, 3 Aug 2011 07:10:43 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4100B21F861E for ; Wed, 3 Aug 2011 07:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312380652; x=1627740544; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=6bWGTMyOK7DGWZ8QHqhpi vAuS34gLUP5ugEoabP6PKg=; b=AHupv02iKssMRbw4KlaloX0LQZ2jPWGuN7/g+ n6v71qVLSxly06dQW7H+OsjibaWPekfehnRlYykwbdBCY8Edg== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.48049679; Wed, 03 Aug 2011 10:10:50 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 3 Aug 2011 10:10:50 -0400 From: "Rosen, Brian" To: "Joel M. Halpern" Date: Wed, 3 Aug 2011 10:10:50 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxR5yYZC3ZEoI7gSFii+AR2CO9uWw== Message-ID: References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <4E395126.8000307@joelhalpern.com> In-Reply-To: <4E395126.8000307@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:10:44 -0000 I read this entirely differently. Teco is describing an ad-hoc network that needs bandwidth. One or more par= ticipants in the network have an independent path to the Internet. A reque= st is made by participants, possibly relayed through other participants to= determine what spectrum is available in the location of the participant. I don't see any requirements listed for allocating spectrum, although he us= es the word "allocation", I think, incorrectly, when he says: >>> The ad hoc network radios utilise the provided RF channels. Details >>> on forming and maintenance of the ad hoc network, including repair >>> of segmented networks caused by segments operating on different >>> RF channels, is out of scope of spectrum allocation. I agree that if 10 teams set up in the same place, they get the same spectr= um. I don't see anything in Teco's use case that says otherwise. There is no implied requirement that the primary user is told to stop using= spectrum. You get what is normally available in that location. Consequen= tly, there is no speed implication. While there may be some way that the p= rimary user's use is affected by emergencies, that isn't in scope of our wo= rk. =20 In the base use case, we have a requirement for managing schedules. Right = now, the FCC only requires devices to query the database every 24 hours. I= n other nations, this may not hold. In fact, a news crew using wireless mi= crophones would like to get 15 minute or less changes in schedule. I think= we might want to keep that in mind. I believe it only reflects the load o= n the server, although some broadcast like mechanism that says "please rech= eck the database ASAP" might be nice. Brian On Aug 3, 2011, at 9:46 AM, Joel M. Halpern wrote: > As I read Teco's note, he is asking for a system that allocates spectrum. > As I understand the PAWS work, it specifically does not allocate=20 > spectrum. It gives all equivalent requesters in the same place the same= =20 > answer. >=20 > So if 10 emergency teams set up there PAWS oriented gear in the same=20 > place, they will all get the same list of available spectrum. That does= =20 > not appear to meet Teco's stated requrement. >=20 > There is also in implicit requirement that the database be subject to=20 > fairly fast update, so that spectrum taht would normally be reserved can= =20 > be freed up for emergency use if the primary user is suddenly off-line.=20 > There are interesting validation issues for this, particularly since=20 > the party responsible for those licensed uses may be unreachable due to=20 > the same disaster. And DB management and update is, as far as I know,=20 > also outside of the PAWS charter. >=20 > Yours, > Joel >=20 > PS: That is not to say that what Teco describes is uninteresting. It is= =20 > an interesting and important problem. But it seems not to be PAWS. >=20 > On 8/3/2011 8:38 AM, Rosen, Brian wrote: >> I think this is a good use case and brings up a new requirement: >> The protocol must cater for a query from one entity on behalf of another= entity. >>=20 >> In many circumstances, this would be invisible to the protocol - the rel= ay client would simply relay packets or use some private protocol. However= , in some circumstances we may need to know the identity of the requester a= s well as the real client, so the actual requirement is to be able to carry= two identities. >>=20 >> Brian >>=20 >> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>=20 >>> Hi Scott, >>>=20 >>> I have written down an practical use case for PAWS in an ad hoc >>> network for emergency scenario's. Please comment. >>>=20 >>> Thanks, Teco >>>=20 >>>=20 >>>=20 >>> 3.x. Rapid deployed network for emergency scenarios >>>=20 >>> Organizations involved in handling emergency operations often have >>> a fully owned and controlled infrastructure, with dedicated spectrum, >>> for day to day operation. However, lessons learned from recent >>> disasters show such infrastructures are often highly affected by the >>> disaster itself. To set up a replacement quickly, there is a need for >>> fast reallocation of spectrum, where in certain cases spectrum can be >>> freed for disaster relief. >>>=20 >>> To utilize free or freed spectrum quickly and reliable, automation of >>> allocation, assignment and configuration is needed. A preferred >>> option is make use of a robust protocol, already adopted by radio >>> manufacturers. This approach does in no way imply such organizations >>> for disaster relief must compete on spectrum allocation with other >>> white spaces users, but they can. >>>=20 >>> A typical network topology would include wireless access links to >>> the public Internet or private network, wireless ad hoc network >>> radios working independent of a fixed infrastructure and satellite >>> links for backup where lack of coverage, overload or outage of >>> wireless access links occur. >>>=20 >>> \|/ >>> | ad hoc >>> | >>> |-|-------------| >>> | Master node | |------------| >>> \|/ | with | | Whitespace | >>> | ad hoc /| backhaul link | | Database | >>> | /-----/ |---------------| |------------| >>> --|-------------/ | \ / >>> | Master node | | | (--/--) >>> | without | | ------( ) >>> | backhaul link | | Wireless / Private \ >>> ---------------\- | Access ( net or ) >>> \ | \ Internet ) >>> \ \|/ | -------( /\ >>> \ | ad hoc | | (------) \--------- >>> \ | | / | Other | >>> \--|------------- /Satellite | nodes | >>> | Master node | / Link ---------- >>> | with |/ >>> | backhaul link | >>> ----------------- >>>=20 >>>=20 >>> Figure x: Rapid deployed network with partly connected nodes >>>=20 >>>=20 >>> In the ad hoc network, all nodes are master nodes in a way that >>> they allocate RF channels from the white space database. However, >>> the backhaul link could not be available to all nodes, such as >>> depicted for the left node in figure x. To handle RF channel >>> allocation for such nodes, a master node with a backhaul link >>> relays or proxies the database query for them. So master nodes >>> without a backhaul link follow the procedure as defined for >>> clients. >>>=20 >>> The ad hoc network radios utilise the provided RF channels. Details >>> on forming and maintenance of the ad hoc network, including repair >>> of segmented networks caused by segments operating on different >>> RF channels, is out of scope of spectrum allocation. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 From scott.probasco@nokia.com Wed Aug 3 07:29:12 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6B121F8828 for ; Wed, 3 Aug 2011 07:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORCdOQ-hu1rj for ; Wed, 3 Aug 2011 07:29:12 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8A21F8853 for ; Wed, 3 Aug 2011 07:29:11 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p73ETBIm015054; Wed, 3 Aug 2011 17:29:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 17:29:11 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 3 Aug 2011 16:29:10 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.157]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.002; Wed, 3 Aug 2011 16:29:09 +0200 From: To: , , Thread-Topic: [paws] Rural Network use case Thread-Index: AQHMURD3wMrXpOJ/rEyrFEpx74BL5pUJZquAgAA2TQCAAR8AgA== Date: Wed, 3 Aug 2011 14:29:08 +0000 Message-ID: In-Reply-To: <69A7E364B918F949829C3CD4FF25994E09A6EECB08@EMV35-UKDY.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.243.0.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <174C5C28EF2DB94A99001B715DD16411@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Aug 2011 14:29:11.0302 (UTC) FILETIME=[B6346A60:01CC51E9] X-Nokia-AV: Clean Cc: paws@ietf.org, apurva.mody@BAESYSTEMS.COM Subject: Re: [paws] Rural Network use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:29:12 -0000 Hi Gerald, Reviewing section '3.3 Wide-Area or Rural internet broadband access', I don=B9t find any assumption of pre-assigned frequencies. There was no inten= t to include this concept. Could you please identify the text you are thinking of? Regards, Scott On 8/2/11 11:22 AM, "ext michael.fitch@bt.com" wrote: >Dear Brian > >Agreed, we would not want to assume that the rural case will have >pre-planned channels. > >Michael > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Rosen, Brian >Sent: 02 August 2011 14:08 >To: Gerald Chouinard >Cc: paws@ietf.org; Apurva Mody >Subject: Re: [paws] Rural Network use case > >While use cases can discuss co-existence, that aspect is out of scope for >our work at this time. > >Of course, preplanned use of frequencies wouldn't require a database >query, so that would seem to be out of scope also. > >I personally don't think there is much difference between urban, suburban >and rural access in the part of the problem we are looking at in this >work group. The number of available channels might be larger, and the >number of protected devices might be smaller, but that is just a scale >issue: the database query would be the same, and the response would be >the same (modulo the length of the available spectrum response). > >Brian > >On Aug 2, 2011, at 8:37 AM, Gerald Chouinard wrote: > >> Scott, >>=20 >> I appreciated your presentation on the Use Cases document last week in >> Quebec City. However, there is one thing that I am not fully >>comfortable=20 >> with in the Rural Network case. Your assumption is that the rural >>networks=20 >> will have been planned beforehand and frequencies will have been >> pre-assigned. This does not correspond to the assumption that we used >>in=20 >> the development of the IEEE 802.22 Standard. The reason is that, in >>the=20 >> context of a "license-exempt" ("unlicensed" in the US) environment >>where=20 >> any competitor can come in and implement his base station and CPEs, a >> planned network implementation is possible in practice. Such >>pre-planning=20 >> would apply to a frequency band licensed to a specific operator. >> Furthermore, protected low-power devices (e.g., wireless microphones) >>could=20 >> pop up anywhere in the area and disable the frequencies that had been >> pre-planned for the network. No pre-planned frequency assignment of the >> networks in an area would allow an easy adaptation to such an event. >>=20 >> Recognizing such limitation, a technique by which the various cells >>will be=20 >> able to talk to each other through a self-coexistence mechanism to >>exchange=20 >> information on the frequencies that they use and that they have as >>backup=20 >> channels in case their current channel is disabled all of a sudden has >>been=20 >> included in the 802.22 Standard (see Clause 7.20 "Self-coexistence" in >>the=20 >> 802.22 Standard). Additionally, information on how the same channel >>can be=20 >> shared by a number of cells, in case where no other channel is >>available in=20 >> the area, is exchanged between these cells to share the transmission >> capacity among 802.22 WRAN cells on a frame-based TDM mechanism. >>=20 >> This should be reflected in either modifying the current rural case by >> removing the assumption of a pre-planned network or adding a new rural >>case=20 >> where a self-coexistence mechanism would be assumed, while keepnig the >> current rural case for "licensed band" type operation. >>=20 >> Hope this helps. >>=20 >> Regards, >>=20 >> Gerald >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From jmh@joelhalpern.com Wed Aug 3 07:33:26 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55B21F89C1 for ; Wed, 3 Aug 2011 07:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZO8HPOKGw+k for ; Wed, 3 Aug 2011 07:33:25 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 5B90221F86AC for ; Wed, 3 Aug 2011 07:33:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id F382D325BF6D; Wed, 3 Aug 2011 07:33:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.71.0.17] (rrcs-208-105-237-226.nys.biz.rr.com [208.105.237.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6A38F32289B4; Wed, 3 Aug 2011 07:33:36 -0700 (PDT) Message-ID: <4E395C3D.3030901@joelhalpern.com> Date: Wed, 03 Aug 2011 10:33:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Rosen, Brian" References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <4E395126.8000307@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:33:26 -0000 Teco, would you please clarify. Clearly, Brian and I are reading your note differently. Thank you, Joel On 8/3/2011 10:10 AM, Rosen, Brian wrote: > I read this entirely differently. > > Teco is describing an ad-hoc network that needs bandwidth. One or more participants in the network have an independent path to the Internet. A request is made by participants, possibly relayed through other participants to determine what spectrum is available in the location of the participant. > > I don't see any requirements listed for allocating spectrum, although he uses the word "allocation", I think, incorrectly, when he says: >>>> The ad hoc network radios utilise the provided RF channels. Details >>>> on forming and maintenance of the ad hoc network, including repair >>>> of segmented networks caused by segments operating on different >>>> RF channels, is out of scope of spectrum allocation. > > I agree that if 10 teams set up in the same place, they get the same spectrum. I don't see anything in Teco's use case that says otherwise. > > There is no implied requirement that the primary user is told to stop using spectrum. You get what is normally available in that location. Consequently, there is no speed implication. While there may be some way that the primary user's use is affected by emergencies, that isn't in scope of our work. > > In the base use case, we have a requirement for managing schedules. Right now, the FCC only requires devices to query the database every 24 hours. In other nations, this may not hold. In fact, a news crew using wireless microphones would like to get 15 minute or less changes in schedule. I think we might want to keep that in mind. I believe it only reflects the load on the server, although some broadcast like mechanism that says "please recheck the database ASAP" might be nice. > > Brian > > > > On Aug 3, 2011, at 9:46 AM, Joel M. Halpern wrote: > >> As I read Teco's note, he is asking for a system that allocates spectrum. >> As I understand the PAWS work, it specifically does not allocate >> spectrum. It gives all equivalent requesters in the same place the same >> answer. >> >> So if 10 emergency teams set up there PAWS oriented gear in the same >> place, they will all get the same list of available spectrum. That does >> not appear to meet Teco's stated requrement. >> >> There is also in implicit requirement that the database be subject to >> fairly fast update, so that spectrum taht would normally be reserved can >> be freed up for emergency use if the primary user is suddenly off-line. >> There are interesting validation issues for this, particularly since >> the party responsible for those licensed uses may be unreachable due to >> the same disaster. And DB management and update is, as far as I know, >> also outside of the PAWS charter. >> >> Yours, >> Joel >> >> PS: That is not to say that what Teco describes is uninteresting. It is >> an interesting and important problem. But it seems not to be PAWS. >> >> On 8/3/2011 8:38 AM, Rosen, Brian wrote: >>> I think this is a good use case and brings up a new requirement: >>> The protocol must cater for a query from one entity on behalf of another entity. >>> >>> In many circumstances, this would be invisible to the protocol - the relay client would simply relay packets or use some private protocol. However, in some circumstances we may need to know the identity of the requester as well as the real client, so the actual requirement is to be able to carry two identities. >>> >>> Brian >>> >>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>> >>>> Hi Scott, >>>> >>>> I have written down an practical use case for PAWS in an ad hoc >>>> network for emergency scenario's. Please comment. >>>> >>>> Thanks, Teco >>>> >>>> >>>> >>>> 3.x. Rapid deployed network for emergency scenarios >>>> >>>> Organizations involved in handling emergency operations often have >>>> a fully owned and controlled infrastructure, with dedicated spectrum, >>>> for day to day operation. However, lessons learned from recent >>>> disasters show such infrastructures are often highly affected by the >>>> disaster itself. To set up a replacement quickly, there is a need for >>>> fast reallocation of spectrum, where in certain cases spectrum can be >>>> freed for disaster relief. >>>> >>>> To utilize free or freed spectrum quickly and reliable, automation of >>>> allocation, assignment and configuration is needed. A preferred >>>> option is make use of a robust protocol, already adopted by radio >>>> manufacturers. This approach does in no way imply such organizations >>>> for disaster relief must compete on spectrum allocation with other >>>> white spaces users, but they can. >>>> >>>> A typical network topology would include wireless access links to >>>> the public Internet or private network, wireless ad hoc network >>>> radios working independent of a fixed infrastructure and satellite >>>> links for backup where lack of coverage, overload or outage of >>>> wireless access links occur. >>>> >>>> \|/ >>>> | ad hoc >>>> | >>>> |-|-------------| >>>> | Master node | |------------| >>>> \|/ | with | | Whitespace | >>>> | ad hoc /| backhaul link | | Database | >>>> | /-----/ |---------------| |------------| >>>> --|-------------/ | \ / >>>> | Master node | | | (--/--) >>>> | without | | ------( ) >>>> | backhaul link | | Wireless / Private \ >>>> ---------------\- | Access ( net or ) >>>> \ | \ Internet ) >>>> \ \|/ | -------( /\ >>>> \ | ad hoc | | (------) \--------- >>>> \ | | / | Other | >>>> \--|------------- /Satellite | nodes | >>>> | Master node | / Link ---------- >>>> | with |/ >>>> | backhaul link | >>>> ----------------- >>>> >>>> >>>> Figure x: Rapid deployed network with partly connected nodes >>>> >>>> >>>> In the ad hoc network, all nodes are master nodes in a way that >>>> they allocate RF channels from the white space database. However, >>>> the backhaul link could not be available to all nodes, such as >>>> depicted for the left node in figure x. To handle RF channel >>>> allocation for such nodes, a master node with a backhaul link >>>> relays or proxies the database query for them. So master nodes >>>> without a backhaul link follow the procedure as defined for >>>> clients. >>>> >>>> The ad hoc network radios utilise the provided RF channels. Details >>>> on forming and maintenance of the ad hoc network, including repair >>>> of segmented networks caused by segments operating on different >>>> RF channels, is out of scope of spectrum allocation. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> > > From nbravin@earthlink.net Wed Aug 3 07:34:02 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18D21F89C1 for ; Wed, 3 Aug 2011 07:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChR2YPD-WhxN for ; Wed, 3 Aug 2011 07:34:01 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 252C221F86AC for ; Wed, 3 Aug 2011 07:34:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pyJy3Qn3J9/JTlhp3KNFcFCpHg7KWZdxalZsSAdKpir5M2L/6pd2XDlht/2gNnmy; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QocWQ-0001GV-K7; Wed, 03 Aug 2011 10:34:10 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: Date: Wed, 3 Aug 2011 07:34:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C284FF3-36B9-4242-9240-86007A21C892@earthlink.net> References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad860a63c6256b7084ed450b00fa140626f2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:34:02 -0000 Dear Brian,=20 It is not that I do not understand what you are saying, what is in scope = and what is not, what is in the prevue of others=85what I am suggesting = is, in the case of HAM operators, it is something that spectrum is allocated for, which = one can find in the ITU, and each country's regulations relating to = such use. As such, licensed, it could be a valuable resource in some of = the disasters that take place around the world. I do understand that it = is licensed, there are many types of transmitting equipment on the tops = of mountains around the world and as=20 an additional resource, you are not allocated spectrum, it is already = there, with in some cases voice, video, IP access etc=85I thought that = it might be an extra component that could contact the database and in = doing so, give location, or pass on the information as described in the = previous examples. If this is out of scope, my apologies.=20 Thanks for your thoughts. Sincerely, Nancy On Aug 3, 2011, at 6:25 AM, Rosen, Brian wrote: > Nancy >=20 > In any standards work, it's essential to stay within the agreed upon = scope. If you don't, then you can't finish. >=20 > The issues you raise here are no doubt interesting and important, but = they are not in scope of this work. If you wish to work on solving = them, then start an effort to do so. If that involves protocol work, = the IETF has a pretty easy process to get work going, assuming there is = a large enough group of people in the organization who want to solve = that problem with you. >=20 > For this work, our scope is a protocol between a white space device = and a database that asks what spectrum is available for the type, = location and other parameters the white space device is in. Teco has = provided another use case that fits that. =20 >=20 > We are always obligated to consider attacks of various forms on the = protocol, as well as any unusual requirements for overload conditions. = I don't think there are many here, but if you don't agree, then please = suggest requirements. Given how these databases work, I don't think a = priority access mechanism has much value: often we find that the work to = identify and prioritize use is more work than serving all responses. I = think that would be the case here. In any event, we will need some sort = of identity for getting access to the database, and the database could = take that identity into account when servicing the response, including = some priority mechanism. We don't need any standards for that. >=20 > HAM operators would seem to have no role in the protocol, and thus no = need of identifiers. >=20 > Likewise, I don't see any protocol requirements to support disaster = situations. What would we need to do IN THE PROTOCOL to have it work in = disaster situations? >=20 > Finally, this work seems to be applicable to any country that has = spectrum congestion. You don't need to share spectrum if there is room = for all players, but even in developing countries, spectrum is = relatively scarce. I don't think the size or location of the country = has any bearing on the protocol. If you think otherwise, please state = what requirement we need. >=20 > Brian >=20 > On Aug 3, 2011, at 8:58 AM, Nancy Bravin wrote: >=20 >> Scott and Teco,=20 >> What happens when the systems WS or otherwise are overloaded with = calls, emails from around the world and the database can not handle the = traffic >> let alone the priority for first responders=85is there no transfer to = other regions for 1. Information that someone is alive, a posting as it = were? 2. NO power >> or no infrastucture left? 3. Two identities are an important = ingredient, but maybe HAM operators should be part of this as they have = been in the past >> picking up others by voice and transferring that information? Should = they not have an identifier?=20 >> If you look at any disaster in Northern Japan, Indonesia, flooding = around the world, how will this work? What will the backhaul be and >> a fixed or replaced or temporary system can take a while if = conditions make getting to locations impossible? ANd should some have to = move to higher ground >> and abandon any working equipment assuming power and something to = receive the signal?=20 >> I think this has some great thoughts, but seems to be more relative = in the US, or EU, what about developing countries, will this work as = well? >> Thanks for your time, SIncerely, Nancy=20 >>=20 >>=20 >> On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote: >>=20 >>> I think this is a good use case and brings up a new requirement: >>> The protocol must cater for a query from one entity on behalf of = another entity. =20 >>>=20 >>> In many circumstances, this would be invisible to the protocol - the = relay client would simply relay packets or use some private protocol. = However, in some circumstances we may need to know the identity of the = requester as well as the real client, so the actual requirement is to be = able to carry two identities. >>>=20 >>> Brian >>>=20 >>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>=20 >>>> Hi Scott, >>>>=20 >>>> I have written down an practical use case for PAWS in an ad hoc >>>> network for emergency scenario's. Please comment. >>>>=20 >>>> Thanks, Teco >>>>=20 >>>>=20 >>>>=20 >>>> 3.x. Rapid deployed network for emergency scenarios >>>>=20 >>>> Organizations involved in handling emergency operations often have=20= >>>> a fully owned and controlled infrastructure, with dedicated = spectrum,=20 >>>> for day to day operation. However, lessons learned from recent=20 >>>> disasters show such infrastructures are often highly affected by = the=20 >>>> disaster itself. To set up a replacement quickly, there is a need = for=20 >>>> fast reallocation of spectrum, where in certain cases spectrum can = be=20 >>>> freed for disaster relief. >>>>=20 >>>> To utilize free or freed spectrum quickly and reliable, automation = of >>>> allocation, assignment and configuration is needed. A preferred=20 >>>> option is make use of a robust protocol, already adopted by radio >>>> manufacturers. This approach does in no way imply such = organizations >>>> for disaster relief must compete on spectrum allocation with other=20= >>>> white spaces users, but they can. >>>>=20 >>>> A typical network topology would include wireless access links to=20= >>>> the public Internet or private network, wireless ad hoc network=20 >>>> radios working independent of a fixed infrastructure and satellite=20= >>>> links for backup where lack of coverage, overload or outage of=20 >>>> wireless access links occur. >>>>=20 >>>> \|/ >>>> | ad hoc >>>> | >>>> |-|-------------| >>>> | Master node | |------------| >>>> \|/ | with | | Whitespace | >>>> | ad hoc /| backhaul link | | Database | >>>> | /-----/ |---------------| |------------| >>>> --|-------------/ | \ / >>>> | Master node | | | (--/--) >>>> | without | | ------( ) >>>> | backhaul link | | Wireless / Private \ >>>> ---------------\- | Access ( net or ) >>>> \ | \ Internet ) >>>> \ \|/ | -------( /\ >>>> \ | ad hoc | | (------) \--------- >>>> \ | | / | Other | >>>> \--|------------- /Satellite | nodes | >>>> | Master node | / Link ---------- >>>> | with |/ >>>> | backhaul link | >>>> ----------------- >>>>=20 >>>>=20 >>>> Figure x: Rapid deployed network with partly connected nodes >>>>=20 >>>>=20 >>>> In the ad hoc network, all nodes are master nodes in a way that >>>> they allocate RF channels from the white space database. However, >>>> the backhaul link could not be available to all nodes, such as >>>> depicted for the left node in figure x. To handle RF channel=20 >>>> allocation for such nodes, a master node with a backhaul link=20 >>>> relays or proxies the database query for them. So master nodes=20 >>>> without a backhaul link follow the procedure as defined for=20 >>>> clients. >>>>=20 >>>> The ad hoc network radios utilise the provided RF channels. Details=20= >>>> on forming and maintenance of the ad hoc network, including repair=20= >>>> of segmented networks caused by segments operating on different=20 >>>> RF channels, is out of scope of spectrum allocation. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 From brian.rosen@neustar.biz Wed Aug 3 07:41:18 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99F921F86DC for ; Wed, 3 Aug 2011 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDVCf9cHoPFx for ; Wed, 3 Aug 2011 07:41:17 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 56BEA21F86C1 for ; Wed, 3 Aug 2011 07:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312382487; x=1627740544; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=NNRJrjvq9ham2QP/m/gAq DfE/ZrYpfOFC5Dwj7DSkNg=; b=KRd9ZOwt/Gx87Wo4pRVYD0eH1O4GdjREmpxo0 o+0A02mCfQb5OpkJiDbkSwor6w1dlHPjmGzmBTOBgjQhtAovA== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.48050784; Wed, 03 Aug 2011 10:41:26 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 3 Aug 2011 10:41:26 -0400 From: "Rosen, Brian" To: Nancy Bravin Date: Wed, 3 Aug 2011 10:41:25 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxR62vWu+cOvm92R7iUMLDpvfSgsA== Message-ID: References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> <3C284FF3-36B9-4242-9240-86007A21C892@earthlink.net> In-Reply-To: <3C284FF3-36B9-4242-9240-86007A21C892@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 5DiGXKkmm5TGSelwKGoOsw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:41:18 -0000 It's out of scope. The scope of this work is that we have a set of primary users that may not = be using all of the spectrum in the band. That is what gives rise to the t= erm "white space" =3D empty space. We have secondary users who desire to m= ake use of this empty space. We're providing a protocol for those secondar= y users to ask where the white space is. Your example of HAM operators doesn't fit. There are no permitted secondar= y users in the amateur bands. Brian On Aug 3, 2011, at 10:34 AM, Nancy Bravin wrote: > Dear Brian,=20 > It is not that I do not understand what you are saying, what is in scope = and what is not, what is in the prevue of others=85what I am suggesting is,= in the case > of HAM operators, it is something that spectrum is allocated for, which o= ne can find in the ITU, and each country's regulations relating to such us= e. As such, licensed, it could be a valuable resource in some of the disast= ers that take place around the world. I do understand that it is licensed, = there are many types of transmitting equipment on the tops of mountains aro= und the world and as=20 > an additional resource, you are not allocated spectrum, it is already the= re, with in some cases voice, video, IP access etc=85I thought that it migh= t be an extra component that could contact the database and in doing so, gi= ve location, or pass on the information as described in the previous exampl= es. If this is out of scope, my apologies.=20 > Thanks for your thoughts. > Sincerely, Nancy >=20 >=20 > On Aug 3, 2011, at 6:25 AM, Rosen, Brian wrote: >=20 >> Nancy >>=20 >> In any standards work, it's essential to stay within the agreed upon sco= pe. If you don't, then you can't finish. >>=20 >> The issues you raise here are no doubt interesting and important, but th= ey are not in scope of this work. If you wish to work on solving them, the= n start an effort to do so. If that involves protocol work, the IETF has a= pretty easy process to get work going, assuming there is a large enough gr= oup of people in the organization who want to solve that problem with you. >>=20 >> For this work, our scope is a protocol between a white space device and = a database that asks what spectrum is available for the type, location and = other parameters the white space device is in. Teco has provided another u= se case that fits that. =20 >>=20 >> We are always obligated to consider attacks of various forms on the prot= ocol, as well as any unusual requirements for overload conditions. I don't= think there are many here, but if you don't agree, then please suggest req= uirements. Given how these databases work, I don't think a priority access= mechanism has much value: often we find that the work to identify and prio= ritize use is more work than serving all responses. I think that would be = the case here. In any event, we will need some sort of identity for gettin= g access to the database, and the database could take that identity into ac= count when servicing the response, including some priority mechanism. We d= on't need any standards for that. >>=20 >> HAM operators would seem to have no role in the protocol, and thus no ne= ed of identifiers. >>=20 >> Likewise, I don't see any protocol requirements to support disaster situ= ations. What would we need to do IN THE PROTOCOL to have it work in disast= er situations? >>=20 >> Finally, this work seems to be applicable to any country that has spectr= um congestion. You don't need to share spectrum if there is room for all p= layers, but even in developing countries, spectrum is relatively scarce. I= don't think the size or location of the country has any bearing on the pro= tocol. If you think otherwise, please state what requirement we need. >>=20 >> Brian >>=20 >> On Aug 3, 2011, at 8:58 AM, Nancy Bravin wrote: >>=20 >>> Scott and Teco,=20 >>> What happens when the systems WS or otherwise are overloaded with calls= , emails from around the world and the database can not handle the traffic >>> let alone the priority for first responders=85is there no transfer to o= ther regions for 1. Information that someone is alive, a posting as it were= ? 2. NO power >>> or no infrastucture left? 3. Two identities are an important ingredient= , but maybe HAM operators should be part of this as they have been in the p= ast >>> picking up others by voice and transferring that information? Should th= ey not have an identifier?=20 >>> If you look at any disaster in Northern Japan, Indonesia, flooding arou= nd the world, how will this work? What will the backhaul be and >>> a fixed or replaced or temporary system can take a while if conditions = make getting to locations impossible? ANd should some have to move to highe= r ground >>> and abandon any working equipment assuming power and something to recei= ve the signal?=20 >>> I think this has some great thoughts, but seems to be more relative in = the US, or EU, what about developing countries, will this work as well? >>> Thanks for your time, SIncerely, Nancy=20 >>>=20 >>>=20 >>> On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote: >>>=20 >>>> I think this is a good use case and brings up a new requirement: >>>> The protocol must cater for a query from one entity on behalf of anoth= er entity. =20 >>>>=20 >>>> In many circumstances, this would be invisible to the protocol - the r= elay client would simply relay packets or use some private protocol. Howev= er, in some circumstances we may need to know the identity of the requester= as well as the real client, so the actual requirement is to be able to car= ry two identities. >>>>=20 >>>> Brian >>>>=20 >>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>=20 >>>>> Hi Scott, >>>>>=20 >>>>> I have written down an practical use case for PAWS in an ad hoc >>>>> network for emergency scenario's. Please comment. >>>>>=20 >>>>> Thanks, Teco >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>=20 >>>>> Organizations involved in handling emergency operations often have=20 >>>>> a fully owned and controlled infrastructure, with dedicated spectrum,= =20 >>>>> for day to day operation. However, lessons learned from recent=20 >>>>> disasters show such infrastructures are often highly affected by the= =20 >>>>> disaster itself. To set up a replacement quickly, there is a need for= =20 >>>>> fast reallocation of spectrum, where in certain cases spectrum can be= =20 >>>>> freed for disaster relief. >>>>>=20 >>>>> To utilize free or freed spectrum quickly and reliable, automation of >>>>> allocation, assignment and configuration is needed. A preferred=20 >>>>> option is make use of a robust protocol, already adopted by radio >>>>> manufacturers. This approach does in no way imply such organizations >>>>> for disaster relief must compete on spectrum allocation with other=20 >>>>> white spaces users, but they can. >>>>>=20 >>>>> A typical network topology would include wireless access links to=20 >>>>> the public Internet or private network, wireless ad hoc network=20 >>>>> radios working independent of a fixed infrastructure and satellite=20 >>>>> links for backup where lack of coverage, overload or outage of=20 >>>>> wireless access links occur. >>>>>=20 >>>>> \|/ >>>>> | ad hoc >>>>> | >>>>> |-|-------------| >>>>> | Master node | |------------| >>>>> \|/ | with | | Whitespace | >>>>> | ad hoc /| backhaul link | | Database | >>>>> | /-----/ |---------------| |------------| >>>>> --|-------------/ | \ / >>>>> | Master node | | | (--/--) >>>>> | without | | ------( ) >>>>> | backhaul link | | Wireless / Private \ >>>>> ---------------\- | Access ( net or ) >>>>> \ | \ Internet ) >>>>> \ \|/ | -------( /\ >>>>> \ | ad hoc | | (------) \--------- >>>>> \ | | / | Other | >>>>> \--|------------- /Satellite | nodes | >>>>> | Master node | / Link ---------- >>>>> | with |/ >>>>> | backhaul link | >>>>> ----------------- >>>>>=20 >>>>>=20 >>>>> Figure x: Rapid deployed network with partly connected nodes >>>>>=20 >>>>>=20 >>>>> In the ad hoc network, all nodes are master nodes in a way that >>>>> they allocate RF channels from the white space database. However, >>>>> the backhaul link could not be available to all nodes, such as >>>>> depicted for the left node in figure x. To handle RF channel=20 >>>>> allocation for such nodes, a master node with a backhaul link=20 >>>>> relays or proxies the database query for them. So master nodes=20 >>>>> without a backhaul link follow the procedure as defined for=20 >>>>> clients. >>>>>=20 >>>>> The ad hoc network radios utilise the provided RF channels. Details=20 >>>>> on forming and maintenance of the ad hoc network, including repair=20 >>>>> of segmented networks caused by segments operating on different=20 >>>>> RF channels, is out of scope of spectrum allocation. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>=20 >=20 From scott.probasco@nokia.com Wed Aug 3 08:48:09 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F0321F8B20 for ; Wed, 3 Aug 2011 08:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbbLH-0Hw951 for ; Wed, 3 Aug 2011 08:48:09 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B508A21F861A for ; Wed, 3 Aug 2011 08:48:00 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p73FmArx011168; Wed, 3 Aug 2011 18:48:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 18:48:10 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 3 Aug 2011 17:48:09 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.157]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.002; Wed, 3 Aug 2011 17:47:56 +0200 From: To: , , Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AQHMTHiIDmEnhbg6zkGnITr0qmH85JUJPwyAgAFvpmGAAEtugP//4QuA Date: Wed, 3 Aug 2011 15:47:56 +0000 Message-ID: In-Reply-To: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.243.0.17] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Aug 2011 15:48:10.0241 (UTC) FILETIME=[BED51F10:01CC51F4] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:48:09 -0000 Hi, I support this use case. PAWS should support a query from one entity on behalf of another. Regards, Scott On 8/3/11 7:38 AM, "ext Rosen, Brian" wrote: >I think this is a good use case and brings up a new requirement: >The protocol must cater for a query from one entity on behalf of another >entity. =20 > >In many circumstances, this would be invisible to the protocol - the >relay client would simply relay packets or use some private protocol. >However, in some circumstances we may need to know the identity of the >requester as well as the real client, so the actual requirement is to be >able to carry two identities. > >Brian > >On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > >> Hi Scott, >>=20 >> I have written down an practical use case for PAWS in an ad hoc >> network for emergency scenario's. Please comment. >>=20 >> Thanks, Teco >>=20 >>=20 >>=20 >> 3.x. Rapid deployed network for emergency scenarios >>=20 >> Organizations involved in handling emergency operations often have >> a fully owned and controlled infrastructure, with dedicated spectrum, >> for day to day operation. However, lessons learned from recent >> disasters show such infrastructures are often highly affected by the >> disaster itself. To set up a replacement quickly, there is a need for >> fast reallocation of spectrum, where in certain cases spectrum can be >> freed for disaster relief. >>=20 >> To utilize free or freed spectrum quickly and reliable, automation of >> allocation, assignment and configuration is needed. A preferred >> option is make use of a robust protocol, already adopted by radio >> manufacturers. This approach does in no way imply such organizations >> for disaster relief must compete on spectrum allocation with other >> white spaces users, but they can. >>=20 >> A typical network topology would include wireless access links to >> the public Internet or private network, wireless ad hoc network >> radios working independent of a fixed infrastructure and satellite >> links for backup where lack of coverage, overload or outage of >> wireless access links occur. >>=20 >> \|/ >> | ad hoc >> | >> |-|-------------| >> | Master node | |------------| >> \|/ | with | | Whitespace | >> | ad hoc /| backhaul link | | Database | >> | /-----/ |---------------| |------------| >> --|-------------/ | \ / >> | Master node | | | (--/--) >> | without | | ------( ) >> | backhaul link | | Wireless / Private \ >> ---------------\- | Access ( net or ) >> \ | \ Internet ) >> \ \|/ | -------( /\ >> \ | ad hoc | | (------) \--------- >> \ | | / | Other | >> \--|------------- /Satellite | nodes | >> | Master node | / Link ---------- >> | with |/ >> | backhaul link | >> ----------------- >>=20 >>=20 >> Figure x: Rapid deployed network with partly connected nodes >>=20 >>=20 >> In the ad hoc network, all nodes are master nodes in a way that >> they allocate RF channels from the white space database. However, >> the backhaul link could not be available to all nodes, such as >> depicted for the left node in figure x. To handle RF channel >> allocation for such nodes, a master node with a backhaul link >> relays or proxies the database query for them. So master nodes >> without a backhaul link follow the procedure as defined for >> clients. >>=20 >> The ad hoc network radios utilise the provided RF channels. Details >> on forming and maintenance of the ad hoc network, including repair >> of segmented networks caused by segments operating on different >> RF channels, is out of scope of spectrum allocation. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Wed Aug 3 08:55:12 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F8321F8BB7 for ; Wed, 3 Aug 2011 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLUtwkQN1pzH for ; Wed, 3 Aug 2011 08:55:12 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8783521F8BB5 for ; Wed, 3 Aug 2011 08:55:10 -0700 (PDT) Received: by fxe6 with SMTP id 6so1190522fxe.31 for ; Wed, 03 Aug 2011 08:55:22 -0700 (PDT) Received: by 10.223.5.212 with SMTP id 20mr10280084faw.40.1312386922167; Wed, 03 Aug 2011 08:55:22 -0700 (PDT) Received: from [10.87.14.21] ([80.187.218.140]) by mx.google.com with ESMTPS id q15sm612562fah.8.2011.08.03.08.55.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 08:55:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4E395126.8000307@joelhalpern.com> Date: Wed, 3 Aug 2011 17:55:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92230AA5-A5F2-40BF-BF50-E162612ECB91@inf-net.nl> References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <4E395126.8000307@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:55:13 -0000 Joel, Op 3 aug 2011, om 15:46 heeft Joel M. Halpern het volgende geschreven: > As I read Teco's note, he is asking for a system that allocates = spectrum. > As I understand the PAWS work, it specifically does not allocate = spectrum. It gives all equivalent requesters in the same place the same = answer. I should have circumvent the term "allocate". To be replaced with = "request free" or similar. > So if 10 emergency teams set up there PAWS oriented gear in the same = place, they will all get the same list of available spectrum. That does = not appear to meet Teco's stated requrement. There are MAC layers that work in shared spectrum (e.g. 802.11). I am = aware of the lack of guaranteed service, but using it is "better than = nothing". Often, the principle is: use what you can get. And be polite, = others are with you.=20 Radio could start using the most unused channels (e.g. by sensing). Or = use spread spectrum. Or CSMA (which is sensing). It helps a lot if the gear gets running without manual intervention. = Planning is also a bad idea. Using shared media access technology helps. > There is also in implicit requirement that the database be subject to = fairly fast update, so that spectrum taht would normally be reserved can = be freed up for emergency use if the primary user is suddenly off-line. = There are interesting validation issues for this, particularly since the = party responsible for those licensed uses may be unreachable due to the = same disaster. And DB management and update is, as far as I know, also = outside of the PAWS charter. No misunderstanding, I do not suggest revocations. Using time-out within = hours or days is much faster than current practice where allocation is = in decades. A scenario could be where TV broadcast is limited to fewer channels, and = a messages is pushed: "there could be more RF for you". This type of = message can be out-of-band for PAWS (and should be, I think). Sure there = could be less RF also. But that would not revoke, I think. Want to see TVWS video? Check http://www.youtube.com/watch?v=3DIxLvEoP_jLM= This tower had a small fire, with unexpected results. More free spectrum = near where I live :-) Thanks, Teco >=20 > Yours, > Joel >=20 > PS: That is not to say that what Teco describes is uninteresting. It = is an interesting and important problem. But it seems not to be PAWS. >=20 > On 8/3/2011 8:38 AM, Rosen, Brian wrote: >> I think this is a good use case and brings up a new requirement: >> The protocol must cater for a query from one entity on behalf of = another entity. >>=20 >> In many circumstances, this would be invisible to the protocol - the = relay client would simply relay packets or use some private protocol. = However, in some circumstances we may need to know the identity of the = requester as well as the real client, so the actual requirement is to be = able to carry two identities. >>=20 >> Brian >>=20 >> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>=20 >>> Hi Scott, >>>=20 >>> I have written down an practical use case for PAWS in an ad hoc >>> network for emergency scenario's. Please comment. >>>=20 >>> Thanks, Teco >>>=20 >>>=20 >>>=20 >>> 3.x. Rapid deployed network for emergency scenarios >>>=20 >>> Organizations involved in handling emergency operations often have >>> a fully owned and controlled infrastructure, with dedicated = spectrum, >>> for day to day operation. However, lessons learned from recent >>> disasters show such infrastructures are often highly affected by the >>> disaster itself. To set up a replacement quickly, there is a need = for >>> fast reallocation of spectrum, where in certain cases spectrum can = be >>> freed for disaster relief. >>>=20 >>> To utilize free or freed spectrum quickly and reliable, automation = of >>> allocation, assignment and configuration is needed. A preferred >>> option is make use of a robust protocol, already adopted by radio >>> manufacturers. This approach does in no way imply such organizations >>> for disaster relief must compete on spectrum allocation with other >>> white spaces users, but they can. >>>=20 >>> A typical network topology would include wireless access links to >>> the public Internet or private network, wireless ad hoc network >>> radios working independent of a fixed infrastructure and satellite >>> links for backup where lack of coverage, overload or outage of >>> wireless access links occur. >>>=20 >>> \|/ >>> | ad hoc >>> | >>> |-|-------------| >>> | Master node | |------------| >>> \|/ | with | | Whitespace | >>> | ad hoc /| backhaul link | | Database | >>> | /-----/ |---------------| |------------| >>> --|-------------/ | \ / >>> | Master node | | | (--/--) >>> | without | | ------( ) >>> | backhaul link | | Wireless / Private \ >>> ---------------\- | Access ( net or ) >>> \ | \ Internet ) >>> \ \|/ | -------( /\ >>> \ | ad hoc | | (------) \--------- >>> \ | | / | Other | >>> \--|------------- /Satellite | nodes | >>> | Master node | / Link ---------- >>> | with |/ >>> | backhaul link | >>> ----------------- >>>=20 >>>=20 >>> Figure x: Rapid deployed network with partly connected nodes >>>=20 >>>=20 >>> In the ad hoc network, all nodes are master nodes in a way that >>> they allocate RF channels from the white space database. However, >>> the backhaul link could not be available to all nodes, such as >>> depicted for the left node in figure x. To handle RF channel >>> allocation for such nodes, a master node with a backhaul link >>> relays or proxies the database query for them. So master nodes >>> without a backhaul link follow the procedure as defined for >>> clients. >>>=20 >>> The ad hoc network radios utilise the provided RF channels. Details >>> on forming and maintenance of the ad hoc network, including repair >>> of segmented networks caused by segments operating on different >>> RF channels, is out of scope of spectrum allocation. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 From nbravin@earthlink.net Wed Aug 3 10:08:22 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52C621F86D0 for ; Wed, 3 Aug 2011 10:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVoyrrd8HIAb for ; Wed, 3 Aug 2011 10:08:21 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63C21F863C for ; Wed, 3 Aug 2011 10:08:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=COxcm++egi60/sa2hQeaZD8Rj5ybtqKwmWwam+TdvE4Fjp+IrQ/MJYnb/tlnaSvq; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qoev2-0002GA-Dh; Wed, 03 Aug 2011 13:07:44 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: Date: Wed, 3 Aug 2011 10:07:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6034D202-4B3A-4FEA-9111-632649505B79@neustar.biz> <8C742C44-C3FC-43F2-959A-AFDEA8EA3FF7@earthlink.net> <3C284FF3-36B9-4242-9240-86007A21C892@earthlink.net> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8617445e6e83c4b4c12000e45ebb575a44350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:08:22 -0000 Dear Brian and all,=20 Yes, it may very well be out of scope, my thought is the same as the one = that was given below=85I thought that the spectrum allocated to HAM = operators, would qualify as one that could be "freed" and consistent with 3.x below. I Sorry my = interpretation of this emergency situation for disaster only was not in = line with what the author meant.=20 Sincerely, Nancy =20 >>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>=20 >>>>>> Organizations involved in handling emergency operations often = have=20 >>>>>> a fully owned and controlled infrastructure, with dedicated = spectrum,=20 >>>>>> for day to day operation. However, lessons learned from recent=20 >>>>>> disasters show such infrastructures are often highly affected by = the=20 >>>>>> disaster itself. To set up a replacement quickly, there is a need = for=20 >>>>>> fast reallocation of spectrum, where in certain cases spectrum = can be=20 >>>>>> freed for disaster relief. >>>>>>=20 >>>>>> To utilize free or freed spectrum quickly and reliable, = automation of >>>>>> allocation, assignment and configuration is needed. A preferred=20= >>>>>> option is make use of a robust protocol, already adopted by radio >>>>>> manufacturers. This approach does in no way imply such = organizations >>>>>> for disaster relief must compete on spectrum allocation with = other=20 >>>>>> white spaces users, but they can. On Aug 3, 2011, at 7:41 AM, Rosen, Brian wrote: > It's out of scope. >=20 > The scope of this work is that we have a set of primary users that may = not be using all of the spectrum in the band. That is what gives rise = to the term "white space" =3D empty space. We have secondary users who = desire to make use of this empty space. We're providing a protocol for = those secondary users to ask where the white space is. >=20 > Your example of HAM operators doesn't fit. There are no permitted = secondary users in the amateur bands. >=20 > Brian >=20 > On Aug 3, 2011, at 10:34 AM, Nancy Bravin wrote: >=20 >> Dear Brian,=20 >> It is not that I do not understand what you are saying, what is in = scope and what is not, what is in the prevue of others=85what I am = suggesting is, in the case >> of HAM operators, it is something that spectrum is allocated for, = which one can find in the ITU, and each country's regulations relating = to such use. As such, licensed, it could be a valuable resource in some = of the disasters that take place around the world. I do understand that = it is licensed, there are many types of transmitting equipment on the = tops of mountains around the world and as=20 >> an additional resource, you are not allocated spectrum, it is already = there, with in some cases voice, video, IP access etc=85I thought that = it might be an extra component that could contact the database and in = doing so, give location, or pass on the information as described in the = previous examples. If this is out of scope, my apologies.=20 >> Thanks for your thoughts. >> Sincerely, Nancy >>=20 >>=20 >> On Aug 3, 2011, at 6:25 AM, Rosen, Brian wrote: >>=20 >>> Nancy >>>=20 >>> In any standards work, it's essential to stay within the agreed upon = scope. If you don't, then you can't finish. >>>=20 >>> The issues you raise here are no doubt interesting and important, = but they are not in scope of this work. If you wish to work on solving = them, then start an effort to do so. If that involves protocol work, = the IETF has a pretty easy process to get work going, assuming there is = a large enough group of people in the organization who want to solve = that problem with you. >>>=20 >>> For this work, our scope is a protocol between a white space device = and a database that asks what spectrum is available for the type, = location and other parameters the white space device is in. Teco has = provided another use case that fits that. =20 >>>=20 >>> We are always obligated to consider attacks of various forms on the = protocol, as well as any unusual requirements for overload conditions. = I don't think there are many here, but if you don't agree, then please = suggest requirements. Given how these databases work, I don't think a = priority access mechanism has much value: often we find that the work to = identify and prioritize use is more work than serving all responses. I = think that would be the case here. In any event, we will need some sort = of identity for getting access to the database, and the database could = take that identity into account when servicing the response, including = some priority mechanism. We don't need any standards for that. >>>=20 >>> HAM operators would seem to have no role in the protocol, and thus = no need of identifiers. >>>=20 >>> Likewise, I don't see any protocol requirements to support disaster = situations. What would we need to do IN THE PROTOCOL to have it work in = disaster situations? >>>=20 >>> Finally, this work seems to be applicable to any country that has = spectrum congestion. You don't need to share spectrum if there is room = for all players, but even in developing countries, spectrum is = relatively scarce. I don't think the size or location of the country = has any bearing on the protocol. If you think otherwise, please state = what requirement we need. >>>=20 >>> Brian >>>=20 >>> On Aug 3, 2011, at 8:58 AM, Nancy Bravin wrote: >>>=20 >>>> Scott and Teco,=20 >>>> What happens when the systems WS or otherwise are overloaded with = calls, emails from around the world and the database can not handle the = traffic >>>> let alone the priority for first responders=85is there no transfer = to other regions for 1. Information that someone is alive, a posting as = it were? 2. NO power >>>> or no infrastucture left? 3. Two identities are an important = ingredient, but maybe HAM operators should be part of this as they have = been in the past >>>> picking up others by voice and transferring that information? = Should they not have an identifier?=20 >>>> If you look at any disaster in Northern Japan, Indonesia, flooding = around the world, how will this work? What will the backhaul be and >>>> a fixed or replaced or temporary system can take a while if = conditions make getting to locations impossible? ANd should some have to = move to higher ground >>>> and abandon any working equipment assuming power and something to = receive the signal?=20 >>>> I think this has some great thoughts, but seems to be more relative = in the US, or EU, what about developing countries, will this work as = well? >>>> Thanks for your time, SIncerely, Nancy=20 >>>>=20 >>>>=20 >>>> On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote: >>>>=20 >>>>> I think this is a good use case and brings up a new requirement: >>>>> The protocol must cater for a query from one entity on behalf of = another entity. =20 >>>>>=20 >>>>> In many circumstances, this would be invisible to the protocol - = the relay client would simply relay packets or use some private = protocol. However, in some circumstances we may need to know the = identity of the requester as well as the real client, so the actual = requirement is to be able to carry two identities. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>=20 >>>>>> Hi Scott, >>>>>>=20 >>>>>> I have written down an practical use case for PAWS in an ad hoc >>>>>> network for emergency scenario's. Please comment. >>>>>>=20 >>>>>> Thanks, Teco >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>=20 >>>>>> Organizations involved in handling emergency operations often = have=20 >>>>>> a fully owned and controlled infrastructure, with dedicated = spectrum,=20 >>>>>> for day to day operation. However, lessons learned from recent=20 >>>>>> disasters show such infrastructures are often highly affected by = the=20 >>>>>> disaster itself. To set up a replacement quickly, there is a need = for=20 >>>>>> fast reallocation of spectrum, where in certain cases spectrum = can be=20 >>>>>> freed for disaster relief. >>>>>>=20 >>>>>> To utilize free or freed spectrum quickly and reliable, = automation of >>>>>> allocation, assignment and configuration is needed. A preferred=20= >>>>>> option is make use of a robust protocol, already adopted by radio >>>>>> manufacturers. This approach does in no way imply such = organizations >>>>>> for disaster relief must compete on spectrum allocation with = other=20 >>>>>> white spaces users, but they can. >>>>>>=20 >>>>>> A typical network topology would include wireless access links to=20= >>>>>> the public Internet or private network, wireless ad hoc network=20= >>>>>> radios working independent of a fixed infrastructure and = satellite=20 >>>>>> links for backup where lack of coverage, overload or outage of=20 >>>>>> wireless access links occur. >>>>>>=20 >>>>>> \|/ >>>>>> | ad hoc >>>>>> | >>>>>> |-|-------------| >>>>>> | Master node | |------------| >>>>>> \|/ | with | | Whitespace | >>>>>> | ad hoc /| backhaul link | | Database | >>>>>> | /-----/ |---------------| |------------| >>>>>> --|-------------/ | \ / >>>>>> | Master node | | | (--/--) >>>>>> | without | | ------( ) >>>>>> | backhaul link | | Wireless / Private \ >>>>>> ---------------\- | Access ( net or ) >>>>>> \ | \ Internet ) >>>>>> \ \|/ | -------( /\ >>>>>> \ | ad hoc | | (------) \--------- >>>>>> \ | | / | Other | >>>>>> \--|------------- /Satellite | nodes | >>>>>> | Master node | / Link ---------- >>>>>> | with |/ >>>>>> | backhaul link | >>>>>> ----------------- >>>>>>=20 >>>>>>=20 >>>>>> Figure x: Rapid deployed network with partly connected nodes >>>>>>=20 >>>>>>=20 >>>>>> In the ad hoc network, all nodes are master nodes in a way that >>>>>> they allocate RF channels from the white space database. However, >>>>>> the backhaul link could not be available to all nodes, such as >>>>>> depicted for the left node in figure x. To handle RF channel=20 >>>>>> allocation for such nodes, a master node with a backhaul link=20 >>>>>> relays or proxies the database query for them. So master nodes=20 >>>>>> without a backhaul link follow the procedure as defined for=20 >>>>>> clients. >>>>>>=20 >>>>>> The ad hoc network radios utilise the provided RF channels. = Details=20 >>>>>> on forming and maintenance of the ad hoc network, including = repair=20 >>>>>> of segmented networks caused by segments operating on different=20= >>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>=20 >>=20 >=20 From subir@research.telcordia.com Thu Aug 4 11:51:04 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79725E8002 for ; Thu, 4 Aug 2011 11:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73ae6-PAvV1j for ; Thu, 4 Aug 2011 11:51:04 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6A31321F8834 for ; Thu, 4 Aug 2011 11:51:03 -0700 (PDT) Received: from [128.96.58.39] (vpntnlA39.research.telcordia.com [128.96.58.39]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p74IpAfK027433 for ; Thu, 4 Aug 2011 14:51:13 -0400 (EDT) Message-ID: <4E3AEA21.9050800@research.telcordia.com> Date: Thu, 04 Aug 2011 14:51:13 -0400 From: Subir Das User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: paws@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:51:05 -0000 Scott, Are you suggesting to have proxy/relay support ? Thanks, _Subir On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: > Hi, > > I support this use case. PAWS should support a query from one entity on > behalf of another. > > Regards, > Scott > > > On 8/3/11 7:38 AM, "ext Rosen, Brian" wrote: > >> I think this is a good use case and brings up a new requirement: >> The protocol must cater for a query from one entity on behalf of another >> entity. >> >> In many circumstances, this would be invisible to the protocol - the >> relay client would simply relay packets or use some private protocol. >> However, in some circumstances we may need to know the identity of the >> requester as well as the real client, so the actual requirement is to be >> able to carry two identities. >> >> Brian >> >> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >> >>> Hi Scott, >>> >>> I have written down an practical use case for PAWS in an ad hoc >>> network for emergency scenario's. Please comment. >>> >>> Thanks, Teco >>> >>> >>> >>> 3.x. Rapid deployed network for emergency scenarios >>> >>> Organizations involved in handling emergency operations often have >>> a fully owned and controlled infrastructure, with dedicated spectrum, >>> for day to day operation. However, lessons learned from recent >>> disasters show such infrastructures are often highly affected by the >>> disaster itself. To set up a replacement quickly, there is a need for >>> fast reallocation of spectrum, where in certain cases spectrum can be >>> freed for disaster relief. >>> >>> To utilize free or freed spectrum quickly and reliable, automation of >>> allocation, assignment and configuration is needed. A preferred >>> option is make use of a robust protocol, already adopted by radio >>> manufacturers. This approach does in no way imply such organizations >>> for disaster relief must compete on spectrum allocation with other >>> white spaces users, but they can. >>> >>> A typical network topology would include wireless access links to >>> the public Internet or private network, wireless ad hoc network >>> radios working independent of a fixed infrastructure and satellite >>> links for backup where lack of coverage, overload or outage of >>> wireless access links occur. >>> >>> \|/ >>> | ad hoc >>> | >>> |-|-------------| >>> | Master node | |------------| >>> \|/ | with | | Whitespace | >>> | ad hoc /| backhaul link | | Database | >>> | /-----/ |---------------| |------------| >>> --|-------------/ | \ / >>> | Master node | | | (--/--) >>> | without | | ------( ) >>> | backhaul link | | Wireless / Private \ >>> ---------------\- | Access ( net or ) >>> \ | \ Internet ) >>> \ \|/ | -------( /\ >>> \ | ad hoc | | (------) \--------- >>> \ | | / | Other | >>> \--|------------- /Satellite | nodes | >>> | Master node | / Link ---------- >>> | with |/ >>> | backhaul link | >>> ----------------- >>> >>> >>> Figure x: Rapid deployed network with partly connected nodes >>> >>> >>> In the ad hoc network, all nodes are master nodes in a way that >>> they allocate RF channels from the white space database. However, >>> the backhaul link could not be available to all nodes, such as >>> depicted for the left node in figure x. To handle RF channel >>> allocation for such nodes, a master node with a backhaul link >>> relays or proxies the database query for them. So master nodes >>> without a backhaul link follow the procedure as defined for >>> clients. >>> >>> The ad hoc network radios utilise the provided RF channels. Details >>> on forming and maintenance of the ad hoc network, including repair >>> of segmented networks caused by segments operating on different >>> RF channels, is out of scope of spectrum allocation. >>> >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Thu Aug 4 12:35:28 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EB911E807B for ; Thu, 4 Aug 2011 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCNbT9cd376b for ; Thu, 4 Aug 2011 12:35:27 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC701F0C3E for ; Thu, 4 Aug 2011 12:35:26 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p74JZebB001740; Thu, 4 Aug 2011 22:35:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 22:35:40 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 4 Aug 2011 21:35:39 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.157]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.002; Thu, 4 Aug 2011 21:35:39 +0200 From: To: , Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AQHMTHiIDmEnhbg6zkGnITr0qmH85JUJPwyAgAFvpmGAAEtugP//4QuAgAIZU4D//7iWgA== Date: Thu, 4 Aug 2011 19:35:39 +0000 Message-ID: In-Reply-To: <4E3AEA21.9050800@research.telcordia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.243.0.17] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2011 19:35:40.0560 (UTC) FILETIME=[B1784100:01CC52DD] X-Nokia-AV: Clean Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:35:28 -0000 Hi Subir, Yes. The use case below requires this functionality. Regards, Scott On 8/4/11 1:51 PM, "ext Subir Das" wrote: >Scott, >Are you suggesting to have proxy/relay support ? > >Thanks, >_Subir > >On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >> Hi, >> >> I support this use case. PAWS should support a query from one entity on >> behalf of another. >> >> Regards, >> Scott >> >> >> On 8/3/11 7:38 AM, "ext Rosen, Brian" wrote: >> >>> I think this is a good use case and brings up a new requirement: >>> The protocol must cater for a query from one entity on behalf of >>>another >>> entity. >>> >>> In many circumstances, this would be invisible to the protocol - the >>> relay client would simply relay packets or use some private protocol. >>> However, in some circumstances we may need to know the identity of the >>> requester as well as the real client, so the actual requirement is to >>>be >>> able to carry two identities. >>> >>> Brian >>> >>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>> >>>> Hi Scott, >>>> >>>> I have written down an practical use case for PAWS in an ad hoc >>>> network for emergency scenario's. Please comment. >>>> >>>> Thanks, Teco >>>> >>>> >>>> >>>> 3.x. Rapid deployed network for emergency scenarios >>>> >>>> Organizations involved in handling emergency operations often have >>>> a fully owned and controlled infrastructure, with dedicated spectrum, >>>> for day to day operation. However, lessons learned from recent >>>> disasters show such infrastructures are often highly affected by the >>>> disaster itself. To set up a replacement quickly, there is a need for >>>> fast reallocation of spectrum, where in certain cases spectrum can be >>>> freed for disaster relief. >>>> >>>> To utilize free or freed spectrum quickly and reliable, automation of >>>> allocation, assignment and configuration is needed. A preferred >>>> option is make use of a robust protocol, already adopted by radio >>>> manufacturers. This approach does in no way imply such organizations >>>> for disaster relief must compete on spectrum allocation with other >>>> white spaces users, but they can. >>>> >>>> A typical network topology would include wireless access links to >>>> the public Internet or private network, wireless ad hoc network >>>> radios working independent of a fixed infrastructure and satellite >>>> links for backup where lack of coverage, overload or outage of >>>> wireless access links occur. >>>> >>>> \|/ >>>> | ad hoc >>>> | >>>> |-|-------------| >>>> | Master node | |------------| >>>> \|/ | with | | Whitespace | >>>> | ad hoc /| backhaul link | | Database | >>>> | /-----/ |---------------| |------------| >>>> --|-------------/ | \ / >>>> | Master node | | | (--/--) >>>> | without | | ------( ) >>>> | backhaul link | | Wireless / Private \ >>>> ---------------\- | Access ( net or ) >>>> \ | \ Internet ) >>>> \ \|/ | -------( /\ >>>> \ | ad hoc | | (------) \--------- >>>> \ | | / | Other | >>>> \--|------------- /Satellite | nodes | >>>> | Master node | / Link ---------- >>>> | with |/ >>>> | backhaul link | >>>> ----------------- >>>> >>>> >>>> Figure x: Rapid deployed network with partly connected nodes >>>> >>>> >>>> In the ad hoc network, all nodes are master nodes in a way that >>>> they allocate RF channels from the white space database. However, >>>> the backhaul link could not be available to all nodes, such as >>>> depicted for the left node in figure x. To handle RF channel >>>> allocation for such nodes, a master node with a backhaul link >>>> relays or proxies the database query for them. So master nodes >>>> without a backhaul link follow the procedure as defined for >>>> clients. >>>> >>>> The ad hoc network radios utilise the provided RF channels. Details >>>> on forming and maintenance of the ad hoc network, including repair >>>> of segmented networks caused by segments operating on different >>>> RF channels, is out of scope of spectrum allocation. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From fountainwu@yahoo.com Thu Aug 4 12:40:09 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C9C21F8761 for ; Thu, 4 Aug 2011 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQuwN9U3jlVw for ; Thu, 4 Aug 2011 12:40:08 -0700 (PDT) Received: from nm14-vm2.bullet.mail.ne1.yahoo.com (nm14-vm2.bullet.mail.ne1.yahoo.com [98.138.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 845FE21F866A for ; Thu, 4 Aug 2011 12:40:08 -0700 (PDT) Received: from [98.138.90.56] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 04 Aug 2011 19:40:23 -0000 Received: from [98.138.87.8] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 04 Aug 2011 19:40:23 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 04 Aug 2011 19:40:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 791035.97147.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 26384 invoked by uid 60001); 4 Aug 2011 19:40:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312486823; bh=RfqIA8LZB3x1vEV5DjwSu8jLy09EU7RDAyC+DAbCg2c=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=M0FmiUvHt/6SI479SuCg3GkMj6e6qjIsPw12yBRQAZZeilGC+MdJo+dne8GpsSeaak7HrAfb8Gq9M0z6HpOtcEU3bHubhRZUIeDPhR2vLVeQ6UY3ree6fuhi8tvUADFNcDPKJhLtOh7UZ9o7yXkxiw3egaEiGlnGOhf1k3njj60= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=I4aS6nIUeStxftUXjyW3mILRbQSOFKmdavAXitRonx9FhkBH6NXwL7XtU6SUN7Rm2ovXBer5IDtIXCJYPhrN0i4YoIpTbFSi0P9oIgP/kShaTuo40d3e+pCJHs+NfcY/jVMxY3hTr2IqNShr4NkketBNK9K/HeZ0jGAPDWTBKfk=; X-YMail-OSG: bKDhlrgVM1nEqeePuLNcKbQfCXzFoIa95Hj.khCRnWC3WVW dhwswrxusMTVEsnBCw1rMG2uFpvEgG5xSEGtlBRR5pHiLLyi1i9hyJnSJYtQ uVqjMsT17N0vGhxunGtbZwWJYZNa0tLHEGlN5oyybhyA2SheqtgrqnKyC8e7 .SrAi66R.uwo59mS_aT5ofQ8WFgS5GdOxB_7efiojyUr70U9SnbuQez7QB0r cFhV6Cmx8ZwOtcJ8lnmS0unrIgmPZ7N8hUDqn3G5KkfE3MVhZT10SkYL93H8 Z5K5x2PmXleR6.fOt3e7jTDhpMV.1MFdi9Uef8ZNpOf95qQ5WKI4xQhtzYi9 U6aqOP2wNtX_C8Idxv07At2bLngq.TjUtYstkU31jm374GCGPpEQ.uWazwDT E4X45DIcv2LuQjAGOY_MZr3HtCcZYbSu__jfP2U4mGIYiyevyAF_NKYbz.t5 ry39uL8Wq9FmlAuGLsU660qQ6BbA6kyGCTFp92S6fZXb4uDJqHFpbYSuxU_R GBhxB6LGyQK_QBsg- Received: from [38.117.85.142] by web121612.mail.ne1.yahoo.com via HTTP; Thu, 04 Aug 2011 12:40:23 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.113.313619 Message-ID: <1312486823.22682.YahooMailClassic@web121612.mail.ne1.yahoo.com> Date: Thu, 4 Aug 2011 12:40:23 -0700 (PDT) From: Robert Wu To: subir@research.telcordia.com, paws@ietf.org, scott.probasco@nokia.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1560677079-1312486823=:22682" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:40:09 -0000 --0-1560677079-1312486823=:22682 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Will be very happy if PAWS can support this use case - critical for M2M.=A0 Best regards,=A0Robert=A0 6Harmonics Inc.=A0 --- On Fri, 8/5/11, scott.probasco@nokia.com wro= te: From: scott.probasco@nokia.com Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's To: subir@research.telcordia.com, paws@ietf.org Received: Friday, August 5, 2011, 1:35 AM Hi Subir, Yes. The use case below requires this functionality. Regards, Scott On 8/4/11 1:51 PM, "ext Subir Das" wrote: >Scott, >Are you suggesting to have proxy/relay support ? > >Thanks, >_Subir > >On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >> Hi, >> >> I support this use case. PAWS should support a query from one entity on >> behalf of another. >> >> Regards, >> Scott >> >> >> On 8/3/11 7:38 AM, "ext Rosen, Brian"=A0 wrote: >> >>> I think this is a good use case and brings up a new requirement: >>> The protocol must cater for a query from one entity on behalf of >>>another >>> entity. >>> >>> In many circumstances, this would be invisible to the protocol - the >>> relay client would simply relay packets or use some private protocol. >>> However, in some circumstances we may need to know the identity of the >>> requester as well as the real client, so the actual requirement is to >>>be >>> able to carry two identities. >>> >>> Brian >>> >>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>> >>>> Hi Scott, >>>> >>>> I have written down an practical use case for PAWS in an ad hoc >>>> network for emergency scenario's. Please comment. >>>> >>>> Thanks, Teco >>>> >>>> >>>> >>>> 3.x.=A0 Rapid deployed network for emergency scenarios >>>> >>>> Organizations involved in handling emergency operations often have >>>> a fully owned and controlled infrastructure, with dedicated spectrum, >>>> for day to day operation. However, lessons learned from recent >>>> disasters show such infrastructures are often highly affected by the >>>> disaster itself. To set up a replacement quickly, there is a need for >>>> fast reallocation of spectrum, where in certain cases spectrum can be >>>> freed for disaster relief. >>>> >>>> To utilize free or freed spectrum quickly and reliable, automation of >>>> allocation, assignment and configuration is needed. A preferred >>>> option is make use of a robust protocol, already adopted by radio >>>> manufacturers. This approach does in no way imply such organizations >>>> for disaster relief must compete on spectrum allocation with other >>>> white spaces users, but they can. >>>> >>>> A typical network topology would include wireless access links to >>>> the public Internet or private network, wireless ad hoc network >>>> radios working independent of a fixed infrastructure and satellite >>>> links for backup where lack of coverage, overload or outage of >>>> wireless access links occur. >>>> >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \|/ >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0| ad hoc >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0| >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0|-|-----------= --| >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0| Master node= =A0=A0=A0|=A0 =A0 =A0=A0=A0|------------| >>>>=A0=A0=A0\|/=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0| with=A0 =A0 = =A0 =A0 =A0 |=A0 =A0 =A0=A0=A0| Whitespace | >>>>=A0 =A0 | ad hoc=A0 =A0 =A0 =A0 =A0 =A0 =A0 /| backhaul link |=A0 =A0 = =A0=A0=A0| Database=A0=A0=A0| >>>>=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 /-----/ |---------------|=A0 =A0 = =A0=A0=A0|------------| >>>> --|-------------/=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 \=A0 =A0= =A0 =A0 =A0=A0=A0/ >>>> | Master node=A0=A0=A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0=A0= =A0|=A0 =A0 =A0 (--/--) >>>> | without=A0 =A0 =A0=A0=A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 = =A0=A0=A0------(=A0 =A0 =A0=A0=A0) >>>> | backhaul link |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 Wireless=A0 / Pr= ivate \ >>>> ---------------\-=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 Access (=A0= =A0=A0net or=A0 ) >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 \ Internet ) >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0\=A0 =A0 \|/=A0 =A0 =A0 =A0 |= =A0 =A0 =A0 -------(=A0 =A0 =A0 =A0 /\ >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \=A0 =A0 | ad hoc=A0 |=A0 =A0 = =A0 |=A0 =A0 =A0=A0=A0(------)=A0 \--------- >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0\=A0=A0=A0|=A0 =A0 =A0 =A0= =A0=A0|=A0 =A0 =A0 /=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0| Other=A0 | >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \--|-------------=A0 /Satel= lite=A0 =A0 =A0 =A0=A0=A0| nodes=A0 | >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Master node=A0=A0=A0| / L= ink=A0 =A0 =A0 =A0 =A0 =A0 =A0 ---------- >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | with=A0 =A0 =A0 =A0 =A0 |= / >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | backhaul link | >>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ----------------- >>>> >>>> >>>>=A0 =A0 =A0 Figure x: Rapid deployed network with partly connected node= s >>>> >>>> >>>> In the ad hoc network, all nodes are master nodes in a way that >>>> they allocate RF channels from the white space database. However, >>>> the backhaul link could not be available to all nodes, such as >>>> depicted for the left node in figure x. To handle RF channel >>>> allocation for such nodes, a master node with a backhaul link >>>> relays or proxies the database query for them. So master nodes >>>> without a backhaul link follow the procedure as defined for >>>> clients. >>>> >>>> The ad hoc network radios utilise the provided RF channels. Details >>>> on forming and maintenance of the ad hoc network, including repair >>>> of segmented networks caused by segments operating on different >>>> RF channels, is out of scope of spectrum allocation. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --0-1560677079-1312486823=:22682 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1560677079-1312486823=:22682-- From subir@research.telcordia.com Thu Aug 4 12:46:09 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD11F0C3F for ; Thu, 4 Aug 2011 12:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJLfEKYCrdSa for ; Thu, 4 Aug 2011 12:46:09 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id E873321F898E for ; Thu, 4 Aug 2011 12:46:08 -0700 (PDT) Received: from [128.96.58.39] (vpntnlA39.research.telcordia.com [128.96.58.39]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p74JkHrN001781; Thu, 4 Aug 2011 15:46:20 -0400 (EDT) Message-ID: <4E3AF70D.8010000@research.telcordia.com> Date: Thu, 04 Aug 2011 15:46:21 -0400 From: Subir Das User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: scott.probasco@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:46:09 -0000 Thanks. _Subir On 8/4/2011 3:35 PM, scott.probasco@nokia.com wrote: > Hi Subir, > > Yes. The use case below requires this functionality. > > Regards, > Scott > > > On 8/4/11 1:51 PM, "ext Subir Das" wrote: > >> Scott, >> Are you suggesting to have proxy/relay support ? >> >> Thanks, >> _Subir >> >> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>> Hi, >>> >>> I support this use case. PAWS should support a query from one entity on >>> behalf of another. >>> >>> Regards, >>> Scott >>> >>> >>> On 8/3/11 7:38 AM, "ext Rosen, Brian" wrote: >>> >>>> I think this is a good use case and brings up a new requirement: >>>> The protocol must cater for a query from one entity on behalf of >>>> another >>>> entity. >>>> >>>> In many circumstances, this would be invisible to the protocol - the >>>> relay client would simply relay packets or use some private protocol. >>>> However, in some circumstances we may need to know the identity of the >>>> requester as well as the real client, so the actual requirement is to >>>> be >>>> able to carry two identities. >>>> >>>> Brian >>>> >>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>> >>>>> Hi Scott, >>>>> >>>>> I have written down an practical use case for PAWS in an ad hoc >>>>> network for emergency scenario's. Please comment. >>>>> >>>>> Thanks, Teco >>>>> >>>>> >>>>> >>>>> 3.x. Rapid deployed network for emergency scenarios >>>>> >>>>> Organizations involved in handling emergency operations often have >>>>> a fully owned and controlled infrastructure, with dedicated spectrum, >>>>> for day to day operation. However, lessons learned from recent >>>>> disasters show such infrastructures are often highly affected by the >>>>> disaster itself. To set up a replacement quickly, there is a need for >>>>> fast reallocation of spectrum, where in certain cases spectrum can be >>>>> freed for disaster relief. >>>>> >>>>> To utilize free or freed spectrum quickly and reliable, automation of >>>>> allocation, assignment and configuration is needed. A preferred >>>>> option is make use of a robust protocol, already adopted by radio >>>>> manufacturers. This approach does in no way imply such organizations >>>>> for disaster relief must compete on spectrum allocation with other >>>>> white spaces users, but they can. >>>>> >>>>> A typical network topology would include wireless access links to >>>>> the public Internet or private network, wireless ad hoc network >>>>> radios working independent of a fixed infrastructure and satellite >>>>> links for backup where lack of coverage, overload or outage of >>>>> wireless access links occur. >>>>> >>>>> \|/ >>>>> | ad hoc >>>>> | >>>>> |-|-------------| >>>>> | Master node | |------------| >>>>> \|/ | with | | Whitespace | >>>>> | ad hoc /| backhaul link | | Database | >>>>> | /-----/ |---------------| |------------| >>>>> --|-------------/ | \ / >>>>> | Master node | | | (--/--) >>>>> | without | | ------( ) >>>>> | backhaul link | | Wireless / Private \ >>>>> ---------------\- | Access ( net or ) >>>>> \ | \ Internet ) >>>>> \ \|/ | -------( /\ >>>>> \ | ad hoc | | (------) \--------- >>>>> \ | | / | Other | >>>>> \--|------------- /Satellite | nodes | >>>>> | Master node | / Link ---------- >>>>> | with |/ >>>>> | backhaul link | >>>>> ----------------- >>>>> >>>>> >>>>> Figure x: Rapid deployed network with partly connected nodes >>>>> >>>>> >>>>> In the ad hoc network, all nodes are master nodes in a way that >>>>> they allocate RF channels from the white space database. However, >>>>> the backhaul link could not be available to all nodes, such as >>>>> depicted for the left node in figure x. To handle RF channel >>>>> allocation for such nodes, a master node with a backhaul link >>>>> relays or proxies the database query for them. So master nodes >>>>> without a backhaul link follow the procedure as defined for >>>>> clients. >>>>> >>>>> The ad hoc network radios utilise the provided RF channels. Details >>>>> on forming and maintenance of the ad hoc network, including repair >>>>> of segmented networks caused by segments operating on different >>>>> RF channels, is out of scope of spectrum allocation. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Thu Aug 4 14:59:43 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F150221F86AF for ; Thu, 4 Aug 2011 14:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oksU1Q9wgQtn for ; Thu, 4 Aug 2011 14:59:42 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id CC54621F863C for ; Thu, 4 Aug 2011 14:59:41 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTjsWTf6Svs2+NlVsvZfZDhXJ/1f/p1SB@postini.com; Thu, 04 Aug 2011 14:59:57 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 4 Aug 2011 14:59:40 -0700 From: Paul Lambert To: "scott.probasco@nokia.com" , "subir@research.telcordia.com" , "paws@ietf.org" Date: Thu, 4 Aug 2011 14:59:38 -0700 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AQHMTHiIDmEnhbg6zkGnITr0qmH85JUJPwyAgAFvpmGAAEtugP//4QuAgAIZU4D//7iWgIAAnBkA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> References: <4E3AEA21.9050800@research.telcordia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:59:43 -0000 I don't see that a proxy or two addresses are ever required to meet the des= cribed use cases. 1) security needs to be end-to-end and a proxy that can modify the request = is not allowed by the FCC 2) devices that cannot initially reach the GDB can initially be a client/sl= ave/Mode I device The "master" then asks on their behalf and enables operation of the clie= nt Subsequently the device that was the client could act as a Master since it can now reach the GDB through the initial master Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > scott.probasco@nokia.com > Sent: Thursday, August 04, 2011 12:36 PM > To: subir@research.telcordia.com; paws@ietf.org > Subject: Re: [paws] PAWS use case: ad hoc network for emergency > scenario's >=20 > Hi Subir, >=20 > Yes. The use case below requires this functionality. >=20 > Regards, > Scott >=20 >=20 > On 8/4/11 1:51 PM, "ext Subir Das" > wrote: >=20 > >Scott, > >Are you suggesting to have proxy/relay support ? > > > >Thanks, > >_Subir > > > >On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: > >> Hi, > >> > >> I support this use case. PAWS should support a query from one entity > on > >> behalf of another. > >> > >> Regards, > >> Scott > >> > >> > >> On 8/3/11 7:38 AM, "ext Rosen, Brian" > wrote: > >> > >>> I think this is a good use case and brings up a new requirement: > >>> The protocol must cater for a query from one entity on behalf of > >>>another > >>> entity. > >>> > >>> In many circumstances, this would be invisible to the protocol - > the > >>> relay client would simply relay packets or use some private > protocol. > >>> However, in some circumstances we may need to know the identity of > the > >>> requester as well as the real client, so the actual requirement is > to > >>>be > >>> able to carry two identities. > >>> > >>> Brian > >>> > >>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > >>> > >>>> Hi Scott, > >>>> > >>>> I have written down an practical use case for PAWS in an ad hoc > >>>> network for emergency scenario's. Please comment. > >>>> > >>>> Thanks, Teco > >>>> > >>>> > >>>> > >>>> 3.x. Rapid deployed network for emergency scenarios > >>>> > >>>> Organizations involved in handling emergency operations often have > >>>> a fully owned and controlled infrastructure, with dedicated > spectrum, > >>>> for day to day operation. However, lessons learned from recent > >>>> disasters show such infrastructures are often highly affected by > the > >>>> disaster itself. To set up a replacement quickly, there is a need > for > >>>> fast reallocation of spectrum, where in certain cases spectrum can > be > >>>> freed for disaster relief. > >>>> > >>>> To utilize free or freed spectrum quickly and reliable, automation > of > >>>> allocation, assignment and configuration is needed. A preferred > >>>> option is make use of a robust protocol, already adopted by radio > >>>> manufacturers. This approach does in no way imply such > organizations > >>>> for disaster relief must compete on spectrum allocation with other > >>>> white spaces users, but they can. > >>>> > >>>> A typical network topology would include wireless access links to > >>>> the public Internet or private network, wireless ad hoc network > >>>> radios working independent of a fixed infrastructure and satellite > >>>> links for backup where lack of coverage, overload or outage of > >>>> wireless access links occur. > >>>> > >>>> \|/ > >>>> | ad hoc > >>>> | > >>>> |-|-------------| > >>>> | Master node | |------------| > >>>> \|/ | with | | Whitespace | > >>>> | ad hoc /| backhaul link | | Database | > >>>> | /-----/ |---------------| |------------| > >>>> --|-------------/ | \ / > >>>> | Master node | | | (--/--) > >>>> | without | | ------( ) > >>>> | backhaul link | | Wireless / Private \ > >>>> ---------------\- | Access ( net or ) > >>>> \ | \ Internet ) > >>>> \ \|/ | -------( /\ > >>>> \ | ad hoc | | (------) \------ > --- > >>>> \ | | / | Other > | > >>>> \--|------------- /Satellite | nodes > | > >>>> | Master node | / Link ------- > --- > >>>> | with |/ > >>>> | backhaul link | > >>>> ----------------- > >>>> > >>>> > >>>> Figure x: Rapid deployed network with partly connected nodes > >>>> > >>>> > >>>> In the ad hoc network, all nodes are master nodes in a way that > >>>> they allocate RF channels from the white space database. However, > >>>> the backhaul link could not be available to all nodes, such as > >>>> depicted for the left node in figure x. To handle RF channel > >>>> allocation for such nodes, a master node with a backhaul link > >>>> relays or proxies the database query for them. So master nodes > >>>> without a backhaul link follow the procedure as defined for > >>>> clients. > >>>> > >>>> The ad hoc network radios utilise the provided RF channels. > Details > >>>> on forming and maintenance of the ad hoc network, including repair > >>>> of segmented networks caused by segments operating on different > >>>> RF channels, is out of scope of spectrum allocation. > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Thu Aug 4 15:06:41 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9E228006 for ; Thu, 4 Aug 2011 15:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvLHrnH3Enq2 for ; Thu, 4 Aug 2011 15:06:40 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E81CE21F8ABC for ; Thu, 4 Aug 2011 15:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312495614; x=1627852275; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Y9jhIf5TiijXZqxu+Jd7/ 8AOQlXWDvVCz6M0aAZy7P8=; b=HmGBZieDelTF2n3m3erdosV520mPrK8tIbpqB VLhq2sqlUffec3SDTRj6D/Zf57XL3GBZxjbT2K78vk1lL6mmA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.25516873; Thu, 04 Aug 2011 18:06:53 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 4 Aug 2011 18:06:53 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Thu, 4 Aug 2011 18:06:51 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxS8tC43mA2CSHjR3OhYq+Cidrk6g== Message-ID: <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:06:41 -0000 You are confusing U.S. FCC rules with IETF protocol requirements. We have several participants, including me, that would foresee "on behalf o= f" requests, where identification of both the original requester and the in= termediary may be needed. I will reiterate that it may be that the interm= ediary is simply relaying packets and would not be visible in a protocol ex= change. That would work on current FCC rules, but doesn't need anything in= the protocol to support. Just because the FCC currently disallows such a situation does not mean tha= t there won't be other nations that do allow them. I do think that the security model has to be fleshed out more, and we might= have more requirements there. =20 Brian On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: > I don't see that a proxy or two addresses are ever required to meet the d= escribed use cases. > 1) security needs to be end-to-end and a proxy that can modify the reques= t is not allowed by the FCC > 2) devices that cannot initially reach the GDB can initially be a client/= slave/Mode I device > The "master" then asks on their behalf and enables operation of the cli= ent > Subsequently the device that was the client could act as a Master > since it can now reach the GDB through the initial master >=20 >=20 > Paul >=20 >=20 >=20 > Paul A. Lambert | Marvell | +1 650 787 9141 >=20 >=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> scott.probasco@nokia.com >> Sent: Thursday, August 04, 2011 12:36 PM >> To: subir@research.telcordia.com; paws@ietf.org >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >> scenario's >>=20 >> Hi Subir, >>=20 >> Yes. The use case below requires this functionality. >>=20 >> Regards, >> Scott >>=20 >>=20 >> On 8/4/11 1:51 PM, "ext Subir Das" >> wrote: >>=20 >>> Scott, >>> Are you suggesting to have proxy/relay support ? >>>=20 >>> Thanks, >>> _Subir >>>=20 >>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>>> Hi, >>>>=20 >>>> I support this use case. PAWS should support a query from one entity >> on >>>> behalf of another. >>>>=20 >>>> Regards, >>>> Scott >>>>=20 >>>>=20 >>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" >> wrote: >>>>=20 >>>>> I think this is a good use case and brings up a new requirement: >>>>> The protocol must cater for a query from one entity on behalf of >>>>> another >>>>> entity. >>>>>=20 >>>>> In many circumstances, this would be invisible to the protocol - >> the >>>>> relay client would simply relay packets or use some private >> protocol. >>>>> However, in some circumstances we may need to know the identity of >> the >>>>> requester as well as the real client, so the actual requirement is >> to >>>>> be >>>>> able to carry two identities. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>=20 >>>>>> Hi Scott, >>>>>>=20 >>>>>> I have written down an practical use case for PAWS in an ad hoc >>>>>> network for emergency scenario's. Please comment. >>>>>>=20 >>>>>> Thanks, Teco >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>=20 >>>>>> Organizations involved in handling emergency operations often have >>>>>> a fully owned and controlled infrastructure, with dedicated >> spectrum, >>>>>> for day to day operation. However, lessons learned from recent >>>>>> disasters show such infrastructures are often highly affected by >> the >>>>>> disaster itself. To set up a replacement quickly, there is a need >> for >>>>>> fast reallocation of spectrum, where in certain cases spectrum can >> be >>>>>> freed for disaster relief. >>>>>>=20 >>>>>> To utilize free or freed spectrum quickly and reliable, automation >> of >>>>>> allocation, assignment and configuration is needed. A preferred >>>>>> option is make use of a robust protocol, already adopted by radio >>>>>> manufacturers. This approach does in no way imply such >> organizations >>>>>> for disaster relief must compete on spectrum allocation with other >>>>>> white spaces users, but they can. >>>>>>=20 >>>>>> A typical network topology would include wireless access links to >>>>>> the public Internet or private network, wireless ad hoc network >>>>>> radios working independent of a fixed infrastructure and satellite >>>>>> links for backup where lack of coverage, overload or outage of >>>>>> wireless access links occur. >>>>>>=20 >>>>>> \|/ >>>>>> | ad hoc >>>>>> | >>>>>> |-|-------------| >>>>>> | Master node | |------------| >>>>>> \|/ | with | | Whitespace | >>>>>> | ad hoc /| backhaul link | | Database | >>>>>> | /-----/ |---------------| |------------| >>>>>> --|-------------/ | \ / >>>>>> | Master node | | | (--/--) >>>>>> | without | | ------( ) >>>>>> | backhaul link | | Wireless / Private \ >>>>>> ---------------\- | Access ( net or ) >>>>>> \ | \ Internet ) >>>>>> \ \|/ | -------( /\ >>>>>> \ | ad hoc | | (------) \------ >> --- >>>>>> \ | | / | Other >> | >>>>>> \--|------------- /Satellite | nodes >> | >>>>>> | Master node | / Link ------- >> --- >>>>>> | with |/ >>>>>> | backhaul link | >>>>>> ----------------- >>>>>>=20 >>>>>>=20 >>>>>> Figure x: Rapid deployed network with partly connected nodes >>>>>>=20 >>>>>>=20 >>>>>> In the ad hoc network, all nodes are master nodes in a way that >>>>>> they allocate RF channels from the white space database. However, >>>>>> the backhaul link could not be available to all nodes, such as >>>>>> depicted for the left node in figure x. To handle RF channel >>>>>> allocation for such nodes, a master node with a backhaul link >>>>>> relays or proxies the database query for them. So master nodes >>>>>> without a backhaul link follow the procedure as defined for >>>>>> clients. >>>>>>=20 >>>>>> The ad hoc network radios utilise the provided RF channels. >> Details >>>>>> on forming and maintenance of the ad hoc network, including repair >>>>>> of segmented networks caused by segments operating on different >>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Thu Aug 4 16:33:09 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F7821F8A7E for ; Thu, 4 Aug 2011 16:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arvLWJnsqslq for ; Thu, 4 Aug 2011 16:33:09 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59C21F8A7D for ; Thu, 4 Aug 2011 16:33:08 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTjssOKZnJAcJXG0/y63DP9XWBw3P2T9R@postini.com; Thu, 04 Aug 2011 16:33:24 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Thu, 4 Aug 2011 16:33:12 -0700 From: Paul Lambert To: "Rosen, Brian" Date: Thu, 4 Aug 2011 16:33:10 -0700 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxS8tC43mA2CSHjR3OhYq+Cidrk6gAC1sLw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> In-Reply-To: <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:33:09 -0000 Ok - FCC being an example ... here's the requirement: 48) The PAWS protocols must provide end-to-end security that prevents the m= odification of the messages sent between a White Spaces Device and the Geol= ocation Database. A proxy is a man-in-the-middle attack. A proxy that can modify a request a= nd insert it's own address information is a mechanisms and not a useful req= uirement. A transparent proxy ... that tunnels messages or changes link/network/trans= port layer information is possible, but does not seem very interesting in t= he scope of this effort.=20 Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Thursday, August 04, 2011 3:07 PM > To: Paul Lambert > Cc: scott.probasco@nokia.com; subir@research.telcordia.com; > paws@ietf.org > Subject: Re: [paws] PAWS use case: ad hoc network for emergency > scenario's >=20 > You are confusing U.S. FCC rules with IETF protocol requirements. >=20 > We have several participants, including me, that would foresee "on > behalf of" requests, where identification of both the original > requester and the intermediary may be needed. I will reiterate that > it may be that the intermediary is simply relaying packets and would > not be visible in a protocol exchange. That would work on current FCC > rules, but doesn't need anything in the protocol to support. >=20 > Just because the FCC currently disallows such a situation does not mean > that there won't be other nations that do allow them. >=20 > I do think that the security model has to be fleshed out more, and we > might have more requirements there. >=20 > Brian >=20 > On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: >=20 > > I don't see that a proxy or two addresses are ever required to meet > the described use cases. > > 1) security needs to be end-to-end and a proxy that can modify the > request is not allowed by the FCC > > 2) devices that cannot initially reach the GDB can initially be a > client/slave/Mode I device > > The "master" then asks on their behalf and enables operation of the > client > > Subsequently the device that was the client could act as a Master > > since it can now reach the GDB through the initial master > > > > > > Paul > > > > > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > > > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> scott.probasco@nokia.com > >> Sent: Thursday, August 04, 2011 12:36 PM > >> To: subir@research.telcordia.com; paws@ietf.org > >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency > >> scenario's > >> > >> Hi Subir, > >> > >> Yes. The use case below requires this functionality. > >> > >> Regards, > >> Scott > >> > >> > >> On 8/4/11 1:51 PM, "ext Subir Das" > >> wrote: > >> > >>> Scott, > >>> Are you suggesting to have proxy/relay support ? > >>> > >>> Thanks, > >>> _Subir > >>> > >>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: > >>>> Hi, > >>>> > >>>> I support this use case. PAWS should support a query from one > entity > >> on > >>>> behalf of another. > >>>> > >>>> Regards, > >>>> Scott > >>>> > >>>> > >>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" > >> wrote: > >>>> > >>>>> I think this is a good use case and brings up a new requirement: > >>>>> The protocol must cater for a query from one entity on behalf of > >>>>> another > >>>>> entity. > >>>>> > >>>>> In many circumstances, this would be invisible to the protocol - > >> the > >>>>> relay client would simply relay packets or use some private > >> protocol. > >>>>> However, in some circumstances we may need to know the identity > of > >> the > >>>>> requester as well as the real client, so the actual requirement > is > >> to > >>>>> be > >>>>> able to carry two identities. > >>>>> > >>>>> Brian > >>>>> > >>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > >>>>> > >>>>>> Hi Scott, > >>>>>> > >>>>>> I have written down an practical use case for PAWS in an ad hoc > >>>>>> network for emergency scenario's. Please comment. > >>>>>> > >>>>>> Thanks, Teco > >>>>>> > >>>>>> > >>>>>> > >>>>>> 3.x. Rapid deployed network for emergency scenarios > >>>>>> > >>>>>> Organizations involved in handling emergency operations often > have > >>>>>> a fully owned and controlled infrastructure, with dedicated > >> spectrum, > >>>>>> for day to day operation. However, lessons learned from recent > >>>>>> disasters show such infrastructures are often highly affected by > >> the > >>>>>> disaster itself. To set up a replacement quickly, there is a > need > >> for > >>>>>> fast reallocation of spectrum, where in certain cases spectrum > can > >> be > >>>>>> freed for disaster relief. > >>>>>> > >>>>>> To utilize free or freed spectrum quickly and reliable, > automation > >> of > >>>>>> allocation, assignment and configuration is needed. A preferred > >>>>>> option is make use of a robust protocol, already adopted by > radio > >>>>>> manufacturers. This approach does in no way imply such > >> organizations > >>>>>> for disaster relief must compete on spectrum allocation with > other > >>>>>> white spaces users, but they can. > >>>>>> > >>>>>> A typical network topology would include wireless access links > to > >>>>>> the public Internet or private network, wireless ad hoc network > >>>>>> radios working independent of a fixed infrastructure and > satellite > >>>>>> links for backup where lack of coverage, overload or outage of > >>>>>> wireless access links occur. > >>>>>> > >>>>>> \|/ > >>>>>> | ad hoc > >>>>>> | > >>>>>> |-|-------------| > >>>>>> | Master node | |------------| > >>>>>> \|/ | with | | Whitespace | > >>>>>> | ad hoc /| backhaul link | | Database | > >>>>>> | /-----/ |---------------| |------------| > >>>>>> --|-------------/ | \ / > >>>>>> | Master node | | | (--/--) > >>>>>> | without | | ------( ) > >>>>>> | backhaul link | | Wireless / Private \ > >>>>>> ---------------\- | Access ( net or ) > >>>>>> \ | \ Internet ) > >>>>>> \ \|/ | -------( /\ > >>>>>> \ | ad hoc | | (------) \----- > - > >> --- > >>>>>> \ | | / | > Other > >> | > >>>>>> \--|------------- /Satellite | > nodes > >> | > >>>>>> | Master node | / Link ------ > - > >> --- > >>>>>> | with |/ > >>>>>> | backhaul link | > >>>>>> ----------------- > >>>>>> > >>>>>> > >>>>>> Figure x: Rapid deployed network with partly connected nodes > >>>>>> > >>>>>> > >>>>>> In the ad hoc network, all nodes are master nodes in a way that > >>>>>> they allocate RF channels from the white space database. > However, > >>>>>> the backhaul link could not be available to all nodes, such as > >>>>>> depicted for the left node in figure x. To handle RF channel > >>>>>> allocation for such nodes, a master node with a backhaul link > >>>>>> relays or proxies the database query for them. So master nodes > >>>>>> without a backhaul link follow the procedure as defined for > >>>>>> clients. > >>>>>> > >>>>>> The ad hoc network radios utilise the provided RF channels. > >> Details > >>>>>> on forming and maintenance of the ad hoc network, including > repair > >>>>>> of segmented networks caused by segments operating on different > >>>>>> RF channels, is out of scope of spectrum allocation. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> paws mailing list > >>>>>> paws@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>> _______________________________________________ > >>>>> paws mailing list > >>>>> paws@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/paws > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Fri Aug 5 00:55:58 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1D621F893C for ; Fri, 5 Aug 2011 00:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sZxfXqV7EYP for ; Fri, 5 Aug 2011 00:55:57 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB4D21F887C for ; Fri, 5 Aug 2011 00:55:55 -0700 (PDT) Received: by ewy19 with SMTP id 19so1369636ewy.31 for ; Fri, 05 Aug 2011 00:56:12 -0700 (PDT) Received: by 10.213.98.194 with SMTP id r2mr630673ebn.15.1312530971977; Fri, 05 Aug 2011 00:56:11 -0700 (PDT) Received: from [10.175.173.2] (524A158D.cm-4-3a.dynamic.ziggo.nl [82.74.21.141]) by mx.google.com with ESMTPS id p49sm1130456eef.58.2011.08.05.00.56.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 00:56:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> Date: Fri, 5 Aug 2011 09:56:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:55:58 -0000 Paul, Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende geschreven: > Ok - FCC being an example ... here's the requirement: >=20 > 48) The PAWS protocols must provide end-to-end security that prevents = the modification of the messages sent between a White Spaces Device and = the Geolocation Database. Please provide ref. I read FCC requirements as it allows a (protected) proxy function = between Mode II and Fixed / Mode I. Other regulators exist. FCC Federal Register/Vol. 75, No. 233:: >> 62. The Commission will further require that communications between = TV bands devices and databases be transmitted using secure methods to = prevent corruption or unauthorized modification of data. This = requirement includes communications of channel availability and other = spectrum access information between fixed and Mode II devices (it is not = necessary for TVBDs to apply security coding to channel availability and = channel access information that they simply pass through as such = information will already be protected by the sending device). The = Commission will require that when Mode I devices communicate with fixed = or Mode II devices for purposes of obtaining a list of available = channels, they are to use a secure method that ensures against = corruption or unauthorized modification of the data.=20 And: >> (f) Mode II personal/portable device. A personal/portable TVBD that = uses an internal geo-location capability and access to a TV bands = database, either through a direct connection to the Internet or through = an indirect connection to the Internet by way of fixed TVBD or another = Mode II TVBD, to obtain a list of available channels. I see (future) possibilities for this proxy function between fixed = (rapid deployed) nodes. > A proxy is a man-in-the-middle attack. A proxy that can modify a = request and insert it's own address information is a mechanisms and not = a useful requirement. If a TVWS device is malfunctioning, the security model is broken. > A transparent proxy ... that tunnels messages or changes = link/network/transport layer information is possible, but does not seem = very interesting in the scope of this effort.=20 If relay is used, it could be IP packet forwarding. Or PAWS message = relay. No impact on PAWS protocol indeed. But this is to be decided = later on. The use case simply describes the use case, nothing more. Next = steps are gathering requirements and engineering. Teco=20 >=20 > Paul >=20 >=20 > Paul A. Lambert | Marvell | +1 650 787 9141 >=20 >=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Thursday, August 04, 2011 3:07 PM >> To: Paul Lambert >> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; >> paws@ietf.org >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >> scenario's >>=20 >> You are confusing U.S. FCC rules with IETF protocol requirements. >>=20 >> We have several participants, including me, that would foresee "on >> behalf of" requests, where identification of both the original >> requester and the intermediary may be needed. I will reiterate that >> it may be that the intermediary is simply relaying packets and would >> not be visible in a protocol exchange. That would work on current = FCC >> rules, but doesn't need anything in the protocol to support. >>=20 >> Just because the FCC currently disallows such a situation does not = mean >> that there won't be other nations that do allow them. >>=20 >> I do think that the security model has to be fleshed out more, and we >> might have more requirements there. >>=20 >> Brian >>=20 >> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: >>=20 >>> I don't see that a proxy or two addresses are ever required to meet >> the described use cases. >>> 1) security needs to be end-to-end and a proxy that can modify the >> request is not allowed by the FCC >>> 2) devices that cannot initially reach the GDB can initially be a >> client/slave/Mode I device >>> The "master" then asks on their behalf and enables operation of the >> client >>> Subsequently the device that was the client could act as a Master >>> since it can now reach the GDB through the initial master >>>=20 >>>=20 >>> Paul >>>=20 >>>=20 >>>=20 >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf >> Of >>>> scott.probasco@nokia.com >>>> Sent: Thursday, August 04, 2011 12:36 PM >>>> To: subir@research.telcordia.com; paws@ietf.org >>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>> scenario's >>>>=20 >>>> Hi Subir, >>>>=20 >>>> Yes. The use case below requires this functionality. >>>>=20 >>>> Regards, >>>> Scott >>>>=20 >>>>=20 >>>> On 8/4/11 1:51 PM, "ext Subir Das" >>>> wrote: >>>>=20 >>>>> Scott, >>>>> Are you suggesting to have proxy/relay support ? >>>>>=20 >>>>> Thanks, >>>>> _Subir >>>>>=20 >>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I support this use case. PAWS should support a query from one >> entity >>>> on >>>>>> behalf of another. >>>>>>=20 >>>>>> Regards, >>>>>> Scott >>>>>>=20 >>>>>>=20 >>>>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" >>>> wrote: >>>>>>=20 >>>>>>> I think this is a good use case and brings up a new requirement: >>>>>>> The protocol must cater for a query from one entity on behalf of >>>>>>> another >>>>>>> entity. >>>>>>>=20 >>>>>>> In many circumstances, this would be invisible to the protocol - >>>> the >>>>>>> relay client would simply relay packets or use some private >>>> protocol. >>>>>>> However, in some circumstances we may need to know the identity >> of >>>> the >>>>>>> requester as well as the real client, so the actual requirement >> is >>>> to >>>>>>> be >>>>>>> able to carry two identities. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>>>=20 >>>>>>>> Hi Scott, >>>>>>>>=20 >>>>>>>> I have written down an practical use case for PAWS in an ad hoc >>>>>>>> network for emergency scenario's. Please comment. >>>>>>>>=20 >>>>>>>> Thanks, Teco >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>>>=20 >>>>>>>> Organizations involved in handling emergency operations often >> have >>>>>>>> a fully owned and controlled infrastructure, with dedicated >>>> spectrum, >>>>>>>> for day to day operation. However, lessons learned from recent >>>>>>>> disasters show such infrastructures are often highly affected = by >>>> the >>>>>>>> disaster itself. To set up a replacement quickly, there is a >> need >>>> for >>>>>>>> fast reallocation of spectrum, where in certain cases spectrum >> can >>>> be >>>>>>>> freed for disaster relief. >>>>>>>>=20 >>>>>>>> To utilize free or freed spectrum quickly and reliable, >> automation >>>> of >>>>>>>> allocation, assignment and configuration is needed. A preferred >>>>>>>> option is make use of a robust protocol, already adopted by >> radio >>>>>>>> manufacturers. This approach does in no way imply such >>>> organizations >>>>>>>> for disaster relief must compete on spectrum allocation with >> other >>>>>>>> white spaces users, but they can. >>>>>>>>=20 >>>>>>>> A typical network topology would include wireless access links >> to >>>>>>>> the public Internet or private network, wireless ad hoc network >>>>>>>> radios working independent of a fixed infrastructure and >> satellite >>>>>>>> links for backup where lack of coverage, overload or outage of >>>>>>>> wireless access links occur. >>>>>>>>=20 >>>>>>>> \|/ >>>>>>>> | ad hoc >>>>>>>> | >>>>>>>> |-|-------------| >>>>>>>> | Master node | |------------| >>>>>>>> \|/ | with | | Whitespace | >>>>>>>> | ad hoc /| backhaul link | | Database | >>>>>>>> | /-----/ |---------------| |------------| >>>>>>>> --|-------------/ | \ / >>>>>>>> | Master node | | | (--/--) >>>>>>>> | without | | ------( ) >>>>>>>> | backhaul link | | Wireless / Private \ >>>>>>>> ---------------\- | Access ( net or ) >>>>>>>> \ | \ Internet ) >>>>>>>> \ \|/ | -------( /\ >>>>>>>> \ | ad hoc | | (------) \----- >> - >>>> --- >>>>>>>> \ | | / | >> Other >>>> | >>>>>>>> \--|------------- /Satellite | >> nodes >>>> | >>>>>>>> | Master node | / Link ------ >> - >>>> --- >>>>>>>> | with |/ >>>>>>>> | backhaul link | >>>>>>>> ----------------- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Figure x: Rapid deployed network with partly connected nodes >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> In the ad hoc network, all nodes are master nodes in a way that >>>>>>>> they allocate RF channels from the white space database. >> However, >>>>>>>> the backhaul link could not be available to all nodes, such as >>>>>>>> depicted for the left node in figure x. To handle RF channel >>>>>>>> allocation for such nodes, a master node with a backhaul link >>>>>>>> relays or proxies the database query for them. So master nodes >>>>>>>> without a backhaul link follow the procedure as defined for >>>>>>>> clients. >>>>>>>>=20 >>>>>>>> The ad hoc network radios utilise the provided RF channels. >>>> Details >>>>>>>> on forming and maintenance of the ad hoc network, including >> repair >>>>>>>> of segmented networks caused by segments operating on different >>>>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Fri Aug 5 05:38:23 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924E221F859E for ; Fri, 5 Aug 2011 05:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMvD9M2qvhJH for ; Fri, 5 Aug 2011 05:38:19 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E930C21F85A3 for ; Fri, 5 Aug 2011 05:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312547909; x=1627897246; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=X5fLV6Mff1h9Y6/DcSd8+ ZzB2BhLP1agJt22xgaklxM=; b=WuIJk0tGy2LYi2x6G5PpSuxeeuGkE4/KvfqKv lFX86EB7ER2IpJj9N4sbblVCqEgRVU6jfri3tPxTzqkPapbrQ== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.39974560; Fri, 05 Aug 2011 08:38:28 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 5 Aug 2011 08:38:28 -0400 From: "Rosen, Brian" To: Teco Boot Date: Fri, 5 Aug 2011 08:38:27 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxTbJMG6f2zN6zNTbWPpOm1aW79Tw== Message-ID: <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> In-Reply-To: <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Z+rubxpwmzc9/3DqqUGgug== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:38:23 -0000 I believe we do have a requirement to ensure privacy and integrity in the t= ransaction between the device and the database. Privacy because location i= s revealed. Integrity because a Man in the Middle attack which modifies th= e request or response could cause interference for primary and/or secondary= users. We also have a requirement for authentication, because, as in the = U.S., the database may be a commercial service with authorized users, and, = in order to reveal location, the user will want to make sure it is talking = to the bona fide database it thinks it is. Its very common for protocols like this to have such requirements, and we p= robably would be questioned if we did not provide such capability in the pr= otocol. The protocol document will require a "Security Considerations" sec= tion in which these kinds of issues, among others, will need to be discusse= d. The IETF is particularly sensitive to the privacy considerations associ= ated with location of users. Brian On Aug 5, 2011, at 3:56 AM, Teco Boot wrote: > Paul, >=20 > Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende geschreven: >=20 >> Ok - FCC being an example ... here's the requirement: >>=20 >> 48) The PAWS protocols must provide end-to-end security that prevents th= e modification of the messages sent between a White Spaces Device and the G= eolocation Database. > Please provide ref. >=20 > I read FCC requirements as it allows a (protected) proxy function between= Mode II and Fixed / Mode I. Other regulators exist. >=20 > FCC Federal Register/Vol. 75, No. 233:: >>> 62. The Commission will further require that communications between TV = bands devices and databases be transmitted using secure methods to prevent = corruption or unauthorized modification of data. This requirement includes = communications of channel availability and other spectrum access informatio= n between fixed and Mode II devices (it is not necessary for TVBDs to apply= security coding to channel availability and channel access information tha= t they simply pass through as such information will already be protected by= the sending device). The Commission will require that when Mode I devices = communicate with fixed or Mode II devices for purposes of obtaining a list = of available channels, they are to use a secure method that ensures against= corruption or unauthorized modification of the data.=20 >=20 > And: >>> (f) Mode II personal/portable device. A personal/portable TVBD that use= s an internal geo-location capability and access to a TV bands database, ei= ther through a direct connection to the Internet or through an indirect con= nection to the Internet by way of fixed TVBD or another Mode II TVBD, to ob= tain a list of available channels. >=20 > I see (future) possibilities for this proxy function between fixed (rapid= deployed) nodes. >=20 >=20 >> A proxy is a man-in-the-middle attack. A proxy that can modify a reques= t and insert it's own address information is a mechanisms and not a useful = requirement. > If a TVWS device is malfunctioning, the security model is broken. >=20 >> A transparent proxy ... that tunnels messages or changes link/network/tr= ansport layer information is possible, but does not seem very interesting i= n the scope of this effort.=20 > If relay is used, it could be IP packet forwarding. Or PAWS message relay= . No impact on PAWS protocol indeed. But this is to be decided later on. Th= e use case simply describes the use case, nothing more. Next steps are gath= ering requirements and engineering. >=20 > Teco=20 >=20 >=20 >>=20 >> Paul >>=20 >>=20 >> Paul A. Lambert | Marvell | +1 650 787 9141 >>=20 >>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Thursday, August 04, 2011 3:07 PM >>> To: Paul Lambert >>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; >>> paws@ietf.org >>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>> scenario's >>>=20 >>> You are confusing U.S. FCC rules with IETF protocol requirements. >>>=20 >>> We have several participants, including me, that would foresee "on >>> behalf of" requests, where identification of both the original >>> requester and the intermediary may be needed. I will reiterate that >>> it may be that the intermediary is simply relaying packets and would >>> not be visible in a protocol exchange. That would work on current FCC >>> rules, but doesn't need anything in the protocol to support. >>>=20 >>> Just because the FCC currently disallows such a situation does not mean >>> that there won't be other nations that do allow them. >>>=20 >>> I do think that the security model has to be fleshed out more, and we >>> might have more requirements there. >>>=20 >>> Brian >>>=20 >>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: >>>=20 >>>> I don't see that a proxy or two addresses are ever required to meet >>> the described use cases. >>>> 1) security needs to be end-to-end and a proxy that can modify the >>> request is not allowed by the FCC >>>> 2) devices that cannot initially reach the GDB can initially be a >>> client/slave/Mode I device >>>> The "master" then asks on their behalf and enables operation of the >>> client >>>> Subsequently the device that was the client could act as a Master >>>> since it can now reach the GDB through the initial master >>>>=20 >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>>=20 >>>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>> Of >>>>> scott.probasco@nokia.com >>>>> Sent: Thursday, August 04, 2011 12:36 PM >>>>> To: subir@research.telcordia.com; paws@ietf.org >>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>>> scenario's >>>>>=20 >>>>> Hi Subir, >>>>>=20 >>>>> Yes. The use case below requires this functionality. >>>>>=20 >>>>> Regards, >>>>> Scott >>>>>=20 >>>>>=20 >>>>> On 8/4/11 1:51 PM, "ext Subir Das" >>>>> wrote: >>>>>=20 >>>>>> Scott, >>>>>> Are you suggesting to have proxy/relay support ? >>>>>>=20 >>>>>> Thanks, >>>>>> _Subir >>>>>>=20 >>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> I support this use case. PAWS should support a query from one >>> entity >>>>> on >>>>>>> behalf of another. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Scott >>>>>>>=20 >>>>>>>=20 >>>>>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" >>>>> wrote: >>>>>>>=20 >>>>>>>> I think this is a good use case and brings up a new requirement: >>>>>>>> The protocol must cater for a query from one entity on behalf of >>>>>>>> another >>>>>>>> entity. >>>>>>>>=20 >>>>>>>> In many circumstances, this would be invisible to the protocol - >>>>> the >>>>>>>> relay client would simply relay packets or use some private >>>>> protocol. >>>>>>>> However, in some circumstances we may need to know the identity >>> of >>>>> the >>>>>>>> requester as well as the real client, so the actual requirement >>> is >>>>> to >>>>>>>> be >>>>>>>> able to carry two identities. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> Hi Scott, >>>>>>>>>=20 >>>>>>>>> I have written down an practical use case for PAWS in an ad hoc >>>>>>>>> network for emergency scenario's. Please comment. >>>>>>>>>=20 >>>>>>>>> Thanks, Teco >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>>>>=20 >>>>>>>>> Organizations involved in handling emergency operations often >>> have >>>>>>>>> a fully owned and controlled infrastructure, with dedicated >>>>> spectrum, >>>>>>>>> for day to day operation. However, lessons learned from recent >>>>>>>>> disasters show such infrastructures are often highly affected by >>>>> the >>>>>>>>> disaster itself. To set up a replacement quickly, there is a >>> need >>>>> for >>>>>>>>> fast reallocation of spectrum, where in certain cases spectrum >>> can >>>>> be >>>>>>>>> freed for disaster relief. >>>>>>>>>=20 >>>>>>>>> To utilize free or freed spectrum quickly and reliable, >>> automation >>>>> of >>>>>>>>> allocation, assignment and configuration is needed. A preferred >>>>>>>>> option is make use of a robust protocol, already adopted by >>> radio >>>>>>>>> manufacturers. This approach does in no way imply such >>>>> organizations >>>>>>>>> for disaster relief must compete on spectrum allocation with >>> other >>>>>>>>> white spaces users, but they can. >>>>>>>>>=20 >>>>>>>>> A typical network topology would include wireless access links >>> to >>>>>>>>> the public Internet or private network, wireless ad hoc network >>>>>>>>> radios working independent of a fixed infrastructure and >>> satellite >>>>>>>>> links for backup where lack of coverage, overload or outage of >>>>>>>>> wireless access links occur. >>>>>>>>>=20 >>>>>>>>> \|/ >>>>>>>>> | ad hoc >>>>>>>>> | >>>>>>>>> |-|-------------| >>>>>>>>> | Master node | |------------| >>>>>>>>> \|/ | with | | Whitespace | >>>>>>>>> | ad hoc /| backhaul link | | Database | >>>>>>>>> | /-----/ |---------------| |------------| >>>>>>>>> --|-------------/ | \ / >>>>>>>>> | Master node | | | (--/--) >>>>>>>>> | without | | ------( ) >>>>>>>>> | backhaul link | | Wireless / Private \ >>>>>>>>> ---------------\- | Access ( net or ) >>>>>>>>> \ | \ Internet ) >>>>>>>>> \ \|/ | -------( /\ >>>>>>>>> \ | ad hoc | | (------) \----- >>> - >>>>> --- >>>>>>>>> \ | | / | >>> Other >>>>> | >>>>>>>>> \--|------------- /Satellite | >>> nodes >>>>> | >>>>>>>>> | Master node | / Link ------ >>> - >>>>> --- >>>>>>>>> | with |/ >>>>>>>>> | backhaul link | >>>>>>>>> ----------------- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Figure x: Rapid deployed network with partly connected nodes >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> In the ad hoc network, all nodes are master nodes in a way that >>>>>>>>> they allocate RF channels from the white space database. >>> However, >>>>>>>>> the backhaul link could not be available to all nodes, such as >>>>>>>>> depicted for the left node in figure x. To handle RF channel >>>>>>>>> allocation for such nodes, a master node with a backhaul link >>>>>>>>> relays or proxies the database query for them. So master nodes >>>>>>>>> without a backhaul link follow the procedure as defined for >>>>>>>>> clients. >>>>>>>>>=20 >>>>>>>>> The ad hoc network radios utilise the provided RF channels. >>>>> Details >>>>>>>>> on forming and maintenance of the ad hoc network, including >>> repair >>>>>>>>> of segmented networks caused by segments operating on different >>>>>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 From teco@inf-net.nl Fri Aug 5 06:29:38 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56DF21F8B92 for ; Fri, 5 Aug 2011 06:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwzRspKQHDNz for ; Fri, 5 Aug 2011 06:29:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 694BD21F8B8B for ; Fri, 5 Aug 2011 06:29:37 -0700 (PDT) Received: by ewy19 with SMTP id 19so129355ewy.31 for ; Fri, 05 Aug 2011 06:29:54 -0700 (PDT) Received: by 10.213.107.13 with SMTP id z13mr686178ebo.137.1312550994098; Fri, 05 Aug 2011 06:29:54 -0700 (PDT) Received: from [10.175.173.2] (524A158D.cm-4-3a.dynamic.ziggo.nl [82.74.21.141]) by mx.google.com with ESMTPS id x7sm286303eef.59.2011.08.05.06.29.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 06:29:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> Date: Fri, 5 Aug 2011 15:29:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:29:39 -0000 Brian, Op 5 aug 2011, om 14:38 heeft Rosen, Brian het volgende geschreven: > I believe we do have a requirement to ensure privacy and integrity in = the transaction between the device and the database. Privacy because = location is revealed. Integrity because a Man in the Middle attack = which modifies the request or response could cause interference for = primary and/or secondary users. We also have a requirement for = authentication, because, as in the U.S., the database may be a = commercial service with authorized users, and, in order to reveal = location, the user will want to make sure it is talking to the bona fide = database it thinks it is. OK. I think nothing prevents us for having a proxy or relay function. There = is a trust relation between the PAWS master and geo database. There = should be a trust relation between the TVWS master and slave (out of = scope for PAWS). If the master functions as proxy or relay for the = slave, the PAWS trust model is extended, in that the geo database has a = trust relation with the master and implicit with all its slaves. I can = imagine that some master devices are accredited for such, not all. Teco > Its very common for protocols like this to have such requirements, and = we probably would be questioned if we did not provide such capability in = the protocol. The protocol document will require a "Security = Considerations" section in which these kinds of issues, among others, = will need to be discussed. The IETF is particularly sensitive to the = privacy considerations associated with location of users. >=20 > Brian >=20 > On Aug 5, 2011, at 3:56 AM, Teco Boot wrote: >=20 >> Paul, >>=20 >> Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende geschreven: >>=20 >>> Ok - FCC being an example ... here's the requirement: >>>=20 >>> 48) The PAWS protocols must provide end-to-end security that = prevents the modification of the messages sent between a White Spaces = Device and the Geolocation Database. >> Please provide ref. >>=20 >> I read FCC requirements as it allows a (protected) proxy function = between Mode II and Fixed / Mode I. Other regulators exist. >>=20 >> FCC Federal Register/Vol. 75, No. 233:: >>>> 62. The Commission will further require that communications between = TV bands devices and databases be transmitted using secure methods to = prevent corruption or unauthorized modification of data. This = requirement includes communications of channel availability and other = spectrum access information between fixed and Mode II devices (it is not = necessary for TVBDs to apply security coding to channel availability and = channel access information that they simply pass through as such = information will already be protected by the sending device). The = Commission will require that when Mode I devices communicate with fixed = or Mode II devices for purposes of obtaining a list of available = channels, they are to use a secure method that ensures against = corruption or unauthorized modification of the data.=20 >>=20 >> And: >>>> (f) Mode II personal/portable device. A personal/portable TVBD that = uses an internal geo-location capability and access to a TV bands = database, either through a direct connection to the Internet or through = an indirect connection to the Internet by way of fixed TVBD or another = Mode II TVBD, to obtain a list of available channels. >>=20 >> I see (future) possibilities for this proxy function between fixed = (rapid deployed) nodes. >>=20 >>=20 >>> A proxy is a man-in-the-middle attack. A proxy that can modify a = request and insert it's own address information is a mechanisms and not = a useful requirement. >> If a TVWS device is malfunctioning, the security model is broken. >>=20 >>> A transparent proxy ... that tunnels messages or changes = link/network/transport layer information is possible, but does not seem = very interesting in the scope of this effort.=20 >> If relay is used, it could be IP packet forwarding. Or PAWS message = relay. No impact on PAWS protocol indeed. But this is to be decided = later on. The use case simply describes the use case, nothing more. Next = steps are gathering requirements and engineering. >>=20 >> Teco=20 >>=20 >>=20 >>>=20 >>> Paul >>>=20 >>>=20 >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Thursday, August 04, 2011 3:07 PM >>>> To: Paul Lambert >>>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; >>>> paws@ietf.org >>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>> scenario's >>>>=20 >>>> You are confusing U.S. FCC rules with IETF protocol requirements. >>>>=20 >>>> We have several participants, including me, that would foresee "on >>>> behalf of" requests, where identification of both the original >>>> requester and the intermediary may be needed. I will reiterate = that >>>> it may be that the intermediary is simply relaying packets and = would >>>> not be visible in a protocol exchange. That would work on current = FCC >>>> rules, but doesn't need anything in the protocol to support. >>>>=20 >>>> Just because the FCC currently disallows such a situation does not = mean >>>> that there won't be other nations that do allow them. >>>>=20 >>>> I do think that the security model has to be fleshed out more, and = we >>>> might have more requirements there. >>>>=20 >>>> Brian >>>>=20 >>>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: >>>>=20 >>>>> I don't see that a proxy or two addresses are ever required to = meet >>>> the described use cases. >>>>> 1) security needs to be end-to-end and a proxy that can modify the >>>> request is not allowed by the FCC >>>>> 2) devices that cannot initially reach the GDB can initially be a >>>> client/slave/Mode I device >>>>> The "master" then asks on their behalf and enables operation of = the >>>> client >>>>> Subsequently the device that was the client could act as a Master >>>>> since it can now reach the GDB through the initial master >>>>>=20 >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf >>>> Of >>>>>> scott.probasco@nokia.com >>>>>> Sent: Thursday, August 04, 2011 12:36 PM >>>>>> To: subir@research.telcordia.com; paws@ietf.org >>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>>>> scenario's >>>>>>=20 >>>>>> Hi Subir, >>>>>>=20 >>>>>> Yes. The use case below requires this functionality. >>>>>>=20 >>>>>> Regards, >>>>>> Scott >>>>>>=20 >>>>>>=20 >>>>>> On 8/4/11 1:51 PM, "ext Subir Das" >>>>>> wrote: >>>>>>=20 >>>>>>> Scott, >>>>>>> Are you suggesting to have proxy/relay support ? >>>>>>>=20 >>>>>>> Thanks, >>>>>>> _Subir >>>>>>>=20 >>>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I support this use case. PAWS should support a query from one >>>> entity >>>>>> on >>>>>>>> behalf of another. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Scott >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" >>>>>> wrote: >>>>>>>>=20 >>>>>>>>> I think this is a good use case and brings up a new = requirement: >>>>>>>>> The protocol must cater for a query from one entity on behalf = of >>>>>>>>> another >>>>>>>>> entity. >>>>>>>>>=20 >>>>>>>>> In many circumstances, this would be invisible to the protocol = - >>>>>> the >>>>>>>>> relay client would simply relay packets or use some private >>>>>> protocol. >>>>>>>>> However, in some circumstances we may need to know the = identity >>>> of >>>>>> the >>>>>>>>> requester as well as the real client, so the actual = requirement >>>> is >>>>>> to >>>>>>>>> be >>>>>>>>> able to carry two identities. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Scott, >>>>>>>>>>=20 >>>>>>>>>> I have written down an practical use case for PAWS in an ad = hoc >>>>>>>>>> network for emergency scenario's. Please comment. >>>>>>>>>>=20 >>>>>>>>>> Thanks, Teco >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>>>>>=20 >>>>>>>>>> Organizations involved in handling emergency operations often >>>> have >>>>>>>>>> a fully owned and controlled infrastructure, with dedicated >>>>>> spectrum, >>>>>>>>>> for day to day operation. However, lessons learned from = recent >>>>>>>>>> disasters show such infrastructures are often highly affected = by >>>>>> the >>>>>>>>>> disaster itself. To set up a replacement quickly, there is a >>>> need >>>>>> for >>>>>>>>>> fast reallocation of spectrum, where in certain cases = spectrum >>>> can >>>>>> be >>>>>>>>>> freed for disaster relief. >>>>>>>>>>=20 >>>>>>>>>> To utilize free or freed spectrum quickly and reliable, >>>> automation >>>>>> of >>>>>>>>>> allocation, assignment and configuration is needed. A = preferred >>>>>>>>>> option is make use of a robust protocol, already adopted by >>>> radio >>>>>>>>>> manufacturers. This approach does in no way imply such >>>>>> organizations >>>>>>>>>> for disaster relief must compete on spectrum allocation with >>>> other >>>>>>>>>> white spaces users, but they can. >>>>>>>>>>=20 >>>>>>>>>> A typical network topology would include wireless access = links >>>> to >>>>>>>>>> the public Internet or private network, wireless ad hoc = network >>>>>>>>>> radios working independent of a fixed infrastructure and >>>> satellite >>>>>>>>>> links for backup where lack of coverage, overload or outage = of >>>>>>>>>> wireless access links occur. >>>>>>>>>>=20 >>>>>>>>>> \|/ >>>>>>>>>> | ad hoc >>>>>>>>>> | >>>>>>>>>> |-|-------------| >>>>>>>>>> | Master node | |------------| >>>>>>>>>> \|/ | with | | Whitespace = | >>>>>>>>>> | ad hoc /| backhaul link | | Database | >>>>>>>>>> | /-----/ |---------------| |------------| >>>>>>>>>> --|-------------/ | \ / >>>>>>>>>> | Master node | | | (--/--) >>>>>>>>>> | without | | ------( ) >>>>>>>>>> | backhaul link | | Wireless / Private \ >>>>>>>>>> ---------------\- | Access ( net or ) >>>>>>>>>> \ | \ Internet ) >>>>>>>>>> \ \|/ | -------( /\ >>>>>>>>>> \ | ad hoc | | (------) \----- >>>> - >>>>>> --- >>>>>>>>>> \ | | / | >>>> Other >>>>>> | >>>>>>>>>> \--|------------- /Satellite | >>>> nodes >>>>>> | >>>>>>>>>> | Master node | / Link ------ >>>> - >>>>>> --- >>>>>>>>>> | with |/ >>>>>>>>>> | backhaul link | >>>>>>>>>> ----------------- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Figure x: Rapid deployed network with partly connected nodes >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> In the ad hoc network, all nodes are master nodes in a way = that >>>>>>>>>> they allocate RF channels from the white space database. >>>> However, >>>>>>>>>> the backhaul link could not be available to all nodes, such = as >>>>>>>>>> depicted for the left node in figure x. To handle RF channel >>>>>>>>>> allocation for such nodes, a master node with a backhaul link >>>>>>>>>> relays or proxies the database query for them. So master = nodes >>>>>>>>>> without a backhaul link follow the procedure as defined for >>>>>>>>>> clients. >>>>>>>>>>=20 >>>>>>>>>> The ad hoc network radios utilise the provided RF channels. >>>>>> Details >>>>>>>>>> on forming and maintenance of the ad hoc network, including >>>> repair >>>>>>>>>> of segmented networks caused by segments operating on = different >>>>>>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 From paul@marvell.com Fri Aug 5 14:03:36 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CDD11E80CA for ; Fri, 5 Aug 2011 14:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFZv5UKnELb1 for ; Fri, 5 Aug 2011 14:03:34 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0F11E80A0 for ; Fri, 5 Aug 2011 14:03:15 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTjxaoVZfZh5YzpWuTgOy8pkYh6Lp2Ljz@postini.com; Fri, 05 Aug 2011 14:03:34 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Fri, 5 Aug 2011 14:03:23 -0700 From: Paul Lambert To: Teco Boot , "Rosen, Brian" Date: Fri, 5 Aug 2011 14:03:19 -0700 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxTc8Sl5JpvDr98ReaiqZ0+cEmCpgAPOSeg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D014073D45BA@SC-VEXCH2.marvell.com> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 21:03:36 -0000 Hi Teco, While disagreeing initially with your proxy-ish requirement for PAWS .. I do see a difference in how we are viewing the set of requirements. There seem to a variety of ways to look at this elephant: PAWS as a unique "protocol" PAWS as a data model for information carried in a particular framework PAWS as a system specification supporting various communication models Etc ... As a system - I agree with you that implementations should be allowed that "relay" PAWS messages/PDUs. This seems to be viable without specific work at the upper layers and should be transparent to end-to-endd security. Proxy is another matter. I usually interpret a proxy as acting on behalf and modifying the original request. A system can always create a proxy like mode without additional specification or considerations. The proxy however would be viewed (at the other end of the communications) as the principal. The current FCC notion of Mode II devices requesting enablement for Mode I is akin to a proxy where the Master is acting on behalf of the client. We could call this a proxy ... but the role(IMHO) needs stronger definition that simply passing on the request of another device. The role of the Master is stronger in the sense that it may directly provide enablement and channel information without direct queries to the GDB. There is more state here than a simple proxy would maintain. All this said ... your basic request at the network topology level is quite valid. Not all entities will have access to a GDB and yet will need ways to determine available spectrum. Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Friday, August 05, 2011 6:30 AM > To: Rosen, Brian > Cc: Paul Lambert; paws@ietf.org > Subject: Re: [paws] PAWS use case: ad hoc network for emergency > scenario's > > Brian, > > Op 5 aug 2011, om 14:38 heeft Rosen, Brian het volgende geschreven: > > > I believe we do have a requirement to ensure privacy and integrity in > the transaction between the device and the database. Privacy because > location is revealed. Integrity because a Man in the Middle attack > which modifies the request or response could cause interference for > primary and/or secondary users. We also have a requirement for > authentication, because, as in the U.S., the database may be a > commercial service with authorized users, and, in order to reveal > location, the user will want to make sure it is talking to the bona > fide database it thinks it is. > OK. > > I think nothing prevents us for having a proxy or relay function. There > is a trust relation between the PAWS master and geo database. There > should be a trust relation between the TVWS master and slave (out of > scope for PAWS). If the master functions as proxy or relay for the > slave, the PAWS trust model is extended, in that the geo database has a > trust relation with the master and implicit with all its slaves. I can > imagine that some master devices are accredited for such, not all. > > Teco > > > > Its very common for protocols like this to have such requirements, > and we probably would be questioned if we did not provide such > capability in the protocol. The protocol document will require a > "Security Considerations" section in which these kinds of issues, among > others, will need to be discussed. The IETF is particularly sensitive > to the privacy considerations associated with location of users. > > > > Brian > > > > On Aug 5, 2011, at 3:56 AM, Teco Boot wrote: > > > >> Paul, > >> > >> Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende geschreven: > >> > >>> Ok - FCC being an example ... here's the requirement: > >>> > >>> 48) The PAWS protocols must provide end-to-end security that > prevents the modification of the messages sent between a White Spaces > Device and the Geolocation Database. > >> Please provide ref. > >> > >> I read FCC requirements as it allows a (protected) proxy function > between Mode II and Fixed / Mode I. Other regulators exist. > >> > >> FCC Federal Register/Vol. 75, No. 233:: > >>>> 62. The Commission will further require that communications > between TV bands devices and databases be transmitted using secure > methods to prevent corruption or unauthorized modification of data. > This requirement includes communications of channel availability and > other spectrum access information between fixed and Mode II devices (it > is not necessary for TVBDs to apply security coding to channel > availability and channel access information that they simply pass > through as such information will already be protected by the sending > device). The Commission will require that when Mode I devices > communicate with fixed or Mode II devices for purposes of obtaining a > list of available channels, they are to use a secure method that > ensures against corruption or unauthorized modification of the data. > >> > >> And: > >>>> (f) Mode II personal/portable device. A personal/portable TVBD > that uses an internal geo-location capability and access to a TV bands > database, either through a direct connection to the Internet or through > an indirect connection to the Internet by way of fixed TVBD or another > Mode II TVBD, to obtain a list of available channels. > >> > >> I see (future) possibilities for this proxy function between fixed > (rapid deployed) nodes. > >> > >> > >>> A proxy is a man-in-the-middle attack. A proxy that can modify a > request and insert it's own address information is a mechanisms and not > a useful requirement. > >> If a TVWS device is malfunctioning, the security model is broken. > >> > >>> A transparent proxy ... that tunnels messages or changes > link/network/transport layer information is possible, but does not seem > very interesting in the scope of this effort. > >> If relay is used, it could be IP packet forwarding. Or PAWS message > relay. No impact on PAWS protocol indeed. But this is to be decided > later on. The use case simply describes the use case, nothing more. > Next steps are gathering requirements and engineering. > >> > >> Teco > >> > >> > >>> > >>> Paul > >>> > >>> > >>> Paul A. Lambert | Marvell | +1 650 787 9141 > >>> > >>> > >>>> -----Original Message----- > >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >>>> Sent: Thursday, August 04, 2011 3:07 PM > >>>> To: Paul Lambert > >>>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; > >>>> paws@ietf.org > >>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency > >>>> scenario's > >>>> > >>>> You are confusing U.S. FCC rules with IETF protocol requirements. > >>>> > >>>> We have several participants, including me, that would foresee "on > >>>> behalf of" requests, where identification of both the original > >>>> requester and the intermediary may be needed. I will reiterate > that > >>>> it may be that the intermediary is simply relaying packets and > would > >>>> not be visible in a protocol exchange. That would work on current > FCC > >>>> rules, but doesn't need anything in the protocol to support. > >>>> > >>>> Just because the FCC currently disallows such a situation does not > mean > >>>> that there won't be other nations that do allow them. > >>>> > >>>> I do think that the security model has to be fleshed out more, and > we > >>>> might have more requirements there. > >>>> > >>>> Brian > >>>> > >>>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: > >>>> > >>>>> I don't see that a proxy or two addresses are ever required to > meet > >>>> the described use cases. > >>>>> 1) security needs to be end-to-end and a proxy that can modify > the > >>>> request is not allowed by the FCC > >>>>> 2) devices that cannot initially reach the GDB can initially be a > >>>> client/slave/Mode I device > >>>>> The "master" then asks on their behalf and enables operation of > the > >>>> client > >>>>> Subsequently the device that was the client could act as a Master > >>>>> since it can now reach the GDB through the initial master > >>>>> > >>>>> > >>>>> Paul > >>>>> > >>>>> > >>>>> > >>>>> Paul A. Lambert | Marvell | +1 650 787 9141 > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>> scott.probasco@nokia.com > >>>>>> Sent: Thursday, August 04, 2011 12:36 PM > >>>>>> To: subir@research.telcordia.com; paws@ietf.org > >>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency > >>>>>> scenario's > >>>>>> > >>>>>> Hi Subir, > >>>>>> > >>>>>> Yes. The use case below requires this functionality. > >>>>>> > >>>>>> Regards, > >>>>>> Scott > >>>>>> > >>>>>> > >>>>>> On 8/4/11 1:51 PM, "ext Subir Das" > > >>>>>> wrote: > >>>>>> > >>>>>>> Scott, > >>>>>>> Are you suggesting to have proxy/relay support ? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> _Subir > >>>>>>> > >>>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I support this use case. PAWS should support a query from one > >>>> entity > >>>>>> on > >>>>>>>> behalf of another. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Scott > >>>>>>>> > >>>>>>>> > >>>>>>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> I think this is a good use case and brings up a new > requirement: > >>>>>>>>> The protocol must cater for a query from one entity on behalf > of > >>>>>>>>> another > >>>>>>>>> entity. > >>>>>>>>> > >>>>>>>>> In many circumstances, this would be invisible to the > protocol - > >>>>>> the > >>>>>>>>> relay client would simply relay packets or use some private > >>>>>> protocol. > >>>>>>>>> However, in some circumstances we may need to know the > identity > >>>> of > >>>>>> the > >>>>>>>>> requester as well as the real client, so the actual > requirement > >>>> is > >>>>>> to > >>>>>>>>> be > >>>>>>>>> able to carry two identities. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > >>>>>>>>> > >>>>>>>>>> Hi Scott, > >>>>>>>>>> > >>>>>>>>>> I have written down an practical use case for PAWS in an ad > hoc > >>>>>>>>>> network for emergency scenario's. Please comment. > >>>>>>>>>> > >>>>>>>>>> Thanks, Teco > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 3.x. Rapid deployed network for emergency scenarios > >>>>>>>>>> > >>>>>>>>>> Organizations involved in handling emergency operations > often > >>>> have > >>>>>>>>>> a fully owned and controlled infrastructure, with dedicated > >>>>>> spectrum, > >>>>>>>>>> for day to day operation. However, lessons learned from > recent > >>>>>>>>>> disasters show such infrastructures are often highly > affected by > >>>>>> the > >>>>>>>>>> disaster itself. To set up a replacement quickly, there is a > >>>> need > >>>>>> for > >>>>>>>>>> fast reallocation of spectrum, where in certain cases > spectrum > >>>> can > >>>>>> be > >>>>>>>>>> freed for disaster relief. > >>>>>>>>>> > >>>>>>>>>> To utilize free or freed spectrum quickly and reliable, > >>>> automation > >>>>>> of > >>>>>>>>>> allocation, assignment and configuration is needed. A > preferred > >>>>>>>>>> option is make use of a robust protocol, already adopted by > >>>> radio > >>>>>>>>>> manufacturers. This approach does in no way imply such > >>>>>> organizations > >>>>>>>>>> for disaster relief must compete on spectrum allocation with > >>>> other > >>>>>>>>>> white spaces users, but they can. > >>>>>>>>>> > >>>>>>>>>> A typical network topology would include wireless access > links > >>>> to > >>>>>>>>>> the public Internet or private network, wireless ad hoc > network > >>>>>>>>>> radios working independent of a fixed infrastructure and > >>>> satellite > >>>>>>>>>> links for backup where lack of coverage, overload or outage > of > >>>>>>>>>> wireless access links occur. > >>>>>>>>>> > >>>>>>>>>> \|/ > >>>>>>>>>> | ad hoc > >>>>>>>>>> | > >>>>>>>>>> |-|-------------| > >>>>>>>>>> | Master node | |------------| > >>>>>>>>>> \|/ | with | | Whitespace > | > >>>>>>>>>> | ad hoc /| backhaul link | | Database > | > >>>>>>>>>> | /-----/ |---------------| |------------ > | > >>>>>>>>>> --|-------------/ | \ / > >>>>>>>>>> | Master node | | | (--/--) > >>>>>>>>>> | without | | ------( ) > >>>>>>>>>> | backhaul link | | Wireless / Private \ > >>>>>>>>>> ---------------\- | Access ( net or ) > >>>>>>>>>> \ | \ Internet ) > >>>>>>>>>> \ \|/ | -------( /\ > >>>>>>>>>> \ | ad hoc | | (------) \---- > - > >>>> - > >>>>>> --- > >>>>>>>>>> \ | | / | > >>>> Other > >>>>>> | > >>>>>>>>>> \--|------------- /Satellite | > >>>> nodes > >>>>>> | > >>>>>>>>>> | Master node | / Link ----- > - > >>>> - > >>>>>> --- > >>>>>>>>>> | with |/ > >>>>>>>>>> | backhaul link | > >>>>>>>>>> ----------------- > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Figure x: Rapid deployed network with partly connected > nodes > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> In the ad hoc network, all nodes are master nodes in a way > that > >>>>>>>>>> they allocate RF channels from the white space database. > >>>> However, > >>>>>>>>>> the backhaul link could not be available to all nodes, such > as > >>>>>>>>>> depicted for the left node in figure x. To handle RF channel > >>>>>>>>>> allocation for such nodes, a master node with a backhaul > link > >>>>>>>>>> relays or proxies the database query for them. So master > nodes > >>>>>>>>>> without a backhaul link follow the procedure as defined for > >>>>>>>>>> clients. > >>>>>>>>>> > >>>>>>>>>> The ad hoc network radios utilise the provided RF channels. > >>>>>> Details > >>>>>>>>>> on forming and maintenance of the ad hoc network, including > >>>> repair > >>>>>>>>>> of segmented networks caused by segments operating on > different > >>>>>>>>>> RF channels, is out of scope of spectrum allocation. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> paws mailing list > >>>>>>>>>> paws@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>>>> _______________________________________________ > >>>>>>>>> paws mailing list > >>>>>>>>> paws@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>>> _______________________________________________ > >>>>>>>> paws mailing list > >>>>>>>> paws@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>> _______________________________________________ > >>>>>>> paws mailing list > >>>>>>> paws@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>> > >>>>>> _______________________________________________ > >>>>>> paws mailing list > >>>>>> paws@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>> _______________________________________________ > >>>>> paws mailing list > >>>>> paws@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/paws > >>> > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> > > From teco@inf-net.nl Sat Aug 6 01:06:14 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA58221F884F for ; Sat, 6 Aug 2011 01:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o887frEnH+jX for ; Sat, 6 Aug 2011 01:06:13 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7C821F884C for ; Sat, 6 Aug 2011 01:06:10 -0700 (PDT) Received: by eyx24 with SMTP id 24so1710621eyx.19 for ; Sat, 06 Aug 2011 01:06:27 -0700 (PDT) Received: by 10.14.0.69 with SMTP id 45mr941453eea.123.1312617986725; Sat, 06 Aug 2011 01:06:26 -0700 (PDT) Received: from [10.175.173.2] (524A158D.cm-4-3a.dynamic.ziggo.nl [82.74.21.141]) by mx.google.com with ESMTPS id y1sm1266432eem.60.2011.08.06.01.06.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Aug 2011 01:06:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D014073D45BA@SC-VEXCH2.marvell.com> Date: Sat, 6 Aug 2011 10:06:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D45BA@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 08:06:15 -0000 Hi Paul, Op 5 aug 2011, om 23:03 heeft Paul Lambert het volgende geschreven: > Hi Teco, > > While disagreeing initially with your proxy-ish requirement for > PAWS .. I do see a difference in how we are viewing > the set of requirements. I think we have to do some work on requirements. At first, let's have use cases. I hope we see a merged document soon, as WG doc, and ask WG for comments. Could be interim telco meeting. Use cases should be complete. Then, we analyze the reqs. But as I mentioned in the meeting, reqs are highly driven by rules from regulators. We have to describe how this works (IETF consensus is not enough). Having a baseline of reqs is fine. > There seem to a variety of ways to look at this elephant: It is not that big... > PAWS as a unique "protocol" > PAWS as a data model for information carried in a particular framework > PAWS as a system specification supporting various communication models > Etc ... I would say: all three, but in reverse order. And it is not "unique". There are many similar protocols, tailored for different purposes. > As a system - I agree with you that implementations should > be allowed that "relay" PAWS messages/PDUs. This seems to > be viable without specific work at the upper layers and > should be transparent to end-to-endd security. OK. Can be done at IP layer. We don't need to come up with another network protocol :-) However, the PAWS packet exchange could have an unacceptable volume for acquiring a communication channel. > Proxy is another matter. I usually interpret a proxy > as acting on behalf and modifying the original request. > A system can always create a proxy like mode without additional > specification or considerations. The proxy however would be > viewed (at the other end of the communications) as the principal. Not sure on this. Assume master is fixed. DB registers locations. Others request RF channel list. Can we accept that proxying master spoofs its own position? What if initiating master is of another type? Term "initiating master" needs another thought. Slave doesn't fit either, because slave can switch to master after it has connectivity to the DB. > The current FCC notion of Mode II devices requesting > enablement for Mode I is akin to a proxy where the Master > is acting on behalf of the client. We could call this a > proxy ... but the role(IMHO) needs stronger definition > that simply passing on the request of another device. OK. > The role of the Master is stronger in the sense that it > may directly provide enablement and channel information > without direct queries to the GDB. There is more state here > than a simple proxy would maintain. OK, it would be a "complex proxy". > All this said ... your basic request at the network topology level > is quite valid. Not all entities will have access to a GDB > and yet will need ways to determine available spectrum. Thanks. Teco > > Paul > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > > >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl] >> Sent: Friday, August 05, 2011 6:30 AM >> To: Rosen, Brian >> Cc: Paul Lambert; paws@ietf.org >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >> scenario's >> >> Brian, >> >> Op 5 aug 2011, om 14:38 heeft Rosen, Brian het volgende geschreven: >> >>> I believe we do have a requirement to ensure privacy and integrity in >> the transaction between the device and the database. Privacy because >> location is revealed. Integrity because a Man in the Middle attack >> which modifies the request or response could cause interference for >> primary and/or secondary users. We also have a requirement for >> authentication, because, as in the U.S., the database may be a >> commercial service with authorized users, and, in order to reveal >> location, the user will want to make sure it is talking to the bona >> fide database it thinks it is. >> OK. >> >> I think nothing prevents us for having a proxy or relay function. There >> is a trust relation between the PAWS master and geo database. There >> should be a trust relation between the TVWS master and slave (out of >> scope for PAWS). If the master functions as proxy or relay for the >> slave, the PAWS trust model is extended, in that the geo database has a >> trust relation with the master and implicit with all its slaves. I can >> imagine that some master devices are accredited for such, not all. >> >> Teco >> >> >>> Its very common for protocols like this to have such requirements, >> and we probably would be questioned if we did not provide such >> capability in the protocol. The protocol document will require a >> "Security Considerations" section in which these kinds of issues, among >> others, will need to be discussed. The IETF is particularly sensitive >> to the privacy considerations associated with location of users. >>> >>> Brian >>> >>> On Aug 5, 2011, at 3:56 AM, Teco Boot wrote: >>> >>>> Paul, >>>> >>>> Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende geschreven: >>>> >>>>> Ok - FCC being an example ... here's the requirement: >>>>> >>>>> 48) The PAWS protocols must provide end-to-end security that >> prevents the modification of the messages sent between a White Spaces >> Device and the Geolocation Database. >>>> Please provide ref. >>>> >>>> I read FCC requirements as it allows a (protected) proxy function >> between Mode II and Fixed / Mode I. Other regulators exist. >>>> >>>> FCC Federal Register/Vol. 75, No. 233:: >>>>>> 62. The Commission will further require that communications >> between TV bands devices and databases be transmitted using secure >> methods to prevent corruption or unauthorized modification of data. >> This requirement includes communications of channel availability and >> other spectrum access information between fixed and Mode II devices (it >> is not necessary for TVBDs to apply security coding to channel >> availability and channel access information that they simply pass >> through as such information will already be protected by the sending >> device). The Commission will require that when Mode I devices >> communicate with fixed or Mode II devices for purposes of obtaining a >> list of available channels, they are to use a secure method that >> ensures against corruption or unauthorized modification of the data. >>>> >>>> And: >>>>>> (f) Mode II personal/portable device. A personal/portable TVBD >> that uses an internal geo-location capability and access to a TV bands >> database, either through a direct connection to the Internet or through >> an indirect connection to the Internet by way of fixed TVBD or another >> Mode II TVBD, to obtain a list of available channels. >>>> >>>> I see (future) possibilities for this proxy function between fixed >> (rapid deployed) nodes. >>>> >>>> >>>>> A proxy is a man-in-the-middle attack. A proxy that can modify a >> request and insert it's own address information is a mechanisms and not >> a useful requirement. >>>> If a TVWS device is malfunctioning, the security model is broken. >>>> >>>>> A transparent proxy ... that tunnels messages or changes >> link/network/transport layer information is possible, but does not seem >> very interesting in the scope of this effort. >>>> If relay is used, it could be IP packet forwarding. Or PAWS message >> relay. No impact on PAWS protocol indeed. But this is to be decided >> later on. The use case simply describes the use case, nothing more. >> Next steps are gathering requirements and engineering. >>>> >>>> Teco >>>> >>>> >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: Thursday, August 04, 2011 3:07 PM >>>>>> To: Paul Lambert >>>>>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; >>>>>> paws@ietf.org >>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>>>> scenario's >>>>>> >>>>>> You are confusing U.S. FCC rules with IETF protocol requirements. >>>>>> >>>>>> We have several participants, including me, that would foresee "on >>>>>> behalf of" requests, where identification of both the original >>>>>> requester and the intermediary may be needed. I will reiterate >> that >>>>>> it may be that the intermediary is simply relaying packets and >> would >>>>>> not be visible in a protocol exchange. That would work on current >> FCC >>>>>> rules, but doesn't need anything in the protocol to support. >>>>>> >>>>>> Just because the FCC currently disallows such a situation does not >> mean >>>>>> that there won't be other nations that do allow them. >>>>>> >>>>>> I do think that the security model has to be fleshed out more, and >> we >>>>>> might have more requirements there. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: >>>>>> >>>>>>> I don't see that a proxy or two addresses are ever required to >> meet >>>>>> the described use cases. >>>>>>> 1) security needs to be end-to-end and a proxy that can modify >> the >>>>>> request is not allowed by the FCC >>>>>>> 2) devices that cannot initially reach the GDB can initially be a >>>>>> client/slave/Mode I device >>>>>>> The "master" then asks on their behalf and enables operation of >> the >>>>>> client >>>>>>> Subsequently the device that was the client could act as a Master >>>>>>> since it can now reach the GDB through the initial master >>>>>>> >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> Behalf >>>>>> Of >>>>>>>> scott.probasco@nokia.com >>>>>>>> Sent: Thursday, August 04, 2011 12:36 PM >>>>>>>> To: subir@research.telcordia.com; paws@ietf.org >>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>>>>>> scenario's >>>>>>>> >>>>>>>> Hi Subir, >>>>>>>> >>>>>>>> Yes. The use case below requires this functionality. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> On 8/4/11 1:51 PM, "ext Subir Das" >> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Scott, >>>>>>>>> Are you suggesting to have proxy/relay support ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> _Subir >>>>>>>>> >>>>>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I support this use case. PAWS should support a query from one >>>>>> entity >>>>>>>> on >>>>>>>>>> behalf of another. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/3/11 7:38 AM, "ext Rosen, Brian" >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I think this is a good use case and brings up a new >> requirement: >>>>>>>>>>> The protocol must cater for a query from one entity on behalf >> of >>>>>>>>>>> another >>>>>>>>>>> entity. >>>>>>>>>>> >>>>>>>>>>> In many circumstances, this would be invisible to the >> protocol - >>>>>>>> the >>>>>>>>>>> relay client would simply relay packets or use some private >>>>>>>> protocol. >>>>>>>>>>> However, in some circumstances we may need to know the >> identity >>>>>> of >>>>>>>> the >>>>>>>>>>> requester as well as the real client, so the actual >> requirement >>>>>> is >>>>>>>> to >>>>>>>>>>> be >>>>>>>>>>> able to carry two identities. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Scott, >>>>>>>>>>>> >>>>>>>>>>>> I have written down an practical use case for PAWS in an ad >> hoc >>>>>>>>>>>> network for emergency scenario's. Please comment. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Teco >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>>>>>>> >>>>>>>>>>>> Organizations involved in handling emergency operations >> often >>>>>> have >>>>>>>>>>>> a fully owned and controlled infrastructure, with dedicated >>>>>>>> spectrum, >>>>>>>>>>>> for day to day operation. However, lessons learned from >> recent >>>>>>>>>>>> disasters show such infrastructures are often highly >> affected by >>>>>>>> the >>>>>>>>>>>> disaster itself. To set up a replacement quickly, there is a >>>>>> need >>>>>>>> for >>>>>>>>>>>> fast reallocation of spectrum, where in certain cases >> spectrum >>>>>> can >>>>>>>> be >>>>>>>>>>>> freed for disaster relief. >>>>>>>>>>>> >>>>>>>>>>>> To utilize free or freed spectrum quickly and reliable, >>>>>> automation >>>>>>>> of >>>>>>>>>>>> allocation, assignment and configuration is needed. A >> preferred >>>>>>>>>>>> option is make use of a robust protocol, already adopted by >>>>>> radio >>>>>>>>>>>> manufacturers. This approach does in no way imply such >>>>>>>> organizations >>>>>>>>>>>> for disaster relief must compete on spectrum allocation with >>>>>> other >>>>>>>>>>>> white spaces users, but they can. >>>>>>>>>>>> >>>>>>>>>>>> A typical network topology would include wireless access >> links >>>>>> to >>>>>>>>>>>> the public Internet or private network, wireless ad hoc >> network >>>>>>>>>>>> radios working independent of a fixed infrastructure and >>>>>> satellite >>>>>>>>>>>> links for backup where lack of coverage, overload or outage >> of >>>>>>>>>>>> wireless access links occur. >>>>>>>>>>>> >>>>>>>>>>>> \|/ >>>>>>>>>>>> | ad hoc >>>>>>>>>>>> | >>>>>>>>>>>> |-|-------------| >>>>>>>>>>>> | Master node | |------------| >>>>>>>>>>>> \|/ | with | | Whitespace >> | >>>>>>>>>>>> | ad hoc /| backhaul link | | Database >> | >>>>>>>>>>>> | /-----/ |---------------| |------------ >> | >>>>>>>>>>>> --|-------------/ | \ / >>>>>>>>>>>> | Master node | | | (--/--) >>>>>>>>>>>> | without | | ------( ) >>>>>>>>>>>> | backhaul link | | Wireless / Private \ >>>>>>>>>>>> ---------------\- | Access ( net or ) >>>>>>>>>>>> \ | \ Internet ) >>>>>>>>>>>> \ \|/ | -------( /\ >>>>>>>>>>>> \ | ad hoc | | (------) \---- >> - >>>>>> - >>>>>>>> --- >>>>>>>>>>>> \ | | / | >>>>>> Other >>>>>>>> | >>>>>>>>>>>> \--|------------- /Satellite | >>>>>> nodes >>>>>>>> | >>>>>>>>>>>> | Master node | / Link ----- >> - >>>>>> - >>>>>>>> --- >>>>>>>>>>>> | with |/ >>>>>>>>>>>> | backhaul link | >>>>>>>>>>>> ----------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Figure x: Rapid deployed network with partly connected >> nodes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In the ad hoc network, all nodes are master nodes in a way >> that >>>>>>>>>>>> they allocate RF channels from the white space database. >>>>>> However, >>>>>>>>>>>> the backhaul link could not be available to all nodes, such >> as >>>>>>>>>>>> depicted for the left node in figure x. To handle RF channel >>>>>>>>>>>> allocation for such nodes, a master node with a backhaul >> link >>>>>>>>>>>> relays or proxies the database query for them. So master >> nodes >>>>>>>>>>>> without a backhaul link follow the procedure as defined for >>>>>>>>>>>> clients. >>>>>>>>>>>> >>>>>>>>>>>> The ad hoc network radios utilise the provided RF channels. >>>>>>>> Details >>>>>>>>>>>> on forming and maintenance of the ad hoc network, including >>>>>> repair >>>>>>>>>>>> of segmented networks caused by segments operating on >> different >>>>>>>>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> paws mailing list >>>>>>>>>>>> paws@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> paws mailing list >>>>>>>>>>> paws@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> > From paul@marvell.com Mon Aug 8 12:31:24 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE73511E8081 for ; Mon, 8 Aug 2011 12:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pYNmmJ5R42F for ; Mon, 8 Aug 2011 12:31:23 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id C8BEF11E8078 for ; Mon, 8 Aug 2011 12:31:22 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTkA5omCNHi33l4z6M4LQFCJpZOvhwY32@postini.com; Mon, 08 Aug 2011 12:31:49 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 8 Aug 2011 12:31:44 -0700 From: Paul Lambert To: Teco Boot Date: Mon, 8 Aug 2011 12:31:40 -0700 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxUD79mMiyoCqNPRKGrg1cM7NWzKQB7pnig Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01409CCBB59@SC-VEXCH2.marvell.com> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D45BA@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:31:24 -0000 Hi Teco, > > Proxy is another matter. I usually interpret a proxy > > as acting on behalf and modifying the original request. > > A system can always create a proxy like mode without additional > > specification or considerations. The proxy however would be > > viewed (at the other end of the communications) as the principal. > Not sure on this. Assume master is fixed. DB registers locations. > Others request RF channel list. Can we accept that proxying > master spoofs its own position? Proxy is not a word I think we should use here. A device that creates a network speaks on behalf of it's clients that may not have location capabilities. There is a delegation of trust and responsibility to this Master device that is more than just a proxy service. This is a very explicit differentiation into a two tier trust model. Different regulatory domains may differ from the FCC and have other flatter models - however, cutting back from two layers to one is easier than adding a layer of trust/functionality later. A Master enables the use of spectrum by other (non-Master devices) within i= t's geographic range. The master may not need to contact the GDB for each enablement. The FCC currently requires per enablement checking of the device type/id. Checking the available channels has a longer potential latency. This gets into a interesting design area - parameterization of potential regulatory rules ... > What if initiating master is of > another type? > Term "initiating master" needs another thought. Slave doesn't fit > either, because slave can switch to master after it has connectivity > to the DB. Slave or client would fit ... these are different functional elements that would coexist. A device starts as client/slave/Mode-I ... it may continue communicating to GDB as client/slave/Mode-I while at the same time starting to act as a master. Much of the bootstrapping, mesh, IBSS, etc. can be handled by decomposition of the functional elements and allowing multiple at the same time. Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Saturday, August 06, 2011 1:06 AM > To: Paul Lambert > Cc: Rosen, Brian; paws@ietf.org > Subject: Re: [paws] PAWS use case: ad hoc network for emergency > scenario's > > Hi Paul, > > Op 5 aug 2011, om 23:03 heeft Paul Lambert het volgende geschreven: > > > Hi Teco, > > > > While disagreeing initially with your proxy-ish requirement for > > PAWS .. I do see a difference in how we are viewing > > the set of requirements. > I think we have to do some work on requirements. At first, let's > have use cases. > > I hope we see a merged document soon, as WG doc, and ask WG for > comments. Could be interim telco meeting. Use cases should be complete. > Then, we analyze the reqs. > > But as I mentioned in the meeting, reqs are highly driven by rules > from regulators. We have to describe how this works (IETF consensus > is not enough). Having a baseline of reqs is fine. > > > There seem to a variety of ways to look at this elephant: > It is not that big... > > > PAWS as a unique "protocol" > > PAWS as a data model for information carried in a particular > framework > > PAWS as a system specification supporting various communication > models > > Etc ... > I would say: all three, but in reverse order. > And it is not "unique". There are many similar protocols, tailored > for different purposes. > > > As a system - I agree with you that implementations should > > be allowed that "relay" PAWS messages/PDUs. This seems to > > be viable without specific work at the upper layers and > > should be transparent to end-to-endd security. > OK. > Can be done at IP layer. We don't need to come up with another > network protocol :-) > However, the PAWS packet exchange could have an unacceptable volume > for acquiring a communication channel. > > > Proxy is another matter. I usually interpret a proxy > > as acting on behalf and modifying the original request. > > A system can always create a proxy like mode without additional > > specification or considerations. The proxy however would be > > viewed (at the other end of the communications) as the principal. > Not sure on this. Assume master is fixed. DB registers locations. > Others request RF channel list. Can we accept that proxying > master spoofs its own position? What if initiating master is of > another type? > Term "initiating master" needs another thought. Slave doesn't fit > either, because slave can switch to master after it has connectivity > to the DB. > > > The current FCC notion of Mode II devices requesting > > enablement for Mode I is akin to a proxy where the Master > > is acting on behalf of the client. We could call this a > > proxy ... but the role(IMHO) needs stronger definition > > that simply passing on the request of another device. > OK. > > > The role of the Master is stronger in the sense that it > > may directly provide enablement and channel information > > without direct queries to the GDB. There is more state here > > than a simple proxy would maintain. > OK, it would be a "complex proxy". > > > All this said ... your basic request at the network topology level > > is quite valid. Not all entities will have access to a GDB > > and yet will need ways to determine available spectrum. > Thanks. > > Teco > > > > > Paul > > > > > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > > > > > >> -----Original Message----- > >> From: Teco Boot [mailto:teco@inf-net.nl] > >> Sent: Friday, August 05, 2011 6:30 AM > >> To: Rosen, Brian > >> Cc: Paul Lambert; paws@ietf.org > >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency > >> scenario's > >> > >> Brian, > >> > >> Op 5 aug 2011, om 14:38 heeft Rosen, Brian het volgende geschreven: > >> > >>> I believe we do have a requirement to ensure privacy and integrity > in > >> the transaction between the device and the database. Privacy > because > >> location is revealed. Integrity because a Man in the Middle attack > >> which modifies the request or response could cause interference for > >> primary and/or secondary users. We also have a requirement for > >> authentication, because, as in the U.S., the database may be a > >> commercial service with authorized users, and, in order to reveal > >> location, the user will want to make sure it is talking to the bona > >> fide database it thinks it is. > >> OK. > >> > >> I think nothing prevents us for having a proxy or relay function. > There > >> is a trust relation between the PAWS master and geo database. There > >> should be a trust relation between the TVWS master and slave (out of > >> scope for PAWS). If the master functions as proxy or relay for the > >> slave, the PAWS trust model is extended, in that the geo database > has a > >> trust relation with the master and implicit with all its slaves. I > can > >> imagine that some master devices are accredited for such, not all. > >> > >> Teco > >> > >> > >>> Its very common for protocols like this to have such requirements, > >> and we probably would be questioned if we did not provide such > >> capability in the protocol. The protocol document will require a > >> "Security Considerations" section in which these kinds of issues, > among > >> others, will need to be discussed. The IETF is particularly > sensitive > >> to the privacy considerations associated with location of users. > >>> > >>> Brian > >>> > >>> On Aug 5, 2011, at 3:56 AM, Teco Boot wrote: > >>> > >>>> Paul, > >>>> > >>>> Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende > geschreven: > >>>> > >>>>> Ok - FCC being an example ... here's the requirement: > >>>>> > >>>>> 48) The PAWS protocols must provide end-to-end security that > >> prevents the modification of the messages sent between a White > Spaces > >> Device and the Geolocation Database. > >>>> Please provide ref. > >>>> > >>>> I read FCC requirements as it allows a (protected) proxy function > >> between Mode II and Fixed / Mode I. Other regulators exist. > >>>> > >>>> FCC Federal Register/Vol. 75, No. 233:: > >>>>>> 62. The Commission will further require that communications > >> between TV bands devices and databases be transmitted using secure > >> methods to prevent corruption or unauthorized modification of data. > >> This requirement includes communications of channel availability and > >> other spectrum access information between fixed and Mode II devices > (it > >> is not necessary for TVBDs to apply security coding to channel > >> availability and channel access information that they simply pass > >> through as such information will already be protected by the sending > >> device). The Commission will require that when Mode I devices > >> communicate with fixed or Mode II devices for purposes of obtaining > a > >> list of available channels, they are to use a secure method that > >> ensures against corruption or unauthorized modification of the data. > >>>> > >>>> And: > >>>>>> (f) Mode II personal/portable device. A personal/portable TVBD > >> that uses an internal geo-location capability and access to a TV > bands > >> database, either through a direct connection to the Internet or > through > >> an indirect connection to the Internet by way of fixed TVBD or > another > >> Mode II TVBD, to obtain a list of available channels. > >>>> > >>>> I see (future) possibilities for this proxy function between fixed > >> (rapid deployed) nodes. > >>>> > >>>> > >>>>> A proxy is a man-in-the-middle attack. A proxy that can modify a > >> request and insert it's own address information is a mechanisms and > not > >> a useful requirement. > >>>> If a TVWS device is malfunctioning, the security model is broken. > >>>> > >>>>> A transparent proxy ... that tunnels messages or changes > >> link/network/transport layer information is possible, but does not > seem > >> very interesting in the scope of this effort. > >>>> If relay is used, it could be IP packet forwarding. Or PAWS > message > >> relay. No impact on PAWS protocol indeed. But this is to be decided > >> later on. The use case simply describes the use case, nothing more. > >> Next steps are gathering requirements and engineering. > >>>> > >>>> Teco > >>>> > >>>> > >>>>> > >>>>> Paul > >>>>> > >>>>> > >>>>> Paul A. Lambert | Marvell | +1 650 787 9141 > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >>>>>> Sent: Thursday, August 04, 2011 3:07 PM > >>>>>> To: Paul Lambert > >>>>>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; > >>>>>> paws@ietf.org > >>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency > >>>>>> scenario's > >>>>>> > >>>>>> You are confusing U.S. FCC rules with IETF protocol > requirements. > >>>>>> > >>>>>> We have several participants, including me, that would foresee > "on > >>>>>> behalf of" requests, where identification of both the original > >>>>>> requester and the intermediary may be needed. I will reiterate > >> that > >>>>>> it may be that the intermediary is simply relaying packets and > >> would > >>>>>> not be visible in a protocol exchange. That would work on > current > >> FCC > >>>>>> rules, but doesn't need anything in the protocol to support. > >>>>>> > >>>>>> Just because the FCC currently disallows such a situation does > not > >> mean > >>>>>> that there won't be other nations that do allow them. > >>>>>> > >>>>>> I do think that the security model has to be fleshed out more, > and > >> we > >>>>>> might have more requirements there. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: > >>>>>> > >>>>>>> I don't see that a proxy or two addresses are ever required to > >> meet > >>>>>> the described use cases. > >>>>>>> 1) security needs to be end-to-end and a proxy that can modify > >> the > >>>>>> request is not allowed by the FCC > >>>>>>> 2) devices that cannot initially reach the GDB can initially be > a > >>>>>> client/slave/Mode I device > >>>>>>> The "master" then asks on their behalf and enables operation of > >> the > >>>>>> client > >>>>>>> Subsequently the device that was the client could act as a > Master > >>>>>>> since it can now reach the GDB through the initial master > >>>>>>> > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Paul A. Lambert | Marvell | +1 650 787 9141 > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >> Behalf > >>>>>> Of > >>>>>>>> scott.probasco@nokia.com > >>>>>>>> Sent: Thursday, August 04, 2011 12:36 PM > >>>>>>>> To: subir@research.telcordia.com; paws@ietf.org > >>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for > emergency > >>>>>>>> scenario's > >>>>>>>> > >>>>>>>> Hi Subir, > >>>>>>>> > >>>>>>>> Yes. The use case below requires this functionality. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Scott > >>>>>>>> > >>>>>>>> > >>>>>>>> On 8/4/11 1:51 PM, "ext Subir Das" > >> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Scott, > >>>>>>>>> Are you suggesting to have proxy/relay support ? > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> _Subir > >>>>>>>>> > >>>>>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I support this use case. PAWS should support a query from > one > >>>>>> entity > >>>>>>>> on > >>>>>>>>>> behalf of another. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Scott > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 8/3/11 7:38 AM, "ext Rosen, > Brian" > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> I think this is a good use case and brings up a new > >> requirement: > >>>>>>>>>>> The protocol must cater for a query from one entity on > behalf > >> of > >>>>>>>>>>> another > >>>>>>>>>>> entity. > >>>>>>>>>>> > >>>>>>>>>>> In many circumstances, this would be invisible to the > >> protocol - > >>>>>>>> the > >>>>>>>>>>> relay client would simply relay packets or use some private > >>>>>>>> protocol. > >>>>>>>>>>> However, in some circumstances we may need to know the > >> identity > >>>>>> of > >>>>>>>> the > >>>>>>>>>>> requester as well as the real client, so the actual > >> requirement > >>>>>> is > >>>>>>>> to > >>>>>>>>>>> be > >>>>>>>>>>> able to carry two identities. > >>>>>>>>>>> > >>>>>>>>>>> Brian > >>>>>>>>>>> > >>>>>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi Scott, > >>>>>>>>>>>> > >>>>>>>>>>>> I have written down an practical use case for PAWS in an > ad > >> hoc > >>>>>>>>>>>> network for emergency scenario's. Please comment. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, Teco > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 3.x. Rapid deployed network for emergency scenarios > >>>>>>>>>>>> > >>>>>>>>>>>> Organizations involved in handling emergency operations > >> often > >>>>>> have > >>>>>>>>>>>> a fully owned and controlled infrastructure, with > dedicated > >>>>>>>> spectrum, > >>>>>>>>>>>> for day to day operation. However, lessons learned from > >> recent > >>>>>>>>>>>> disasters show such infrastructures are often highly > >> affected by > >>>>>>>> the > >>>>>>>>>>>> disaster itself. To set up a replacement quickly, there is > a > >>>>>> need > >>>>>>>> for > >>>>>>>>>>>> fast reallocation of spectrum, where in certain cases > >> spectrum > >>>>>> can > >>>>>>>> be > >>>>>>>>>>>> freed for disaster relief. > >>>>>>>>>>>> > >>>>>>>>>>>> To utilize free or freed spectrum quickly and reliable, > >>>>>> automation > >>>>>>>> of > >>>>>>>>>>>> allocation, assignment and configuration is needed. A > >> preferred > >>>>>>>>>>>> option is make use of a robust protocol, already adopted > by > >>>>>> radio > >>>>>>>>>>>> manufacturers. This approach does in no way imply such > >>>>>>>> organizations > >>>>>>>>>>>> for disaster relief must compete on spectrum allocation > with > >>>>>> other > >>>>>>>>>>>> white spaces users, but they can. > >>>>>>>>>>>> > >>>>>>>>>>>> A typical network topology would include wireless access > >> links > >>>>>> to > >>>>>>>>>>>> the public Internet or private network, wireless ad hoc > >> network > >>>>>>>>>>>> radios working independent of a fixed infrastructure and > >>>>>> satellite > >>>>>>>>>>>> links for backup where lack of coverage, overload or > outage > >> of > >>>>>>>>>>>> wireless access links occur. > >>>>>>>>>>>> > >>>>>>>>>>>> \|/ > >>>>>>>>>>>> | ad hoc > >>>>>>>>>>>> | > >>>>>>>>>>>> |-|-------------| > >>>>>>>>>>>> | Master node | |------------ > | > >>>>>>>>>>>> \|/ | with | | > Whitespace > >> | > >>>>>>>>>>>> | ad hoc /| backhaul link | | Database > >> | > >>>>>>>>>>>> | /-----/ |---------------| |---------- > -- > >> | > >>>>>>>>>>>> --|-------------/ | \ / > >>>>>>>>>>>> | Master node | | | (--/--) > >>>>>>>>>>>> | without | | ------( ) > >>>>>>>>>>>> | backhaul link | | Wireless / Private \ > >>>>>>>>>>>> ---------------\- | Access ( net or ) > >>>>>>>>>>>> \ | \ Internet ) > >>>>>>>>>>>> \ \|/ | -------( /\ > >>>>>>>>>>>> \ | ad hoc | | (------) \--- > - > >> - > >>>>>> - > >>>>>>>> --- > >>>>>>>>>>>> \ | | / | > >>>>>> Other > >>>>>>>> | > >>>>>>>>>>>> \--|------------- /Satellite | > >>>>>> nodes > >>>>>>>> | > >>>>>>>>>>>> | Master node | / Link ---- > - > >> - > >>>>>> - > >>>>>>>> --- > >>>>>>>>>>>> | with |/ > >>>>>>>>>>>> | backhaul link | > >>>>>>>>>>>> ----------------- > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Figure x: Rapid deployed network with partly connected > >> nodes > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> In the ad hoc network, all nodes are master nodes in a way > >> that > >>>>>>>>>>>> they allocate RF channels from the white space database. > >>>>>> However, > >>>>>>>>>>>> the backhaul link could not be available to all nodes, > such > >> as > >>>>>>>>>>>> depicted for the left node in figure x. To handle RF > channel > >>>>>>>>>>>> allocation for such nodes, a master node with a backhaul > >> link > >>>>>>>>>>>> relays or proxies the database query for them. So master > >> nodes > >>>>>>>>>>>> without a backhaul link follow the procedure as defined > for > >>>>>>>>>>>> clients. > >>>>>>>>>>>> > >>>>>>>>>>>> The ad hoc network radios utilise the provided RF > channels. > >>>>>>>> Details > >>>>>>>>>>>> on forming and maintenance of the ad hoc network, > including > >>>>>> repair > >>>>>>>>>>>> of segmented networks caused by segments operating on > >> different > >>>>>>>>>>>> RF channels, is out of scope of spectrum allocation. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> paws mailing list > >>>>>>>>>>>> paws@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> paws mailing list > >>>>>>>>>>> paws@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> paws mailing list > >>>>>>>>>> paws@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>>>> _______________________________________________ > >>>>>>>>> paws mailing list > >>>>>>>>> paws@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> paws mailing list > >>>>>>>> paws@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>>> _______________________________________________ > >>>>>>> paws mailing list > >>>>>>> paws@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>> > >>>>> _______________________________________________ > >>>>> paws mailing list > >>>>> paws@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/paws > >>>> > >>> > > From brian.rosen@neustar.biz Mon Aug 8 12:47:41 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E316E21F8BBA for ; Mon, 8 Aug 2011 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgeH2v4PP9gh for ; Mon, 8 Aug 2011 12:47:40 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F021F8BB6 for ; Mon, 8 Aug 2011 12:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312832878; x=1628183484; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=qIAMa3iLdieEFxXEZWTpa fn2bfiNGNA7OBUhDFSEIq4=; b=IwOLFiNsZ1vqbRjxuld/GQSZzVnhGVcaKdP1E pKYY0C33IBflUvBaR0dK6qI3Gch8tYFYB4VpnPlam2QAc8kVQ== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.40061237; Mon, 08 Aug 2011 15:47:48 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 8 Aug 2011 15:47:48 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Mon, 8 Aug 2011 15:47:47 -0400 Thread-Topic: [paws] PAWS use case: ad hoc network for emergency scenario's Thread-Index: AcxWBAxnr23EayTBS/S6bLLBD+YhQw== Message-ID: <58D2DF3F-4DAB-4B57-AF14-26C9D8D53D62@neustar.biz> References: <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D45BA@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01409CCBB59@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01409CCBB59@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:47:42 -0000 The point of the use case is an ad hoc network with no master. That's why = "proxy" is a better term. Brian On Aug 8, 2011, at 3:31 PM, Paul Lambert wrote: > Hi Teco, > >>> Proxy is another matter. I usually interpret a proxy >>> as acting on behalf and modifying the original request. >>> A system can always create a proxy like mode without additional >>> specification or considerations. The proxy however would be >>> viewed (at the other end of the communications) as the principal. >> Not sure on this. Assume master is fixed. DB registers locations. >> Others request RF channel list. Can we accept that proxying >> master spoofs its own position? > > Proxy is not a word I think we should use here. A device that creates > a network speaks on behalf of it's clients that may not have location > capabilities. There is a delegation of trust and responsibility to > this Master device that is more than just a proxy service. > > This is a very explicit differentiation into a two tier trust model. > Different regulatory domains may differ from the FCC and have other > flatter models - however, cutting back from two layers to one is > easier than adding a layer of trust/functionality later. > > A Master enables the use of spectrum by other (non-Master devices) within= it's > geographic range. The master may not need to contact the GDB for each > enablement. The FCC currently requires per enablement checking of the > device type/id. Checking the available channels has a longer potential > latency. > > This gets into a interesting design area - parameterization of potential > regulatory rules ... > >> What if initiating master is of >> another type? >> Term "initiating master" needs another thought. Slave doesn't fit >> either, because slave can switch to master after it has connectivity >> to the DB. > > Slave or client would fit ... these are different functional elements > that would coexist. A device starts as client/slave/Mode-I ... it may > continue communicating to GDB as client/slave/Mode-I while at the same ti= me > starting to act as a master. > > Much of the bootstrapping, mesh, IBSS, etc. can be handled by decompositi= on > of the functional elements and allowing multiple at the same time. > > Paul > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl] >> Sent: Saturday, August 06, 2011 1:06 AM >> To: Paul Lambert >> Cc: Rosen, Brian; paws@ietf.org >> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >> scenario's >> >> Hi Paul, >> >> Op 5 aug 2011, om 23:03 heeft Paul Lambert het volgende geschreven: >> >>> Hi Teco, >>> >>> While disagreeing initially with your proxy-ish requirement for >>> PAWS .. I do see a difference in how we are viewing >>> the set of requirements. >> I think we have to do some work on requirements. At first, let's >> have use cases. >> >> I hope we see a merged document soon, as WG doc, and ask WG for >> comments. Could be interim telco meeting. Use cases should be complete. >> Then, we analyze the reqs. >> >> But as I mentioned in the meeting, reqs are highly driven by rules >> from regulators. We have to describe how this works (IETF consensus >> is not enough). Having a baseline of reqs is fine. >> >>> There seem to a variety of ways to look at this elephant: >> It is not that big... >> >>> PAWS as a unique "protocol" >>> PAWS as a data model for information carried in a particular >> framework >>> PAWS as a system specification supporting various communication >> models >>> Etc ... >> I would say: all three, but in reverse order. >> And it is not "unique". There are many similar protocols, tailored >> for different purposes. >> >>> As a system - I agree with you that implementations should >>> be allowed that "relay" PAWS messages/PDUs. This seems to >>> be viable without specific work at the upper layers and >>> should be transparent to end-to-endd security. >> OK. >> Can be done at IP layer. We don't need to come up with another >> network protocol :-) >> However, the PAWS packet exchange could have an unacceptable volume >> for acquiring a communication channel. >> >>> Proxy is another matter. I usually interpret a proxy >>> as acting on behalf and modifying the original request. >>> A system can always create a proxy like mode without additional >>> specification or considerations. The proxy however would be >>> viewed (at the other end of the communications) as the principal. >> Not sure on this. Assume master is fixed. DB registers locations. >> Others request RF channel list. Can we accept that proxying >> master spoofs its own position? What if initiating master is of >> another type? >> Term "initiating master" needs another thought. Slave doesn't fit >> either, because slave can switch to master after it has connectivity >> to the DB. >> >>> The current FCC notion of Mode II devices requesting >>> enablement for Mode I is akin to a proxy where the Master >>> is acting on behalf of the client. We could call this a >>> proxy ... but the role(IMHO) needs stronger definition >>> that simply passing on the request of another device. >> OK. >> >>> The role of the Master is stronger in the sense that it >>> may directly provide enablement and channel information >>> without direct queries to the GDB. There is more state here >>> than a simple proxy would maintain. >> OK, it would be a "complex proxy". >> >>> All this said ... your basic request at the network topology level >>> is quite valid. Not all entities will have access to a GDB >>> and yet will need ways to determine available spectrum. >> Thanks. >> >> Teco >> >>> >>> Paul >>> >>> >>> >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>> >>> >>>> -----Original Message----- >>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>> Sent: Friday, August 05, 2011 6:30 AM >>>> To: Rosen, Brian >>>> Cc: Paul Lambert; paws@ietf.org >>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>> scenario's >>>> >>>> Brian, >>>> >>>> Op 5 aug 2011, om 14:38 heeft Rosen, Brian het volgende geschreven: >>>> >>>>> I believe we do have a requirement to ensure privacy and integrity >> in >>>> the transaction between the device and the database. Privacy >> because >>>> location is revealed. Integrity because a Man in the Middle attack >>>> which modifies the request or response could cause interference for >>>> primary and/or secondary users. We also have a requirement for >>>> authentication, because, as in the U.S., the database may be a >>>> commercial service with authorized users, and, in order to reveal >>>> location, the user will want to make sure it is talking to the bona >>>> fide database it thinks it is. >>>> OK. >>>> >>>> I think nothing prevents us for having a proxy or relay function. >> There >>>> is a trust relation between the PAWS master and geo database. There >>>> should be a trust relation between the TVWS master and slave (out of >>>> scope for PAWS). If the master functions as proxy or relay for the >>>> slave, the PAWS trust model is extended, in that the geo database >> has a >>>> trust relation with the master and implicit with all its slaves. I >> can >>>> imagine that some master devices are accredited for such, not all. >>>> >>>> Teco >>>> >>>> >>>>> Its very common for protocols like this to have such requirements, >>>> and we probably would be questioned if we did not provide such >>>> capability in the protocol. The protocol document will require a >>>> "Security Considerations" section in which these kinds of issues, >> among >>>> others, will need to be discussed. The IETF is particularly >> sensitive >>>> to the privacy considerations associated with location of users. >>>>> >>>>> Brian >>>>> >>>>> On Aug 5, 2011, at 3:56 AM, Teco Boot wrote: >>>>> >>>>>> Paul, >>>>>> >>>>>> Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende >> geschreven: >>>>>> >>>>>>> Ok - FCC being an example ... here's the requirement: >>>>>>> >>>>>>> 48) The PAWS protocols must provide end-to-end security that >>>> prevents the modification of the messages sent between a White >> Spaces >>>> Device and the Geolocation Database. >>>>>> Please provide ref. >>>>>> >>>>>> I read FCC requirements as it allows a (protected) proxy function >>>> between Mode II and Fixed / Mode I. Other regulators exist. >>>>>> >>>>>> FCC Federal Register/Vol. 75, No. 233:: >>>>>>>> 62. The Commission will further require that communications >>>> between TV bands devices and databases be transmitted using secure >>>> methods to prevent corruption or unauthorized modification of data. >>>> This requirement includes communications of channel availability and >>>> other spectrum access information between fixed and Mode II devices >> (it >>>> is not necessary for TVBDs to apply security coding to channel >>>> availability and channel access information that they simply pass >>>> through as such information will already be protected by the sending >>>> device). The Commission will require that when Mode I devices >>>> communicate with fixed or Mode II devices for purposes of obtaining >> a >>>> list of available channels, they are to use a secure method that >>>> ensures against corruption or unauthorized modification of the data. >>>>>> >>>>>> And: >>>>>>>> (f) Mode II personal/portable device. A personal/portable TVBD >>>> that uses an internal geo-location capability and access to a TV >> bands >>>> database, either through a direct connection to the Internet or >> through >>>> an indirect connection to the Internet by way of fixed TVBD or >> another >>>> Mode II TVBD, to obtain a list of available channels. >>>>>> >>>>>> I see (future) possibilities for this proxy function between fixed >>>> (rapid deployed) nodes. >>>>>> >>>>>> >>>>>>> A proxy is a man-in-the-middle attack. A proxy that can modify a >>>> request and insert it's own address information is a mechanisms and >> not >>>> a useful requirement. >>>>>> If a TVWS device is malfunctioning, the security model is broken. >>>>>> >>>>>>> A transparent proxy ... that tunnels messages or changes >>>> link/network/transport layer information is possible, but does not >> seem >>>> very interesting in the scope of this effort. >>>>>> If relay is used, it could be IP packet forwarding. Or PAWS >> message >>>> relay. No impact on PAWS protocol indeed. But this is to be decided >>>> later on. The use case simply describes the use case, nothing more. >>>> Next steps are gathering requirements and engineering. >>>>>> >>>>>> Teco >>>>>> >>>>>> >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>> Sent: Thursday, August 04, 2011 3:07 PM >>>>>>>> To: Paul Lambert >>>>>>>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com; >>>>>>>> paws@ietf.org >>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency >>>>>>>> scenario's >>>>>>>> >>>>>>>> You are confusing U.S. FCC rules with IETF protocol >> requirements. >>>>>>>> >>>>>>>> We have several participants, including me, that would foresee >> "on >>>>>>>> behalf of" requests, where identification of both the original >>>>>>>> requester and the intermediary may be needed. I will reiterate >>>> that >>>>>>>> it may be that the intermediary is simply relaying packets and >>>> would >>>>>>>> not be visible in a protocol exchange. That would work on >> current >>>> FCC >>>>>>>> rules, but doesn't need anything in the protocol to support. >>>>>>>> >>>>>>>> Just because the FCC currently disallows such a situation does >> not >>>> mean >>>>>>>> that there won't be other nations that do allow them. >>>>>>>> >>>>>>>> I do think that the security model has to be fleshed out more, >> and >>>> we >>>>>>>> might have more requirements there. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote: >>>>>>>> >>>>>>>>> I don't see that a proxy or two addresses are ever required to >>>> meet >>>>>>>> the described use cases. >>>>>>>>> 1) security needs to be end-to-end and a proxy that can modify >>>> the >>>>>>>> request is not allowed by the FCC >>>>>>>>> 2) devices that cannot initially reach the GDB can initially be >> a >>>>>>>> client/slave/Mode I device >>>>>>>>> The "master" then asks on their behalf and enables operation of >>>> the >>>>>>>> client >>>>>>>>> Subsequently the device that was the client could act as a >> Master >>>>>>>>> since it can now reach the GDB through the initial master >>>>>>>>> >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>> Behalf >>>>>>>> Of >>>>>>>>>> scott.probasco@nokia.com >>>>>>>>>> Sent: Thursday, August 04, 2011 12:36 PM >>>>>>>>>> To: subir@research.telcordia.com; paws@ietf.org >>>>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for >> emergency >>>>>>>>>> scenario's >>>>>>>>>> >>>>>>>>>> Hi Subir, >>>>>>>>>> >>>>>>>>>> Yes. The use case below requires this functionality. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/4/11 1:51 PM, "ext Subir Das" >>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Scott, >>>>>>>>>>> Are you suggesting to have proxy/relay support ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> _Subir >>>>>>>>>>> >>>>>>>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I support this use case. PAWS should support a query from >> one >>>>>>>> entity >>>>>>>>>> on >>>>>>>>>>>> behalf of another. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 8/3/11 7:38 AM, "ext Rosen, >> Brian" >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I think this is a good use case and brings up a new >>>> requirement: >>>>>>>>>>>>> The protocol must cater for a query from one entity on >> behalf >>>> of >>>>>>>>>>>>> another >>>>>>>>>>>>> entity. >>>>>>>>>>>>> >>>>>>>>>>>>> In many circumstances, this would be invisible to the >>>> protocol - >>>>>>>>>> the >>>>>>>>>>>>> relay client would simply relay packets or use some private >>>>>>>>>> protocol. >>>>>>>>>>>>> However, in some circumstances we may need to know the >>>> identity >>>>>>>> of >>>>>>>>>> the >>>>>>>>>>>>> requester as well as the real client, so the actual >>>> requirement >>>>>>>> is >>>>>>>>>> to >>>>>>>>>>>>> be >>>>>>>>>>>>> able to carry two identities. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Scott, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have written down an practical use case for PAWS in an >> ad >>>> hoc >>>>>>>>>>>>>> network for emergency scenario's. Please comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, Teco >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.x. Rapid deployed network for emergency scenarios >>>>>>>>>>>>>> >>>>>>>>>>>>>> Organizations involved in handling emergency operations >>>> often >>>>>>>> have >>>>>>>>>>>>>> a fully owned and controlled infrastructure, with >> dedicated >>>>>>>>>> spectrum, >>>>>>>>>>>>>> for day to day operation. However, lessons learned from >>>> recent >>>>>>>>>>>>>> disasters show such infrastructures are often highly >>>> affected by >>>>>>>>>> the >>>>>>>>>>>>>> disaster itself. To set up a replacement quickly, there is >> a >>>>>>>> need >>>>>>>>>> for >>>>>>>>>>>>>> fast reallocation of spectrum, where in certain cases >>>> spectrum >>>>>>>> can >>>>>>>>>> be >>>>>>>>>>>>>> freed for disaster relief. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To utilize free or freed spectrum quickly and reliable, >>>>>>>> automation >>>>>>>>>> of >>>>>>>>>>>>>> allocation, assignment and configuration is needed. A >>>> preferred >>>>>>>>>>>>>> option is make use of a robust protocol, already adopted >> by >>>>>>>> radio >>>>>>>>>>>>>> manufacturers. This approach does in no way imply such >>>>>>>>>> organizations >>>>>>>>>>>>>> for disaster relief must compete on spectrum allocation >> with >>>>>>>> other >>>>>>>>>>>>>> white spaces users, but they can. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A typical network topology would include wireless access >>>> links >>>>>>>> to >>>>>>>>>>>>>> the public Internet or private network, wireless ad hoc >>>> network >>>>>>>>>>>>>> radios working independent of a fixed infrastructure and >>>>>>>> satellite >>>>>>>>>>>>>> links for backup where lack of coverage, overload or >> outage >>>> of >>>>>>>>>>>>>> wireless access links occur. >>>>>>>>>>>>>> >>>>>>>>>>>>>> \|/ >>>>>>>>>>>>>> | ad hoc >>>>>>>>>>>>>> | >>>>>>>>>>>>>> |-|-------------| >>>>>>>>>>>>>> | Master node | |------------ >> | >>>>>>>>>>>>>> \|/ | with | | >> Whitespace >>>> | >>>>>>>>>>>>>> | ad hoc /| backhaul link | | Database >>>> | >>>>>>>>>>>>>> | /-----/ |---------------| |---------- >> -- >>>> | >>>>>>>>>>>>>> --|-------------/ | \ / >>>>>>>>>>>>>> | Master node | | | (--/--) >>>>>>>>>>>>>> | without | | ------( ) >>>>>>>>>>>>>> | backhaul link | | Wireless / Private \ >>>>>>>>>>>>>> ---------------\- | Access ( net or ) >>>>>>>>>>>>>> \ | \ Internet ) >>>>>>>>>>>>>> \ \|/ | -------( /\ >>>>>>>>>>>>>> \ | ad hoc | | (------) \--- >> - >>>> - >>>>>>>> - >>>>>>>>>> --- >>>>>>>>>>>>>> \ | | / | >>>>>>>> Other >>>>>>>>>> | >>>>>>>>>>>>>> \--|------------- /Satellite | >>>>>>>> nodes >>>>>>>>>> | >>>>>>>>>>>>>> | Master node | / Link ---- >> - >>>> - >>>>>>>> - >>>>>>>>>> --- >>>>>>>>>>>>>> | with |/ >>>>>>>>>>>>>> | backhaul link | >>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Figure x: Rapid deployed network with partly connected >>>> nodes >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the ad hoc network, all nodes are master nodes in a way >>>> that >>>>>>>>>>>>>> they allocate RF channels from the white space database. >>>>>>>> However, >>>>>>>>>>>>>> the backhaul link could not be available to all nodes, >> such >>>> as >>>>>>>>>>>>>> depicted for the left node in figure x. To handle RF >> channel >>>>>>>>>>>>>> allocation for such nodes, a master node with a backhaul >>>> link >>>>>>>>>>>>>> relays or proxies the database query for them. So master >>>> nodes >>>>>>>>>>>>>> without a backhaul link follow the procedure as defined >> for >>>>>>>>>>>>>> clients. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The ad hoc network radios utilise the provided RF >> channels. >>>>>>>>>> Details >>>>>>>>>>>>>> on forming and maintenance of the ad hoc network, >> including >>>>>>>> repair >>>>>>>>>>>>>> of segmented networks caused by segments operating on >>>> different >>>>>>>>>>>>>> RF channels, is out of scope of spectrum allocation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> paws mailing list >>>>>>>>>>>>>> paws@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> paws mailing list >>>>>>>>>>>>> paws@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> paws mailing list >>>>>>>>>>>> paws@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> paws mailing list >>>>>>>>>>> paws@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>> >>> > From gerald.chouinard@crc.ca Mon Aug 8 14:12:47 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498E021F8BE5 for ; Mon, 8 Aug 2011 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypnxg6UCvzEM for ; Mon, 8 Aug 2011 14:12:45 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 4200521F865F for ; Mon, 8 Aug 2011 14:12:45 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id CFB296B0451; Mon, 8 Aug 2011 17:13:11 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id BB09B6B03A5; Mon, 8 Aug 2011 17:13:11 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id ABBF26B03E2; Mon, 8 Aug 2011 17:13:11 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 2D57A6B03A5; Mon, 8 Aug 2011 17:13:07 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-01.rem.crc.ca [142.92.171.11]) by mailhub.crc.ca (Postfix) with ESMTP id 4BB8C6B11F8; Mon, 8 Aug 2011 17:13:06 -0400 (EDT) Message-Id: <5.1.0.14.2.20110808164905.02d7a6b0@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Aug 2011 17:12:46 -0400 To: "Rosen, Brian" From: Gerald Chouinard In-Reply-To: <58D2DF3F-4DAB-4B57-AF14-26C9D8D53D62@neustar.biz> References: <7BAC95F5A7E67643AAFB2C31BEE662D01409CCBB59@SC-VEXCH2.marvell.com> <4E3AEA21.9050800@research.telcordia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014073D435A@SC-VEXCH2.marvell.com> <2027CD1D-1F3B-4B05-9A89-9F3153829DC5@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D43AA@SC-VEXCH2.marvell.com> <1EBC6560-298F-45F8-88D9-8C2DD9149CC0@inf-net.nl> <92A4EEBC-7356-4E72-9EB4-B9DAF32D938D@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D014073D45BA@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01409CCBB59@SC-VEXCH2.marvell.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "paws@ietf.org" Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 21:12:47 -0000 Brian,

My preference goes to Paul's interpretation.  A master role for the delegation of the database query makes more sense because it carries with it a 'legal' responsibility whereby, someone is still responsible if interference occurs because the recommendations from the database have not been followed.  This responsibility would be more difficult to define, or to attribute, in the case of an ad-hoc network.

By the way, in the case of the FCC Regulation, the paragraph that deals with "proxying" or better "mastering" database queries is 15.701(c) of the 10-174 MO&O on Fixed Devices, second sentence, where it is specified that: "A fixed TVBD may select channels for operation itself from a list of available channels provided by a TV bands database, initiate and operate a network by sending enabling signals to one or more fixed TVBDs and/or personal/portable TVBDs."

This is what the base stations in the 802.22 WRANs will do.  This way, the operator of the base station has the legal responsibility of complying to the database requests.

Gerald


At 15:47 08-08-11 -0400, Rosen, Brian wrote:
The point of the use case is an ad hoc network with no master.  That's why "proxy" is a better term.

Brian

On Aug 8, 2011, at 3:31 PM, Paul Lambert wrote:

> Hi Teco,
>
>>> Proxy is another matter. I usually interpret a proxy
>>> as acting on behalf and modifying the original request.
>>> A system can always create a proxy like mode without additional
>>> specification or considerations.  The proxy however would be
>>> viewed (at the other end of the communications) as the principal.
>> Not sure on this. Assume master is fixed. DB registers locations.
>> Others request RF channel list. Can we accept that proxying
>> master spoofs its own position?
>
> Proxy is not a word I think we should use here.  A device that creates
> a network speaks on behalf of it's clients that may not have location
> capabilities.  There is a delegation of trust and responsibility to
> this Master device that is more than just a proxy service.
>
> This is a very explicit differentiation into a two tier trust model.
> Different regulatory domains may differ from the FCC and have other
> flatter models - however, cutting back from two layers to one is
> easier than adding a layer of trust/functionality later.
>
> A Master enables the use of spectrum by other (non-Master devices) within it's
> geographic range.  The master may not need to contact the GDB for each
> enablement. The FCC currently requires per enablement checking of the
> device type/id.  Checking the available channels has a longer potential
> latency.
>
> This gets into a interesting design area - parameterization of potential
> regulatory rules ...
>
>> What if initiating master is of
>> another type?
>> Term "initiating master" needs another thought. Slave doesn't fit
>> either, because slave can switch to master after it has connectivity
>> to the DB.
>
> Slave or client would fit ... these are different functional elements
> that would coexist. A device starts as client/slave/Mode-I ... it may
> continue communicating to GDB as client/slave/Mode-I while at the same time
> starting to act as a master.
>
> Much of the bootstrapping, mesh, IBSS, etc. can be handled by decomposition
> of the functional elements and allowing multiple at the same time.
>
> Paul
>
>
>
> Paul A. Lambert |  Marvell  | +1 650 787 9141
>
>> -----Original Message-----
>> From: Teco Boot [mailto:teco@inf-net.nl]
>> Sent: Saturday, August 06, 2011 1:06 AM
>> To: Paul Lambert
>> Cc: Rosen, Brian; paws@ietf.org
>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency
>> scenario's
>>
>> Hi Paul,
>>
>> Op 5 aug 2011, om 23:03 heeft Paul Lambert het volgende geschreven:
>>
>>> Hi Teco,
>>>
>>> While disagreeing initially with your proxy-ish requirement for
>>> PAWS .. I do see a difference in how we are viewing
>>> the set of requirements.
>> I think we have to do some work on requirements. At first, let's
>> have use cases.
>>
>> I hope we see a merged document soon, as WG doc, and ask WG for
>> comments. Could be interim telco meeting. Use cases should be complete.
>> Then, we analyze the reqs.
>>
>> But as I mentioned in the meeting, reqs are highly driven by rules
>> from regulators. We have to describe how this works (IETF consensus
>> is not enough). Having a baseline of reqs is fine.
>>
>>> There seem to a variety of ways to look at this elephant:
>> It is not that big...
>>
>>> PAWS as a unique "protocol"
>>> PAWS as a data model for information carried in a particular
>> framework
>>> PAWS as a system specification supporting various communication
>> models
>>> Etc ...
>> I would say: all three, but in reverse order.
>> And it is not "unique". There are many similar protocols, tailored
>> for different purposes.
>>
>>> As a system - I agree with you that implementations should
>>> be allowed that "relay" PAWS messages/PDUs. This seems to
>>> be viable without specific work at the upper layers and
>>> should be transparent to end-to-endd security.
>> OK.
>> Can be done at IP layer. We don't need to come up with another
>> network protocol :-)
>> However, the PAWS packet exchange could have an unacceptable volume
>> for acquiring a communication channel.
>>
>>> Proxy is another matter. I usually interpret a proxy
>>> as acting on behalf and modifying the original request.
>>> A system can always create a proxy like mode without additional
>>> specification or considerations.  The proxy however would be
>>> viewed (at the other end of the communications) as the principal.
>> Not sure on this. Assume master is fixed. DB registers locations.
>> Others request RF channel list. Can we accept that proxying
>> master spoofs its own position? What if initiating master is of
>> another type?
>> Term "initiating master" needs another thought. Slave doesn't fit
>> either, because slave can switch to master after it has connectivity
>> to the DB.
>>
>>> The current FCC notion of Mode II devices requesting
>>> enablement for Mode I is akin to a proxy where the Master
>>> is acting on behalf of the client.  We could call this a
>>> proxy ... but the role(IMHO) needs stronger definition
>>> that simply passing on the request of another device.
>> OK.
>>
>>> The role of the Master is stronger in the sense that it
>>> may directly provide enablement and channel information
>>> without direct queries to the GDB.  There is more state here
>>> than a simple proxy would maintain.
>> OK, it would be a "complex proxy".
>>
>>> All this said ... your basic request at the network topology level
>>> is quite valid.  Not all entities will have access to a GDB
>>> and yet will need ways to determine available spectrum.
>> Thanks.
>>
>> Teco
>>
>>>
>>> Paul
>>>
>>>
>>>
>>> Paul A. Lambert |  Marvell  | +1 650 787 9141
>>>
>>>
>>>> -----Original Message-----
>>>> From: Teco Boot [mailto:teco@inf-net.nl]
>>>> Sent: Friday, August 05, 2011 6:30 AM
>>>> To: Rosen, Brian
>>>> Cc: Paul Lambert; paws@ietf.org
>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency
>>>> scenario's
>>>>
>>>> Brian,
>>>>
>>>> Op 5 aug 2011, om 14:38 heeft Rosen, Brian het volgende geschreven:
>>>>
>>>>> I believe we do have a requirement to ensure privacy and integrity
>> in
>>>> the transaction between the device and the database.  Privacy
>> because
>>>> location is revealed.  Integrity because a Man in the Middle attack
>>>> which modifies the request or response could cause interference for
>>>> primary and/or secondary users.  We also have a requirement for
>>>> authentication, because, as in the U.S., the database may be a
>>>> commercial service with authorized users, and, in order to reveal
>>>> location, the user will want to make sure it is talking to the bona
>>>> fide database it thinks it is.
>>>> OK.
>>>>
>>>> I think nothing prevents us for having a proxy or relay function.
>> There
>>>> is a trust relation between the PAWS master and geo database. There
>>>> should be a trust relation between the TVWS master and slave (out of
>>>> scope for PAWS). If the master functions as proxy or relay for the
>>>> slave, the PAWS trust model is extended, in that the geo database
>> has a
>>>> trust relation with the master and implicit with all its slaves. I
>> can
>>>> imagine that some master devices are accredited for such, not all.
>>>>
>>>> Teco
>>>>
>>>>
>>>>> Its very common for protocols like this to have such requirements,
>>>> and we probably would be questioned if we did not provide such
>>>> capability in the protocol.  The protocol document will require a
>>>> "Security Considerations" section in which these kinds of issues,
>> among
>>>> others, will need to be discussed.  The IETF is particularly
>> sensitive
>>>> to the privacy considerations associated with location of users.
>>>>>
>>>>> Brian
>>>>>
>>>>> On Aug 5, 2011, at 3:56 AM, Teco Boot wrote:
>>>>>
>>>>>> Paul,
>>>>>>
>>>>>> Op 5 aug 2011, om 01:33 heeft Paul Lambert het volgende
>> geschreven:
>>>>>>
>>>>>>> Ok - FCC being an example ... here's the requirement:
>>>>>>>
>>>>>>> 48) The PAWS protocols must provide end-to-end security that
>>>> prevents the modification of the messages sent between a White
>> Spaces
>>>> Device and the Geolocation Database.
>>>>>> Please provide ref.
>>>>>>
>>>>>> I read FCC requirements as it allows a (protected) proxy function
>>>> between Mode II and Fixed / Mode I. Other regulators exist.
>>>>>>
>>>>>> FCC Federal Register/Vol. 75, No. 233::
>>>>>>>> 62. The Commission will further require that communications
>>>> between TV bands devices and databases be transmitted using secure
>>>> methods to prevent corruption or unauthorized modification of data.
>>>> This requirement includes communications of channel availability and
>>>> other spectrum access information between fixed and Mode II devices
>> (it
>>>> is not necessary for TVBDs to apply security coding to channel
>>>> availability and channel access information that they simply pass
>>>> through as such information will already be protected by the sending
>>>> device). The Commission will require that when Mode I devices
>>>> communicate with fixed or Mode II devices for purposes of obtaining
>> a
>>>> list of available channels, they are to use a secure method that
>>>> ensures against corruption or unauthorized modification of the data.
>>>>>>
>>>>>> And:
>>>>>>>> (f) Mode II personal/portable device. A personal/portable TVBD
>>>> that uses an internal geo-location capability and access to a TV
>> bands
>>>> database, either through a direct connection to the Internet or
>> through
>>>> an indirect connection to the Internet by way of fixed TVBD or
>> another
>>>> Mode II TVBD, to obtain a list of available channels.
>>>>>>
>>>>>> I see (future) possibilities for this proxy function between fixed
>>>> (rapid deployed) nodes.
>>>>>>
>>>>>>
>>>>>>> A proxy is a man-in-the-middle attack.  A proxy that can modify a
>>>> request and insert it's own address information is a mechanisms and
>> not
>>>> a useful requirement.
>>>>>> If a TVWS device is malfunctioning, the security model is broken.
>>>>>>
>>>>>>> A transparent proxy ... that tunnels messages or changes
>>>> link/network/transport layer information is possible, but does not
>> seem
>>>> very interesting in the scope of this effort.
>>>>>> If relay is used, it could be IP packet forwarding. Or PAWS
>> message
>>>> relay. No impact on PAWS protocol indeed. But this is to be decided
>>>> later on. The use case simply describes the use case, nothing more.
>>>> Next steps are gathering requirements and engineering.
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>> Paul A. Lambert |  Marvell  | +1 650 787 9141
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
>>>>>>>> Sent: Thursday, August 04, 2011 3:07 PM
>>>>>>>> To: Paul Lambert
>>>>>>>> Cc: scott.probasco@nokia.com; subir@research.telcordia.com;
>>>>>>>> paws@ietf.org
>>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for emergency
>>>>>>>> scenario's
>>>>>>>>
>>>>>>>> You are confusing U.S. FCC rules with IETF protocol
>> requirements.
>>>>>>>>
>>>>>>>> We have several participants, including me, that would foresee
>> "on
>>>>>>>> behalf of" requests, where identification of both the original
>>>>>>>> requester and the intermediary may be needed.   I will reiterate
>>>> that
>>>>>>>> it may be that the intermediary is simply relaying packets and
>>>> would
>>>>>>>> not be visible in a protocol exchange.  That would work on
>> current
>>>> FCC
>>>>>>>> rules, but doesn't need anything in the protocol to support.
>>>>>>>>
>>>>>>>> Just because the FCC currently disallows such a situation does
>> not
>>>> mean
>>>>>>>> that there won't be other nations that do allow them.
>>>>>>>>
>>>>>>>> I do think that the security model has to be fleshed out more,
>> and
>>>> we
>>>>>>>> might have more requirements there.
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> On Aug 4, 2011, at 5:59 PM, Paul Lambert wrote:
>>>>>>>>
>>>>>>>>> I don't see that a proxy or two addresses are ever required to
>>>> meet
>>>>>>>> the described use cases.
>>>>>>>>> 1) security needs to be end-to-end and a proxy that can modify
>>>> the
>>>>>>>> request is not allowed by the FCC
>>>>>>>>> 2) devices that cannot initially reach the GDB can initially be
>> a
>>>>>>>> client/slave/Mode I device
>>>>>>>>> The "master" then asks on their behalf and enables operation of
>>>> the
>>>>>>>> client
>>>>>>>>> Subsequently the device that was the client could act as a
>> Master
>>>>>>>>> since it can now reach the GDB through the initial master
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Paul A. Lambert |  Marvell  | +1 650 787 9141
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On
>>>> Behalf
>>>>>>>> Of
>>>>>>>>>> scott.probasco@nokia.com
>>>>>>>>>> Sent: Thursday, August 04, 2011 12:36 PM
>>>>>>>>>> To: subir@research.telcordia.com; paws@ietf.org
>>>>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for
>> emergency
>>>>>>>>>> scenario's
>>>>>>>>>>
>>>>>>>>>> Hi Subir,
>>>>>>>>>>
>>>>>>>>>> Yes. The use case below requires this functionality.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8/4/11 1:51 PM, "ext Subir Das"
>>>> <subir@research.telcordia.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Scott,
>>>>>>>>>>> Are you suggesting to have proxy/relay support ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> _Subir
>>>>>>>>>>>
>>>>>>>>>>> On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I support this use case. PAWS should support a query from
>> one
>>>>>>>> entity
>>>>>>>>>> on
>>>>>>>>>>>> behalf of another.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Scott
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/3/11 7:38 AM, "ext Rosen,
>> Brian"<Brian.Rosen@neustar.biz>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I think this is a good use case and brings up a new
>>>> requirement:
>>>>>>>>>>>>> The protocol must cater for a query from one entity on
>> behalf
>>>> of
>>>>>>>>>>>>> another
>>>>>>>>>>>>> entity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In many circumstances, this would be invisible to the
>>>> protocol -
>>>>>>>>>> the
>>>>>>>>>>>>> relay client would simply relay packets or use some private
>>>>>>>>>> protocol.
>>>>>>>>>>>>> However, in some circumstances we may need to know the
>>>> identity
>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>>>>> requester as well as the real client, so the actual
>>>> requirement
>>>>>>>> is
>>>>>>>>>> to
>>>>>>>>>>>>> be
>>>>>>>>>>>>> able to carry two identities.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 3, 2011, at 2:08 AM, Teco Boot wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Scott,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have written down an practical use case for PAWS in an
>> ad
>>>> hoc
>>>>>>>>>>>>>> network for emergency scenario's. Please comment.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, Teco
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3.x.  Rapid deployed network for emergency scenarios
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Organizations involved in handling emergency operations
>>>> often
>>>>>>>> have
>>>>>>>>>>>>>> a fully owned and controlled infrastructure, with
>> dedicated
>>>>>>>>>> spectrum,
>>>>>>>>>>>>>> for day to day operation. However, lessons learned from
>>>> recent
>>>>>>>>>>>>>> disasters show such infrastructures are often highly
>>>> affected by
>>>>>>>>>> the
>>>>>>>>>>>>>> disaster itself. To set up a replacement quickly, there is
>> a
>>>>>>>> need
>>>>>>>>>> for
>>>>>>>>>>>>>> fast reallocation of spectrum, where in certain cases
>>>> spectrum
>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>>>>>> freed for disaster relief.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To utilize free or freed spectrum quickly and reliable,
>>>>>>>> automation
>>>>>>>>>> of
>>>>>>>>>>>>>> allocation, assignment and configuration is needed. A
>>>> preferred
>>>>>>>>>>>>>> option is make use of a robust protocol, already adopted
>> by
>>>>>>>> radio
>>>>>>>>>>>>>> manufacturers. This approach does in no way imply such
>>>>>>>>>> organizations
>>>>>>>>>>>>>> for disaster relief must compete on spectrum allocation
>> with
>>>>>>>> other
>>>>>>>>>>>>>> white spaces users, but they can.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A typical network topology would include wireless access
>>>> links
>>>>>>>> to
>>>>>>>>>>>>>> the public Internet or private network, wireless ad hoc
>>>> network
>>>>>>>>>>>>>> radios working independent of a fixed infrastructure and
>>>>>>>> satellite
>>>>>>>>>>>>>> links for backup where lack of coverage, overload or
>> outage
>>>> of
>>>>>>>>>>>>>> wireless access links occur.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                      \|/
>>>>>>>>>>>>>>                       | ad hoc
>>>>>>>>>>>>>>                       |
>>>>>>>>>>>>>>                     |-|-------------|
>>>>>>>>>>>>>>                     | Master node   |       |------------
>> |
>>>>>>>>>>>>>> \|/                     | with          |       |
>> Whitespace
>>>> |
>>>>>>>>>>>>>> | ad hoc              /| backhaul link |       | Database
>>>> |
>>>>>>>>>>>>>> |              /-----/ |---------------|       |----------
>> --
>>>> |
>>>>>>>>>>>>>> --|-------------/                |      \           /
>>>>>>>>>>>>>> | Master node   |                |       |      (--/--)
>>>>>>>>>>>>>> | without       |                |       ------(       )
>>>>>>>>>>>>>> | backhaul link |                |  Wireless  / Private \
>>>>>>>>>>>>>> ---------------\-                |    Access (   net or  )
>>>>>>>>>>>>>>            \                |            \ Internet )
>>>>>>>>>>>>>>             \    \|/        |      -------(        /\
>>>>>>>>>>>>>>              \    | ad hoc  |      |       (------)  \---
>> -
>>>> -
>>>>>>>> -
>>>>>>>>>> ---
>>>>>>>>>>>>>>               \   |         |      /                 |
>>>>>>>> Other
>>>>>>>>>> |
>>>>>>>>>>>>>>                \--|-------------  /Satellite         |
>>>>>>>> nodes
>>>>>>>>>> |
>>>>>>>>>>>>>>                | Master node   | / Link              ----
>> -
>>>> -
>>>>>>>> -
>>>>>>>>>> ---
>>>>>>>>>>>>>>                | with          |/
>>>>>>>>>>>>>>                | backhaul link |
>>>>>>>>>>>>>>                -----------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Figure x: Rapid deployed network with partly connected
>>>> nodes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the ad hoc network, all nodes are master nodes in a way
>>>> that
>>>>>>>>>>>>>> they allocate RF channels from the white space database.
>>>>>>>> However,
>>>>>>>>>>>>>> the backhaul link could not be available to all nodes,
>> such
>>>> as
>>>>>>>>>>>>>> depicted for the left node in figure x. To handle RF
>> channel
>>>>>>>>>>>>>> allocation for such nodes, a master node with a backhaul
>>>> link
>>>>>>>>>>>>>> relays or proxies the database query for them. So master
>>>> nodes
>>>>>>>>>>>>>> without a backhaul link follow the procedure as defined
>> for
>>>>>>>>>>>>>> clients.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The ad hoc network radios utilise the provided RF
>> channels.
>>>>>>>>>> Details
>>>>>>>>>>>>>> on forming and maintenance of the ad hoc network,
>> including
>>>>>>>> repair
>>>>>>>>>>>>>> of segmented networks caused by segments operating on
>>>> different
>>>>>>>>>>>>>> RF channels, is out of scope of spectrum allocation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> paws mailing list
>>>>>>>>>>>>>> paws@ietf.org
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> paws mailing list
>>>>>>>>>>>>> paws@ietf.org
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> paws mailing list
>>>>>>>>>>>> paws@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> paws mailing list
>>>>>>>>>>> paws@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> paws mailing list
>>>>>>>>>> paws@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>>> _______________________________________________
>>>>>>>>> paws mailing list
>>>>>>>>> paws@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> paws mailing list
>>>>>>> paws@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>
>>>>>
>>>
>

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From gerald.chouinard@crc.ca Mon Aug 8 15:00:31 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1211E80CA for ; Mon, 8 Aug 2011 15:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWs3SELsdhNC for ; Mon, 8 Aug 2011 15:00:31 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id B236011E8091 for ; Mon, 8 Aug 2011 15:00:30 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id E220D6B0441; Mon, 8 Aug 2011 18:00:54 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id C70A86B03AC; Mon, 8 Aug 2011 18:00:54 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id BA53E6B03E2; Mon, 8 Aug 2011 18:00:54 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 994046B03AC; Mon, 8 Aug 2011 18:00:50 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-01.rem.crc.ca [142.92.171.11]) by mailhub.crc.ca (Postfix) with ESMTP id 37B926B11F8; Mon, 8 Aug 2011 18:00:50 -0400 (EDT) Message-Id: <5.1.0.14.2.20110808174328.02ca2790@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Aug 2011 18:00:33 -0400 To: From: Gerald Chouinard In-Reply-To: References: <69A7E364B918F949829C3CD4FF25994E09A6EECB08@EMV35-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Cc: paws@ietf.org, apurva.mody@BAESYSTEMS.COM Subject: Re: [paws] Rural Network use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 22:00:31 -0000 Scott,

The text that I am referring to is as follows: "Many of the masters/BS are assumed to be deployed and operated by a single entity, i.e., there is coordination between many of the master/BSs."

The first assumption, although possible, cannot be used in the context of an "unlicensed" use of the band.  Any new comer that is not part of the same entity will be allowed to operte and even compete for the local spectrum.  However, the second assumption is correct where some coordination between the local masters/BSs will be needed to make the best use of the spectrum.  This has been built into the 802.22 WRAN standard through the "coexistence beacon protocol (CBP)" which allows the BSs to exchange information, directly or through its CPEs, on the channels being used, the backup channels that would be used if an incumbent was to appear and which frames should be used by which BS in case the same channel needs to be re-used.

Also, related to the previous sentence, operation of broadband access WRANs is not limited to the casewherte there are "many available radio channels" which would be the case in very remote rural areas.  Such WRANs could also operate in rural areas close to urban centers where less channels would be available by possibly sharing the same channels as explained above.

I would suggest the following change to these two sentences:
"This deployment is typically characterized by one or more fixed master(s)/BS(s), and many available radio channels. Many of the masters/BS are assumed to be deployed and operated by a single entity, i.e., there is It is assumed that coordination would exist between many of the master/BSs to optimize the choice of available channels."

Thank's,

Gerald


At 14:29 03-08-11 +0000, scott.probasco@nokia.com wrote:
Hi Gerald,

Reviewing section '3.3 Wide-Area or Rural internet broadband access', I
don=B9t find any assumption of pre-assigned frequencies. There was no intent
to include this concept.

Could you please identify the text you are thinking of?

Regards,
Scott


On 8/2/11 11:22 AM, "ext michael.fitch@bt.com" <michael.fitch@bt.com>
wrote:

>Dear Brian
>
>Agreed, we would not want to assume that the rural case will have
>pre-planned channels.
>
>Michael
>
>-----Original Message-----
>From: paws-bounces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of
>Rosen, Brian
>Sent: 02 August 2011 14:08
>To: Gerald Chouinard
>Cc: paws@ietf.org; Apurva Mody
>Subject: Re: [paws] Rural Network use case
>
>While use cases can discuss co-existence, that aspect is out of scope for
>our work at this time.
>
>Of course, preplanned use of frequencies wouldn't require a database
>query, so that would seem to be out of scope also.
>
>I personally don't think there is much difference between urban, suburban
>and rural access in the part of the problem we are looking at in this
>work group.  The number of available channels might be larger, and the
>number of protected devices might be smaller, but that is just a scale
>issue: the database query would be the same, and the response would be
>the same (modulo the length of the available spectrum=20 response).
>
>Brian
>
>On Aug 2, 2011, at 8:37 AM, Gerald Chouinard wrote:
>
>> Scott,
>>
>> I appreciated your presentation on the Use Cases document last week in
>> Quebec City.  However, there is one thing that I am not fully
>>comfortable
>> with in the Rural Network case.  Your assumption is that the rural
>>networks
>> will have been planned beforehand and frequencies will have been
>> pre-assigned.  This does not correspond to the assumption that we used
>>in
>> the development of the IEEE 802.22 Standard.  The reason is that, in
>>the
>> context of a "license-exempt" ("unlicensed" in the US) environment
>>where
>> any competitor can come in and implement his base station and CPEs, a
>> planned network implementation is possible in practice. Such
>>pre-planning
>> would apply to a frequency band licensed to a specific operator.
>> Furthermore, protected low-power devices (e.g., wireless microphones)
>>could
>> pop up anywhere in the area and disable the frequencies that had been
>> pre-planned for the network. No pre-planned frequency assignment of the
>> networks in an area would allow an easy adaptation to such an event.
>>
>> Recognizing such limitation, a technique by which the various cells
>>will be
>> able to talk to each other through a self-coexistence mechanism to
>>exchange
>> information on the frequencies that they use and that they have as
>>backup
>> channels in case their current channel is disabled all of a sudden has
>>been
>> included in the 802.22 Standard (see Clause 7.20 "Self-coexistence" in
>>the
>> 802.22 Standard).  Additionally, information on how the same channel
>>can be
>> shared by a number of cells, in case where no other channel is
>>available in
>> the area, is exchanged between these cells to share the transmission
>> capacity  among 802.22 WRAN cells on a frame-based TDM mechanism.
>>
>> This should be reflected in either modifying the current rural case by
>> removing the assumption of a pre-planned network or adding a new rural
>>case
>> where a self-coexistence mechanism would be assumed, while keepnig the
>> current rural case for "licensed band" type operation.
>>
>> Hope this helps.
>>
>> Regards,
>>
>> Gerald
>>
>>
>> _______________________________________________
>> paws mailing list
>> paws@ietf.org
>> https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws
From lei.zhu@huawei.com Mon Aug 8 20:58:56 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF31B11E809F for ; Mon, 8 Aug 2011 20:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVYzjBjFSg61 for ; Mon, 8 Aug 2011 20:58:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29A21F86DE for ; Mon, 8 Aug 2011 20:58:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPN00BOL72XE4@szxga04-in.huawei.com> for paws@ietf.org; Tue, 09 Aug 2011 11:59:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPN00ADL72XSP@szxga04-in.huawei.com> for paws@ietf.org; Tue, 09 Aug 2011 11:59:21 +0800 (CST) Received: from z41317b ([10.108.64.160]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPN00GJ572SSL@szxml04-in.huawei.com> for paws@ietf.org; Tue, 09 Aug 2011 11:59:21 +0800 (CST) Date: Tue, 09 Aug 2011 11:59:16 +0800 From: Zhu Lei In-reply-to: <69A7E364B918F949829C3CD4FF25994E09A6EEC905@EMV35-UKDY.domain1.systemhost.net> To: michael.fitch@bt.com, paws@ietf.org Message-id: <003501cc5648$b5b4a290$211de7b0$%zhu@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cjBRNdt+dVeNIUxT08XjTg)" Content-language: zh-cn Thread-index: AcxQYaFdJtjaH9IGS0OW4FVa2jr0jAF5c52w References: <69A7E364B918F949829C3CD4FF25994E09A6EEC905@EMV35-UKDY.domain1.systemhost.net> Subject: Re: [paws] draft-lei-paws-overview-usecases-00.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 03:58:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_cjBRNdt+dVeNIUxT08XjTg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Michael and all, =20 Sorry for not responding on time. =20 Yes, I think paws made some statements to combine the use cases into one document with context which is for people to understand when reading protocol document. =20 According to your comments, I may reframe the supper-wifi terminology = and so on. I=A1=AFd like to revise this particular ID to reflect your comments = by now, or soon. Then, please provide your opinions one this draft, and hopely = frame the structure of use case document. =20 Best regards, Zhu Lei =20 =B7=A2=BC=FE=C8=CB: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = =B4=FA=B1=ED michael.fitch@bt.com =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C21=C8=D5 23:43 =CA=D5=BC=FE=C8=CB: paws@ietf.org =D6=F7=CC=E2: [paws] draft-lei-paws-overview-usecases-00.txt =20 Dear all =20 This is the first contribution to the mailing list from ourselves at BT, = so please forgive any mistakes with the =A1=AEprotocol=A1=AF. =20 We refer to the document = =A1=AEdraft-lei-paws-overview-usecases-00.txt=A1=AF and would like to make some comments. We are also happy to become involved = in the further drafting of the document if appropriate. =20 1. Introduction The use-cases mentioned here are Rural Broadband Access and = location-based services, but these are not the ones expanded upon in section 3. We need some better alignment here I think. We are happy to propose some text. = We would rather avoid the use of =A1=AEWiFi=A1=AF =A1=AEsuper-WiFi=A1=AF in = this document, as it implies a particular use of WiFi protocols and the document = shouldn=A1=AFt pronounce on such things.=20 =20 2. Terminology =A8C the database should return a list of available channels and maximum transmit powers [and optionally directional information] 3. Use Cases. The use-cases of interest to us are Rural Broadband (not-spots), Dynamic Backhaul (for traditional WiFi hot spots or for femto-cells / micro-cells), indoor networking (called in this document super-WiFi) and Machine to Machine. These should be expanded in later = parts of section 3, ie 3.1, 3.2 etc. , except we should drop the super-WiFi = tag. =20 At present, 3.1 addresses indoor networking, 3.2 is TVWS ad-hoc = networking and 3.3 is TD-LTE MBMS. These last two are not even mentioned in the introduction (section 1) or in the introductory paragraph of section 3.=20 I propose we have the following expanded structure: 3.1 =A8C Rural Broadband 3.2 =A8C Indoor Networking 3.3 =A8C Dynamic Backhaul 3.4 =A8C Machine to machine 3.5 =A8C Ad-hoc networking 3.6 =A8C MBMS (or more broadly, cellular extension ?) =20 We offer to contribute text to the new sections 3.1, 3.2, 3.3, 3.4. =20 4. Requirements We need to add a confidence interval to the location accuracy. = Currently, GPS has only 70% at 50m I believe. We should take into account directivity of antennas at the master and = slave stations Other countries will use this (not just the US) so we need to expand = beyond FCC=20 We should not tie the document to GPS, as there are other techniques for determining location.=20 =20 =20 Best wishes =20 Michael Fitch and Richard MacKenzie BT =20 --Boundary_(ID_cjBRNdt+dVeNIUxT08XjTg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Michael and all,

 

Sorry for not responding on = time.

 

Yes, I think paws made some = statements to combine the use cases into one document with context which = is for people to understand when reading protocol = document.

 

According to your comments, I = may reframe the supper-wifi terminology and so on. I=A1=AFd like to = revise this particular ID to reflect your comments by now, or soon. = Then, please provide your opinions one this draft, and hopely frame the = structure of use case document.

 

Best = regards,

Z= hu Lei

 

=B7=A2=BC=FE=C8=CB: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] =B4=FA=B1=ED = michael.fitch@bt.com
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C21=C8=D5 23:43
=CA=D5=BC=FE=C8=CB: = paws@ietf.org
=D6=F7=CC=E2: [paws] = draft-lei-paws-overview-usecases-00.txt

 

Dear all

 

This is the first contribution to the mailing list from = ourselves at BT, so please forgive any mistakes with the = =A1=AEprotocol=A1=AF.

 

We refer to the document = =A1=AEdraft-lei-paws-overview-usecases-00.txt=A1=AF and would like to = make some comments. We are also happy to become involved in the further = drafting of the document if appropriate.

 

1.      = Introduction

The use-cases mentioned here = are Rural Broadband Access and location-based services, but these are = not the ones expanded upon in section 3. We need some better alignment = here I think. We are happy to propose some text.  We would rather = avoid the use of =A1=AEWiFi=A1=AF =A1=AEsuper-WiFi=A1=AF in this = document, as it implies a particular use of WiFi protocols and the = document shouldn=A1=AFt pronounce on such things. =

 

2.      = Terminology =A8C the = database should return a list of available channels and maximum transmit = powers [and optionally directional information]

3.      = Use Cases. The = use-cases of interest to us are Rural Broadband (not-spots), Dynamic = Backhaul (for traditional WiFi hot spots or for femto-cells / = micro-cells),  indoor networking (called in this document = super-WiFi) and Machine to Machine. These should be expanded in later = parts of section 3, ie 3.1, 3.2 etc. , except we should drop the = super-WiFi tag.  

 At present, 3.1 addresses indoor = networking, 3.2 is TVWS ad-hoc networking and 3.3 is TD-LTE MBMS. These = last two are not even mentioned in the introduction (section 1) or in = the introductory paragraph of section 3.
I propose we have the = following expanded structure:

3.1   =A8C Rural Broadband

3.2   =A8C Indoor Networking

3.3   =A8C Dynamic Backhaul

3.4   =A8C Machine to machine

3.5   =A8C Ad-hoc networking

3.6   =A8C MBMS (or more broadly, cellular extension = ?)

 

We offer to contribute = text to the new sections 3.1, 3.2, 3.3, 3.4.

 

4.      = Requirements

We need to add a confidence = interval to the location accuracy. Currently, GPS has only 70% at 50m I = believe.

We should take into account directivity of antennas at the = master and slave stations

Other countries will use = this (not just the US) so we need to expand beyond FCC =

We = should not tie the document to GPS, as there are other techniques for = determining location.

 

 

Best = wishes

 

Michael Fitch and Richard = MacKenzie

BT

 

= --Boundary_(ID_cjBRNdt+dVeNIUxT08XjTg)-- From Gabor.Bajko@nokia.com Fri Aug 19 14:21:36 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3898511E80ED for ; Fri, 19 Aug 2011 14:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aEAf8E3fK9M for ; Fri, 19 Aug 2011 14:21:35 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7395611E80E5 for ; Fri, 19 Aug 2011 14:21:35 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7JLMVQF006612 for ; Sat, 20 Aug 2011 00:22:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Aug 2011 00:22:31 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 19 Aug 2011 23:22:31 +0200 Received: from 008-AM1MPN1-001.mgdnok.nokia.com ([169.254.1.198]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.002; Fri, 19 Aug 2011 23:22:30 +0200 From: To: Thread-Topic: Quebec hums confirmation Thread-Index: AcxetOLe+QnKRqkIR5+XsATvuZzczQ== Date: Fri, 19 Aug 2011 21:22:30 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47605515B@008-AM1MPN1-001.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.108.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Aug 2011 21:22:31.0445 (UTC) FILETIME=[1AD9EC50:01CC5EB6] X-Nokia-AV: Clean Subject: [paws] Quebec hums confirmation X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:21:36 -0000 I'd like to confirm on the list the hums we took during the PAWS session in= Quebec. We took 3 hums, one to combine the PS and the use cases document i= nto one informational one, then to adopt the text in the PS and use cases d= ocument as a WG baseline, with the caveat that the requirements have to be = reformulated (to make them not FCC specific and to be applicable to the pro= tocol and data model instead of the endpoints). Therefore, once Scott comes= up with a combined PS and use cases document, we'll ask on the list to ado= pt it as WG document. The minutes (taken by Pete McCan) and presentation sl= ides are uploaded to https://datatracker.ietf.org/meeting/81/materials.html= .=20 -Gabor From richard@shockey.us Fri Aug 19 18:22:27 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5769221F85F1 for ; Fri, 19 Aug 2011 18:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.825 X-Spam-Level: X-Spam-Status: No, score=-99.825 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WqaeVff0azt for ; Fri, 19 Aug 2011 18:22:26 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 7434421F85AB for ; Fri, 19 Aug 2011 18:22:22 -0700 (PDT) Received: (qmail 1356 invoked by uid 0); 20 Aug 2011 01:23:17 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 20 Aug 2011 01:23:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=2zpS31UYJK7mQyL7344F4VbZo0L6uWeKBioGvC4WUsc=; b=KtC0FOCFWM0djLZcGWE4e6FMkXWt7N3feyP4Ss/vViJdD7FhXoaVbiilx+SFn4XnleBuHS3632wWbgjfRWcTMAXCxlT6FxdHhf20BGVJlCfjtUUJVzQ/ovhBSAIc48kP; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1QuaHM-0008Jg-Vc for paws@ietf.org; Fri, 19 Aug 2011 19:23:17 -0600 From: "Richard Shockey" To: References: <1ECAFF543A2FED4EA2BEB6CACE08E47605515B@008-AM1MPN1-001.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605515B@008-AM1MPN1-001.mgdnok.nokia.com> Date: Fri, 19 Aug 2011 21:23:13 -0400 Message-ID: <01e101cc5ed7$bb7490e0$325db2a0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxetOLe+QnKRqkIR5+XsATvuZzczQAItBpg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: Re: [paws] Quebec hums confirmation X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 01:22:27 -0000 +1 -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Friday, August 19, 2011 5:23 PM To: paws@ietf.org Subject: [paws] Quebec hums confirmation I'd like to confirm on the list the hums we took during the PAWS session in Quebec. We took 3 hums, one to combine the PS and the use cases document into one informational one, then to adopt the text in the PS and use cases document as a WG baseline, with the caveat that the requirements have to be reformulated (to make them not FCC specific and to be applicable to the protocol and data model instead of the endpoints). Therefore, once Scott comes up with a combined PS and use cases document, we'll ask on the list to adopt it as WG document. The minutes (taken by Pete McCan) and presentation slides are uploaded to https://datatracker.ietf.org/meeting/81/materials.html. -Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From jmh@joelhalpern.com Fri Aug 19 19:09:19 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5652A21F884C for ; Fri, 19 Aug 2011 19:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo+CHIgbejtq for ; Fri, 19 Aug 2011 19:09:18 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id E1E9121F883A for ; Fri, 19 Aug 2011 19:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 48B5C3246996; Fri, 19 Aug 2011 19:10:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.105] (pool-71-161-51-177.clppva.btas.verizon.net [71.161.51.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id B9827324422B; Fri, 19 Aug 2011 19:10:16 -0700 (PDT) Message-ID: <4E4F1777.1070301@joelhalpern.com> Date: Fri, 19 Aug 2011 22:09:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Richard Shockey References: <1ECAFF543A2FED4EA2BEB6CACE08E47605515B@008-AM1MPN1-001.mgdnok.nokia.com> <01e101cc5ed7$bb7490e0$325db2a0$@us> In-Reply-To: <01e101cc5ed7$bb7490e0$325db2a0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Quebec hums confirmation X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 02:09:19 -0000 Sounds like a good set of ideas to me. Yours, Joel On 8/19/2011 9:23 PM, Richard Shockey wrote: > +1 > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Friday, August 19, 2011 5:23 PM > To: paws@ietf.org > Subject: [paws] Quebec hums confirmation > > I'd like to confirm on the list the hums we took during the PAWS session in > Quebec. We took 3 hums, one to combine the PS and the use cases document > into one informational one, then to adopt the text in the PS and use cases > document as a WG baseline, with the caveat that the requirements have to be > reformulated (to make them not FCC specific and to be applicable to the > protocol and data model instead of the endpoints). Therefore, once Scott > comes up with a combined PS and use cases document, we'll ask on the list to > adopt it as WG document. The minutes (taken by Pete McCan) and presentation > slides are uploaded to > https://datatracker.ietf.org/meeting/81/materials.html. > > -Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From subir@research.telcordia.com Fri Aug 19 19:12:00 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7048221F888A for ; Fri, 19 Aug 2011 19:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JN+KXLCxnV4 for ; Fri, 19 Aug 2011 19:11:59 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5004321F8862 for ; Fri, 19 Aug 2011 19:11:59 -0700 (PDT) Received: from [128.96.58.39] (vpntnlA39.research.telcordia.com [128.96.58.39]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p7K2Cncu013388 for ; Fri, 19 Aug 2011 22:12:53 -0400 (EDT) Message-ID: <4E4F1831.6000508@research.telcordia.com> Date: Fri, 19 Aug 2011 22:13:05 -0400 From: Subir Das User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: paws@ietf.org References: <1ECAFF543A2FED4EA2BEB6CACE08E47605515B@008-AM1MPN1-001.mgdnok.nokia.com> <01e101cc5ed7$bb7490e0$325db2a0$@us> <4E4F1777.1070301@joelhalpern.com> In-Reply-To: <4E4F1777.1070301@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [paws] Quebec hums confirmation X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 02:12:00 -0000 +1 On 8/19/2011 10:09 PM, Joel M. Halpern wrote: > Sounds like a good set of ideas to me. > Yours, > Joel > > On 8/19/2011 9:23 PM, Richard Shockey wrote: >> +1 >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Gabor.Bajko@nokia.com >> Sent: Friday, August 19, 2011 5:23 PM >> To: paws@ietf.org >> Subject: [paws] Quebec hums confirmation >> >> I'd like to confirm on the list the hums we took during the PAWS >> session in >> Quebec. We took 3 hums, one to combine the PS and the use cases document >> into one informational one, then to adopt the text in the PS and use >> cases >> document as a WG baseline, with the caveat that the requirements have >> to be >> reformulated (to make them not FCC specific and to be applicable to the >> protocol and data model instead of the endpoints). Therefore, once Scott >> comes up with a combined PS and use cases document, we'll ask on the >> list to >> adopt it as WG document. The minutes (taken by Pete McCan) and >> presentation >> slides are uploaded to >> https://datatracker.ietf.org/meeting/81/materials.html. >> >> -Gabor >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Aug 22 09:17:19 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B475A21F8AED for ; Mon, 22 Aug 2011 09:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgjoVGxtn2TB for ; Mon, 22 Aug 2011 09:17:19 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3021F8A62 for ; Mon, 22 Aug 2011 09:17:18 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7MGIKbf024309; Mon, 22 Aug 2011 19:18:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 19:18:04 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 22 Aug 2011 18:18:03 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Mon, 22 Aug 2011 18:18:02 +0200 From: To: Thread-Topic: combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVA== Date: Mon, 22 Aug 2011 16:18:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.243.0.17] Content-Type: multipart/alternative; boundary="_000_CA77EB668275scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2011 16:18:04.0645 (UTC) FILETIME=[123AB150:01CC60E7] X-Nokia-AV: Clean Subject: [paws] combined problem statement, use cases & requirements X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:17:19 -0000 --_000_CA77EB668275scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, According to the results of the face-to-face meeting, we have combined the = problem statement I-D and use case & requirement I-D into a single I-D. Yo= ur comments are welcomed. Regards, Scott URL: http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts= -00.txt Abstract: Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed for enabling the use of the primary user owned white space spectrum for secondary users, without causing interference, by querying a database which knows the channel availability at any given location and time. A number of possible use cases of this spectrum and derived requirements are also described. --_000_CA77EB668275scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5DC42841AECB3640A4E5814C0C7A8AE6@nokia.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

According to the results of the face-to-face meeting, we have combined the = problem statement I-D and use case & requirement I-D into a single I-D.=  Your comments are welcomed.

 

Regards,

Scott


URL: http://www.ietf.org/id/draft-probasco-paws-problem= -stmt-usecases-rqmts-00.txt



Abstract:
   Port= ions of the radio spectrum that are allocated to a licensed,
   prim= ary user but are unused or unoccupied at specific locations and
   time= s are defined as &quot;white space&quot;.  The concept of= allowing
   seco= ndary transmissions (licensed or unlicensed) in white space is a
   tech= nique to &quot;unlock&quot; existing spectrum for new use. &nb= sp;An obvious
   requ= irement is that these secondary transmissions do not interfere
   with= the primary use of the spectrum.  One approach to using the
   whit= e space spectrum at a given time and location is to verify with a
   data= base available channels.

   This= document describes the concept of TV White Spaces.  It also
   desc= ribes the problems that need to be addressed for enabling the use
   of t= he primary user owned white space spectrum for secondary users,
   with= out causing interference, by querying a database which knows the
   chan= nel availability at any given location and time.  A number of
   poss= ible use cases of this spectrum and derived requirements are also
   desc= ribed.

--_000_CA77EB668275scottprobasconokiacom_-- From gerald.chouinard@crc.ca Mon Aug 22 12:45:25 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222021F8B22 for ; Mon, 22 Aug 2011 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBdVa69onVo6 for ; Mon, 22 Aug 2011 12:45:24 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 0490121F8B20 for ; Mon, 22 Aug 2011 12:45:23 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 858B16B04BE for ; Mon, 22 Aug 2011 15:46:23 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 766E06B0349 for ; Mon, 22 Aug 2011 15:46:23 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 67CA06B03AD; Mon, 22 Aug 2011 15:46:23 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id BD7706B0349 for ; Mon, 22 Aug 2011 15:46:19 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-01.rem.crc.ca [142.92.171.11]) by mailhub.crc.ca (Postfix) with ESMTP id 9B07B6B139A for ; Mon, 22 Aug 2011 15:46:19 -0400 (EDT) Message-Id: <5.1.0.14.2.20110822154024.03c79e30@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Aug 2011 15:46:12 -0400 To: From: Gerald Chouinard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Subject: [paws] Fwd: combined problem statement, use cases & requirements X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:45:25 -0000 Hi, You may want to take a look at the Report produced by the CEPT ECC SE 43 to get an idea of what the Europeans have in mind for use cases and what they expect from the database protocol such as the indication of the maximum EIRP that can be used by a TVBD on a specific channel at a specific location. http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCREP159.PDF Regards, Gerald >From: >To: >Thread-Topic: combined problem statement, use cases & requirements >Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVA== >Date: Mon, 22 Aug 2011 16:18:02 +0000 >Subject: [paws] combined problem statement, use cases & requirements >List-Id: "Protocol to Access White Space database \(PAWS\)" >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: paws-bounces@ietf.org >X-Virus-Scanned: ClamAV using ClamSMTP > >Hi, > >According to the results of the face-to-face meeting, we have combined the >problem statement I-D and use case & requirement I-D into a single >I-D. Your comments are welcomed. > >Regards, > >Scott > >URL: >http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt > >Abstract: > Portions of the radio spectrum that are allocated to a licensed, > primary user but are unused or unoccupied at specific locations and > times are defined as "white space". The concept of allowing > secondary transmissions (licensed or unlicensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these secondary transmissions do not interfere > with the primary use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with a > database available channels. > > This document describes the concept of TV White Spaces. It also > describes the problems that need to be addressed for enabling the use > of the primary user owned white space spectrum for secondary users, > without causing interference, by querying a database which knows the > channel availability at any given location and time. A number of > possible use cases of this spectrum and derived requirements are also > described. > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Mon Aug 22 14:43:28 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656B821F8C76 for ; Mon, 22 Aug 2011 14:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGLXRcZBbRfm for ; Mon, 22 Aug 2011 14:43:27 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C385321F8C74 for ; Mon, 22 Aug 2011 14:43:27 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7MLiH5c020785 for ; Tue, 23 Aug 2011 00:44:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 00:43:06 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 22 Aug 2011 23:43:02 +0200 Received: from 008-AM1MPN1-001.mgdnok.nokia.com ([169.254.1.198]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Mon, 22 Aug 2011 23:43:01 +0200 From: To: Thread-Topic: combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVJUpXkBw Date: Mon, 22 Aug 2011 21:43:01 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.108.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2011 21:43:06.0558 (UTC) FILETIME=[7A4675E0:01CC6114] X-Nokia-AV: Clean Subject: Re: [paws] combined problem statement, use cases & requirements X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:43:28 -0000 During the Quebec session, we had presentations of the PS and the use cases= drafts. The wg then decided it wants to see these drafts merged into one. = Scott just did that and posted the merged draft: http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.t= xt Now I would like to ask if the wg feels like this document is ready to be a= dopted as a wg document. Please send your feedback and hum to the list by t= his time next week. -Gabor ---------------------------------------------------------------------------= ---------------------------- From: Probasco Scott=20 Sent: Monday, August 22, 2011 9:18 AM To: paws@ietf.org Subject: combined problem statement, use cases & requirements Hi, =A0 According to the results of the face-to-face meeting, we have combined the = problem statement I-D and use case & requirement I-D into a single I-D. =A0= Your comments are welcomed. =A0 Regards, Scott URL:=A0http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqm= ts-00.txt Abstract: =A0=A0 Portions of the radio spectrum that are allocated to a licensed, =A0=A0 primary user but are unused or unoccupied at specific locations and =A0=A0 times are defined as 'white space'.=A0=A0The concept of allowing =A0=A0 secondary transmissions (licensed or unlicensed) in white space is a =A0=A0 technique to 'unlock' existing spectrum for new use.=A0=A0An obvious =A0=A0 requirement is that these secondary transmissions do not interfere =A0=A0 with the primary use of the spectrum.=A0=A0One approach to using the =A0=A0 white space spectrum at a given time and location is to verify with = a =A0=A0 database available channels. =A0=A0 This document describes the concept of TV White Spaces.=A0=A0It also =A0=A0 describes the problems that need to be addressed for enabling the us= e =A0=A0 of the primary user owned white space spectrum for secondary users, =A0=A0 without causing interference, by querying a database which knows the =A0=A0 channel availability at any given location and time.=A0=A0A number o= f =A0=A0 possible use cases of this spectrum and derived requirements are als= o =A0=A0 described. From Gabor.Bajko@nokia.com Tue Aug 30 10:40:45 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A2F21F8D64 for ; Tue, 30 Aug 2011 10:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o20FbhfsYs7 for ; Tue, 30 Aug 2011 10:40:44 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 86CDD21F8D53 for ; Tue, 30 Aug 2011 10:40:44 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7UHg0A2024119 for ; Tue, 30 Aug 2011 20:42:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 20:42:05 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 30 Aug 2011 19:42:06 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.245]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Tue, 30 Aug 2011 19:42:05 +0200 From: To: Thread-Topic: combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVJUpXkBwgAxXBHA= Date: Tue, 30 Aug 2011 17:42:04 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.108.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Aug 2011 17:42:05.0718 (UTC) FILETIME=[223F6360:01CC673C] X-Nokia-AV: Clean Subject: Re: [paws] combined problem statement, use cases & requirements X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 17:40:45 -0000 I sent this email to the list one week ago, asking for feedback on=20 http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.t= xt but there was not one feedback received. I take that as people have no comm= ents to the draft at this time. And I am asking again: is there any objection in adopting the above draft a= s a wg document? -Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Gabor.Bajko@nokia.com Sent: Monday, August 22, 2011 2:43 PM To: paws@ietf.org Subject: Re: [paws] combined problem statement, use cases & requirements During the Quebec session, we had presentations of the PS and the use cases= drafts. The wg then decided it wants to see these drafts merged into one. = Scott just did that and posted the merged draft: http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.t= xt Now I would like to ask if the wg feels like this document is ready to be a= dopted as a wg document. Please send your feedback and hum to the list by t= his time next week. -Gabor ---------------------------------------------------------------------------= ---------------------------- From: Probasco Scott=20 Sent: Monday, August 22, 2011 9:18 AM To: paws@ietf.org Subject: combined problem statement, use cases & requirements Hi, =A0 According to the results of the face-to-face meeting, we have combined the = problem statement I-D and use case & requirement I-D into a single I-D. =A0= Your comments are welcomed. =A0 Regards, Scott URL:=A0http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqm= ts-00.txt Abstract: =A0=A0 Portions of the radio spectrum that are allocated to a licensed, =A0=A0 primary user but are unused or unoccupied at specific locations and =A0=A0 times are defined as 'white space'.=A0=A0The concept of allowing =A0=A0 secondary transmissions (licensed or unlicensed) in white space is a =A0=A0 technique to 'unlock' existing spectrum for new use.=A0=A0An obvious =A0=A0 requirement is that these secondary transmissions do not interfere =A0=A0 with the primary use of the spectrum.=A0=A0One approach to using the =A0=A0 white space spectrum at a given time and location is to verify with = a =A0=A0 database available channels. =A0=A0 This document describes the concept of TV White Spaces.=A0=A0It also =A0=A0 describes the problems that need to be addressed for enabling the us= e =A0=A0 of the primary user owned white space spectrum for secondary users, =A0=A0 without causing interference, by querying a database which knows the =A0=A0 channel availability at any given location and time.=A0=A0A number o= f =A0=A0 possible use cases of this spectrum and derived requirements are als= o =A0=A0 described. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@crc.ca Tue Aug 30 15:04:59 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C24A21F8F54 for ; Tue, 30 Aug 2011 15:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXzA+yUbtj41 for ; Tue, 30 Aug 2011 15:04:58 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 6EA3921F8F53 for ; Tue, 30 Aug 2011 15:04:58 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id A70FE6B044E; Tue, 30 Aug 2011 18:06:22 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 8DE846B035E; Tue, 30 Aug 2011 18:06:22 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 7F7116B03F3; Tue, 30 Aug 2011 18:06:22 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id CA78A6B035E; Tue, 30 Aug 2011 18:06:18 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-01.rem.crc.ca [142.92.171.11]) by mailhub.crc.ca (Postfix) with ESMTP id 5D9366B1479; Tue, 30 Aug 2011 18:06:18 -0400 (EDT) Message-Id: <5.1.0.14.2.20110830170014.02ac6338@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Aug 2011 18:06:01 -0400 To: , From: Gerald Chouinard In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgd nok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Virus-Scanned: ClamAV using ClamSMTP Cc: apurva mody Subject: Re: [paws] combined problem statement, use cases & requirements X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:04:59 -0000 Hi Gabor,

I have reviewed the document and I am not completely satisfied with the description of the Wide-Area and Rural internet broadband access use case described in section 5.3 (page 13).  Here are e few modifications to the text:

"5.3.  Wide-Area or Rural internet broadband access

   In this use case, internet broadband access is provided as a Wide-Area
   Network (WAN) or Wireless Regional Area Network (WRAN).  A typical
   deployment scenario is a wide area or rural area, where internet
   broadband access is provided to local businesses and residents from a
   master (i.e.  BS) connected to the internet.  This deployment
   scenario is typically characterized by one or more fixed master(s)/
   BS(s), cells with relatively large radius (tens of kilometers, up to 100
   km), and manya number of available radio channels.  ManySome of the masters/BSs are
   assumed tomay be deployed and operated by a single entity, i.e. there iscan be
   centralized coordination between many of these masters/BSs, whereas other masters/BSs may be deployed and operated by operators competing for the radio channels in a license-exempt TVWS environment where decentralized coordination using the air-interface would be required.  The BS in this
   scenario use a TDD radio technology and transmit at or below a
   transmit power thresholdlimit established by the local regulator.  Each
   base station has a connection to the internet and provides internet
   connectivity to multiple slave/end-user devices.  End user terminals
   or devices may be fixed or portable."

Notes:
I believe the expression: "many available radio channels" gives the impression that there will be more channels than needed.  On the contrary, the RF spectrum will usually be limited and clever coordination will be needed to share the limitged resourcesx among the various celss in operation in an area.
The following sentence still gives the impression that most of the BS(s) will be coordinated by a single operator while the reality will be, in the license-exempt TVWS environment, many operators will compete for the same spectrum (think of Wi-Fi at 2.4 GHz). Some of the BS(s) in operation may be coordinated by a central NOC but, in reality, decentralized coexistence schemes will need to be applied for best use of the spectrum.  Even the coordinated BS(s) will have to deal with the other BS(s) through decentralized coexistence schemes to be able to get their share of the resource.
In the development of the 802.22 WRAN standard, major effort was spent to develop means for these uncoordinated BS(s) to communicate with each other to establish self-coexistence mechanisms.  802.19 is developing means by which coexistence will be attempted among dissimilar technologies using the TVWS.  As you can imagine, the centrally coordinated operation among BS(s) belonging to the same operator will be the simplest case.  The more difficult decentralized coordination cases should not be overlooked.

Items 8 and 9 on page 15 also need a bit of refinement as follows:

"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 databasemaster for a list of channels list available at, based on the slaves' geolocation.

   9.  Once this list of available channels is received from the database by Tthe master, the latter will decide, based on the list of available channels for all its other associated slaves whether it should continue operation on its current channel or change channel to accommodate the new slave in case this channel is not available at its location. The master will notify all its associated slaves/user devices of the new channel to move to if operation needs to change channel provides the list of channels locally available to the
       slave/user device.  If the channel that the user terminal is
       currently using is not included in the list of locally available
       channels, the master will drop its association with the slave/user device so that it ceases all operation on its current channel and indicate the new operating channel before dropping the link if a change has been decided.  The slave/user device may move to the indicated new channel if so indicated or scan for another WRAN transmission on a different channel.
Note:
The BS has to find the 'common denominator' across all lists of available channels for all its associated slaves and a decision has to be made whether it can accommodate the new slave or not.  It may happen that, in the case where its current operating channel is not available at the new slave location, the master can still find a channel that is still available to all its slaves, including the new slave. A channel move would then be indicated to accept this new slave.  However, if changing channel means that, say, two other slaves would no longer be available, thaen, a value judgement needs to take place at the master based on the importance of this new slaver versus the two slaves that would lose association.  The process has to allow for this intelligence at the master.

Respectully,

Gerald


At 17:42 30-08-11 +0000, Gabor.Bajko@nokia.com wrote:
I sent this email to the list one week ago, asking for feedback on
http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt
but there was not one feedback received. I take that as people have no comments to the draft at this time.

And I am asking again: is there any objection in adopting the above draft as a wg document?

-Gabor

-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gabor.Bajko@nokia.com
Sent: Monday, August 22, 2011 2:43 PM
To: paws@ietf.org
Subject: Re: [paws] combined problem statement, use cases & requirements

During the Quebec session, we had presentations of the PS and the use cases drafts. The wg then decided it wants to see these drafts merged into one. Scott just did that and posted the merged draft:
http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt

Now I would like to ask if the wg feels like this document is ready to be adopted as a wg document. Please send your feedback and hum to the list by this time next week.

-Gabor

-------------------------------------------------------------------------------------------------------
From: Probasco Scott
Sent: Monday, August 22, 2011 9:18 AM
To: paws@ietf.org
Subject: combined problem statement, use cases & requirements

Hi,
 
According to the results of the face-to-face meeting, we have combined the problem statement I-D and use case & requirement I-D into a single I-D.  Your comments are welcomed.
 
Regards,
Scott

URL: http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt


Abstract:
   Portions of the radio spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as 'white space'.  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to 'unlock' existing spectrum for new use.  An obvious
   requirement is that these secondary transmissions do not interfere
   with the primary use of the spectrum.  One approach to using the
   white space spectrum at a given time and location is to verify with a
   database available channels.

   This document describes the concept of TV White Spaces.  It also
   describes the problems that need to be addressed for enabling the use
   of the primary user owned white space spectrum for secondary users,
   without causing interference, by querying a database which knows the
   channel availability at any given location and time.  A number of
   possible use cases of this spectrum and derived requirements are also
   described.

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

Will be very= happy if PAWS can support this use case - critical for M2M. 

Best regards, 
Ro= bert 

6Harmonics Inc. 



--- On Fri, 8/5/11, scott.probasco@nokia.com <scott.probasco@nok= ia.com> wrote:

From: scott.proba= sco@nokia.com <scott.probasco@nokia.com>
Subject: Re: [paws] PAWS = use case: ad hoc network for emergency scenario's
To: subir@research.telcordia.com, paws@ietf.or= g
Received: Friday, August 5, 2011, 1:35 AM

Hi Subir,

Yes. The use case below requires this functionality.
Regards,
Scott


On 8/4/11 1:51 PM, "ext Subir Das" <<= a ymailto=3D"mailto:subir@research.telcordia.com" href=3D"/mc/compose?to=3D= subir@research.telcordia.com">subir@research.telcordia.com> wrote:
>Scott,
>Are you suggesting to have proxy/relay support ?>
>Thanks,
>_Subir
>
>On 8/3/2011 11:47 AM, scott.probasco@nokia.com wrote:
>> Hi,
= >>
>> I support this use case. PAWS should support a query f= rom one entity on
>> behalf of another.
>>
>> Re= gards,
>> Scott
>>
>>
>> On 8/3/11 7:38= AM, "ext Rosen, Brian"<Brian.Rosen@neustar.biz&g= t;  wrote:
>>
>>> I think this is a good use case= and brings up a new requirement:
>>> The protocol must cater f= or a query from one entity on behalf of
>>>another
>>&= gt; entity.
>>>
>>> In many circumstances, this wou= ld be invisible to the protocol - the
>>> relay client would si= mply relay packets or use some private protocol.
>>> However, i= n some circumstances we may need to know the identity of the
>>>= ; requester as well as the real client, so the actual requirement is to
= >>>be
>>> able to carry two identities.
>>>= ;
>>> Brian
>>>
>>> On Aug 3, 2011, at = 2:08 AM, Teco Boot wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> I have written down an prac= tical use case for PAWS in an ad hoc
>>>> network for emerge= ncy scenario's. Please comment.
>>>>
>>>> Tha= nks, Teco
>>>>
>>>>
>>>>
&g= t;>>> 3.x.  Rapid deployed network for emergency scenarios>>>>
>>>> Organizations involved in handling em= ergency operations often have
>>>> a fully owned and control= led infrastructure, with dedicated spectrum,
>>>> for day to= day operation. However, lessons learned from recent
>>>> di= sasters show such infrastructures are often highly affected by the
>&= gt;>> disaster itself. To set up a replacement quickly, there is a ne= ed for
>>>> fast reallocation of spectrum, where in certain = cases spectrum can be
>>>> freed for disaster relief.
>>>>
>>>> To utilize free or freed s= pectrum quickly and reliable, automation of
>>>> allocation,= assignment and configuration is needed. A preferred
>>>> op= tion is make use of a robust protocol, already adopted by radio
>>= >> manufacturers. This approach does in no way imply such organizatio= ns
>>>> for disaster relief must compete on spectrum allocat= ion with other
>>>> white spaces users, but they can.
>= ;>>>
>>>> A typical network topology would include = wireless access links to
>>>> the public Internet or private= network, wireless ad hoc network
>>>> radios working indepe= ndent of a fixed infrastructure and satellite
>>>> links for= backup where lack of coverage, overload or outage of
>>>> w= ireless access links occur.
>>>>
>>>>        =                     \|/>>>>                &= nbsp;            | ad hoc
>>>= ;>                    =          |
>>>>    &= nbsp;                    =   |-|-------------|
>>>>       = ;                    = ;| Master node   |       |---------= ---|
>>>>   \|/        &n= bsp;            | with    &nbs= p;     |       | Whitespace |
>>>>    | ad hoc        &nb= sp;     /| backhaul link |       | Datab= ase   |
>>>>    |    &nbs= p;         /-----/ |---------------|     = ;  |------------|
>>>> --|-------------/  &nb= sp;             |      \ =          /
>>>> | Master node=    |                = |       |      (--/--)
>>&= gt;> | without       |      &nbs= p;         |       ------(&nbs= p;      )
>>>> | backhaul link |  &= nbsp;             |  Wireless  / Private \
>>>> ---------------\-  &nb= sp;             |    Access ( =   net or  )
>>>>        &= nbsp;         \           = ;     |            \ Internet )
= >>>>                &nb= sp;  \    \|/        |   =   -------(        /\
>>>>  &n= bsp;                 \   = | ad hoc  |      |       (---= ---)  \---------
>>>>         =            \   |  &= nbsp;      |      /                 | Other  |
&g= t;>>>                 = ;     \--|-------------  /Satellite      &nbs= p;  | nodes  |
>>>>       = ;               | Master node  = ; | / Link              ----------<= br>>>>>                =       | with          |/
>>= ;>>                  &nb= sp;   | backhaul link |
>>>>       =               -----------------
>= >>>
>>>>
>>>>      Fi= gure x: Rapid deployed network with partly connected nodes
>>>>
>>>>
>>>> In the a= d hoc network, all nodes are master nodes in a way that
>>>>= they allocate RF channels from the white space database. However,
>&= gt;>> the backhaul link could not be available to all nodes, such as<= br>>>>> depicted for the left node in figure x. To handle RF ch= annel
>>>> allocation for such nodes, a master node with a b= ackhaul link
>>>> relays or proxies the database query for t= hem. So master nodes
>>>> without a backhaul link follow the= procedure as defined for
>>>> clients.
>>>><= br>>>>> The ad hoc network radios utilise the provided RF chann= els. Details
>>>> on forming and maintenance of the ad hoc n= etwork, including repair
>>>> of segmented networks caused b= y segments operating on different
>>>> RF channels, is out of scope of spectrum allocation.
>>>>
>>>= ;>
>>>>
>>>>
>>>> _________= ______________________________________
>>>> paws mailing lis= t
>>>> paws@ietf.org
>>>> https://www.ietf= .org/mailman/listinfo/paws
>>> ____________________________= ___________________
>>> paws mailing list
>>> paws= @ietf.org
>>> https://www.ietf.org/mailman/listinfo/paws<= br>>> _______________________________________________
>> paw= s mailing list
>> paws@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/paws
>___________________________= ____________________
>paws mailing list
>paws@ietf.org
= >https://www.ietf.org/mailman/listinfo/paws

___________________= ____________________________
paws mailing list
paws@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/paws
<= div>