From teco@inf-net.nl Thu Sep 1 22:51:30 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 EC7C821F914C for ; Thu, 1 Sep 2011 22:51:30 -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=[AWL=0.001, 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 LV72ySCtdQVU for ; Thu, 1 Sep 2011 22:51:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6E3221F8EFC for ; Thu, 1 Sep 2011 22:51:28 -0700 (PDT) Received: by wyg8 with SMTP id 8so2290786wyg.31 for ; Thu, 01 Sep 2011 22:53:02 -0700 (PDT) Received: by 10.216.134.158 with SMTP id s30mr620515wei.71.1314942782750; Thu, 01 Sep 2011 22:53:02 -0700 (PDT) Received: from [172.16.4.75] ([188.205.88.52]) by mx.google.com with ESMTPS id o7sm508800wbh.8.2011.09.01.22.53.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 22:53:01 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Sep 2011 07:52:59 +0200 Message-Id: <14EF51BD-F536-4037-B1CE-78A92FF49362@inf-net.nl> To: paws@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [paws] Pointers to Ofcom material 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, 02 Sep 2011 05:51:31 -0000 Here some pointers to Ofcom material: = http://consumers.ofcom.org.uk/2011/09/ofcom-progresses-with-new-wireless-t= echnology/ (describes three use cases)=20 = http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/statem= ent/statement.pdf (roughly describes the proces for getting requirements for TVWS usage) I think the PS&UC&R doc should be lined up with this, and ref section = should include the statement doc. Teco= From teco@inf-net.nl Thu Sep 1 23: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 8086121F93B5 for ; Thu, 1 Sep 2011 23:04:59 -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=[AWL=0.000, 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 2-lMOwJZT2tG for ; Thu, 1 Sep 2011 23:04:58 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60F7021F93B1 for ; Thu, 1 Sep 2011 23:04:58 -0700 (PDT) Received: by wyg8 with SMTP id 8so2297301wyg.31 for ; Thu, 01 Sep 2011 23:06:32 -0700 (PDT) Received: by 10.216.154.75 with SMTP id g53mr1002980wek.50.1314943592677; Thu, 01 Sep 2011 23:06:32 -0700 (PDT) Received: from [172.16.4.75] ([188.205.88.52]) by mx.google.com with ESMTPS id fp17sm535186wbb.6.2011.09.01.23.06.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 23:06:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> Date: Fri, 2 Sep 2011 08:06:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> References: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: paws@ietf.org 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: Fri, 02 Sep 2011 06:04:59 -0000 I think the doc is a good starting point. I support adoption. I suggest reordering: specifying problem statement after introducing the = use cases. Some asked for the ad hoc network scenario. This includes me :-). This = is important, because it demonstrates the need for "proxy". BTW, I wonder why similar scenario doesn't pop up from WiFi deployments. = Usage of controllers in large sites is not uncommon. Not to mention 11s. The requirements is left open. I'm looking forward see some draft text. Thanks, Teco =20 Op 30 aug 2011, om 19:42 heeft = het volgende geschreven: > 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.= txt > but there was not one feedback received. I take that as people have no = comments to the draft at this time. >=20 > And I am asking again: is there any objection in adopting the above = draft as a wg document? >=20 > -Gabor >=20 > -----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 >=20 > 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 >=20 > 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. >=20 > -Gabor >=20 > = --------------------------------------------------------------------------= ----------------------------- > From: Probasco Scott=20 > Sent: Monday, August 22, 2011 9:18 AM > To: paws@ietf.org > Subject: combined problem statement, use cases & requirements >=20 > Hi, > =20 > 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. > =20 > Regards, > Scott >=20 > URL: = http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.= txt >=20 >=20 > 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. >=20 > 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. >=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 Gabor.Bajko@nokia.com Fri Sep 2 14:17: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 4FEBB21F8D99 for ; Fri, 2 Sep 2011 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 CrvRdE1swFOg for ; Fri, 2 Sep 2011 14:17:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE121F8DA3 for ; Fri, 2 Sep 2011 14:17:42 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p82LJ5Ia030259; Sat, 3 Sep 2011 00:19: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); Sat, 3 Sep 2011 00:19:11 +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, 2 Sep 2011 23:19:10 +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.007; Fri, 2 Sep 2011 23:19:10 +0200 From: To: , Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVJUpXkBwgAxXBHCAA9RNgIABHcBg Date: Fri, 2 Sep 2011 21:19:09 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> In-Reply-To: <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> 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: 02 Sep 2011 21:19:11.0217 (UTC) FILETIME=[F54A0E10:01CC69B5] 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: Fri, 02 Sep 2011 21:17:44 -0000 Teco, Gerald, Thanks for the feedback. I'd suggest that we make this draft a WG item, wit= h Gerald's proposed changes in it. Regarding the order of the problem state= ment vs use cases, my preference would be to leave it as it is (but we can = always change it, if that is what the WG wants). So, I'd ask Scott to submit a WG version of this draft, then have someone c= ome up with text for this ad-hoc network scenario, have the WG agree with t= he text and include it in one of the subsequent versions. Teco, would you w= rite up some text for this ad-hoc use case the WG could discuss? We'll also send an initial version of a list of requirements to the list ne= xt week. - Gabor -----Original Message----- From: ext Teco Boot [mailto:teco@inf-net.nl]=20 Sent: Thursday, September 01, 2011 11:06 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] combined problem statement, use cases & requirements I think the doc is a good starting point. I support adoption. I suggest reordering: specifying problem statement after introducing the us= e cases. Some asked for the ad hoc network scenario. This includes me :-). This is i= mportant, because it demonstrates the need for "proxy". BTW, I wonder why similar scenario doesn't pop up from WiFi deployments. Us= age of controllers in large sites is not uncommon. Not to mention 11s. The requirements is left open. I'm looking forward see some draft text. Thanks, Teco =20 Op 30 aug 2011, om 19:42 heeft het volgende geschreven: > 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.txt but there was not one feedback received. I take that as people=20 > have no comments to the draft at this time. >=20 > And I am asking again: is there any objection in adopting the above draft= as a wg document? >=20 > -Gabor >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > 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 &=20 > requirements >=20 > During the Quebec session, we had presentations of the PS and the use cas= es 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 >=20 > 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. >=20 > -Gabor >=20 > ---------------------------------------------------------------------- > --------------------------------- > From: Probasco Scott > Sent: Monday, August 22, 2011 9:18 AM > To: paws@ietf.org > Subject: combined problem statement, use cases & requirements >=20 > Hi, > =20 > According to the results of the face-to-face meeting, we have combined th= e problem statement I-D and use case & requirement I-D into a single I-D. = Your comments are welcomed. > =20 > Regards, > Scott >=20 > URL:=20 > http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts > -00.txt >=20 >=20 > 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. >=20 > 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. >=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 Gabor.Bajko@nokia.com Fri Sep 2 14:37:35 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 2AE1C21F8DAD for ; Fri, 2 Sep 2011 14:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-0.187, 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 NZBdTKl6r2Uz for ; Fri, 2 Sep 2011 14:37:34 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 62CD821F8DAC for ; Fri, 2 Sep 2011 14:37:34 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p82Lbkrd023380 for ; Sat, 3 Sep 2011 00:37:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Sep 2011 00:37:41 +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; Fri, 2 Sep 2011 23:37:40 +0200 Received: from 008-AM1MPN1-001.mgdnok.nokia.com ([169.254.1.198]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Fri, 2 Sep 2011 23:37:39 +0200 From: To: Thread-Topic: Meeting in Taipei Thread-Index: AcxpuEgZaqvqq4smQlmoFCXzn5ydzQ== Date: Fri, 2 Sep 2011 21:37:39 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760DAD0E@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: 02 Sep 2011 21:37:41.0557 (UTC) FILETIME=[8B1A7E50:01CC69B8] X-Nokia-AV: Clean Subject: [paws] Meeting in Taipei 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, 02 Sep 2011 21:37:35 -0000 Folks, The AD asked me to poll the WG to see if we want to meet in Taipei. I would= assume we want, as we'll likely have the requirements and some solution pr= oposals to talk about. Let me know if you think otherwise. -Gabor From nbravin@earthlink.net Sat Sep 3 15:39:40 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 3323A21F8A71 for ; Sat, 3 Sep 2011 15:39:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcn07CmbYbY7 for ; Sat, 3 Sep 2011 15:39:39 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5F21E21F8A6C for ; Sat, 3 Sep 2011 15:39:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=b2k5oautpKNlmQOwdJaIzcRDAjny8FVpPGKycJaK18vs43Gj6EQKLkz2dHV4INn8; 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-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qzyti-0006xM-JU; Sat, 03 Sep 2011 18:41:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> Date: Sat, 3 Sep 2011 15:41:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> To: Gabor.Bajko@nokia.com X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad862e31ce440cca9d35b84c3f6b6a01646b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org 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: Sat, 03 Sep 2011 22:39:40 -0000 Dear Gabor and All,=20 I think it is appropriate to put the use cases before the PS for obvious = reasons, and including the "proxy" need in the first draft. I support = including both Gerald's suggestions and Teco's proposal in the original draft and not = waiting until a later time. It is the proper order, inclusive and needed = in the initial draft in my opinion. I believe with the talent in the group it will not = take long to accomplish this and you will have a more cohesive draft. SIncerely, Nancy On Sep 2, 2011, at 2:19 PM, = wrote: > Teco, Gerald, >=20 > Thanks for the feedback. I'd suggest that we make this draft a WG = item, with Gerald's proposed changes in it. Regarding the order of the = problem statement vs use cases, my preference would be to leave it as it = is (but we can always change it, if that is what the WG wants). >=20 > So, I'd ask Scott to submit a WG version of this draft, then have = someone come up with text for this ad-hoc network scenario, have the WG = agree with the text and include it in one of the subsequent versions. = Teco, would you write up some text for this ad-hoc use case the WG could = discuss? >=20 > We'll also send an initial version of a list of requirements to the = list next week. >=20 > - Gabor >=20 >=20 > -----Original Message----- > From: ext Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Thursday, September 01, 2011 11:06 PM > To: Bajko Gabor (Nokia-CIC/SiliconValley) > Cc: paws@ietf.org > Subject: Re: [paws] combined problem statement, use cases & = requirements >=20 > I think the doc is a good starting point. I support adoption. >=20 > I suggest reordering: specifying problem statement after introducing = the use cases. >=20 > Some asked for the ad hoc network scenario. This includes me :-). This = is important, because it demonstrates the need for "proxy". > BTW, I wonder why similar scenario doesn't pop up from WiFi = deployments. Usage of controllers in large sites is not uncommon. Not to = mention 11s. >=20 > The requirements is left open. I'm looking forward see some draft = text. >=20 > Thanks, Teco >=20 >=20 > Op 30 aug 2011, om 19:42 heeft = het volgende geschreven: >=20 >> 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.txt but there was not one feedback received. I take that as = people=20 >> have no comments to the draft at this time. >>=20 >> And I am asking again: is there any objection in adopting the above = draft as a wg document? >>=20 >> -Gabor >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20= >> 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 &=20 >> requirements >>=20 >> 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 >>=20 >> 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. >>=20 >> -Gabor >>=20 >> = ---------------------------------------------------------------------- >> --------------------------------- >> From: Probasco Scott >> Sent: Monday, August 22, 2011 9:18 AM >> To: paws@ietf.org >> Subject: combined problem statement, use cases & requirements >>=20 >> Hi, >>=20 >> 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. >>=20 >> Regards, >> Scott >>=20 >> URL:=20 >> = http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts >> -00.txt >>=20 >>=20 >> 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. >>=20 >> 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. >>=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 Basavaraj.Patil@nokia.com Tue Sep 6 09:55: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 45ECB21F8C30 for ; Tue, 6 Sep 2011 09:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 eGeK1ARXjB-t for ; Tue, 6 Sep 2011 09:55:17 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59021F85B1 for ; Tue, 6 Sep 2011 09:55:17 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p86Gv2xC028836 for ; Tue, 6 Sep 2011 19:57:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 19:56:42 +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; Tue, 6 Sep 2011 18:56:41 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Tue, 6 Sep 2011 18:56:41 +0200 From: To: , Thread-Topic: [paws] Meeting in Taipei Thread-Index: AcxpuEgZaqvqq4smQlmoFCXzn5ydzQCwv1qA Date: Tue, 6 Sep 2011 16:56:41 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760DAD0E@008-AM1MPN1-001.mgdnok.nokia.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: [172.19.59.27] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2011 16:56:42.0911 (UTC) FILETIME=[F43842F0:01CC6CB5] X-Nokia-AV: Clean Subject: Re: [paws] Meeting in Taipei 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, 06 Sep 2011 16:55:18 -0000 I do agree that we need to have a meeting at IETF82 to make forward progress on the deliverables. -Basavaraj On 9/2/11 4:37 PM, "ext Gabor.Bajko@nokia.com" wrote: >Folks, > >The AD asked me to poll the WG to see if we want to meet in Taipei. I >would assume we want, as we'll likely have the requirements and some >solution proposals to talk about. >Let me know if you think otherwise. > >-Gabor >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Wed Sep 7 13:30:48 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 E36F321F8CB0 for ; Wed, 7 Sep 2011 13:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 kA3RL0pW+JfH for ; Wed, 7 Sep 2011 13:30:48 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B827221F8CAE for ; Wed, 7 Sep 2011 13:30:47 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p87KWSo0028305; Wed, 7 Sep 2011 23:32:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 23:32:23 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 22:32:23 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.245]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 7 Sep 2011 22:32:22 +0200 From: To: Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVJUpXkBwgAxXBHCAA9RNgIABHcBggAGKfgCABkSf4A== Date: Wed, 7 Sep 2011 20:32:22 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760F84CC@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> In-Reply-To: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.106.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2011 20:32:23.0920 (UTC) FILETIME=[40134700:01CC6D9D] 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: Wed, 07 Sep 2011 20:30:49 -0000 Ok, let's try that then. Scott, can you put use cases before PS, and add the ad-hoc use case. I just= scanned through the list and spotted that Teco indeed provided a descripti= on for that use case on Aug 3rd. And submit the draft as a wg item, unless there are still objections. -Gabor -----Original Message----- From: ext Nancy Bravin [mailto:nbravin@earthlink.net]=20 Sent: Saturday, September 03, 2011 3:41 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: Teco Boot; Gerald Chouinard; paws@ietf.org Subject: Re: [paws] combined problem statement, use cases & requirements Dear Gabor and All,=20 I think it is appropriate to put the use cases before the PS for obvious re= asons, and including the "proxy" need in the first draft. I support includi= ng both Gerald's suggestions and Teco's proposal in the original draft and = not waiting until a later time. It is the proper order, inclusive and neede= d in the initial draft in my opinion. I believe with the talent in the grou= p it will not take long to accomplish this and you will have a more cohesiv= e draft. SIncerely, Nancy On Sep 2, 2011, at 2:19 PM, = wrote: > Teco, Gerald, >=20 > Thanks for the feedback. I'd suggest that we make this draft a WG item, w= ith Gerald's proposed changes in it. Regarding the order of the problem sta= tement vs use cases, my preference would be to leave it as it is (but we ca= n always change it, if that is what the WG wants). >=20 > So, I'd ask Scott to submit a WG version of this draft, then have someone= come up with text for this ad-hoc network scenario, have the WG agree with= the text and include it in one of the subsequent versions. Teco, would you= write up some text for this ad-hoc use case the WG could discuss? >=20 > We'll also send an initial version of a list of requirements to the list = next week. >=20 > - Gabor >=20 >=20 > -----Original Message----- > From: ext Teco Boot [mailto:teco@inf-net.nl] > Sent: Thursday, September 01, 2011 11:06 PM > To: Bajko Gabor (Nokia-CIC/SiliconValley) > Cc: paws@ietf.org > Subject: Re: [paws] combined problem statement, use cases &=20 > requirements >=20 > I think the doc is a good starting point. I support adoption. >=20 > I suggest reordering: specifying problem statement after introducing the = use cases. >=20 > Some asked for the ad hoc network scenario. This includes me :-). This is= important, because it demonstrates the need for "proxy". > BTW, I wonder why similar scenario doesn't pop up from WiFi deployments. = Usage of controllers in large sites is not uncommon. Not to mention 11s. >=20 > The requirements is left open. I'm looking forward see some draft text. >=20 > Thanks, Teco >=20 >=20 > Op 30 aug 2011, om 19:42 heeft het volgende geschreven: >=20 >> 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-rqmt >> s -00.txt but there was not one feedback received. I take that as=20 >> people have no comments to the draft at this time. >>=20 >> And I am asking again: is there any objection in adopting the above draf= t as a wg document? >>=20 >> -Gabor >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 >> 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 &=20 >> requirements >>=20 >> During the Quebec session, we had presentations of the PS and the use ca= ses drafts. The wg then decided it wants to see these drafts merged into on= e. Scott just did that and posted the merged draft: >> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmt >> s >> -00.txt >>=20 >> Now I would like to ask if the wg feels like this document is ready to b= e adopted as a wg document. Please send your feedback and hum to the list b= y this time next week. >>=20 >> -Gabor >>=20 >> --------------------------------------------------------------------- >> - >> --------------------------------- >> From: Probasco Scott >> Sent: Monday, August 22, 2011 9:18 AM >> To: paws@ietf.org >> Subject: combined problem statement, use cases & requirements >>=20 >> Hi, >>=20 >> According to the results of the face-to-face meeting, we have combined t= he problem statement I-D and use case & requirement I-D into a single I-D. = Your comments are welcomed. >>=20 >> Regards, >> Scott >>=20 >> URL:=20 >> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmt >> s >> -00.txt >>=20 >>=20 >> Abstract: >> Portions of the radio spectrum that are allocated to a licensed,=20 >> primary user but are unused or unoccupied at specific locations and=20 >> times are defined as 'white space'. The concept of allowing=20 >> secondary transmissions (licensed or unlicensed) in white space is a=20 >> technique to 'unlock' existing spectrum for new use. An obvious=20 >> requirement is that these secondary transmissions do not interfere=20 >> with the primary use of the spectrum. One approach to using the=20 >> white space spectrum at a given time and location is to verify with a=20 >> database available channels. >>=20 >> This document describes the concept of TV White Spaces. It also=20 >> describes the problems that need to be addressed for enabling the use=20 >> of the primary user owned white space spectrum for secondary users,=20 >> without causing interference, by querying a database which knows the=20 >> channel availability at any given location and time. A number of=20 >> possible use cases of this spectrum and derived requirements are also=20 >> described. >>=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 gerald.chouinard@crc.ca Wed Sep 7 16:59: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 8B94D21F8D08 for ; Wed, 7 Sep 2011 16:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 MpsxmjcERe30 for ; Wed, 7 Sep 2011 16:59:11 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 7007721F8CEF for ; Wed, 7 Sep 2011 16:59:11 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id CEACB6B03B4; Wed, 7 Sep 2011 20:00:56 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id B30616B03A9; Wed, 7 Sep 2011 20:00:56 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id A59846B03B8; Wed, 7 Sep 2011 20:00:56 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id CBF216B03A9; Wed, 7 Sep 2011 20:00:52 -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 721C16B1520; Wed, 7 Sep 2011 20:00:52 -0400 (EDT) Message-Id: <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Sep 2011 20:00:30 -0400 To: From: Gerald Chouinard In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760F84CC@008-AM1MPN1-007.mgd nok.nokia.com> References: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Cc: paws@ietf.org 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: Wed, 07 Sep 2011 23:59:12 -0000 Gabor, Can I ask that the text modifications that I have submitted to scott and copied to the paws reflector in my email dated 8 August be included as well? Thank's, Gerald At 20:32 07-09-11 +0000, Gabor.Bajko@nokia.com wrote: >Ok, let's try that then. >Scott, can you put use cases before PS, and add the ad-hoc use case. I >just scanned through the list and spotted that Teco indeed provided a >description for that use case on Aug 3rd. >And submit the draft as a wg item, unless there are still objections. > >-Gabor > >-----Original Message----- >From: ext Nancy Bravin [mailto:nbravin@earthlink.net] >Sent: Saturday, September 03, 2011 3:41 PM >To: Bajko Gabor (Nokia-CIC/SiliconValley) >Cc: Teco Boot; Gerald Chouinard; paws@ietf.org >Subject: Re: [paws] combined problem statement, use cases & requirements > >Dear Gabor and All, > >I think it is appropriate to put the use cases before the PS for obvious >reasons, and including the "proxy" need in the first draft. I support >including both Gerald's suggestions and Teco's proposal in the original >draft and not waiting until a later time. It is the proper order, >inclusive and needed in the initial draft in my opinion. I believe with >the talent in the group it will not take long to accomplish this and you >will have a more cohesive draft. > >SIncerely, Nancy > > >On Sep 2, 2011, at 2:19 PM, > wrote: > > > Teco, Gerald, > > > > Thanks for the feedback. I'd suggest that we make this draft a WG item, > with Gerald's proposed changes in it. Regarding the order of the problem > statement vs use cases, my preference would be to leave it as it is (but > we can always change it, if that is what the WG wants). > > > > So, I'd ask Scott to submit a WG version of this draft, then have > someone come up with text for this ad-hoc network scenario, have the WG > agree with the text and include it in one of the subsequent versions. > Teco, would you write up some text for this ad-hoc use case the WG could > discuss? > > > > We'll also send an initial version of a list of requirements to the > list next week. > > > > - Gabor > > > > > > -----Original Message----- > > From: ext Teco Boot [mailto:teco@inf-net.nl] > > Sent: Thursday, September 01, 2011 11:06 PM > > To: Bajko Gabor (Nokia-CIC/SiliconValley) > > Cc: paws@ietf.org > > Subject: Re: [paws] combined problem statement, use cases & > > requirements > > > > I think the doc is a good starting point. I support adoption. > > > > I suggest reordering: specifying problem statement after introducing > the use cases. > > > > Some asked for the ad hoc network scenario. This includes me :-). This > is important, because it demonstrates the need for "proxy". > > BTW, I wonder why similar scenario doesn't pop up from WiFi > deployments. Usage of controllers in large sites is not uncommon. Not to > mention 11s. > > > > The requirements is left open. I'm looking forward see some draft text. > > > > Thanks, Teco > > > > > > Op 30 aug 2011, om 19:42 heeft > het volgende geschreven: > > > >> 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-rqmt > >> s -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-rqmt > >> s > >> -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-rqmt > >> s > >> -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 > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From lei.zhu@huawei.com Wed Sep 7 18:33: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 0BE6421F886D for ; Wed, 7 Sep 2011 18:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 ZtoMroECYZs4 for ; Wed, 7 Sep 2011 18:33:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7312D21F87F0 for ; Wed, 7 Sep 2011 18:33:22 -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 <0LR60028YKEOZC@szxga04-in.huawei.com> for paws@ietf.org; Thu, 08 Sep 2011 09:35:12 +0800 (CST) Received: from szxrg01-dlp.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 <0LR6002DNKEJR3@szxga04-in.huawei.com> for paws@ietf.org; Thu, 08 Sep 2011 09:35:12 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV97378; Thu, 08 Sep 2011 09:35:12 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 08 Sep 2011 09:35:06 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.189]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 08 Sep 2011 09:35:07 +0800 Date: Thu, 08 Sep 2011 01:35:06 +0000 From: ZhuLei In-reply-to: <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> X-Originating-IP: [10.108.64.160] To: Gerald Chouinard , "Gabor.Bajko@nokia.com" Message-id: <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [paws] combined problem statement, use cases & requirements Thread-index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> Cc: "paws@ietf.org" 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: Thu, 08 Sep 2011 01:33:24 -0000 SGkgYWxsLA0KDQpJIHRoaW5rIHRoYXQgd2UgZG8gc29tZSB3b3JrcyBvbiBpbXByb3Zpbmcgb3Jp Z2luYWwgdXNlIGNhc2UgZHJhZnQgYnkgYWRkaW5nIHRocmVlIGFkZGl0aW9uYWwgdXNlIGNhc2Vz LCBpbmNsdWRpbmcgaW5kb29yIGNvdmVyYWdlLCBhZCBob2MgbmV0d29yayBhbmQgbHRlIG1ibXMg aXNzdWUuDQoNCk5vdywgSSBhbSBhc2tpbmcgdG8gYWRkIGluZG9vciBjb3ZlcmFnZSBzY2VuYXJp byB3aGljaCBpcyBuZWNlc3NhcnkgZm9yIFBBV1MgcHJvdG9jb2wgdG8gY29uc2lkZXIgaW4gbmV4 dCBzdGFnZS4gVGhlIHByb3Bvc2VkIHVzZSBjYXNlIGlzIHNlZW4gYmVsb3cuIFRoZSB1cGRhdGVk IHZlcnNpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBiZSBzdWJtaXR0ZWQgc29vbiBieSBhZGRpbmcg c29tZSB3b3JkaW5nIG1vZGlmaWNhdGlvbnMuIFNvLCBJIGRvbid0IHRoaW5rIHdlIGFyZSB0byBz a2lwIHRoZSBhZGRpdGlvbmFsIHVzZSBjYXNlcyBldmVuIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwg dXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50IHByb3Bvc2FsIGhhdmUgYmVlbiBpbnRlZ3JhdGVkIG5v dy4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQp4LnguICBJbmRvb3IgdXNhZ2Ugb2YgVFZXUw0KDQogICBBdCBwcmVzZW50LCB0aGUgaW5k b29yIHdpcmVsZXNzIGNvdmVyYWdlIGVxdWlwbWVudHMgY29uc2lzdCBvZiBXaS1GaS0NCiAgIGxp a2UgYWNjZXNzIHBvaW50cyBhbmQgbWljcm8gY2VsbHMsIGFsbCBvZiB0aGVzZSB1dGlsaXplIHNl Z21lbnRzIG9mDQogICBmcmVxdWVuY3ksIGZvcm1lciBhdCBhYm91dCAyLjRHSHogb3IgNUdoeiBh bmQgdGhlIGxhdHRlciwgZm9yDQogICBleGFtcGxlLCA4MDIuMTFuIGF0IGFib3V0IDIuNEdIei4g IEFzIGEgcmVzdWx0IG9mIHRoZSBibG9jayBvZg0KICAgYnVpbGRpbmdzIGFuZCBvdGhlciBvYnN0 cnVjdGlvbiBhbmQgaW50ZXJmZXJlY2UsIGl0IG1heSBub3QgYmUgdGhhdA0KICAgb3B0aW1pc3Rp YyB3aGVuIDgwMi4xMSBkZXZpY2VzIGV4YW1pbmUgdGhlIHN0YXR1cyBvZiB3aXJlbGVzcw0KDQoN Cg0KWmh1ICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyLCAyMDEyICAgICAg ICAgICAgICAgIFtQYWdlIDNdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBQQVdT IHVzZSBjYXNlcyAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExDQoNCg0KICAgaW50ZXJmZXJl cy4gIFRoaXMgdXNlIGNhc2UgdGFrZXMgdGhlIGJlbmVmaXQgb2YgVFYgV2hpdGUgU3BhY2UgdG8N CiAgIHByb3ZpZGUgYWRkaXRpb25hbCBjYXBhY2l0eSB0byBpbmRvb3IgY292ZXJhZ2UgYW5kIHJl ZHVjZSBjaGFubmVsDQogICBpbnRlcmZlcmVjZS4NCg0KICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93 cyBhbiBleGFtcGxlIGRlcGxveW1lbnQgb2YgdGhpcyBzY2VuYXJpby4NCg0KICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCAg ICAgICAgICAgIGluZG9vciAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgIHdoaXRlIHNwYWNl ICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCAgICB8RGV2aWNlfCAt IC0gLSAtIC0gLSAtIC0gLSAtfC0gLXwgTWljcm8gY2VsbCAgfA0KICAgICAgICAgICAgICAgfCAg ICArLS0tLS0tKyAgXCAgICAgICAgICAgICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KICAgICAg ICAgICAgICAgfCAgICArLS0tLS0tKyAgIFx3aGl0ZSBzcGFjZSAgICAgfCAgICAgKC0tLS0tKQ0K ICAgICAgICAgICAgICAgfCAgICB8RGV2aWNlfCAgICBcICstLS0tLS0tLS0tLS0rfCAgICAvICAg ICAgIFwNCiAgICAgICAgICAgICAgIHwgICAgKy0tLS0tLSsgICAgICB8YWNjZXNzIHBvaW50fHw9 PT0oIEludGVybmV0KQ0KICAgICAgICAgICAgICAgfCAgICAgICAgbyAgICAgICAvICstLS0tLS0t LS0tLS0rfCAgICBcICAgICAgIC8NCiAgICAgICAgICAgICAgIHwgICAgICAgIG8gICAgICAvICAg ICAgICAgICAgICAgIHwgICAgICgtLS0tLSkNCiAgICAgICAgICAgICAgIHwgICAgICAgIG8gICAg IC8gICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCg0KDQogICAgICAgICAgICAgICAgICAgICAgIEdyYXBoIDEgSW5kb29yIHVzYWdl IG9mIFRWV1MNCg0KICAgVGhlIGFjY2VzcyBwb2ludCBjb3VsZCBiZSBhIFdJLUZJIHJvdXRlciwg YW5kIHRoZSBtaWNybyBjZWxsIGlzIGENCiAgIHNob3J0IHJhbmdlIHdpcmVsZXNzIGNvdmVyYWdl KGUuZy4gaW4gcmFuZ2Ugb2YgMC01MG0pIGJhc2Ugc3RhdGlvbiwNCiAgIGJvdGggb2YgdGhlbSBh Y3QgYXMgbWFzdGVyIGRldmljZXMsIHF1ZXJ5aW5nIHRoZSBpbnRlcm5ldCBjb25uZWN0ZWQNCiAg IGRhdGFiYXNlIGZvciBhdmFpbGFibGUgd2hpdGUgc3BhY2Ugc3BlY3RydW0gYmFzZWQgb24gaXRz IGdlby0NCiAgIGxvY2F0aW9uLCBhbmQgcHJvdmlkaW5nIFRWV1MgYWNjZXNzIHRvIGluZG9vciB1 c2VyLg0KDQogICBUaGUgVFZXUyBzcGVjdHJ1bSBoYXMgZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNo YXJhY3RlcmlzdGljcyBjb21wYXJlZA0KICAgdG8gaGlnaGVyIGZyZXF1ZW5jeSBiYW5kLCBmb3Ig ZXhhbXBsZSwgdGhlIHRyYW5zbWlzc2lvbiBkaXN0YW5jZQ0KICAgdXNpbmcgVFZXUyBjYW4gYmUg c2V2ZXJhbCB0aW1lcyBsb25nZXIgdGhhbiB0aG9zZSBpbiB0aGUgaGlnaGVyIGJhbmQuDQogICBJ biB0aGlzIGNhc2UsIGdvb2QgcGVuZXRyYXRpb24gY2hhcmFjdGVyaXN0aWMgb2YgVFZXUyBtYWtl cyBpdA0KICAgZGlmZmljdWx0IHRvIGxvY2sgdGhlIHNpZ25hbHMgaW4gdGhlIHJvb20sIHRoZW4g ZGlmZmljdWx0IHRvIGxvY2FsaXplDQogICBhbmQgZGlmZmVyZW50aWF0ZSBzaWduYWxzLCBhbmQg ZmluYWxseSBjYXVzZSBpbnRlcmZlcmVzIGFtb25nDQogICBuZWlnaGJvcmluZyBuZXR3b3Jrcy4g IFJlcXVpcmVtZW50cyB0byBpbmRvb3IgV1MgZGF0ZWJhc2UgdXNhZ2Ugd291bGQNCiAgIGJlOg0K DQoNCiAgIDEuICBBIGZyZXF1ZW5jeSBwcm90ZWN0aW9uIGdhcCBiZXR3ZWVuIG5laWdoYm9ycyhw YXJ0aWN1bGFyIHNwZWN0cnVtDQogICAgICAgYWxsb2NhdGlvbiBhbGdvcml0aG0gaXMgbmVlZGVk IGhlcmUpLg0KDQogICAyLiAgbG93ZXIgb3V0cHV0IHBvd2VyIG9mIEFQL21pY3JvIGNlbGwsIGl0 IHNlZW1zIHRoYXQgb25seSBjZXJ0YWluDQogICAgICAgcGljbyBvciBmZW10byBjZWxscyBiZSBm ZWFzaWJsZSBoZXJlLg0KDQogICAzLiAgUEFXUyBtdXN0IG5vdCBiZSB0aWVkIHRvIGEgc3BlY2lm aWMgZnJlcXVlbmN5IGJhbmQuDQoNCiAgIDQuICBQQVdTIG11c3QgcmVzcG9uc2UgdGhlIHByb3Bl ciBmcmVxdWVuY3kgYmFuZCBsaXN0IHRvIHBhcnRpY3VsYXINCiAgICAgICBjb3ZlcmFnZSB3aGl0 ZSBzcGFjZSBkZXZpY2VzLg0KDQogICA1LiAgTWFzdGVyIGRldmljZXMgc2hvdWxkIHN1cHBvcnQg cG93ZXIgY29udHJvbC4NCg0KICAgNi4gIFNsYXZlIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93 ZXIgY29udHJvbC4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNClpodSBMZWkNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog cGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IEdlcmFsZCBDaG91aW5hcmQNCreiy83KsbzkOiAyMDExxOo51MI4yNUgODowMQ0KytW8/sjLOiBH YWJvci5CYWprb0Bub2tpYS5jb20NCrOty806IHBhd3NAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbcGF3 c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cw0K DQpHYWJvciwNCg0KQ2FuIEkgYXNrIHRoYXQgdGhlIHRleHQgbW9kaWZpY2F0aW9ucyB0aGF0IEkg aGF2ZSBzdWJtaXR0ZWQgdG8gc2NvdHQgYW5kIA0KY29waWVkIHRvIHRoZSBwYXdzIHJlZmxlY3Rv ciBpbiBteSBlbWFpbCBkYXRlZCA4IEF1Z3VzdCBiZSBpbmNsdWRlZCBhcyB3ZWxsPw0KDQpUaGFu aydzLA0KDQpHZXJhbGQNCg0KDQpBdCAyMDozMiAwNy0wOS0xMSArMDAwMCwgR2Fib3IuQmFqa29A bm9raWEuY29tIHdyb3RlOg0KPk9rLCBsZXQncyB0cnkgdGhhdCB0aGVuLg0KPlNjb3R0LCBjYW4g eW91IHB1dCB1c2UgY2FzZXMgYmVmb3JlIFBTLCBhbmQgYWRkIHRoZSBhZC1ob2MgdXNlIGNhc2Uu IEkgDQo+anVzdCBzY2FubmVkIHRocm91Z2ggdGhlIGxpc3QgYW5kIHNwb3R0ZWQgdGhhdCBUZWNv IGluZGVlZCBwcm92aWRlZCBhIA0KPmRlc2NyaXB0aW9uIGZvciB0aGF0IHVzZSBjYXNlIG9uIEF1 ZyAzcmQuDQo+QW5kIHN1Ym1pdCB0aGUgZHJhZnQgYXMgYSB3ZyBpdGVtLCB1bmxlc3MgdGhlcmUg YXJlIHN0aWxsIG9iamVjdGlvbnMuDQo+DQo+LUdhYm9yDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBleHQgTmFuY3kgQnJhdmluIFttYWlsdG86bmJyYXZpbkBlYXJ0aGxp bmsubmV0XQ0KPlNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTEgMzo0MSBQTQ0KPlRv OiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+Q2M6IFRlY28gQm9vdDsg R2VyYWxkIENob3VpbmFyZDsgcGF3c0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcGF3c10gY29t YmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cw0KPg0KPkRl YXIgR2Fib3IgYW5kIEFsbCwNCj4NCj5JIHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRvIHB1dCB0 aGUgdXNlIGNhc2VzIGJlZm9yZSB0aGUgUFMgZm9yIG9idmlvdXMgDQo+cmVhc29ucywgYW5kIGlu Y2x1ZGluZyB0aGUgInByb3h5IiBuZWVkIGluIHRoZSBmaXJzdCBkcmFmdC4gSSBzdXBwb3J0IA0K PmluY2x1ZGluZyBib3RoIEdlcmFsZCdzIHN1Z2dlc3Rpb25zIGFuZCBUZWNvJ3MgcHJvcG9zYWwg aW4gdGhlIG9yaWdpbmFsIA0KPmRyYWZ0IGFuZCBub3Qgd2FpdGluZyB1bnRpbCBhIGxhdGVyIHRp bWUuIEl0IGlzIHRoZSBwcm9wZXIgb3JkZXIsIA0KPmluY2x1c2l2ZSBhbmQgbmVlZGVkIGluIHRo ZSBpbml0aWFsIGRyYWZ0IGluIG15IG9waW5pb24uIEkgYmVsaWV2ZSB3aXRoIA0KPnRoZSB0YWxl bnQgaW4gdGhlIGdyb3VwIGl0IHdpbGwgbm90IHRha2UgbG9uZyB0byBhY2NvbXBsaXNoIHRoaXMg YW5kIHlvdSANCj53aWxsIGhhdmUgYSBtb3JlIGNvaGVzaXZlIGRyYWZ0Lg0KPg0KPlNJbmNlcmVs eSwgTmFuY3kNCj4NCj4NCj5PbiBTZXAgMiwgMjAxMSwgYXQgMjoxOSBQTSwgPEdhYm9yLkJhamtv QG5va2lhLmNvbT4gDQo+PEdhYm9yLkJhamtvQG5va2lhLmNvbT4gd3JvdGU6DQo+DQo+ID4gVGVj bywgR2VyYWxkLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suIEknZCBzdWdnZXN0 IHRoYXQgd2UgbWFrZSB0aGlzIGRyYWZ0IGEgV0cgaXRlbSwgDQo+IHdpdGggR2VyYWxkJ3MgcHJv cG9zZWQgY2hhbmdlcyBpbiBpdC4gUmVnYXJkaW5nIHRoZSBvcmRlciBvZiB0aGUgcHJvYmxlbSAN Cj4gc3RhdGVtZW50IHZzIHVzZSBjYXNlcywgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBsZWF2 ZSBpdCBhcyBpdCBpcyAoYnV0IA0KPiB3ZSBjYW4gYWx3YXlzIGNoYW5nZSBpdCwgaWYgdGhhdCBp cyB3aGF0IHRoZSBXRyB3YW50cykuDQo+ID4NCj4gPiBTbywgSSdkIGFzayBTY290dCB0byBzdWJt aXQgYSBXRyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQsIHRoZW4gaGF2ZSANCj4gc29tZW9uZSBjb21l IHVwIHdpdGggdGV4dCBmb3IgdGhpcyBhZC1ob2MgbmV0d29yayBzY2VuYXJpbywgaGF2ZSB0aGUg V0cgDQo+IGFncmVlIHdpdGggdGhlIHRleHQgYW5kIGluY2x1ZGUgaXQgaW4gb25lIG9mIHRoZSBz dWJzZXF1ZW50IHZlcnNpb25zLiANCj4gVGVjbywgd291bGQgeW91IHdyaXRlIHVwIHNvbWUgdGV4 dCBmb3IgdGhpcyBhZC1ob2MgdXNlIGNhc2UgdGhlIFdHIGNvdWxkIA0KPiBkaXNjdXNzPw0KPiA+ DQo+ID4gV2UnbGwgYWxzbyBzZW5kIGFuIGluaXRpYWwgdmVyc2lvbiBvZiBhIGxpc3Qgb2YgcmVx dWlyZW1lbnRzIHRvIHRoZSANCj4gbGlzdCBuZXh0IHdlZWsuDQo+ID4NCj4gPiAtIEdhYm9yDQo+ ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZXh0IFRl Y28gQm9vdCBbbWFpbHRvOnRlY29AaW5mLW5ldC5ubF0NCj4gPiBTZW50OiBUaHVyc2RheSwgU2Vw dGVtYmVyIDAxLCAyMDExIDExOjA2IFBNDQo+ID4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMv U2lsaWNvblZhbGxleSkNCj4gPiBDYzogcGF3c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBb cGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+ID4gcmVxdWly ZW1lbnRzDQo+ID4NCj4gPiBJIHRoaW5rIHRoZSBkb2MgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50 LiBJIHN1cHBvcnQgYWRvcHRpb24uDQo+ID4NCj4gPiBJIHN1Z2dlc3QgcmVvcmRlcmluZzogc3Bl Y2lmeWluZyBwcm9ibGVtIHN0YXRlbWVudCBhZnRlciBpbnRyb2R1Y2luZyANCj4gdGhlIHVzZSBj YXNlcy4NCj4gPg0KPiA+IFNvbWUgYXNrZWQgZm9yIHRoZSBhZCBob2MgbmV0d29yayBzY2VuYXJp by4gVGhpcyBpbmNsdWRlcyBtZSA6LSkuIFRoaXMgDQo+IGlzIGltcG9ydGFudCwgYmVjYXVzZSBp dCBkZW1vbnN0cmF0ZXMgdGhlIG5lZWQgZm9yICJwcm94eSIuDQo+ID4gQlRXLCBJIHdvbmRlciB3 aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0IHBvcCB1cCBmcm9tIFdpRmkgDQo+IGRlcGxveW1l bnRzLiBVc2FnZSBvZiBjb250cm9sbGVycyBpbiBsYXJnZSBzaXRlcyBpcyBub3QgdW5jb21tb24u IE5vdCB0byANCj4gbWVudGlvbiAxMXMuDQo+ID4NCj4gPiBUaGUgcmVxdWlyZW1lbnRzIGlzIGxl ZnQgb3Blbi4gSSdtIGxvb2tpbmcgZm9yd2FyZCBzZWUgc29tZSBkcmFmdCB0ZXh0Lg0KPiA+DQo+ ID4gVGhhbmtzLCBUZWNvDQo+ID4NCj4gPg0KPiA+IE9wIDMwIGF1ZyAyMDExLCBvbSAxOTo0MiBo ZWVmdCA8R2Fib3IuQmFqa29Abm9raWEuY29tPiANCj4gPEdhYm9yLkJhamtvQG5va2lhLmNvbT4g aGV0IHZvbGdlbmRlIGdlc2NocmV2ZW46DQo+ID4NCj4gPj4gSSBzZW50IHRoaXMgZW1haWwgdG8g dGhlIGxpc3Qgb25lIHdlZWsgYWdvLCBhc2tpbmcgZm9yIGZlZWRiYWNrIG9uDQo+ID4+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2Fz ZXMtcnFtdA0KPiA+PiBzIC0wMC50eHQgYnV0IHRoZXJlIHdhcyBub3Qgb25lIGZlZWRiYWNrIHJl Y2VpdmVkLiBJIHRha2UgdGhhdCBhcw0KPiA+PiBwZW9wbGUgaGF2ZSBubyBjb21tZW50cyB0byB0 aGUgZHJhZnQgYXQgdGhpcyB0aW1lLg0KPiA+Pg0KPiA+PiBBbmQgSSBhbSBhc2tpbmcgYWdhaW46 IGlzIHRoZXJlIGFueSBvYmplY3Rpb24gaW4gYWRvcHRpbmcgdGhlIGFib3ZlIA0KPiBkcmFmdCBh cyBhIHdnIGRvY3VtZW50Pw0KPiA+Pg0KPiA+PiAtR2Fib3INCj4gPj4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPj4gT2YgZXh0IEdhYm9yLkJh amtvQG5va2lhLmNvbQ0KPiA+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSAyOjQzIFBN DQo+ID4+IFRvOiBwYXdzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmlu ZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+ID4+IHJlcXVpcmVtZW50cw0KPiA+ Pg0KPiA+PiBEdXJpbmcgdGhlIFF1ZWJlYyBzZXNzaW9uLCB3ZSBoYWQgcHJlc2VudGF0aW9ucyBv ZiB0aGUgUFMgYW5kIHRoZSB1c2UgDQo+IGNhc2VzIGRyYWZ0cy4gVGhlIHdnIHRoZW4gZGVjaWRl ZCBpdCB3YW50cyB0byBzZWUgdGhlc2UgZHJhZnRzIG1lcmdlZCANCj4gaW50byBvbmUuIFNjb3R0 IGp1c3QgZGlkIHRoYXQgYW5kIHBvc3RlZCB0aGUgbWVyZ2VkIGRyYWZ0Og0KPiA+PiBodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2Vz LXJxbXQNCj4gPj4gcw0KPiA+PiAtMDAudHh0DQo+ID4+DQo+ID4+IE5vdyBJIHdvdWxkIGxpa2Ug dG8gYXNrIGlmIHRoZSB3ZyBmZWVscyBsaWtlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gDQo+ IGJlIGFkb3B0ZWQgYXMgYSB3ZyBkb2N1bWVudC4gUGxlYXNlIHNlbmQgeW91ciBmZWVkYmFjayBh bmQgaHVtIHRvIHRoZSANCj4gbGlzdCBieSB0aGlzIHRpbWUgbmV4dCB3ZWVrLg0KPiA+Pg0KPiA+ PiAtR2Fib3INCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IEZyb206IFByb2Jhc2NvIFNjb3R0DQo+ID4+ IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDExIDk6MTggQU0NCj4gPj4gVG86IHBhd3NAaWV0 Zi5vcmcNCj4gPj4gU3ViamVjdDogY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNl cyAmIHJlcXVpcmVtZW50cw0KPiA+Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gQWNjb3JkaW5nIHRv IHRoZSByZXN1bHRzIG9mIHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZywgd2UgaGF2ZSBjb21iaW5l ZCANCj4gdGhlIHByb2JsZW0gc3RhdGVtZW50IEktRCBhbmQgdXNlIGNhc2UgJiByZXF1aXJlbWVu dCBJLUQgaW50byBhIHNpbmdsZSANCj4gSS1ELiAgWW91ciBjb21tZW50cyBhcmUgd2VsY29tZWQu DQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IFNjb3R0DQo+ID4+DQo+ID4+IFVSTDoNCj4gPj4g aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2JsZW0tc3RtdC11 c2VjYXNlcy1ycW10DQo+ID4+IHMNCj4gPj4gLTAwLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBYnN0 cmFjdDoNCj4gPj4gUG9ydGlvbnMgb2YgdGhlIHJhZGlvIHNwZWN0cnVtIHRoYXQgYXJlIGFsbG9j YXRlZCB0byBhIGxpY2Vuc2VkLA0KPiA+PiBwcmltYXJ5IHVzZXIgYnV0IGFyZSB1bnVzZWQgb3Ig dW5vY2N1cGllZCBhdCBzcGVjaWZpYyBsb2NhdGlvbnMgYW5kDQo+ID4+IHRpbWVzIGFyZSBkZWZp bmVkIGFzICd3aGl0ZSBzcGFjZScuICBUaGUgY29uY2VwdCBvZiBhbGxvd2luZw0KPiA+PiBzZWNv bmRhcnkgdHJhbnNtaXNzaW9ucyAobGljZW5zZWQgb3IgdW5saWNlbnNlZCkgaW4gd2hpdGUgc3Bh Y2UgaXMgYQ0KPiA+PiB0ZWNobmlxdWUgdG8gJ3VubG9jaycgZXhpc3Rpbmcgc3BlY3RydW0gZm9y IG5ldyB1c2UuICBBbiBvYnZpb3VzDQo+ID4+IHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlc2Ugc2Vj b25kYXJ5IHRyYW5zbWlzc2lvbnMgZG8gbm90IGludGVyZmVyZQ0KPiA+PiB3aXRoIHRoZSBwcmlt YXJ5IHVzZSBvZiB0aGUgc3BlY3RydW0uICBPbmUgYXBwcm9hY2ggdG8gdXNpbmcgdGhlDQo+ID4+ IHdoaXRlIHNwYWNlIHNwZWN0cnVtIGF0IGEgZ2l2ZW4gdGltZSBhbmQgbG9jYXRpb24gaXMgdG8g dmVyaWZ5IHdpdGggYQ0KPiA+PiBkYXRhYmFzZSBhdmFpbGFibGUgY2hhbm5lbHMuDQo+ID4+DQo+ ID4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBjb25jZXB0IG9mIFRWIFdoaXRlIFNwYWNl cy4gIEl0IGFsc28NCj4gPj4gZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyB0aGF0IG5lZWQgdG8gYmUg YWRkcmVzc2VkIGZvciBlbmFibGluZyB0aGUgdXNlDQo+ID4+IG9mIHRoZSBwcmltYXJ5IHVzZXIg b3duZWQgd2hpdGUgc3BhY2Ugc3BlY3RydW0gZm9yIHNlY29uZGFyeSB1c2VycywNCj4gPj4gd2l0 aG91dCBjYXVzaW5nIGludGVyZmVyZW5jZSwgYnkgcXVlcnlpbmcgYSBkYXRhYmFzZSB3aGljaCBr bm93cyB0aGUNCj4gPj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgYXQgYW55IGdpdmVuIGxvY2F0aW9u IGFuZCB0aW1lLiAgQSBudW1iZXIgb2YNCj4gPj4gcG9zc2libGUgdXNlIGNhc2VzIG9mIHRoaXMg c3BlY3RydW0gYW5kIGRlcml2ZWQgcmVxdWlyZW1lbnRzIGFyZSBhbHNvDQo+ID4+IGRlc2NyaWJl ZC4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPj4gcGF3c0BpZXRmLm9yZw0KPiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gcGF3cyBtYWlsaW5n IGxpc3QNCj4gPj4gcGF3c0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPiBwYXdzQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBt YWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0K From Gabor.Bajko@nokia.com Wed Sep 7 21:43:54 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 B303C21F8BAE for ; Wed, 7 Sep 2011 21:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-1.921, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 lFXjj8UBEo3Y for ; Wed, 7 Sep 2011 21:43:53 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8A04221F8B80 for ; Wed, 7 Sep 2011 21:43:53 -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 p884iSe5023652; Thu, 8 Sep 2011 07:45:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 07:44:29 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 06:44:28 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.245]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Thu, 8 Sep 2011 06:44:27 +0200 From: To: Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVJUpXkBwgAxXBHCAA9RNgIABHcBggAGKfgCABoExof//+L0AgABTstA= Date: Thu, 8 Sep 2011 04:44:27 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760FA660@008-AM1MPN1-007.mgdnok.nokia.com> References: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.106.191] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 04:44:29.0095 (UTC) FILETIME=[FE737370:01CC6DE1] X-Nokia-AV: Clean Cc: paws@ietf.org 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: Thu, 08 Sep 2011 04:43:54 -0000 Wmh1IExlaSwNCg0KVGhlIGNoYXJ0ZXIgZXhwbGljaXRseSBzdGF0ZXMgdGhhdCBQQVdTIGlzIHRv IGJlIGtlcHQgdGVjaG5vbG9neSBhZ25vc3RpYy4gVGh1cywgbHRlIG1ibXMgdXNlIGNhc2UgaXMg b3V0IG9mIHF1ZXN0aW9uLiBXZSBqdXN0IGFncmVlZCB0byBhZGQgYW4gYWQtaG9jIG5ldHdvcmsg dXNlIGNhc2UsIGFuZCB0aGUgLTAwIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFscmVhZHkgaGFzIGEg bG9jYXRpb24gYmFzZWQgc2VydmljZSB1c2UgY2FzZSBzY2VuYXJpbyB3aGljaCBsb29rcyB0byBt ZSB0byBiZSBhIHN1cGVyc2V0IG9mIHRoZSB1c2UgY2FzZSB5b3UgcHJvdmlkZWQgYmVsb3cgKGlm IEkgdW5kZXJzdG9vZCB5b3VyIHVzZSBjYXNlIGNvcnJlY3RseSkuDQoNCkJ1dCBJIGRvIG5vdCB3 YW50IHRvIHNwZWFrIGluIHRoZSBuYW1lIG9mIHRoZSBlZGl0b3IuIEN1cnJlbnRseSB0aGUgZHJh ZnQgaXMgc3RpbGwgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uLCBzbyBpdCBpcyB1cCB0byB0aGUg ZWRpdG9yIHRvIGluY29ycG9yYXRlIGFueSBzdWdnZXN0aW9uIGZyb20gdGhlIGxpc3QgdG8gaXRz IG93biBkcmFmdC4gVGhpcyB3b3VsZCBjaGFuZ2Ugb25jZSB0aGUgZHJhZnQgaXMgbWFkZSBhIHdn IGl0ZW0uIFRoZXJlZm9yZSwgSSdkIHByb3Bvc2Ugd2UgbWFrZSB0aGlzIGRyYWZ0IGEgd2cgaXRl bS4NCg0KLUdhYm9yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgWmh1 TGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVt YmVyIDA3LCAyMDExIDY6MzUgUE0NClRvOiBHZXJhbGQgQ2hvdWluYXJkOyBCYWprbyBHYWJvciAo Tm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQpDYzogcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWlyZW1l bnRzDQoNCkhpIGFsbCwNCg0KSSB0aGluayB0aGF0IHdlIGRvIHNvbWUgd29ya3Mgb24gaW1wcm92 aW5nIG9yaWdpbmFsIHVzZSBjYXNlIGRyYWZ0IGJ5IGFkZGluZyB0aHJlZSBhZGRpdGlvbmFsIHVz ZSBjYXNlcywgaW5jbHVkaW5nIGluZG9vciBjb3ZlcmFnZSwgYWQgaG9jIG5ldHdvcmsgYW5kIGx0 ZSBtYm1zIGlzc3VlLg0KDQpOb3csIEkgYW0gYXNraW5nIHRvIGFkZCBpbmRvb3IgY292ZXJhZ2Ug c2NlbmFyaW8gd2hpY2ggaXMgbmVjZXNzYXJ5IGZvciBQQVdTIHByb3RvY29sIHRvIGNvbnNpZGVy IGluIG5leHQgc3RhZ2UuIFRoZSBwcm9wb3NlZCB1c2UgY2FzZSBpcyBzZWVuIGJlbG93LiBUaGUg dXBkYXRlZCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gYmUgc3VibWl0dGVkIHNvb24gYnkg YWRkaW5nIHNvbWUgd29yZGluZyBtb2RpZmljYXRpb25zLiBTbywgSSBkb24ndCB0aGluayB3ZSBh cmUgdG8gc2tpcCB0aGUgYWRkaXRpb25hbCB1c2UgY2FzZXMgZXZlbiB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQsIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudCBwcm9wb3NhbCBoYXZlIGJlZW4gaW50ZWdy YXRlZCBub3cuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KeC54LiAgSW5kb29yIHVzYWdlIG9mIFRWV1MNCg0KICAgQXQgcHJlc2VudCwg dGhlIGluZG9vciB3aXJlbGVzcyBjb3ZlcmFnZSBlcXVpcG1lbnRzIGNvbnNpc3Qgb2YgV2ktRmkt DQogICBsaWtlIGFjY2VzcyBwb2ludHMgYW5kIG1pY3JvIGNlbGxzLCBhbGwgb2YgdGhlc2UgdXRp bGl6ZSBzZWdtZW50cyBvZg0KICAgZnJlcXVlbmN5LCBmb3JtZXIgYXQgYWJvdXQgMi40R0h6IG9y IDVHaHogYW5kIHRoZSBsYXR0ZXIsIGZvcg0KICAgZXhhbXBsZSwgODAyLjExbiBhdCBhYm91dCAy LjRHSHouICBBcyBhIHJlc3VsdCBvZiB0aGUgYmxvY2sgb2YNCiAgIGJ1aWxkaW5ncyBhbmQgb3Ro ZXIgb2JzdHJ1Y3Rpb24gYW5kIGludGVyZmVyZWNlLCBpdCBtYXkgbm90IGJlIHRoYXQNCiAgIG9w dGltaXN0aWMgd2hlbiA4MDIuMTEgZGV2aWNlcyBleGFtaW5lIHRoZSBzdGF0dXMgb2Ygd2lyZWxl c3MNCg0KDQoNClpodSAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAx MiAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgUEFXUyB1c2UgY2FzZXMgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMQ0KDQoNCiAgIGlu dGVyZmVyZXMuICBUaGlzIHVzZSBjYXNlIHRha2VzIHRoZSBiZW5lZml0IG9mIFRWIFdoaXRlIFNw YWNlIHRvDQogICBwcm92aWRlIGFkZGl0aW9uYWwgY2FwYWNpdHkgdG8gaW5kb29yIGNvdmVyYWdl IGFuZCByZWR1Y2UgY2hhbm5lbA0KICAgaW50ZXJmZXJlY2UuDQoNCiAgIFRoZSBmaWd1cmUgYmVs b3cgc2hvd3MgYW4gZXhhbXBsZSBkZXBsb3ltZW50IG9mIHRoaXMgc2NlbmFyaW8uDQoNCiAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICAgIHwgICAgICAgICAgICBpbmRvb3IgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgKy0tLS0tLSsgICB3aGl0 ZSBzcGFjZSAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgfERl dmljZXwgLSAtIC0gLSAtIC0gLSAtIC0gLXwtIC18IE1pY3JvIGNlbGwgIHwNCiAgICAgICAgICAg ICAgIHwgICAgKy0tLS0tLSsgIFwgICAgICAgICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICAgIHwgICAgKy0tLS0tLSsgICBcd2hpdGUgc3BhY2UgICAgIHwgICAgICgt LS0tLSkNCiAgICAgICAgICAgICAgIHwgICAgfERldmljZXwgICAgXCArLS0tLS0tLS0tLS0tK3wg ICAgLyAgICAgICBcDQogICAgICAgICAgICAgICB8ICAgICstLS0tLS0rICAgICAgfGFjY2VzcyBw b2ludHx8PT09KCBJbnRlcm5ldCkNCiAgICAgICAgICAgICAgIHwgICAgICAgIG8gICAgICAgLyAr LS0tLS0tLS0tLS0tK3wgICAgXCAgICAgICAvDQogICAgICAgICAgICAgICB8ICAgICAgICBvICAg ICAgLyAgICAgICAgICAgICAgICB8ICAgICAoLS0tLS0pDQogICAgICAgICAgICAgICB8ICAgICAg ICBvICAgICAvICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICBHcmFwaCAxIEluZG9v ciB1c2FnZSBvZiBUVldTDQoNCiAgIFRoZSBhY2Nlc3MgcG9pbnQgY291bGQgYmUgYSBXSS1GSSBy b3V0ZXIsIGFuZCB0aGUgbWljcm8gY2VsbCBpcyBhDQogICBzaG9ydCByYW5nZSB3aXJlbGVzcyBj b3ZlcmFnZShlLmcuIGluIHJhbmdlIG9mIDAtNTBtKSBiYXNlIHN0YXRpb24sDQogICBib3RoIG9m IHRoZW0gYWN0IGFzIG1hc3RlciBkZXZpY2VzLCBxdWVyeWluZyB0aGUgaW50ZXJuZXQgY29ubmVj dGVkDQogICBkYXRhYmFzZSBmb3IgYXZhaWxhYmxlIHdoaXRlIHNwYWNlIHNwZWN0cnVtIGJhc2Vk IG9uIGl0cyBnZW8tDQogICBsb2NhdGlvbiwgYW5kIHByb3ZpZGluZyBUVldTIGFjY2VzcyB0byBp bmRvb3IgdXNlci4NCg0KICAgVGhlIFRWV1Mgc3BlY3RydW0gaGFzIGRpZmZlcmVudCBwcm9wYWdh dGlvbiBjaGFyYWN0ZXJpc3RpY3MgY29tcGFyZWQNCiAgIHRvIGhpZ2hlciBmcmVxdWVuY3kgYmFu ZCwgZm9yIGV4YW1wbGUsIHRoZSB0cmFuc21pc3Npb24gZGlzdGFuY2UNCiAgIHVzaW5nIFRWV1Mg Y2FuIGJlIHNldmVyYWwgdGltZXMgbG9uZ2VyIHRoYW4gdGhvc2UgaW4gdGhlIGhpZ2hlciBiYW5k Lg0KICAgSW4gdGhpcyBjYXNlLCBnb29kIHBlbmV0cmF0aW9uIGNoYXJhY3RlcmlzdGljIG9mIFRW V1MgbWFrZXMgaXQNCiAgIGRpZmZpY3VsdCB0byBsb2NrIHRoZSBzaWduYWxzIGluIHRoZSByb29t LCB0aGVuIGRpZmZpY3VsdCB0byBsb2NhbGl6ZQ0KICAgYW5kIGRpZmZlcmVudGlhdGUgc2lnbmFs cywgYW5kIGZpbmFsbHkgY2F1c2UgaW50ZXJmZXJlcyBhbW9uZw0KICAgbmVpZ2hib3JpbmcgbmV0 d29ya3MuICBSZXF1aXJlbWVudHMgdG8gaW5kb29yIFdTIGRhdGViYXNlIHVzYWdlIHdvdWxkDQog ICBiZToNCg0KDQogICAxLiAgQSBmcmVxdWVuY3kgcHJvdGVjdGlvbiBnYXAgYmV0d2VlbiBuZWln aGJvcnMocGFydGljdWxhciBzcGVjdHJ1bQ0KICAgICAgIGFsbG9jYXRpb24gYWxnb3JpdGhtIGlz IG5lZWRlZCBoZXJlKS4NCg0KICAgMi4gIGxvd2VyIG91dHB1dCBwb3dlciBvZiBBUC9taWNybyBj ZWxsLCBpdCBzZWVtcyB0aGF0IG9ubHkgY2VydGFpbg0KICAgICAgIHBpY28gb3IgZmVtdG8gY2Vs bHMgYmUgZmVhc2libGUgaGVyZS4NCg0KICAgMy4gIFBBV1MgbXVzdCBub3QgYmUgdGllZCB0byBh IHNwZWNpZmljIGZyZXF1ZW5jeSBiYW5kLg0KDQogICA0LiAgUEFXUyBtdXN0IHJlc3BvbnNlIHRo ZSBwcm9wZXIgZnJlcXVlbmN5IGJhbmQgbGlzdCB0byBwYXJ0aWN1bGFyDQogICAgICAgY292ZXJh Z2Ugd2hpdGUgc3BhY2UgZGV2aWNlcy4NCg0KICAgNS4gIE1hc3RlciBkZXZpY2VzIHNob3VsZCBz dXBwb3J0IHBvd2VyIGNvbnRyb2wuDQoNCiAgIDYuICBTbGF2ZSBkZXZpY2VzIHNob3VsZCBzdXBw b3J0IHBvd2VyIGNvbnRyb2wuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQpaaHUgTGVpDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3 orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBHZXJhbGQgQ2hvdWluYXJkDQq3osvNyrG85DogMjAxMcTqOdTCOMjVIDg6MDENCsrV vP7IyzogR2Fib3IuQmFqa29Abm9raWEuY29tDQqzrcvNOiBwYXdzQGlldGYub3JnDQrW98ziOiBS ZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJl bWVudHMNCg0KR2Fib3IsDQoNCkNhbiBJIGFzayB0aGF0IHRoZSB0ZXh0IG1vZGlmaWNhdGlvbnMg dGhhdCBJIGhhdmUgc3VibWl0dGVkIHRvIHNjb3R0IGFuZCBjb3BpZWQgdG8gdGhlIHBhd3MgcmVm bGVjdG9yIGluIG15IGVtYWlsIGRhdGVkIDggQXVndXN0IGJlIGluY2x1ZGVkIGFzIHdlbGw/DQoN ClRoYW5rJ3MsDQoNCkdlcmFsZA0KDQoNCkF0IDIwOjMyIDA3LTA5LTExICswMDAwLCBHYWJvci5C YWprb0Bub2tpYS5jb20gd3JvdGU6DQo+T2ssIGxldCdzIHRyeSB0aGF0IHRoZW4uDQo+U2NvdHQs IGNhbiB5b3UgcHV0IHVzZSBjYXNlcyBiZWZvcmUgUFMsIGFuZCBhZGQgdGhlIGFkLWhvYyB1c2Ug Y2FzZS4gSSANCj5qdXN0IHNjYW5uZWQgdGhyb3VnaCB0aGUgbGlzdCBhbmQgc3BvdHRlZCB0aGF0 IFRlY28gaW5kZWVkIHByb3ZpZGVkIGEgDQo+ZGVzY3JpcHRpb24gZm9yIHRoYXQgdXNlIGNhc2Ug b24gQXVnIDNyZC4NCj5BbmQgc3VibWl0IHRoZSBkcmFmdCBhcyBhIHdnIGl0ZW0sIHVubGVzcyB0 aGVyZSBhcmUgc3RpbGwgb2JqZWN0aW9ucy4NCj4NCj4tR2Fib3INCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IGV4dCBOYW5jeSBCcmF2aW4gW21haWx0bzpuYnJhdmluQGVh cnRobGluay5uZXRdDQo+U2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAwMywgMjAxMSAzOjQxIFBN DQo+VG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNCj5DYzogVGVjbyBC b290OyBHZXJhbGQgQ2hvdWluYXJkOyBwYXdzQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtwYXdz XSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgDQo+cmVxdWlyZW1lbnRz DQo+DQo+RGVhciBHYWJvciBhbmQgQWxsLA0KPg0KPkkgdGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUg dG8gcHV0IHRoZSB1c2UgY2FzZXMgYmVmb3JlIHRoZSBQUyBmb3IgDQo+b2J2aW91cyByZWFzb25z LCBhbmQgaW5jbHVkaW5nIHRoZSAicHJveHkiIG5lZWQgaW4gdGhlIGZpcnN0IGRyYWZ0LiBJIA0K PnN1cHBvcnQgaW5jbHVkaW5nIGJvdGggR2VyYWxkJ3Mgc3VnZ2VzdGlvbnMgYW5kIFRlY28ncyBw cm9wb3NhbCBpbiB0aGUgDQo+b3JpZ2luYWwgZHJhZnQgYW5kIG5vdCB3YWl0aW5nIHVudGlsIGEg bGF0ZXIgdGltZS4gSXQgaXMgdGhlIHByb3BlciANCj5vcmRlciwgaW5jbHVzaXZlIGFuZCBuZWVk ZWQgaW4gdGhlIGluaXRpYWwgZHJhZnQgaW4gbXkgb3Bpbmlvbi4gSSANCj5iZWxpZXZlIHdpdGgg dGhlIHRhbGVudCBpbiB0aGUgZ3JvdXAgaXQgd2lsbCBub3QgdGFrZSBsb25nIHRvIA0KPmFjY29t cGxpc2ggdGhpcyBhbmQgeW91IHdpbGwgaGF2ZSBhIG1vcmUgY29oZXNpdmUgZHJhZnQuDQo+DQo+ U0luY2VyZWx5LCBOYW5jeQ0KPg0KPg0KPk9uIFNlcCAyLCAyMDExLCBhdCAyOjE5IFBNLCA8R2Fi b3IuQmFqa29Abm9raWEuY29tPiANCj48R2Fib3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToNCj4N Cj4gPiBUZWNvLCBHZXJhbGQsDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gSSdk IHN1Z2dlc3QgdGhhdCB3ZSBtYWtlIHRoaXMgZHJhZnQgYSBXRyANCj4gPiBpdGVtLA0KPiB3aXRo IEdlcmFsZCdzIHByb3Bvc2VkIGNoYW5nZXMgaW4gaXQuIFJlZ2FyZGluZyB0aGUgb3JkZXIgb2Yg dGhlIA0KPiBwcm9ibGVtIHN0YXRlbWVudCB2cyB1c2UgY2FzZXMsIG15IHByZWZlcmVuY2Ugd291 bGQgYmUgdG8gbGVhdmUgaXQgYXMgDQo+IGl0IGlzIChidXQgd2UgY2FuIGFsd2F5cyBjaGFuZ2Ug aXQsIGlmIHRoYXQgaXMgd2hhdCB0aGUgV0cgd2FudHMpLg0KPiA+DQo+ID4gU28sIEknZCBhc2sg U2NvdHQgdG8gc3VibWl0IGEgV0cgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0LCB0aGVuIGhhdmUNCj4g c29tZW9uZSBjb21lIHVwIHdpdGggdGV4dCBmb3IgdGhpcyBhZC1ob2MgbmV0d29yayBzY2VuYXJp bywgaGF2ZSB0aGUgDQo+IFdHIGFncmVlIHdpdGggdGhlIHRleHQgYW5kIGluY2x1ZGUgaXQgaW4g b25lIG9mIHRoZSBzdWJzZXF1ZW50IHZlcnNpb25zLg0KPiBUZWNvLCB3b3VsZCB5b3Ugd3JpdGUg dXAgc29tZSB0ZXh0IGZvciB0aGlzIGFkLWhvYyB1c2UgY2FzZSB0aGUgV0cgDQo+IGNvdWxkIGRp c2N1c3M/DQo+ID4NCj4gPiBXZSdsbCBhbHNvIHNlbmQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEg bGlzdCBvZiByZXF1aXJlbWVudHMgdG8gdGhlDQo+IGxpc3QgbmV4dCB3ZWVrLg0KPiA+DQo+ID4g LSBHYWJvcg0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IGV4dCBUZWNvIEJvb3QgW21haWx0bzp0ZWNvQGluZi1uZXQubmxdDQo+ID4gU2VudDogVGh1 cnNkYXksIFNlcHRlbWJlciAwMSwgMjAxMSAxMTowNiBQTQ0KPiA+IFRvOiBCYWprbyBHYWJvciAo Tm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+ID4gQ2M6IHBhd3NAaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiAN Cj4gPiByZXF1aXJlbWVudHMNCj4gPg0KPiA+IEkgdGhpbmsgdGhlIGRvYyBpcyBhIGdvb2Qgc3Rh cnRpbmcgcG9pbnQuIEkgc3VwcG9ydCBhZG9wdGlvbi4NCj4gPg0KPiA+IEkgc3VnZ2VzdCByZW9y ZGVyaW5nOiBzcGVjaWZ5aW5nIHByb2JsZW0gc3RhdGVtZW50IGFmdGVyIGludHJvZHVjaW5nDQo+ IHRoZSB1c2UgY2FzZXMuDQo+ID4NCj4gPiBTb21lIGFza2VkIGZvciB0aGUgYWQgaG9jIG5ldHdv cmsgc2NlbmFyaW8uIFRoaXMgaW5jbHVkZXMgbWUgOi0pLiANCj4gPiBUaGlzDQo+IGlzIGltcG9y dGFudCwgYmVjYXVzZSBpdCBkZW1vbnN0cmF0ZXMgdGhlIG5lZWQgZm9yICJwcm94eSIuDQo+ID4g QlRXLCBJIHdvbmRlciB3aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0IHBvcCB1cCBmcm9tIFdp RmkNCj4gZGVwbG95bWVudHMuIFVzYWdlIG9mIGNvbnRyb2xsZXJzIGluIGxhcmdlIHNpdGVzIGlz IG5vdCB1bmNvbW1vbi4gTm90IA0KPiB0byBtZW50aW9uIDExcy4NCj4gPg0KPiA+IFRoZSByZXF1 aXJlbWVudHMgaXMgbGVmdCBvcGVuLiBJJ20gbG9va2luZyBmb3J3YXJkIHNlZSBzb21lIGRyYWZ0 IHRleHQuDQo+ID4NCj4gPiBUaGFua3MsIFRlY28NCj4gPg0KPiA+DQo+ID4gT3AgMzAgYXVnIDIw MTEsIG9tIDE5OjQyIGhlZWZ0IDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+IDxHYWJvci5CYWpr b0Bub2tpYS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPiA+DQo+ID4+IEkgc2VudCB0 aGlzIGVtYWlsIHRvIHRoZSBsaXN0IG9uZSB3ZWVrIGFnbywgYXNraW5nIGZvciBmZWVkYmFjayBv biANCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2Js ZW0tc3RtdC11c2VjYXNlcy1ycQ0KPiA+PiBtdCBzIC0wMC50eHQgYnV0IHRoZXJlIHdhcyBub3Qg b25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJIHRha2UgdGhhdCANCj4gPj4gYXMgcGVvcGxlIGhhdmUg bm8gY29tbWVudHMgdG8gdGhlIGRyYWZ0IGF0IHRoaXMgdGltZS4NCj4gPj4NCj4gPj4gQW5kIEkg YW0gYXNraW5nIGFnYWluOiBpcyB0aGVyZSBhbnkgb2JqZWN0aW9uIGluIGFkb3B0aW5nIHRoZSBh Ym92ZQ0KPiBkcmFmdCBhcyBhIHdnIGRvY3VtZW50Pw0KPiA+Pg0KPiA+PiAtR2Fib3INCj4gPj4N Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogcGF3cy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4gPj4gQmVoYWxm IE9mIGV4dCBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4gPj4gU2VudDogTW9uZGF5LCBBdWd1c3Qg MjIsIDIwMTEgMjo0MyBQTQ0KPiA+PiBUbzogcGF3c0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBS ZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiANCj4gPj4g cmVxdWlyZW1lbnRzDQo+ID4+DQo+ID4+IER1cmluZyB0aGUgUXVlYmVjIHNlc3Npb24sIHdlIGhh ZCBwcmVzZW50YXRpb25zIG9mIHRoZSBQUyBhbmQgdGhlIA0KPiA+PiB1c2UNCj4gY2FzZXMgZHJh ZnRzLiBUaGUgd2cgdGhlbiBkZWNpZGVkIGl0IHdhbnRzIHRvIHNlZSB0aGVzZSBkcmFmdHMgbWVy Z2VkIA0KPiBpbnRvIG9uZS4gU2NvdHQganVzdCBkaWQgdGhhdCBhbmQgcG9zdGVkIHRoZSBtZXJn ZWQgZHJhZnQ6DQo+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3 cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnENCj4gPj4gbXQNCj4gPj4gcw0KPiA+PiAtMDAudHh0 DQo+ID4+DQo+ID4+IE5vdyBJIHdvdWxkIGxpa2UgdG8gYXNrIGlmIHRoZSB3ZyBmZWVscyBsaWtl IHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgDQo+ID4+IHRvDQo+IGJlIGFkb3B0ZWQgYXMgYSB3ZyBk b2N1bWVudC4gUGxlYXNlIHNlbmQgeW91ciBmZWVkYmFjayBhbmQgaHVtIHRvIHRoZSANCj4gbGlz dCBieSB0aGlzIHRpbWUgbmV4dCB3ZWVrLg0KPiA+Pg0KPiA+PiAtR2Fib3INCj4gPj4NCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+PiAtLQ0KPiA+PiAtDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+PiBGcm9tOiBQcm9iYXNjbyBTY290dA0KPiA+PiBTZW50OiBNb25kYXks IEF1Z3VzdCAyMiwgMjAxMSA5OjE4IEFNDQo+ID4+IFRvOiBwYXdzQGlldGYub3JnDQo+ID4+IFN1 YmplY3Q6IGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVu dHMNCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IEFjY29yZGluZyB0byB0aGUgcmVzdWx0cyBv ZiB0aGUgZmFjZS10by1mYWNlIG1lZXRpbmcsIHdlIGhhdmUgDQo+ID4+IGNvbWJpbmVkDQo+IHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBJLUQgYW5kIHVzZSBjYXNlICYgcmVxdWlyZW1lbnQgSS1EIGlu dG8gYSBzaW5nbGUgDQo+IEktRC4gIFlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWVkLg0KPiA+Pg0K PiA+PiBSZWdhcmRzLA0KPiA+PiBTY290dA0KPiA+Pg0KPiA+PiBVUkw6DQo+ID4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMt cnENCj4gPj4gbXQNCj4gPj4gcw0KPiA+PiAtMDAudHh0DQo+ID4+DQo+ID4+DQo+ID4+IEFic3Ry YWN0Og0KPiA+PiBQb3J0aW9ucyBvZiB0aGUgcmFkaW8gc3BlY3RydW0gdGhhdCBhcmUgYWxsb2Nh dGVkIHRvIGEgbGljZW5zZWQsIA0KPiA+PiBwcmltYXJ5IHVzZXIgYnV0IGFyZSB1bnVzZWQgb3Ig dW5vY2N1cGllZCBhdCBzcGVjaWZpYyBsb2NhdGlvbnMgYW5kIA0KPiA+PiB0aW1lcyBhcmUgZGVm aW5lZCBhcyAnd2hpdGUgc3BhY2UnLiAgVGhlIGNvbmNlcHQgb2YgYWxsb3dpbmcgDQo+ID4+IHNl Y29uZGFyeSB0cmFuc21pc3Npb25zIChsaWNlbnNlZCBvciB1bmxpY2Vuc2VkKSBpbiB3aGl0ZSBz cGFjZSBpcyANCj4gPj4gYSB0ZWNobmlxdWUgdG8gJ3VubG9jaycgZXhpc3Rpbmcgc3BlY3RydW0g Zm9yIG5ldyB1c2UuICBBbiBvYnZpb3VzIA0KPiA+PiByZXF1aXJlbWVudCBpcyB0aGF0IHRoZXNl IHNlY29uZGFyeSB0cmFuc21pc3Npb25zIGRvIG5vdCBpbnRlcmZlcmUgDQo+ID4+IHdpdGggdGhl IHByaW1hcnkgdXNlIG9mIHRoZSBzcGVjdHJ1bS4gIE9uZSBhcHByb2FjaCB0byB1c2luZyB0aGUg DQo+ID4+IHdoaXRlIHNwYWNlIHNwZWN0cnVtIGF0IGEgZ2l2ZW4gdGltZSBhbmQgbG9jYXRpb24g aXMgdG8gdmVyaWZ5IHdpdGggDQo+ID4+IGEgZGF0YWJhc2UgYXZhaWxhYmxlIGNoYW5uZWxzLg0K PiA+Pg0KPiA+PiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgY29uY2VwdCBvZiBUViBXaGl0 ZSBTcGFjZXMuICBJdCBhbHNvIA0KPiA+PiBkZXNjcmliZXMgdGhlIHByb2JsZW1zIHRoYXQgbmVl ZCB0byBiZSBhZGRyZXNzZWQgZm9yIGVuYWJsaW5nIHRoZSANCj4gPj4gdXNlIG9mIHRoZSBwcmlt YXJ5IHVzZXIgb3duZWQgd2hpdGUgc3BhY2Ugc3BlY3RydW0gZm9yIHNlY29uZGFyeSANCj4gPj4g dXNlcnMsIHdpdGhvdXQgY2F1c2luZyBpbnRlcmZlcmVuY2UsIGJ5IHF1ZXJ5aW5nIGEgZGF0YWJh c2Ugd2hpY2ggDQo+ID4+IGtub3dzIHRoZSBjaGFubmVsIGF2YWlsYWJpbGl0eSBhdCBhbnkgZ2l2 ZW4gbG9jYXRpb24gYW5kIHRpbWUuICBBIA0KPiA+PiBudW1iZXIgb2YgcG9zc2libGUgdXNlIGNh c2VzIG9mIHRoaXMgc3BlY3RydW0gYW5kIGRlcml2ZWQgDQo+ID4+IHJlcXVpcmVtZW50cyBhcmUg YWxzbyBkZXNjcmliZWQuDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+IHBhd3MgbWFpbGluZyBsaXN0DQo+ID4+IHBhd3NAaWV0 Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IHBhd3MgbWFpbGluZyBsaXN0DQo+ID4+IHBhd3NAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHBhd3MgbWFpbGluZyBsaXN0DQo+ ID4gcGF3c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGF3cw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From lei.zhu@huawei.com Wed Sep 7 23:36: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 7542321F8C56 for ; Wed, 7 Sep 2011 23:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 1X8XIbW4Cenm for ; Wed, 7 Sep 2011 23:36:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A606821F8781 for ; Wed, 7 Sep 2011 23:36:56 -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 <0LR6001I2YEE8K@szxga04-in.huawei.com> for paws@ietf.org; Thu, 08 Sep 2011 14:37:26 +0800 (CST) Received: from szxrg01-dlp.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 <0LR6004HNYEDQB@szxga04-in.huawei.com> for paws@ietf.org; Thu, 08 Sep 2011 14:37:26 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADW17901; Thu, 08 Sep 2011 14:37:25 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 08 Sep 2011 14:37:19 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.189]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Thu, 08 Sep 2011 14:37:22 +0800 Date: Thu, 08 Sep 2011 06:37:21 +0000 From: ZhuLei In-reply-to: <1ECAFF543A2FED4EA2BEB6CACE08E4760FA660@008-AM1MPN1-007.mgdnok.nokia.com> X-Originating-IP: [10.108.64.160] To: "Gabor.Bajko@nokia.com" Message-id: <470F27D1263A1B4EB73491ED995DE62539B899@szxeml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [paws] combined problem statement, use cases & requirements Thread-index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3A//+x7ICAAJ+pMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760FA660@008-AM1MPN1-007.mgdnok.nokia.com> Cc: "paws@ietf.org" 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: Thu, 08 Sep 2011 06:36:58 -0000 SGkgR2Fib3IsDQoNClRoZSBpbmRvb3IgaXMgc3RpbGwgdGhlIG5lY2Vzc2FyeSBwYXJ0IG9mIENv Z25pdGl2ZSBSYWRpbyBhbmQgUEFXUyBpc3N1ZS4gQ29tcGFyaW5nIHdpdGggdGhlIHN0YXRlZCB1 c2UgY2FzZXMgaW4gY29tYmluZWQgcHJvcG9zZWQgZHJhZnQsIHRoZSBpbmRvb3IgYW5kIGFkIGhv YyBzY2VuYXJpb3MgbWF5IGJlIG1vcmUgaW1wb3J0YW50IHRvIGJlIGluY29ycG9yYXRlZCBhY2Nv cmRpbmcgdG8gbXkgdW5kZXJzdGFuZGluZyBzaW5jZSB0aGUgd29ya2luZyBncm91cCB3b3VsZCBs aWtlbHkgdG8gYXZvaWQgdGhhdCB0aGUgZGlmZmVyZW50IGZyZXF1ZW50IGJhbmRzIHdlcmUgdXNl ZCBpbiBwcm9wZXIgc2NlbmFyaW8ocykuIEkgYW0gbm90IHRvIHNlZSBhIGFncmVlZCBkcmFmdCB3 aXRob3V0IHN1Y2ggaW5zdXJhbmNlIG9mIGluZG9vciBjb3ZlcmFnZSBhbmQgYWQgaG9jIHNjZW5h cmlvcy4gQW5kLCBpdCBpcyBvZiBjb3Vyc2UgYSBuZWVkIHRvIGtlZXAgdXNlIGNhc2VzIHZpc2li bGUgd2hlbiBzdGFydGluZyBwcm90b2NvbCBkZXZlbG9wbWVudHMuIA0KDQpTbywgSSBhbHNvIHRo aW5rIHRoYXQgZWRpdG9yIChTY290dD8pIGNhbiBjb25zaWRlciB0aGUgcHJvcG9zZWQgdXNlIGNh c2VzIGhlcmUgYXMgbmVjZXNzYXJ5IGJ1dCBub3Qgd2FpdGluZyBmb3IgbmV4dCBmMmYgbWVldGlu Zy4gDQoNCkJlc3QgcmVnYXJkcywNClpodSBMZWkNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCrei vP7IyzogR2Fib3IuQmFqa29Abm9raWEuY29tIFttYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29t XSANCreiy83KsbzkOiAyMDExxOo51MI4yNUgMTI6NDQNCsrVvP7IyzogWmh1TGVpDQqzrcvNOiBw YXdzQGlldGYub3JnDQrW98ziOiBSRTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50 LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCg0KWmh1IExlaSwNCg0KVGhlIGNoYXJ0ZXIgZXhw bGljaXRseSBzdGF0ZXMgdGhhdCBQQVdTIGlzIHRvIGJlIGtlcHQgdGVjaG5vbG9neSBhZ25vc3Rp Yy4gVGh1cywgbHRlIG1ibXMgdXNlIGNhc2UgaXMgb3V0IG9mIHF1ZXN0aW9uLiBXZSBqdXN0IGFn cmVlZCB0byBhZGQgYW4gYWQtaG9jIG5ldHdvcmsgdXNlIGNhc2UsIGFuZCB0aGUgLTAwIHZlcnNp b24gb2YgdGhlIGRyYWZ0IGFscmVhZHkgaGFzIGEgbG9jYXRpb24gYmFzZWQgc2VydmljZSB1c2Ug Y2FzZSBzY2VuYXJpbyB3aGljaCBsb29rcyB0byBtZSB0byBiZSBhIHN1cGVyc2V0IG9mIHRoZSB1 c2UgY2FzZSB5b3UgcHJvdmlkZWQgYmVsb3cgKGlmIEkgdW5kZXJzdG9vZCB5b3VyIHVzZSBjYXNl IGNvcnJlY3RseSkuDQoNCkJ1dCBJIGRvIG5vdCB3YW50IHRvIHNwZWFrIGluIHRoZSBuYW1lIG9m IHRoZSBlZGl0b3IuIEN1cnJlbnRseSB0aGUgZHJhZnQgaXMgc3RpbGwgYW4gaW5kaXZpZHVhbCBz dWJtaXNzaW9uLCBzbyBpdCBpcyB1cCB0byB0aGUgZWRpdG9yIHRvIGluY29ycG9yYXRlIGFueSBz dWdnZXN0aW9uIGZyb20gdGhlIGxpc3QgdG8gaXRzIG93biBkcmFmdC4gVGhpcyB3b3VsZCBjaGFu Z2Ugb25jZSB0aGUgZHJhZnQgaXMgbWFkZSBhIHdnIGl0ZW0uIFRoZXJlZm9yZSwgSSdkIHByb3Bv c2Ugd2UgbWFrZSB0aGlzIGRyYWZ0IGEgd2cgaXRlbS4NCg0KLUdhYm9yDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgWmh1TGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWku Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA3LCAyMDExIDY6MzUgUE0NClRvOiBH ZXJhbGQgQ2hvdWluYXJkOyBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQpD YzogcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0 YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWlyZW1lbnRzDQoNCkhpIGFsbCwNCg0KSSB0aGluayB0 aGF0IHdlIGRvIHNvbWUgd29ya3Mgb24gaW1wcm92aW5nIG9yaWdpbmFsIHVzZSBjYXNlIGRyYWZ0 IGJ5IGFkZGluZyB0aHJlZSBhZGRpdGlvbmFsIHVzZSBjYXNlcywgaW5jbHVkaW5nIGluZG9vciBj b3ZlcmFnZSwgYWQgaG9jIG5ldHdvcmsgYW5kIGx0ZSBtYm1zIGlzc3VlLg0KDQpOb3csIEkgYW0g YXNraW5nIHRvIGFkZCBpbmRvb3IgY292ZXJhZ2Ugc2NlbmFyaW8gd2hpY2ggaXMgbmVjZXNzYXJ5 IGZvciBQQVdTIHByb3RvY29sIHRvIGNvbnNpZGVyIGluIG5leHQgc3RhZ2UuIFRoZSBwcm9wb3Nl ZCB1c2UgY2FzZSBpcyBzZWVuIGJlbG93LiBUaGUgdXBkYXRlZCB2ZXJzaW9uIG9mIHRoaXMgZHJh ZnQgaXMgdG8gYmUgc3VibWl0dGVkIHNvb24gYnkgYWRkaW5nIHNvbWUgd29yZGluZyBtb2RpZmlj YXRpb25zLiBTbywgSSBkb24ndCB0aGluayB3ZSBhcmUgdG8gc2tpcCB0aGUgYWRkaXRpb25hbCB1 c2UgY2FzZXMgZXZlbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlIGFuZCByZXF1aXJl bWVudCBwcm9wb3NhbCBoYXZlIGJlZW4gaW50ZWdyYXRlZCBub3cuDQoNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KeC54LiAgSW5kb29yIHVz YWdlIG9mIFRWV1MNCg0KICAgQXQgcHJlc2VudCwgdGhlIGluZG9vciB3aXJlbGVzcyBjb3ZlcmFn ZSBlcXVpcG1lbnRzIGNvbnNpc3Qgb2YgV2ktRmktDQogICBsaWtlIGFjY2VzcyBwb2ludHMgYW5k IG1pY3JvIGNlbGxzLCBhbGwgb2YgdGhlc2UgdXRpbGl6ZSBzZWdtZW50cyBvZg0KICAgZnJlcXVl bmN5LCBmb3JtZXIgYXQgYWJvdXQgMi40R0h6IG9yIDVHaHogYW5kIHRoZSBsYXR0ZXIsIGZvcg0K ICAgZXhhbXBsZSwgODAyLjExbiBhdCBhYm91dCAyLjRHSHouICBBcyBhIHJlc3VsdCBvZiB0aGUg YmxvY2sgb2YNCiAgIGJ1aWxkaW5ncyBhbmQgb3RoZXIgb2JzdHJ1Y3Rpb24gYW5kIGludGVyZmVy ZWNlLCBpdCBtYXkgbm90IGJlIHRoYXQNCiAgIG9wdGltaXN0aWMgd2hlbiA4MDIuMTEgZGV2aWNl cyBleGFtaW5lIHRoZSBzdGF0dXMgb2Ygd2lyZWxlc3MNCg0KDQoNClpodSAgICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAzXQ0K DQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUEFXUyB1c2UgY2FzZXMgICAgICAgICAg ICAgICAgICBBdWd1c3QgMjAxMQ0KDQoNCiAgIGludGVyZmVyZXMuICBUaGlzIHVzZSBjYXNlIHRh a2VzIHRoZSBiZW5lZml0IG9mIFRWIFdoaXRlIFNwYWNlIHRvDQogICBwcm92aWRlIGFkZGl0aW9u YWwgY2FwYWNpdHkgdG8gaW5kb29yIGNvdmVyYWdlIGFuZCByZWR1Y2UgY2hhbm5lbA0KICAgaW50 ZXJmZXJlY2UuDQoNCiAgIFRoZSBmaWd1cmUgYmVsb3cgc2hvd3MgYW4gZXhhbXBsZSBkZXBsb3lt ZW50IG9mIHRoaXMgc2NlbmFyaW8uDQoNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICBpbmRvb3IgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgIHwgICAgKy0tLS0tLSsgICB3aGl0ZSBzcGFjZSAgICAgIHwgICArLS0tLS0tLS0t LS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgfERldmljZXwgLSAtIC0gLSAtIC0gLSAtIC0gLXwt IC18IE1pY3JvIGNlbGwgIHwNCiAgICAgICAgICAgICAgIHwgICAgKy0tLS0tLSsgIFwgICAgICAg ICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgKy0tLS0t LSsgICBcd2hpdGUgc3BhY2UgICAgIHwgICAgICgtLS0tLSkNCiAgICAgICAgICAgICAgIHwgICAg fERldmljZXwgICAgXCArLS0tLS0tLS0tLS0tK3wgICAgLyAgICAgICBcDQogICAgICAgICAgICAg ICB8ICAgICstLS0tLS0rICAgICAgfGFjY2VzcyBwb2ludHx8PT09KCBJbnRlcm5ldCkNCiAgICAg ICAgICAgICAgIHwgICAgICAgIG8gICAgICAgLyArLS0tLS0tLS0tLS0tK3wgICAgXCAgICAgICAv DQogICAgICAgICAgICAgICB8ICAgICAgICBvICAgICAgLyAgICAgICAgICAgICAgICB8ICAgICAo LS0tLS0pDQogICAgICAgICAgICAgICB8ICAgICAgICBvICAgICAvICAgICAgICAgICAgICAgICB8 DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KICAgICAg ICAgICAgICAgICAgICAgICBHcmFwaCAxIEluZG9vciB1c2FnZSBvZiBUVldTDQoNCiAgIFRoZSBh Y2Nlc3MgcG9pbnQgY291bGQgYmUgYSBXSS1GSSByb3V0ZXIsIGFuZCB0aGUgbWljcm8gY2VsbCBp cyBhDQogICBzaG9ydCByYW5nZSB3aXJlbGVzcyBjb3ZlcmFnZShlLmcuIGluIHJhbmdlIG9mIDAt NTBtKSBiYXNlIHN0YXRpb24sDQogICBib3RoIG9mIHRoZW0gYWN0IGFzIG1hc3RlciBkZXZpY2Vz LCBxdWVyeWluZyB0aGUgaW50ZXJuZXQgY29ubmVjdGVkDQogICBkYXRhYmFzZSBmb3IgYXZhaWxh YmxlIHdoaXRlIHNwYWNlIHNwZWN0cnVtIGJhc2VkIG9uIGl0cyBnZW8tDQogICBsb2NhdGlvbiwg YW5kIHByb3ZpZGluZyBUVldTIGFjY2VzcyB0byBpbmRvb3IgdXNlci4NCg0KICAgVGhlIFRWV1Mg c3BlY3RydW0gaGFzIGRpZmZlcmVudCBwcm9wYWdhdGlvbiBjaGFyYWN0ZXJpc3RpY3MgY29tcGFy ZWQNCiAgIHRvIGhpZ2hlciBmcmVxdWVuY3kgYmFuZCwgZm9yIGV4YW1wbGUsIHRoZSB0cmFuc21p c3Npb24gZGlzdGFuY2UNCiAgIHVzaW5nIFRWV1MgY2FuIGJlIHNldmVyYWwgdGltZXMgbG9uZ2Vy IHRoYW4gdGhvc2UgaW4gdGhlIGhpZ2hlciBiYW5kLg0KICAgSW4gdGhpcyBjYXNlLCBnb29kIHBl bmV0cmF0aW9uIGNoYXJhY3RlcmlzdGljIG9mIFRWV1MgbWFrZXMgaXQNCiAgIGRpZmZpY3VsdCB0 byBsb2NrIHRoZSBzaWduYWxzIGluIHRoZSByb29tLCB0aGVuIGRpZmZpY3VsdCB0byBsb2NhbGl6 ZQ0KICAgYW5kIGRpZmZlcmVudGlhdGUgc2lnbmFscywgYW5kIGZpbmFsbHkgY2F1c2UgaW50ZXJm ZXJlcyBhbW9uZw0KICAgbmVpZ2hib3JpbmcgbmV0d29ya3MuICBSZXF1aXJlbWVudHMgdG8gaW5k b29yIFdTIGRhdGViYXNlIHVzYWdlIHdvdWxkDQogICBiZToNCg0KDQogICAxLiAgQSBmcmVxdWVu Y3kgcHJvdGVjdGlvbiBnYXAgYmV0d2VlbiBuZWlnaGJvcnMocGFydGljdWxhciBzcGVjdHJ1bQ0K ICAgICAgIGFsbG9jYXRpb24gYWxnb3JpdGhtIGlzIG5lZWRlZCBoZXJlKS4NCg0KICAgMi4gIGxv d2VyIG91dHB1dCBwb3dlciBvZiBBUC9taWNybyBjZWxsLCBpdCBzZWVtcyB0aGF0IG9ubHkgY2Vy dGFpbg0KICAgICAgIHBpY28gb3IgZmVtdG8gY2VsbHMgYmUgZmVhc2libGUgaGVyZS4NCg0KICAg My4gIFBBV1MgbXVzdCBub3QgYmUgdGllZCB0byBhIHNwZWNpZmljIGZyZXF1ZW5jeSBiYW5kLg0K DQogICA0LiAgUEFXUyBtdXN0IHJlc3BvbnNlIHRoZSBwcm9wZXIgZnJlcXVlbmN5IGJhbmQgbGlz dCB0byBwYXJ0aWN1bGFyDQogICAgICAgY292ZXJhZ2Ugd2hpdGUgc3BhY2UgZGV2aWNlcy4NCg0K ICAgNS4gIE1hc3RlciBkZXZpY2VzIHNob3VsZCBzdXBwb3J0IHBvd2VyIGNvbnRyb2wuDQoNCiAg IDYuICBTbGF2ZSBkZXZpY2VzIHNob3VsZCBzdXBwb3J0IHBvd2VyIGNvbnRyb2wuDQoNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpaaHUg TGVpDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBHZXJhbGQgQ2hvdWluYXJkDQq3 osvNyrG85DogMjAxMcTqOdTCOMjVIDg6MDENCsrVvP7IyzogR2Fib3IuQmFqa29Abm9raWEuY29t DQqzrcvNOiBwYXdzQGlldGYub3JnDQrW98ziOiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0g c3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCg0KR2Fib3IsDQoNCkNhbiBJIGFz ayB0aGF0IHRoZSB0ZXh0IG1vZGlmaWNhdGlvbnMgdGhhdCBJIGhhdmUgc3VibWl0dGVkIHRvIHNj b3R0IGFuZCBjb3BpZWQgdG8gdGhlIHBhd3MgcmVmbGVjdG9yIGluIG15IGVtYWlsIGRhdGVkIDgg QXVndXN0IGJlIGluY2x1ZGVkIGFzIHdlbGw/DQoNClRoYW5rJ3MsDQoNCkdlcmFsZA0KDQoNCkF0 IDIwOjMyIDA3LTA5LTExICswMDAwLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+T2ss IGxldCdzIHRyeSB0aGF0IHRoZW4uDQo+U2NvdHQsIGNhbiB5b3UgcHV0IHVzZSBjYXNlcyBiZWZv cmUgUFMsIGFuZCBhZGQgdGhlIGFkLWhvYyB1c2UgY2FzZS4gSSANCj5qdXN0IHNjYW5uZWQgdGhy b3VnaCB0aGUgbGlzdCBhbmQgc3BvdHRlZCB0aGF0IFRlY28gaW5kZWVkIHByb3ZpZGVkIGEgDQo+ ZGVzY3JpcHRpb24gZm9yIHRoYXQgdXNlIGNhc2Ugb24gQXVnIDNyZC4NCj5BbmQgc3VibWl0IHRo ZSBkcmFmdCBhcyBhIHdnIGl0ZW0sIHVubGVzcyB0aGVyZSBhcmUgc3RpbGwgb2JqZWN0aW9ucy4N Cj4NCj4tR2Fib3INCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGV4dCBO YW5jeSBCcmF2aW4gW21haWx0bzpuYnJhdmluQGVhcnRobGluay5uZXRdDQo+U2VudDogU2F0dXJk YXksIFNlcHRlbWJlciAwMywgMjAxMSAzOjQxIFBNDQo+VG86IEJhamtvIEdhYm9yIChOb2tpYS1D SUMvU2lsaWNvblZhbGxleSkNCj5DYzogVGVjbyBCb290OyBHZXJhbGQgQ2hvdWluYXJkOyBwYXdz QGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVu dCwgdXNlIGNhc2VzICYgDQo+cmVxdWlyZW1lbnRzDQo+DQo+RGVhciBHYWJvciBhbmQgQWxsLA0K Pg0KPkkgdGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUgdG8gcHV0IHRoZSB1c2UgY2FzZXMgYmVmb3Jl IHRoZSBQUyBmb3IgDQo+b2J2aW91cyByZWFzb25zLCBhbmQgaW5jbHVkaW5nIHRoZSAicHJveHki IG5lZWQgaW4gdGhlIGZpcnN0IGRyYWZ0LiBJIA0KPnN1cHBvcnQgaW5jbHVkaW5nIGJvdGggR2Vy YWxkJ3Mgc3VnZ2VzdGlvbnMgYW5kIFRlY28ncyBwcm9wb3NhbCBpbiB0aGUgDQo+b3JpZ2luYWwg ZHJhZnQgYW5kIG5vdCB3YWl0aW5nIHVudGlsIGEgbGF0ZXIgdGltZS4gSXQgaXMgdGhlIHByb3Bl ciANCj5vcmRlciwgaW5jbHVzaXZlIGFuZCBuZWVkZWQgaW4gdGhlIGluaXRpYWwgZHJhZnQgaW4g bXkgb3Bpbmlvbi4gSSANCj5iZWxpZXZlIHdpdGggdGhlIHRhbGVudCBpbiB0aGUgZ3JvdXAgaXQg d2lsbCBub3QgdGFrZSBsb25nIHRvIA0KPmFjY29tcGxpc2ggdGhpcyBhbmQgeW91IHdpbGwgaGF2 ZSBhIG1vcmUgY29oZXNpdmUgZHJhZnQuDQo+DQo+U0luY2VyZWx5LCBOYW5jeQ0KPg0KPg0KPk9u IFNlcCAyLCAyMDExLCBhdCAyOjE5IFBNLCA8R2Fib3IuQmFqa29Abm9raWEuY29tPiANCj48R2Fi b3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToNCj4NCj4gPiBUZWNvLCBHZXJhbGQsDQo+ID4NCj4g PiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gSSdkIHN1Z2dlc3QgdGhhdCB3ZSBtYWtlIHRoaXMg ZHJhZnQgYSBXRyANCj4gPiBpdGVtLA0KPiB3aXRoIEdlcmFsZCdzIHByb3Bvc2VkIGNoYW5nZXMg aW4gaXQuIFJlZ2FyZGluZyB0aGUgb3JkZXIgb2YgdGhlIA0KPiBwcm9ibGVtIHN0YXRlbWVudCB2 cyB1c2UgY2FzZXMsIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gbGVhdmUgaXQgYXMgDQo+IGl0 IGlzIChidXQgd2UgY2FuIGFsd2F5cyBjaGFuZ2UgaXQsIGlmIHRoYXQgaXMgd2hhdCB0aGUgV0cg d2FudHMpLg0KPiA+DQo+ID4gU28sIEknZCBhc2sgU2NvdHQgdG8gc3VibWl0IGEgV0cgdmVyc2lv biBvZiB0aGlzIGRyYWZ0LCB0aGVuIGhhdmUNCj4gc29tZW9uZSBjb21lIHVwIHdpdGggdGV4dCBm b3IgdGhpcyBhZC1ob2MgbmV0d29yayBzY2VuYXJpbywgaGF2ZSB0aGUgDQo+IFdHIGFncmVlIHdp dGggdGhlIHRleHQgYW5kIGluY2x1ZGUgaXQgaW4gb25lIG9mIHRoZSBzdWJzZXF1ZW50IHZlcnNp b25zLg0KPiBUZWNvLCB3b3VsZCB5b3Ugd3JpdGUgdXAgc29tZSB0ZXh0IGZvciB0aGlzIGFkLWhv YyB1c2UgY2FzZSB0aGUgV0cgDQo+IGNvdWxkIGRpc2N1c3M/DQo+ID4NCj4gPiBXZSdsbCBhbHNv IHNlbmQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgbGlzdCBvZiByZXF1aXJlbWVudHMgdG8gdGhl DQo+IGxpc3QgbmV4dCB3ZWVrLg0KPiA+DQo+ID4gLSBHYWJvcg0KPiA+DQo+ID4NCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGV4dCBUZWNvIEJvb3QgW21haWx0bzp0 ZWNvQGluZi1uZXQubmxdDQo+ID4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwMSwgMjAxMSAx MTowNiBQTQ0KPiA+IFRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+ ID4gQ2M6IHBhd3NAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHBy b2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiANCj4gPiByZXF1aXJlbWVudHMNCj4gPg0KPiA+ IEkgdGhpbmsgdGhlIGRvYyBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQuIEkgc3VwcG9ydCBhZG9w dGlvbi4NCj4gPg0KPiA+IEkgc3VnZ2VzdCByZW9yZGVyaW5nOiBzcGVjaWZ5aW5nIHByb2JsZW0g c3RhdGVtZW50IGFmdGVyIGludHJvZHVjaW5nDQo+IHRoZSB1c2UgY2FzZXMuDQo+ID4NCj4gPiBT b21lIGFza2VkIGZvciB0aGUgYWQgaG9jIG5ldHdvcmsgc2NlbmFyaW8uIFRoaXMgaW5jbHVkZXMg bWUgOi0pLiANCj4gPiBUaGlzDQo+IGlzIGltcG9ydGFudCwgYmVjYXVzZSBpdCBkZW1vbnN0cmF0 ZXMgdGhlIG5lZWQgZm9yICJwcm94eSIuDQo+ID4gQlRXLCBJIHdvbmRlciB3aHkgc2ltaWxhciBz Y2VuYXJpbyBkb2Vzbid0IHBvcCB1cCBmcm9tIFdpRmkNCj4gZGVwbG95bWVudHMuIFVzYWdlIG9m IGNvbnRyb2xsZXJzIGluIGxhcmdlIHNpdGVzIGlzIG5vdCB1bmNvbW1vbi4gTm90IA0KPiB0byBt ZW50aW9uIDExcy4NCj4gPg0KPiA+IFRoZSByZXF1aXJlbWVudHMgaXMgbGVmdCBvcGVuLiBJJ20g bG9va2luZyBmb3J3YXJkIHNlZSBzb21lIGRyYWZ0IHRleHQuDQo+ID4NCj4gPiBUaGFua3MsIFRl Y28NCj4gPg0KPiA+DQo+ID4gT3AgMzAgYXVnIDIwMTEsIG9tIDE5OjQyIGhlZWZ0IDxHYWJvci5C YWprb0Bub2tpYS5jb20+DQo+IDxHYWJvci5CYWprb0Bub2tpYS5jb20+IGhldCB2b2xnZW5kZSBn ZXNjaHJldmVuOg0KPiA+DQo+ID4+IEkgc2VudCB0aGlzIGVtYWlsIHRvIHRoZSBsaXN0IG9uZSB3 ZWVrIGFnbywgYXNraW5nIGZvciBmZWVkYmFjayBvbiANCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycQ0KPiA+PiBt dCBzIC0wMC50eHQgYnV0IHRoZXJlIHdhcyBub3Qgb25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJIHRh a2UgdGhhdCANCj4gPj4gYXMgcGVvcGxlIGhhdmUgbm8gY29tbWVudHMgdG8gdGhlIGRyYWZ0IGF0 IHRoaXMgdGltZS4NCj4gPj4NCj4gPj4gQW5kIEkgYW0gYXNraW5nIGFnYWluOiBpcyB0aGVyZSBh bnkgb2JqZWN0aW9uIGluIGFkb3B0aW5nIHRoZSBhYm92ZQ0KPiBkcmFmdCBhcyBhIHdnIGRvY3Vt ZW50Pw0KPiA+Pg0KPiA+PiAtR2Fib3INCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiANCj4gPj4gQmVoYWxmIE9mIGV4dCBHYWJvci5CYWprb0Bub2tpYS5j b20NCj4gPj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEgMjo0MyBQTQ0KPiA+PiBUbzog cGF3c0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0g c3RhdGVtZW50LCB1c2UgY2FzZXMgJiANCj4gPj4gcmVxdWlyZW1lbnRzDQo+ID4+DQo+ID4+IER1 cmluZyB0aGUgUXVlYmVjIHNlc3Npb24sIHdlIGhhZCBwcmVzZW50YXRpb25zIG9mIHRoZSBQUyBh bmQgdGhlIA0KPiA+PiB1c2UNCj4gY2FzZXMgZHJhZnRzLiBUaGUgd2cgdGhlbiBkZWNpZGVkIGl0 IHdhbnRzIHRvIHNlZSB0aGVzZSBkcmFmdHMgbWVyZ2VkIA0KPiBpbnRvIG9uZS4gU2NvdHQganVz dCBkaWQgdGhhdCBhbmQgcG9zdGVkIHRoZSBtZXJnZWQgZHJhZnQ6DQo+ID4+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnEN Cj4gPj4gbXQNCj4gPj4gcw0KPiA+PiAtMDAudHh0DQo+ID4+DQo+ID4+IE5vdyBJIHdvdWxkIGxp a2UgdG8gYXNrIGlmIHRoZSB3ZyBmZWVscyBsaWtlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgDQo+ ID4+IHRvDQo+IGJlIGFkb3B0ZWQgYXMgYSB3ZyBkb2N1bWVudC4gUGxlYXNlIHNlbmQgeW91ciBm ZWVkYmFjayBhbmQgaHVtIHRvIHRoZSANCj4gbGlzdCBieSB0aGlzIHRpbWUgbmV4dCB3ZWVrLg0K PiA+Pg0KPiA+PiAtR2Fib3INCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtLQ0KPiA+PiAt DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBGcm9tOiBQcm9i YXNjbyBTY290dA0KPiA+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSA5OjE4IEFNDQo+ ID4+IFRvOiBwYXdzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IGNvbWJpbmVkIHByb2JsZW0gc3Rh dGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ ID4+IEFjY29yZGluZyB0byB0aGUgcmVzdWx0cyBvZiB0aGUgZmFjZS10by1mYWNlIG1lZXRpbmcs IHdlIGhhdmUgDQo+ID4+IGNvbWJpbmVkDQo+IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBJLUQgYW5k IHVzZSBjYXNlICYgcmVxdWlyZW1lbnQgSS1EIGludG8gYSBzaW5nbGUgDQo+IEktRC4gIFlvdXIg Y29tbWVudHMgYXJlIHdlbGNvbWVkLg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBTY290dA0K PiA+Pg0KPiA+PiBVUkw6DQo+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFz Y28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnENCj4gPj4gbXQNCj4gPj4gcw0KPiA+PiAt MDAudHh0DQo+ID4+DQo+ID4+DQo+ID4+IEFic3RyYWN0Og0KPiA+PiBQb3J0aW9ucyBvZiB0aGUg cmFkaW8gc3BlY3RydW0gdGhhdCBhcmUgYWxsb2NhdGVkIHRvIGEgbGljZW5zZWQsIA0KPiA+PiBw cmltYXJ5IHVzZXIgYnV0IGFyZSB1bnVzZWQgb3IgdW5vY2N1cGllZCBhdCBzcGVjaWZpYyBsb2Nh dGlvbnMgYW5kIA0KPiA+PiB0aW1lcyBhcmUgZGVmaW5lZCBhcyAnd2hpdGUgc3BhY2UnLiAgVGhl IGNvbmNlcHQgb2YgYWxsb3dpbmcgDQo+ID4+IHNlY29uZGFyeSB0cmFuc21pc3Npb25zIChsaWNl bnNlZCBvciB1bmxpY2Vuc2VkKSBpbiB3aGl0ZSBzcGFjZSBpcyANCj4gPj4gYSB0ZWNobmlxdWUg dG8gJ3VubG9jaycgZXhpc3Rpbmcgc3BlY3RydW0gZm9yIG5ldyB1c2UuICBBbiBvYnZpb3VzIA0K PiA+PiByZXF1aXJlbWVudCBpcyB0aGF0IHRoZXNlIHNlY29uZGFyeSB0cmFuc21pc3Npb25zIGRv IG5vdCBpbnRlcmZlcmUgDQo+ID4+IHdpdGggdGhlIHByaW1hcnkgdXNlIG9mIHRoZSBzcGVjdHJ1 bS4gIE9uZSBhcHByb2FjaCB0byB1c2luZyB0aGUgDQo+ID4+IHdoaXRlIHNwYWNlIHNwZWN0cnVt IGF0IGEgZ2l2ZW4gdGltZSBhbmQgbG9jYXRpb24gaXMgdG8gdmVyaWZ5IHdpdGggDQo+ID4+IGEg ZGF0YWJhc2UgYXZhaWxhYmxlIGNoYW5uZWxzLg0KPiA+Pg0KPiA+PiBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyB0aGUgY29uY2VwdCBvZiBUViBXaGl0ZSBTcGFjZXMuICBJdCBhbHNvIA0KPiA+PiBk ZXNjcmliZXMgdGhlIHByb2JsZW1zIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgZm9yIGVuYWJs aW5nIHRoZSANCj4gPj4gdXNlIG9mIHRoZSBwcmltYXJ5IHVzZXIgb3duZWQgd2hpdGUgc3BhY2Ug c3BlY3RydW0gZm9yIHNlY29uZGFyeSANCj4gPj4gdXNlcnMsIHdpdGhvdXQgY2F1c2luZyBpbnRl cmZlcmVuY2UsIGJ5IHF1ZXJ5aW5nIGEgZGF0YWJhc2Ugd2hpY2ggDQo+ID4+IGtub3dzIHRoZSBj aGFubmVsIGF2YWlsYWJpbGl0eSBhdCBhbnkgZ2l2ZW4gbG9jYXRpb24gYW5kIHRpbWUuICBBIA0K PiA+PiBudW1iZXIgb2YgcG9zc2libGUgdXNlIGNhc2VzIG9mIHRoaXMgc3BlY3RydW0gYW5kIGRl cml2ZWQgDQo+ID4+IHJlcXVpcmVtZW50cyBhcmUgYWxzbyBkZXNjcmliZWQuDQo+ID4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHBh d3MgbWFpbGluZyBsaXN0DQo+ID4+IHBhd3NAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHBhd3MgbWFpbGluZyBsaXN0DQo+ID4+IHBh d3NAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IHBhd3MgbWFpbGluZyBsaXN0DQo+ID4gcGF3c0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpw YXdzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MN Cg== From scott.probasco@nokia.com Thu Sep 8 07:56: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 44FC521F84CD for ; Thu, 8 Sep 2011 07:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 7npI5CtsAmaK for ; Thu, 8 Sep 2011 07:56:18 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53821F84BC for ; Thu, 8 Sep 2011 07:56:17 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p88EvEfE010422; Thu, 8 Sep 2011 17:58:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 17:58:02 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 16:58:00 +0200 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.214]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Thu, 8 Sep 2011 16:58:00 +0200 From: To: , Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVDHpqA Date: Thu, 8 Sep 2011 14:58:00 +0000 Message-ID: In-Reply-To: <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> 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.241.54.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DB933C656876547B559A8464C06B0FF@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 14:58:02.0151 (UTC) FILETIME=[B4BE0370:01CC6E37] X-Nokia-AV: Clean Cc: paws@ietf.org 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: Thu, 08 Sep 2011 14:56:19 -0000 Hi Gerald, I have updated the "Wide-Area or Rural internet broadband access" use case according to your email of August 30. This email proposes different edits to the same text as your email of August 8. Are you okay with the Aug 30 version? Thanks, Scott On 9/7/11 7:00 PM, "ext Gerald Chouinard" wrote: >Gabor, > >Can I ask that the text modifications that I have submitted to scott and >copied to the paws reflector in my email dated 8 August be included as >well? > >Thank's, > >Gerald > > >At 20:32 07-09-11 +0000, Gabor.Bajko@nokia.com wrote: >>Ok, let's try that then. >>Scott, can you put use cases before PS, and add the ad-hoc use case. I >>just scanned through the list and spotted that Teco indeed provided a >>description for that use case on Aug 3rd. >>And submit the draft as a wg item, unless there are still objections. >> >>-Gabor >> >>-----Original Message----- >>From: ext Nancy Bravin [mailto:nbravin@earthlink.net] >>Sent: Saturday, September 03, 2011 3:41 PM >>To: Bajko Gabor (Nokia-CIC/SiliconValley) >>Cc: Teco Boot; Gerald Chouinard; paws@ietf.org >>Subject: Re: [paws] combined problem statement, use cases & requirements >> >>Dear Gabor and All, >> >>I think it is appropriate to put the use cases before the PS for obvious >>reasons, and including the "proxy" need in the first draft. I support >>including both Gerald's suggestions and Teco's proposal in the original >>draft and not waiting until a later time. It is the proper order, >>inclusive and needed in the initial draft in my opinion. I believe with >>the talent in the group it will not take long to accomplish this and you >>will have a more cohesive draft. >> >>SIncerely, Nancy >> >> >>On Sep 2, 2011, at 2:19 PM, >> wrote: >> >> > Teco, Gerald, >> > >> > Thanks for the feedback. I'd suggest that we make this draft a WG >>item,=20 >> with Gerald's proposed changes in it. Regarding the order of the >>problem=20 >> statement vs use cases, my preference would be to leave it as it is >>(but=20 >> we can always change it, if that is what the WG wants). >> > >> > So, I'd ask Scott to submit a WG version of this draft, then have >> someone come up with text for this ad-hoc network scenario, have the WG >> agree with the text and include it in one of the subsequent versions. >> Teco, would you write up some text for this ad-hoc use case the WG >>could=20 >> discuss? >> > >> > We'll also send an initial version of a list of requirements to the >> list next week. >> > >> > - Gabor >> > >> > >> > -----Original Message----- >> > From: ext Teco Boot [mailto:teco@inf-net.nl] >> > Sent: Thursday, September 01, 2011 11:06 PM >> > To: Bajko Gabor (Nokia-CIC/SiliconValley) >> > Cc: paws@ietf.org >> > Subject: Re: [paws] combined problem statement, use cases & >> > requirements >> > >> > I think the doc is a good starting point. I support adoption. >> > >> > I suggest reordering: specifying problem statement after introducing >> the use cases. >> > >> > Some asked for the ad hoc network scenario. This includes me :-). >>This=20 >> is important, because it demonstrates the need for "proxy". >> > BTW, I wonder why similar scenario doesn't pop up from WiFi >> deployments. Usage of controllers in large sites is not uncommon. Not >>to=20 >> mention 11s. >> > >> > The requirements is left open. I'm looking forward see some draft >>text. >> > >> > Thanks, Teco >> > >> > >> > Op 30 aug 2011, om 19:42 heeft >> het volgende geschreven: >> > >> >> 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-rqmt >> >> s -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=20 >> 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-rqmt >> >> s >> >> -00.txt >> >> >> >> Now I would like to ask if the wg feels like this document is ready >>to=20 >> 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=20 >> 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-rqmt >> >> s >> >> -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 >> > >> > _______________________________________________ >> > 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 Thu Sep 8 08:14:05 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 3AEB621F8A80 for ; Thu, 8 Sep 2011 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 w+4IbookygaW for ; Thu, 8 Sep 2011 08:14:04 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 74B4421F87D9 for ; Thu, 8 Sep 2011 08:14:03 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 2DC276B0473; Thu, 8 Sep 2011 11:15:52 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 154506B0377; Thu, 8 Sep 2011 11:15:52 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id DE01F6B03EF; Thu, 8 Sep 2011 11:15:51 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 674D36B0377; Thu, 8 Sep 2011 11:15:47 -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 EE2AA6B1520; Thu, 8 Sep 2011 11:15:46 -0400 (EDT) Message-Id: <5.1.0.14.2.20110908111214.02ad6e10@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 Sep 2011 11:15:41 -0400 To: From: Gerald Chouinard In-Reply-To: References: <5.1.0.14.2.20110907195448.02bccf50@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 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: Thu, 08 Sep 2011 15:14:05 -0000 Hi Scott, My apologies; I referred to the wrong email. The proper modifications are the ones contained in my email dated August 30th. Thank's for including it in your most recent version of the document. Gerald At 14:58 08-09-11 +0000, scott.probasco@nokia.com wrote: >Hi Gerald, > >I have updated the "Wide-Area or Rural internet broadband access" use case >according to your email of August 30. This email proposes different edits >to the same text as your email of August 8. Are you okay with the Aug 30 >version? > >Thanks, >Scott > > > >On 9/7/11 7:00 PM, "ext Gerald Chouinard" wrote: > > >Gabor, > > > >Can I ask that the text modifications that I have submitted to scott and > >copied to the paws reflector in my email dated 8 August be included as > >well? > > > >Thank's, > > > >Gerald > > > > > >At 20:32 07-09-11 +0000, Gabor.Bajko@nokia.com wrote: > >>Ok, let's try that then. > >>Scott, can you put use cases before PS, and add the ad-hoc use case. I > >>just scanned through the list and spotted that Teco indeed provided a > >>description for that use case on Aug 3rd. > >>And submit the draft as a wg item, unless there are still objections. > >> > >>-Gabor > >> > >>-----Original Message----- > >>From: ext Nancy Bravin [mailto:nbravin@earthlink.net] > >>Sent: Saturday, September 03, 2011 3:41 PM > >>To: Bajko Gabor (Nokia-CIC/SiliconValley) > >>Cc: Teco Boot; Gerald Chouinard; paws@ietf.org > >>Subject: Re: [paws] combined problem statement, use cases & requirements > >> > >>Dear Gabor and All, > >> > >>I think it is appropriate to put the use cases before the PS for obvious > >>reasons, and including the "proxy" need in the first draft. I support > >>including both Gerald's suggestions and Teco's proposal in the original > >>draft and not waiting until a later time. It is the proper order, > >>inclusive and needed in the initial draft in my opinion. I believe with > >>the talent in the group it will not take long to accomplish this and you > >>will have a more cohesive draft. > >> > >>SIncerely, Nancy > >> > >> > >>On Sep 2, 2011, at 2:19 PM, > >> wrote: > >> > >> > Teco, Gerald, > >> > > >> > Thanks for the feedback. I'd suggest that we make this draft a WG > >>item, > >> with Gerald's proposed changes in it. Regarding the order of the > >>problem > >> statement vs use cases, my preference would be to leave it as it is > >>(but > >> we can always change it, if that is what the WG wants). > >> > > >> > So, I'd ask Scott to submit a WG version of this draft, then have > >> someone come up with text for this ad-hoc network scenario, have the WG > >> agree with the text and include it in one of the subsequent versions. > >> Teco, would you write up some text for this ad-hoc use case the WG > >>could > >> discuss? > >> > > >> > We'll also send an initial version of a list of requirements to the > >> list next week. > >> > > >> > - Gabor > >> > > >> > > >> > -----Original Message----- > >> > From: ext Teco Boot [mailto:teco@inf-net.nl] > >> > Sent: Thursday, September 01, 2011 11:06 PM > >> > To: Bajko Gabor (Nokia-CIC/SiliconValley) > >> > Cc: paws@ietf.org > >> > Subject: Re: [paws] combined problem statement, use cases & > >> > requirements > >> > > >> > I think the doc is a good starting point. I support adoption. > >> > > >> > I suggest reordering: specifying problem statement after introducing > >> the use cases. > >> > > >> > Some asked for the ad hoc network scenario. This includes me :-). > >>This > >> is important, because it demonstrates the need for "proxy". > >> > BTW, I wonder why similar scenario doesn't pop up from WiFi > >> deployments. Usage of controllers in large sites is not uncommon. Not > >>to > >> mention 11s. > >> > > >> > The requirements is left open. I'm looking forward see some draft > >>text. > >> > > >> > Thanks, Teco > >> > > >> > > >> > Op 30 aug 2011, om 19:42 heeft > >> het volgende geschreven: > >> > > >> >> 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-rqmt > >> >> s -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-rqmt > >> >> s > >> >> -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-rqmt > >> >> s > >> >> -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 > >> > > >> > _______________________________________________ > >> > 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 Sep 8 08:48: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 E587621F8557 for ; Thu, 8 Sep 2011 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-2.521, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 kBjc2y1VMxRF for ; Thu, 8 Sep 2011 08:48:08 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C7DE921F84D8 for ; Thu, 8 Sep 2011 08:48:07 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p88FmsGV026425; Thu, 8 Sep 2011 18:49:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 18:49:08 +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; Thu, 8 Sep 2011 17:49:08 +0200 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.214]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Thu, 8 Sep 2011 17:49:07 +0200 From: To: Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3AgAB8ZQA= Date: Thu, 8 Sep 2011 15:49:06 +0000 Message-ID: In-Reply-To: <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.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.241.54.81] Content-Type: text/plain; charset="gb2312" Content-ID: <091C2BBFD1251F4AB563B494736774E7@nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 15:49:08.0334 (UTC) FILETIME=[D85468E0:01CC6E3E] X-Nokia-AV: Clean Cc: paws@ietf.org 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: Thu, 08 Sep 2011 15:48:09 -0000 SGVsbG8gTGVpLA0KDQpJIGhhdmUgc3R1ZGllZCB0aGUgdGV4dCBiZWxvdywgYnV0IEkgZG8gbm90 IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHlvdQ0KYXJlIHByb3Bvc2luZy4gSXQgc2VlbXMgdG8g bWUgdGhhdCB5b3UgYXJlIGRlc2NyaWJpbmcgYSBkZXBsb3ltZW50DQpzY2VuYXJpbyAod2hpY2gg aXMgZmluZSkuIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCBpcyB0aGUgdXNlIGNhc2UsIG9yIGhv dw0KdGhpcyBjYXNlIGlzIGRpZmZlcmVudCBmcm9tICJIb3RzcG90IiB1c2UgY2FzZSAoQVAgaXMg aW5kb29yKSB3aXRoIGENCiJXaWRlLWFyZWEgb3IgcnVyYWwiIHVzZSBjYXNlIGRlcGxveWVkIGlu IHRoZSBzYW1lIGdlbmVyYWwgYXJlYSAobWljcm9jZWxsDQppcyBvdXRkb29yKS4NCg0KSSBhbSBu b3Qgc3BlYWtpbmcgYWdhaW5zdCB0aGUgdXNlIGNhc2UsIHNpbXBseSBzYXlpbmcgdGhhdCBJIGRv bid0DQp1bmRlcnN0YW5kIGl0IHdlbGwgZW5vdWdoIHRvIGNvbW1lbnQgb24gaXQuIEl0IG1pZ2h0 IGhlbHAgZnVydGhlcg0KZGlzY3Vzc2lvbiBpZiB5b3UgY2FuIGRlc2NyaWJlIGluIG1vcmUgZGV0 YWlsIHRoZSB1c2UgY2FzZSwgYW5kIGluY2x1ZGUNCnNwZWNpZmljIGFjdGlvbnMgdGhhdCBlYWNo IGVsZW1lbnQgKG1pY3JvY2VsbCwgQVAsIGRldmljZSwgZGF0YWJhc2UsIGV0YykNCm11c3QgY29t cGxldGUgaW4gb3JkZXIgdG8gZGVwbG95IHRoaXMgdXNlIGNhc2UuDQoNClJlZ2FyZHMsDQpTY290 dA0KDQoNCk9uIDkvNy8xMSA4OjM1IFBNLCAiZXh0IFpodUxlaSIgPGxlaS56aHVAaHVhd2VpLmNv bT4gd3JvdGU6DQoNCj5IaSBhbGwsDQo+DQo+SSB0aGluayB0aGF0IHdlIGRvIHNvbWUgd29ya3Mg b24gaW1wcm92aW5nIG9yaWdpbmFsIHVzZSBjYXNlIGRyYWZ0IGJ5DQo+YWRkaW5nIHRocmVlIGFk ZGl0aW9uYWwgdXNlIGNhc2VzLCBpbmNsdWRpbmcgaW5kb29yIGNvdmVyYWdlLCBhZCBob2MNCj5u ZXR3b3JrIGFuZCBsdGUgbWJtcyBpc3N1ZS4NCj4NCj5Ob3csIEkgYW0gYXNraW5nIHRvIGFkZCBp bmRvb3IgY292ZXJhZ2Ugc2NlbmFyaW8gd2hpY2ggaXMgbmVjZXNzYXJ5IGZvcg0KPlBBV1MgcHJv dG9jb2wgdG8gY29uc2lkZXIgaW4gbmV4dCBzdGFnZS4gVGhlIHByb3Bvc2VkIHVzZSBjYXNlIGlz IHNlZW4NCj5iZWxvdy4gVGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGlzIHRvIGJl IHN1Ym1pdHRlZCBzb29uIGJ5DQo+YWRkaW5nIHNvbWUgd29yZGluZyBtb2RpZmljYXRpb25zLiBT bywgSSBkb24ndCB0aGluayB3ZSBhcmUgdG8gc2tpcCB0aGUNCj5hZGRpdGlvbmFsIHVzZSBjYXNl cyBldmVuIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50DQo+ cHJvcG9zYWwgaGF2ZSBiZWVuIGludGVncmF0ZWQgbm93Lg0KPg0KPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPngueC4gIEluZG9vciB1c2Fn ZSBvZiBUVldTDQo+DQo+ICAgQXQgcHJlc2VudCwgdGhlIGluZG9vciB3aXJlbGVzcyBjb3ZlcmFn ZSBlcXVpcG1lbnRzIGNvbnNpc3Qgb2YgV2ktRmktDQo+ICAgbGlrZSBhY2Nlc3MgcG9pbnRzIGFu ZCBtaWNybyBjZWxscywgYWxsIG9mIHRoZXNlIHV0aWxpemUgc2VnbWVudHMgb2YNCj4gICBmcmVx dWVuY3ksIGZvcm1lciBhdCBhYm91dCAyLjRHSHogb3IgNUdoeiBhbmQgdGhlIGxhdHRlciwgZm9y DQo+ICAgZXhhbXBsZSwgODAyLjExbiBhdCBhYm91dCAyLjRHSHouICBBcyBhIHJlc3VsdCBvZiB0 aGUgYmxvY2sgb2YNCj4gICBidWlsZGluZ3MgYW5kIG90aGVyIG9ic3RydWN0aW9uIGFuZCBpbnRl cmZlcmVjZSwgaXQgbWF5IG5vdCBiZSB0aGF0DQo+ICAgb3B0aW1pc3RpYyB3aGVuIDgwMi4xMSBk ZXZpY2VzIGV4YW1pbmUgdGhlIHN0YXR1cyBvZiB3aXJlbGVzcw0KPg0KPg0KPg0KPlpodSAgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMiAgICAgICAgICAgICAgICBb UGFnZSAzXQ0KPg0KPg0KPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUEFXUyB1c2UgY2Fz ZXMgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMQ0KPg0KPg0KPiAgIGludGVyZmVyZXMuICBU aGlzIHVzZSBjYXNlIHRha2VzIHRoZSBiZW5lZml0IG9mIFRWIFdoaXRlIFNwYWNlIHRvDQo+ICAg cHJvdmlkZSBhZGRpdGlvbmFsIGNhcGFjaXR5IHRvIGluZG9vciBjb3ZlcmFnZSBhbmQgcmVkdWNl IGNoYW5uZWwNCj4gICBpbnRlcmZlcmVjZS4NCj4NCj4gICBUaGUgZmlndXJlIGJlbG93IHNob3dz IGFuIGV4YW1wbGUgZGVwbG95bWVudCBvZiB0aGlzIHNjZW5hcmlvLg0KPg0KPiAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAgICAgICAgICB8 ICAgICAgICAgICAgaW5kb29yICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgIHdoaXRl IHNwYWNlICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KPiAgICAgICAgICAgICAgIHwgICAgfERl dmljZXwgLSAtIC0gLSAtIC0gLSAtIC0gLXwtIC18IE1pY3JvIGNlbGwgIHwNCj4gICAgICAgICAg ICAgICB8ICAgICstLS0tLS0rICBcICAgICAgICAgICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0r DQo+ICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgIFx3aGl0ZSBzcGFjZSAgICAgfCAgICAg KC0tLS0tKQ0KPiAgICAgICAgICAgICAgIHwgICAgfERldmljZXwgICAgXCArLS0tLS0tLS0tLS0t K3wgICAgLyAgICAgICBcDQo+ICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgICAgIHxhY2Nl c3MgcG9pbnR8fD09PSggSW50ZXJuZXQpDQo+ICAgICAgICAgICAgICAgfCAgICAgICAgbyAgICAg ICAvICstLS0tLS0tLS0tLS0rfCAgICBcICAgICAgIC8NCj4gICAgICAgICAgICAgICB8ICAgICAg ICBvICAgICAgLyAgICAgICAgICAgICAgICB8ICAgICAoLS0tLS0pDQo+ICAgICAgICAgICAgICAg fCAgICAgICAgbyAgICAgLyAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICBH cmFwaCAxIEluZG9vciB1c2FnZSBvZiBUVldTDQo+DQo+ICAgVGhlIGFjY2VzcyBwb2ludCBjb3Vs ZCBiZSBhIFdJLUZJIHJvdXRlciwgYW5kIHRoZSBtaWNybyBjZWxsIGlzIGENCj4gICBzaG9ydCBy YW5nZSB3aXJlbGVzcyBjb3ZlcmFnZShlLmcuIGluIHJhbmdlIG9mIDAtNTBtKSBiYXNlIHN0YXRp b24sDQo+ICAgYm90aCBvZiB0aGVtIGFjdCBhcyBtYXN0ZXIgZGV2aWNlcywgcXVlcnlpbmcgdGhl IGludGVybmV0IGNvbm5lY3RlZA0KPiAgIGRhdGFiYXNlIGZvciBhdmFpbGFibGUgd2hpdGUgc3Bh Y2Ugc3BlY3RydW0gYmFzZWQgb24gaXRzIGdlby0NCj4gICBsb2NhdGlvbiwgYW5kIHByb3ZpZGlu ZyBUVldTIGFjY2VzcyB0byBpbmRvb3IgdXNlci4NCj4NCj4gICBUaGUgVFZXUyBzcGVjdHJ1bSBo YXMgZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNoYXJhY3RlcmlzdGljcyBjb21wYXJlZA0KPiAgIHRv IGhpZ2hlciBmcmVxdWVuY3kgYmFuZCwgZm9yIGV4YW1wbGUsIHRoZSB0cmFuc21pc3Npb24gZGlz dGFuY2UNCj4gICB1c2luZyBUVldTIGNhbiBiZSBzZXZlcmFsIHRpbWVzIGxvbmdlciB0aGFuIHRo b3NlIGluIHRoZSBoaWdoZXIgYmFuZC4NCj4gICBJbiB0aGlzIGNhc2UsIGdvb2QgcGVuZXRyYXRp b24gY2hhcmFjdGVyaXN0aWMgb2YgVFZXUyBtYWtlcyBpdA0KPiAgIGRpZmZpY3VsdCB0byBsb2Nr IHRoZSBzaWduYWxzIGluIHRoZSByb29tLCB0aGVuIGRpZmZpY3VsdCB0byBsb2NhbGl6ZQ0KPiAg IGFuZCBkaWZmZXJlbnRpYXRlIHNpZ25hbHMsIGFuZCBmaW5hbGx5IGNhdXNlIGludGVyZmVyZXMg YW1vbmcNCj4gICBuZWlnaGJvcmluZyBuZXR3b3Jrcy4gIFJlcXVpcmVtZW50cyB0byBpbmRvb3Ig V1MgZGF0ZWJhc2UgdXNhZ2Ugd291bGQNCj4gICBiZToNCj4NCj4NCj4gICAxLiAgQSBmcmVxdWVu Y3kgcHJvdGVjdGlvbiBnYXAgYmV0d2VlbiBuZWlnaGJvcnMocGFydGljdWxhciBzcGVjdHJ1bQ0K PiAgICAgICBhbGxvY2F0aW9uIGFsZ29yaXRobSBpcyBuZWVkZWQgaGVyZSkuDQo+DQo+ICAgMi4g IGxvd2VyIG91dHB1dCBwb3dlciBvZiBBUC9taWNybyBjZWxsLCBpdCBzZWVtcyB0aGF0IG9ubHkg Y2VydGFpbg0KPiAgICAgICBwaWNvIG9yIGZlbXRvIGNlbGxzIGJlIGZlYXNpYmxlIGhlcmUuDQo+ DQo+ICAgMy4gIFBBV1MgbXVzdCBub3QgYmUgdGllZCB0byBhIHNwZWNpZmljIGZyZXF1ZW5jeSBi YW5kLg0KPg0KPiAgIDQuICBQQVdTIG11c3QgcmVzcG9uc2UgdGhlIHByb3BlciBmcmVxdWVuY3kg YmFuZCBsaXN0IHRvIHBhcnRpY3VsYXINCj4gICAgICAgY292ZXJhZ2Ugd2hpdGUgc3BhY2UgZGV2 aWNlcy4NCj4NCj4gICA1LiAgTWFzdGVyIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29u dHJvbC4NCj4NCj4gICA2LiAgU2xhdmUgZGV2aWNlcyBzaG91bGQgc3VwcG9ydCBwb3dlciBjb250 cm9sLg0KPg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPg0KPlpodSBMZWkNCj4NCj4NCj4tLS0tLdPKvP7Urbz+LS0tLS0NCj63orz+yMs6 IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBHZXJhbGQNCj5DaG91aW5hcmQNCj63osvNyrG85DogMjAxMcTqOdTCOMjVIDg6MDENCj7K1bz+ yMs6IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPrOty806IHBhd3NAaWV0Zi5vcmcNCj7W98ziOiBS ZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJl bWVudHMNCj4NCj5HYWJvciwNCj4NCj5DYW4gSSBhc2sgdGhhdCB0aGUgdGV4dCBtb2RpZmljYXRp b25zIHRoYXQgSSBoYXZlIHN1Ym1pdHRlZCB0byBzY290dCBhbmQNCj5jb3BpZWQgdG8gdGhlIHBh d3MgcmVmbGVjdG9yIGluIG15IGVtYWlsIGRhdGVkIDggQXVndXN0IGJlIGluY2x1ZGVkIGFzDQo+ d2VsbD8NCj4NCj5UaGFuaydzLA0KPg0KPkdlcmFsZA0KPg0KPg0KPkF0IDIwOjMyIDA3LTA5LTEx ICswMDAwLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+Pk9rLCBsZXQncyB0cnkgdGhh dCB0aGVuLg0KPj5TY290dCwgY2FuIHlvdSBwdXQgdXNlIGNhc2VzIGJlZm9yZSBQUywgYW5kIGFk ZCB0aGUgYWQtaG9jIHVzZSBjYXNlLiBJDQo+Pmp1c3Qgc2Nhbm5lZCB0aHJvdWdoIHRoZSBsaXN0 IGFuZCBzcG90dGVkIHRoYXQgVGVjbyBpbmRlZWQgcHJvdmlkZWQgYQ0KPj5kZXNjcmlwdGlvbiBm b3IgdGhhdCB1c2UgY2FzZSBvbiBBdWcgM3JkLg0KPj5BbmQgc3VibWl0IHRoZSBkcmFmdCBhcyBh IHdnIGl0ZW0sIHVubGVzcyB0aGVyZSBhcmUgc3RpbGwgb2JqZWN0aW9ucy4NCj4+DQo+Pi1HYWJv cg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogZXh0IE5hbmN5IEJy YXZpbiBbbWFpbHRvOm5icmF2aW5AZWFydGhsaW5rLm5ldF0NCj4+U2VudDogU2F0dXJkYXksIFNl cHRlbWJlciAwMywgMjAxMSAzOjQxIFBNDQo+PlRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1Np bGljb25WYWxsZXkpDQo+PkNjOiBUZWNvIEJvb3Q7IEdlcmFsZCBDaG91aW5hcmQ7IHBhd3NAaWV0 Zi5vcmcNCj4+U3ViamVjdDogUmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwg dXNlIGNhc2VzICYgcmVxdWlyZW1lbnRzDQo+Pg0KPj5EZWFyIEdhYm9yIGFuZCBBbGwsDQo+Pg0K Pj5JIHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRvIHB1dCB0aGUgdXNlIGNhc2VzIGJlZm9yZSB0 aGUgUFMgZm9yIG9idmlvdXMNCj4+cmVhc29ucywgYW5kIGluY2x1ZGluZyB0aGUgInByb3h5IiBu ZWVkIGluIHRoZSBmaXJzdCBkcmFmdC4gSSBzdXBwb3J0DQo+PmluY2x1ZGluZyBib3RoIEdlcmFs ZCdzIHN1Z2dlc3Rpb25zIGFuZCBUZWNvJ3MgcHJvcG9zYWwgaW4gdGhlIG9yaWdpbmFsDQo+PmRy YWZ0IGFuZCBub3Qgd2FpdGluZyB1bnRpbCBhIGxhdGVyIHRpbWUuIEl0IGlzIHRoZSBwcm9wZXIg b3JkZXIsDQo+PmluY2x1c2l2ZSBhbmQgbmVlZGVkIGluIHRoZSBpbml0aWFsIGRyYWZ0IGluIG15 IG9waW5pb24uIEkgYmVsaWV2ZSB3aXRoDQo+PnRoZSB0YWxlbnQgaW4gdGhlIGdyb3VwIGl0IHdp bGwgbm90IHRha2UgbG9uZyB0byBhY2NvbXBsaXNoIHRoaXMgYW5kIHlvdQ0KPj53aWxsIGhhdmUg YSBtb3JlIGNvaGVzaXZlIGRyYWZ0Lg0KPj4NCj4+U0luY2VyZWx5LCBOYW5jeQ0KPj4NCj4+DQo+ Pk9uIFNlcCAyLCAyMDExLCBhdCAyOjE5IFBNLCA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj48 R2Fib3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToNCj4+DQo+PiA+IFRlY28sIEdlcmFsZCwNCj4+ ID4NCj4+ID4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suIEknZCBzdWdnZXN0IHRoYXQgd2UgbWFr ZSB0aGlzIGRyYWZ0IGEgV0cNCj4+aXRlbSwgDQo+PiB3aXRoIEdlcmFsZCdzIHByb3Bvc2VkIGNo YW5nZXMgaW4gaXQuIFJlZ2FyZGluZyB0aGUgb3JkZXIgb2YgdGhlDQo+PnByb2JsZW0gDQo+PiBz dGF0ZW1lbnQgdnMgdXNlIGNhc2VzLCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGxlYXZlIGl0 IGFzIGl0IGlzDQo+PihidXQgDQo+PiB3ZSBjYW4gYWx3YXlzIGNoYW5nZSBpdCwgaWYgdGhhdCBp cyB3aGF0IHRoZSBXRyB3YW50cykuDQo+PiA+DQo+PiA+IFNvLCBJJ2QgYXNrIFNjb3R0IHRvIHN1 Ym1pdCBhIFdHIHZlcnNpb24gb2YgdGhpcyBkcmFmdCwgdGhlbiBoYXZlDQo+PiBzb21lb25lIGNv bWUgdXAgd2l0aCB0ZXh0IGZvciB0aGlzIGFkLWhvYyBuZXR3b3JrIHNjZW5hcmlvLCBoYXZlIHRo ZSBXRw0KPj4gYWdyZWUgd2l0aCB0aGUgdGV4dCBhbmQgaW5jbHVkZSBpdCBpbiBvbmUgb2YgdGhl IHN1YnNlcXVlbnQgdmVyc2lvbnMuDQo+PiBUZWNvLCB3b3VsZCB5b3Ugd3JpdGUgdXAgc29tZSB0 ZXh0IGZvciB0aGlzIGFkLWhvYyB1c2UgY2FzZSB0aGUgV0cNCj4+Y291bGQgDQo+PiBkaXNjdXNz Pw0KPj4gPg0KPj4gPiBXZSdsbCBhbHNvIHNlbmQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgbGlz dCBvZiByZXF1aXJlbWVudHMgdG8gdGhlDQo+PiBsaXN0IG5leHQgd2Vlay4NCj4+ID4NCj4+ID4g LSBHYWJvcg0KPj4gPg0KPj4gPg0KPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g PiBGcm9tOiBleHQgVGVjbyBCb290IFttYWlsdG86dGVjb0BpbmYtbmV0Lm5sXQ0KPj4gPiBTZW50 OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAxLCAyMDExIDExOjA2IFBNDQo+PiA+IFRvOiBCYWprbyBH YWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+PiA+IENjOiBwYXdzQGlldGYub3JnDQo+ PiA+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBj YXNlcyAmDQo+PiA+IHJlcXVpcmVtZW50cw0KPj4gPg0KPj4gPiBJIHRoaW5rIHRoZSBkb2MgaXMg YSBnb29kIHN0YXJ0aW5nIHBvaW50LiBJIHN1cHBvcnQgYWRvcHRpb24uDQo+PiA+DQo+PiA+IEkg c3VnZ2VzdCByZW9yZGVyaW5nOiBzcGVjaWZ5aW5nIHByb2JsZW0gc3RhdGVtZW50IGFmdGVyIGlu dHJvZHVjaW5nDQo+PiB0aGUgdXNlIGNhc2VzLg0KPj4gPg0KPj4gPiBTb21lIGFza2VkIGZvciB0 aGUgYWQgaG9jIG5ldHdvcmsgc2NlbmFyaW8uIFRoaXMgaW5jbHVkZXMgbWUgOi0pLg0KPj5UaGlz IA0KPj4gaXMgaW1wb3J0YW50LCBiZWNhdXNlIGl0IGRlbW9uc3RyYXRlcyB0aGUgbmVlZCBmb3Ig InByb3h5Ii4NCj4+ID4gQlRXLCBJIHdvbmRlciB3aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0 IHBvcCB1cCBmcm9tIFdpRmkNCj4+IGRlcGxveW1lbnRzLiBVc2FnZSBvZiBjb250cm9sbGVycyBp biBsYXJnZSBzaXRlcyBpcyBub3QgdW5jb21tb24uIE5vdA0KPj50byANCj4+IG1lbnRpb24gMTFz Lg0KPj4gPg0KPj4gPiBUaGUgcmVxdWlyZW1lbnRzIGlzIGxlZnQgb3Blbi4gSSdtIGxvb2tpbmcg Zm9yd2FyZCBzZWUgc29tZSBkcmFmdA0KPj50ZXh0Lg0KPj4gPg0KPj4gPiBUaGFua3MsIFRlY28N Cj4+ID4NCj4+ID4NCj4+ID4gT3AgMzAgYXVnIDIwMTEsIG9tIDE5OjQyIGhlZWZ0IDxHYWJvci5C YWprb0Bub2tpYS5jb20+DQo+PiA8R2Fib3IuQmFqa29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUg Z2VzY2hyZXZlbjoNCj4+ID4NCj4+ID4+IEkgc2VudCB0aGlzIGVtYWlsIHRvIHRoZSBsaXN0IG9u ZSB3ZWVrIGFnbywgYXNraW5nIGZvciBmZWVkYmFjayBvbg0KPj4gPj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10DQo+ PiA+PiBzIC0wMC50eHQgYnV0IHRoZXJlIHdhcyBub3Qgb25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJ IHRha2UgdGhhdCBhcw0KPj4gPj4gcGVvcGxlIGhhdmUgbm8gY29tbWVudHMgdG8gdGhlIGRyYWZ0 IGF0IHRoaXMgdGltZS4NCj4+ID4+DQo+PiA+PiBBbmQgSSBhbSBhc2tpbmcgYWdhaW46IGlzIHRo ZXJlIGFueSBvYmplY3Rpb24gaW4gYWRvcHRpbmcgdGhlIGFib3ZlDQo+PiBkcmFmdCBhcyBhIHdn IGRvY3VtZW50Pw0KPj4gPj4NCj4+ID4+IC1HYWJvcg0KPj4gPj4NCj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4gPj4gT2YgZXh0IEdhYm9yLkJh amtvQG5va2lhLmNvbQ0KPj4gPj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEgMjo0MyBQ TQ0KPj4gPj4gVG86IHBhd3NAaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29t YmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+PiA+PiByZXF1aXJlbWVudHMN Cj4+ID4+DQo+PiA+PiBEdXJpbmcgdGhlIFF1ZWJlYyBzZXNzaW9uLCB3ZSBoYWQgcHJlc2VudGF0 aW9ucyBvZiB0aGUgUFMgYW5kIHRoZQ0KPj51c2UgDQo+PiBjYXNlcyBkcmFmdHMuIFRoZSB3ZyB0 aGVuIGRlY2lkZWQgaXQgd2FudHMgdG8gc2VlIHRoZXNlIGRyYWZ0cyBtZXJnZWQNCj4+IGludG8g b25lLiBTY290dCBqdXN0IGRpZCB0aGF0IGFuZCBwb3N0ZWQgdGhlIG1lcmdlZCBkcmFmdDoNCj4+ ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0 bXQtdXNlY2FzZXMtcnFtdA0KPj4gPj4gcw0KPj4gPj4gLTAwLnR4dA0KPj4gPj4NCj4+ID4+IE5v dyBJIHdvdWxkIGxpa2UgdG8gYXNrIGlmIHRoZSB3ZyBmZWVscyBsaWtlIHRoaXMgZG9jdW1lbnQg aXMgcmVhZHkNCj4+dG8gDQo+PiBiZSBhZG9wdGVkIGFzIGEgd2cgZG9jdW1lbnQuIFBsZWFzZSBz ZW5kIHlvdXIgZmVlZGJhY2sgYW5kIGh1bSB0byB0aGUNCj4+IGxpc3QgYnkgdGhpcyB0aW1lIG5l eHQgd2Vlay4NCj4+ID4+DQo+PiA+PiAtR2Fib3INCj4+ID4+DQo+PiA+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+ID4+IC0NCj4+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPj4g RnJvbTogUHJvYmFzY28gU2NvdHQNCj4+ID4+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDEx IDk6MTggQU0NCj4+ID4+IFRvOiBwYXdzQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBjb21iaW5l ZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWlyZW1lbnRzDQo+PiA+Pg0KPj4g Pj4gSGksDQo+PiA+Pg0KPj4gPj4gQWNjb3JkaW5nIHRvIHRoZSByZXN1bHRzIG9mIHRoZSBmYWNl LXRvLWZhY2UgbWVldGluZywgd2UgaGF2ZQ0KPj5jb21iaW5lZCANCj4+IHRoZSBwcm9ibGVtIHN0 YXRlbWVudCBJLUQgYW5kIHVzZSBjYXNlICYgcmVxdWlyZW1lbnQgSS1EIGludG8gYSBzaW5nbGUN Cj4+IEktRC4gIFlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWVkLg0KPj4gPj4NCj4+ID4+IFJlZ2Fy ZHMsDQo+PiA+PiBTY290dA0KPj4gPj4NCj4+ID4+IFVSTDoNCj4+ID4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0K Pj4gPj4gcw0KPj4gPj4gLTAwLnR4dA0KPj4gPj4NCj4+ID4+DQo+PiA+PiBBYnN0cmFjdDoNCj4+ ID4+IFBvcnRpb25zIG9mIHRoZSByYWRpbyBzcGVjdHJ1bSB0aGF0IGFyZSBhbGxvY2F0ZWQgdG8g YSBsaWNlbnNlZCwNCj4+ID4+IHByaW1hcnkgdXNlciBidXQgYXJlIHVudXNlZCBvciB1bm9jY3Vw aWVkIGF0IHNwZWNpZmljIGxvY2F0aW9ucyBhbmQNCj4+ID4+IHRpbWVzIGFyZSBkZWZpbmVkIGFz ICd3aGl0ZSBzcGFjZScuICBUaGUgY29uY2VwdCBvZiBhbGxvd2luZw0KPj4gPj4gc2Vjb25kYXJ5 IHRyYW5zbWlzc2lvbnMgKGxpY2Vuc2VkIG9yIHVubGljZW5zZWQpIGluIHdoaXRlIHNwYWNlIGlz IGENCj4+ID4+IHRlY2huaXF1ZSB0byAndW5sb2NrJyBleGlzdGluZyBzcGVjdHJ1bSBmb3IgbmV3 IHVzZS4gIEFuIG9idmlvdXMNCj4+ID4+IHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlc2Ugc2Vjb25k YXJ5IHRyYW5zbWlzc2lvbnMgZG8gbm90IGludGVyZmVyZQ0KPj4gPj4gd2l0aCB0aGUgcHJpbWFy eSB1c2Ugb2YgdGhlIHNwZWN0cnVtLiAgT25lIGFwcHJvYWNoIHRvIHVzaW5nIHRoZQ0KPj4gPj4g d2hpdGUgc3BhY2Ugc3BlY3RydW0gYXQgYSBnaXZlbiB0aW1lIGFuZCBsb2NhdGlvbiBpcyB0byB2 ZXJpZnkgd2l0aCBhDQo+PiA+PiBkYXRhYmFzZSBhdmFpbGFibGUgY2hhbm5lbHMuDQo+PiA+Pg0K Pj4gPj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGNvbmNlcHQgb2YgVFYgV2hpdGUgU3Bh Y2VzLiAgSXQgYWxzbw0KPj4gPj4gZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyB0aGF0IG5lZWQgdG8g YmUgYWRkcmVzc2VkIGZvciBlbmFibGluZyB0aGUgdXNlDQo+PiA+PiBvZiB0aGUgcHJpbWFyeSB1 c2VyIG93bmVkIHdoaXRlIHNwYWNlIHNwZWN0cnVtIGZvciBzZWNvbmRhcnkgdXNlcnMsDQo+PiA+ PiB3aXRob3V0IGNhdXNpbmcgaW50ZXJmZXJlbmNlLCBieSBxdWVyeWluZyBhIGRhdGFiYXNlIHdo aWNoIGtub3dzIHRoZQ0KPj4gPj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgYXQgYW55IGdpdmVuIGxv Y2F0aW9uIGFuZCB0aW1lLiAgQSBudW1iZXIgb2YNCj4+ID4+IHBvc3NpYmxlIHVzZSBjYXNlcyBv ZiB0aGlzIHNwZWN0cnVtIGFuZCBkZXJpdmVkIHJlcXVpcmVtZW50cyBhcmUgYWxzbw0KPj4gPj4g ZGVzY3JpYmVkLg0KPj4gPj4NCj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiA+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4gPj4gcGF3c0BpZXRm Lm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+ID4+IHBhd3NAaWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4gPg0KPj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBwYXdzIG1haWxpbmcg bGlzdA0KPj4gPiBwYXdzQGlldGYub3JnDQo+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+cGF3cyBtYWlsaW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wYXdzIG1haWxpbmcgbGlzdA0K PnBhd3NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg0K From Gabor.Bajko@nokia.com Thu Sep 8 12:54: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 75AC721F8B52 for ; Thu, 8 Sep 2011 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 eiR-4ULrCfpa for ; Thu, 8 Sep 2011 12:54:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A121F8B3C for ; Thu, 8 Sep 2011 12:54:45 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p88JuZiI031276; Thu, 8 Sep 2011 22:56:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 22:56:31 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 21:56:30 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.245]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Thu, 8 Sep 2011 21:56:29 +0200 From: To: , Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMYOcQvI202O9wxE+XVjq4c4dCVJUpXkBwgAxXBHCAA9RNgIABHcBggAGKfgCABoExof//+L0AgABTstCAAADBgIAA/cAQ Date: Thu, 8 Sep 2011 19:56:28 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760FA954@008-AM1MPN1-007.mgdnok.nokia.com> References: <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <1ECAFF543A2FED4EA2BEB6CACE08E47609B2A8@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760BE84E@008-AM1MPN1-007.mgdnok.nokia.com> <94D53BF2-B64A-4786-933D-0C0C49147CE4@inf-net.nl> <1ECAFF543A2FED4EA2BEB6CACE08E4760DAC9A@008-AM1MPN1-001.mgdnok.nokia.com> <2672C046-72B8-4145-B469-627AAE061FFC@earthlink.net> <5.1.0.14.2.20110907195448.02bccf50@imap.crc.ca> <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760FA660@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62539B899@szxeml504-mbx.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE62539B899@szxeml504-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.187] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 19:56:31.0097 (UTC) FILETIME=[674E4E90:01CC6E61] 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: Thu, 08 Sep 2011 19:54:47 -0000 Wmh1IExlaSwNCg0KTm90ZSwgdGhhdCBDb2duaXRpdmUgUmFkaW8gYXNwZWN0cyBhcmUgbm90IHBh cnQgb2YgdGhlIGN1cnJlbnQgcGF3cyBjaGFydGVyLiANCkknZCBub3cgZW5jb3VyYWdlIHRoZSBl ZGl0b3IgdG8gc3VibWl0IGEgbmV3IHZlcnNpb24gIG9mIHRoZSBkcmFmdCBhcyBhIHdnIGl0ZW0g aW5jb3Jwb3JhdGluZyB0aGUgY2hhbmdlcyBhZ3JlZWQgc28gZmFyIG9uIHRoZSBsaXN0LCB0aGVu IHdlIGNhbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB3aGF0IGFkZGl0aW9uYWwgdXNlIGNh c2VzIHRvIGluY29ycG9yYXRlIGludG8gdGhlIG5vdyB3ZyBkcmFmdC4gDQpJbiB0aGUgbWVhbnRp bWUsIEkgaG9wZSBaaHUgTGVpIGNhbiBwdXQgaXRzIHByb3Bvc2VkIHVzZXMgY2FzZXMgaW50byBh IG1vcmUgdW5kZXJzdGFuZGFibGUgZm9ybWF0IChhbmQgaW4gbGluZSB3aXRoIHRoZSB0ZW1wbGF0 ZSBmb2xsb3dlZCBieSB0aGUgb3RoZXIgdXNlIGNhc2UgZGVzY3JpcHRpb25zIGluIHRoZSBkcmFm dCkgYW5kIGtlZXAgdGhlbSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBjdXJyZW50IGNoYXJ0ZXIu IFRoZW4gd2UgY2FuIGRlYmF0ZSBvbiB0aGUgbGlzdCBpZiB0aGUgdXNlIGNhc2VzIGhhdmUgZW5v dWdoIG1lcml0IHRvIGJlIGFkZGVkIHRvIHRoZSB3ZyBkcmFmdC4gQW5kIGFzIHlvdSBzYWlkIFpo dSBMZWksIHdlIGRvIG5vdCBuZWVkIHRvIHdhaXQgd2l0aCB0aGF0IHVudGlsIHRoZSBuZXh0IGYy Ziwgd2UgY2FuIGRlY2lkZSBoZXJlIG9uIHRoZSBsaXN0LCBob3BlZnVsbHkgYmVmb3JlIHRoZSBU YWlwZWkgZjJmLg0KLWdhYm9yDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGV4dCBaaHVMZWkgW21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dIA0KU2VudDogV2VkbmVzZGF5 LCBTZXB0ZW1iZXIgMDcsIDIwMTEgMTE6MzcgUE0NClRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lD L1NpbGljb25WYWxsZXkpDQpDYzogcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwYXdzXSBj b21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWlyZW1lbnRzDQoNCkhp IEdhYm9yLA0KDQpUaGUgaW5kb29yIGlzIHN0aWxsIHRoZSBuZWNlc3NhcnkgcGFydCBvZiBDb2du aXRpdmUgUmFkaW8gYW5kIFBBV1MgaXNzdWUuIENvbXBhcmluZyB3aXRoIHRoZSBzdGF0ZWQgdXNl IGNhc2VzIGluIGNvbWJpbmVkIHByb3Bvc2VkIGRyYWZ0LCB0aGUgaW5kb29yIGFuZCBhZCBob2Mg c2NlbmFyaW9zIG1heSBiZSBtb3JlIGltcG9ydGFudCB0byBiZSBpbmNvcnBvcmF0ZWQgYWNjb3Jk aW5nIHRvIG15IHVuZGVyc3RhbmRpbmcgc2luY2UgdGhlIHdvcmtpbmcgZ3JvdXAgd291bGQgbGlr ZWx5IHRvIGF2b2lkIHRoYXQgdGhlIGRpZmZlcmVudCBmcmVxdWVudCBiYW5kcyB3ZXJlIHVzZWQg aW4gcHJvcGVyIHNjZW5hcmlvKHMpLiBJIGFtIG5vdCB0byBzZWUgYSBhZ3JlZWQgZHJhZnQgd2l0 aG91dCBzdWNoIGluc3VyYW5jZSBvZiBpbmRvb3IgY292ZXJhZ2UgYW5kIGFkIGhvYyBzY2VuYXJp b3MuIEFuZCwgaXQgaXMgb2YgY291cnNlIGEgbmVlZCB0byBrZWVwIHVzZSBjYXNlcyB2aXNpYmxl IHdoZW4gc3RhcnRpbmcgcHJvdG9jb2wgZGV2ZWxvcG1lbnRzLiANCg0KU28sIEkgYWxzbyB0aGlu ayB0aGF0IGVkaXRvciAoU2NvdHQ/KSBjYW4gY29uc2lkZXIgdGhlIHByb3Bvc2VkIHVzZSBjYXNl cyBoZXJlIGFzIG5lY2Vzc2FyeSBidXQgbm90IHdhaXRpbmcgZm9yIG5leHQgZjJmIG1lZXRpbmcu IA0KDQpCZXN0IHJlZ2FyZHMsDQpaaHUgTGVpDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+ yMs6IEdhYm9yLkJhamtvQG5va2lhLmNvbSBbbWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbV0N Creiy83KsbzkOiAyMDExxOo51MI4yNUgMTI6NDQNCsrVvP7IyzogWmh1TGVpDQqzrcvNOiBwYXdz QGlldGYub3JnDQrW98ziOiBSRTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1 c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCg0KWmh1IExlaSwNCg0KVGhlIGNoYXJ0ZXIgZXhwbGlj aXRseSBzdGF0ZXMgdGhhdCBQQVdTIGlzIHRvIGJlIGtlcHQgdGVjaG5vbG9neSBhZ25vc3RpYy4g VGh1cywgbHRlIG1ibXMgdXNlIGNhc2UgaXMgb3V0IG9mIHF1ZXN0aW9uLiBXZSBqdXN0IGFncmVl ZCB0byBhZGQgYW4gYWQtaG9jIG5ldHdvcmsgdXNlIGNhc2UsIGFuZCB0aGUgLTAwIHZlcnNpb24g b2YgdGhlIGRyYWZ0IGFscmVhZHkgaGFzIGEgbG9jYXRpb24gYmFzZWQgc2VydmljZSB1c2UgY2Fz ZSBzY2VuYXJpbyB3aGljaCBsb29rcyB0byBtZSB0byBiZSBhIHN1cGVyc2V0IG9mIHRoZSB1c2Ug Y2FzZSB5b3UgcHJvdmlkZWQgYmVsb3cgKGlmIEkgdW5kZXJzdG9vZCB5b3VyIHVzZSBjYXNlIGNv cnJlY3RseSkuDQoNCkJ1dCBJIGRvIG5vdCB3YW50IHRvIHNwZWFrIGluIHRoZSBuYW1lIG9mIHRo ZSBlZGl0b3IuIEN1cnJlbnRseSB0aGUgZHJhZnQgaXMgc3RpbGwgYW4gaW5kaXZpZHVhbCBzdWJt aXNzaW9uLCBzbyBpdCBpcyB1cCB0byB0aGUgZWRpdG9yIHRvIGluY29ycG9yYXRlIGFueSBzdWdn ZXN0aW9uIGZyb20gdGhlIGxpc3QgdG8gaXRzIG93biBkcmFmdC4gVGhpcyB3b3VsZCBjaGFuZ2Ug b25jZSB0aGUgZHJhZnQgaXMgbWFkZSBhIHdnIGl0ZW0uIFRoZXJlZm9yZSwgSSdkIHByb3Bvc2Ug d2UgbWFrZSB0aGlzIGRyYWZ0IGEgd2cgaXRlbS4NCg0KLUdhYm9yDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgWmh1TGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWkuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDcsIDIwMTEgNjozNSBQTQ0KVG86IEdlcmFs ZCBDaG91aW5hcmQ7IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNCkNjOiBw YXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVt ZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCg0KSGkgYWxsLA0KDQpJIHRoaW5rIHRoYXQg d2UgZG8gc29tZSB3b3JrcyBvbiBpbXByb3Zpbmcgb3JpZ2luYWwgdXNlIGNhc2UgZHJhZnQgYnkg YWRkaW5nIHRocmVlIGFkZGl0aW9uYWwgdXNlIGNhc2VzLCBpbmNsdWRpbmcgaW5kb29yIGNvdmVy YWdlLCBhZCBob2MgbmV0d29yayBhbmQgbHRlIG1ibXMgaXNzdWUuDQoNCk5vdywgSSBhbSBhc2tp bmcgdG8gYWRkIGluZG9vciBjb3ZlcmFnZSBzY2VuYXJpbyB3aGljaCBpcyBuZWNlc3NhcnkgZm9y IFBBV1MgcHJvdG9jb2wgdG8gY29uc2lkZXIgaW4gbmV4dCBzdGFnZS4gVGhlIHByb3Bvc2VkIHVz ZSBjYXNlIGlzIHNlZW4gYmVsb3cuIFRoZSB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBp cyB0byBiZSBzdWJtaXR0ZWQgc29vbiBieSBhZGRpbmcgc29tZSB3b3JkaW5nIG1vZGlmaWNhdGlv bnMuIFNvLCBJIGRvbid0IHRoaW5rIHdlIGFyZSB0byBza2lwIHRoZSBhZGRpdGlvbmFsIHVzZSBj YXNlcyBldmVuIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50 IHByb3Bvc2FsIGhhdmUgYmVlbiBpbnRlZ3JhdGVkIG5vdy4NCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp4LnguICBJbmRvb3IgdXNhZ2Ug b2YgVFZXUw0KDQogICBBdCBwcmVzZW50LCB0aGUgaW5kb29yIHdpcmVsZXNzIGNvdmVyYWdlIGVx dWlwbWVudHMgY29uc2lzdCBvZiBXaS1GaS0NCiAgIGxpa2UgYWNjZXNzIHBvaW50cyBhbmQgbWlj cm8gY2VsbHMsIGFsbCBvZiB0aGVzZSB1dGlsaXplIHNlZ21lbnRzIG9mDQogICBmcmVxdWVuY3ks IGZvcm1lciBhdCBhYm91dCAyLjRHSHogb3IgNUdoeiBhbmQgdGhlIGxhdHRlciwgZm9yDQogICBl eGFtcGxlLCA4MDIuMTFuIGF0IGFib3V0IDIuNEdIei4gIEFzIGEgcmVzdWx0IG9mIHRoZSBibG9j ayBvZg0KICAgYnVpbGRpbmdzIGFuZCBvdGhlciBvYnN0cnVjdGlvbiBhbmQgaW50ZXJmZXJlY2Us IGl0IG1heSBub3QgYmUgdGhhdA0KICAgb3B0aW1pc3RpYyB3aGVuIDgwMi4xMSBkZXZpY2VzIGV4 YW1pbmUgdGhlIHN0YXR1cyBvZiB3aXJlbGVzcw0KDQoNCg0KWmh1ICAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoNCg0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBQQVdTIHVzZSBjYXNlcyAgICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDExDQoNCg0KICAgaW50ZXJmZXJlcy4gIFRoaXMgdXNlIGNhc2UgdGFrZXMg dGhlIGJlbmVmaXQgb2YgVFYgV2hpdGUgU3BhY2UgdG8NCiAgIHByb3ZpZGUgYWRkaXRpb25hbCBj YXBhY2l0eSB0byBpbmRvb3IgY292ZXJhZ2UgYW5kIHJlZHVjZSBjaGFubmVsDQogICBpbnRlcmZl cmVjZS4NCg0KICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlIGRlcGxveW1lbnQg b2YgdGhpcyBzY2VuYXJpby4NCg0KICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgIGluZG9vciAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgfCAgICArLS0tLS0tKyAgIHdoaXRlIHNwYWNlICAgICAgfCAgICstLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgICAgfCAgICB8RGV2aWNlfCAtIC0gLSAtIC0gLSAtIC0gLSAtfC0gLXwg TWljcm8gY2VsbCAgfA0KICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgXCAgICAgICAgICAg ICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAg IFx3aGl0ZSBzcGFjZSAgICAgfCAgICAgKC0tLS0tKQ0KICAgICAgICAgICAgICAgfCAgICB8RGV2 aWNlfCAgICBcICstLS0tLS0tLS0tLS0rfCAgICAvICAgICAgIFwNCiAgICAgICAgICAgICAgIHwg ICAgKy0tLS0tLSsgICAgICB8YWNjZXNzIHBvaW50fHw9PT0oIEludGVybmV0KQ0KICAgICAgICAg ICAgICAgfCAgICAgICAgbyAgICAgICAvICstLS0tLS0tLS0tLS0rfCAgICBcICAgICAgIC8NCiAg ICAgICAgICAgICAgIHwgICAgICAgIG8gICAgICAvICAgICAgICAgICAgICAgIHwgICAgICgtLS0t LSkNCiAgICAgICAgICAgICAgIHwgICAgICAgIG8gICAgIC8gICAgICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQogICAgICAgICAg ICAgICAgICAgICAgIEdyYXBoIDEgSW5kb29yIHVzYWdlIG9mIFRWV1MNCg0KICAgVGhlIGFjY2Vz cyBwb2ludCBjb3VsZCBiZSBhIFdJLUZJIHJvdXRlciwgYW5kIHRoZSBtaWNybyBjZWxsIGlzIGEN CiAgIHNob3J0IHJhbmdlIHdpcmVsZXNzIGNvdmVyYWdlKGUuZy4gaW4gcmFuZ2Ugb2YgMC01MG0p IGJhc2Ugc3RhdGlvbiwNCiAgIGJvdGggb2YgdGhlbSBhY3QgYXMgbWFzdGVyIGRldmljZXMsIHF1 ZXJ5aW5nIHRoZSBpbnRlcm5ldCBjb25uZWN0ZWQNCiAgIGRhdGFiYXNlIGZvciBhdmFpbGFibGUg d2hpdGUgc3BhY2Ugc3BlY3RydW0gYmFzZWQgb24gaXRzIGdlby0NCiAgIGxvY2F0aW9uLCBhbmQg cHJvdmlkaW5nIFRWV1MgYWNjZXNzIHRvIGluZG9vciB1c2VyLg0KDQogICBUaGUgVFZXUyBzcGVj dHJ1bSBoYXMgZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNoYXJhY3RlcmlzdGljcyBjb21wYXJlZA0K ICAgdG8gaGlnaGVyIGZyZXF1ZW5jeSBiYW5kLCBmb3IgZXhhbXBsZSwgdGhlIHRyYW5zbWlzc2lv biBkaXN0YW5jZQ0KICAgdXNpbmcgVFZXUyBjYW4gYmUgc2V2ZXJhbCB0aW1lcyBsb25nZXIgdGhh biB0aG9zZSBpbiB0aGUgaGlnaGVyIGJhbmQuDQogICBJbiB0aGlzIGNhc2UsIGdvb2QgcGVuZXRy YXRpb24gY2hhcmFjdGVyaXN0aWMgb2YgVFZXUyBtYWtlcyBpdA0KICAgZGlmZmljdWx0IHRvIGxv Y2sgdGhlIHNpZ25hbHMgaW4gdGhlIHJvb20sIHRoZW4gZGlmZmljdWx0IHRvIGxvY2FsaXplDQog ICBhbmQgZGlmZmVyZW50aWF0ZSBzaWduYWxzLCBhbmQgZmluYWxseSBjYXVzZSBpbnRlcmZlcmVz IGFtb25nDQogICBuZWlnaGJvcmluZyBuZXR3b3Jrcy4gIFJlcXVpcmVtZW50cyB0byBpbmRvb3Ig V1MgZGF0ZWJhc2UgdXNhZ2Ugd291bGQNCiAgIGJlOg0KDQoNCiAgIDEuICBBIGZyZXF1ZW5jeSBw cm90ZWN0aW9uIGdhcCBiZXR3ZWVuIG5laWdoYm9ycyhwYXJ0aWN1bGFyIHNwZWN0cnVtDQogICAg ICAgYWxsb2NhdGlvbiBhbGdvcml0aG0gaXMgbmVlZGVkIGhlcmUpLg0KDQogICAyLiAgbG93ZXIg b3V0cHV0IHBvd2VyIG9mIEFQL21pY3JvIGNlbGwsIGl0IHNlZW1zIHRoYXQgb25seSBjZXJ0YWlu DQogICAgICAgcGljbyBvciBmZW10byBjZWxscyBiZSBmZWFzaWJsZSBoZXJlLg0KDQogICAzLiAg UEFXUyBtdXN0IG5vdCBiZSB0aWVkIHRvIGEgc3BlY2lmaWMgZnJlcXVlbmN5IGJhbmQuDQoNCiAg IDQuICBQQVdTIG11c3QgcmVzcG9uc2UgdGhlIHByb3BlciBmcmVxdWVuY3kgYmFuZCBsaXN0IHRv IHBhcnRpY3VsYXINCiAgICAgICBjb3ZlcmFnZSB3aGl0ZSBzcGFjZSBkZXZpY2VzLg0KDQogICA1 LiAgTWFzdGVyIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29udHJvbC4NCg0KICAgNi4g IFNsYXZlIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29udHJvbC4NCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClpodSBMZWkN Cg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEdlcmFsZCBDaG91aW5hcmQNCreiy83K sbzkOiAyMDExxOo51MI4yNUgODowMQ0KytW8/sjLOiBHYWJvci5CYWprb0Bub2tpYS5jb20NCrOt y806IHBhd3NAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0 ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cw0KDQpHYWJvciwNCg0KQ2FuIEkgYXNrIHRo YXQgdGhlIHRleHQgbW9kaWZpY2F0aW9ucyB0aGF0IEkgaGF2ZSBzdWJtaXR0ZWQgdG8gc2NvdHQg YW5kIGNvcGllZCB0byB0aGUgcGF3cyByZWZsZWN0b3IgaW4gbXkgZW1haWwgZGF0ZWQgOCBBdWd1 c3QgYmUgaW5jbHVkZWQgYXMgd2VsbD8NCg0KVGhhbmsncywNCg0KR2VyYWxkDQoNCg0KQXQgMjA6 MzIgMDctMDktMTEgKzAwMDAsIEdhYm9yLkJhamtvQG5va2lhLmNvbSB3cm90ZToNCj5PaywgbGV0 J3MgdHJ5IHRoYXQgdGhlbi4NCj5TY290dCwgY2FuIHlvdSBwdXQgdXNlIGNhc2VzIGJlZm9yZSBQ UywgYW5kIGFkZCB0aGUgYWQtaG9jIHVzZSBjYXNlLiBJIA0KPmp1c3Qgc2Nhbm5lZCB0aHJvdWdo IHRoZSBsaXN0IGFuZCBzcG90dGVkIHRoYXQgVGVjbyBpbmRlZWQgcHJvdmlkZWQgYSANCj5kZXNj cmlwdGlvbiBmb3IgdGhhdCB1c2UgY2FzZSBvbiBBdWcgM3JkLg0KPkFuZCBzdWJtaXQgdGhlIGRy YWZ0IGFzIGEgd2cgaXRlbSwgdW5sZXNzIHRoZXJlIGFyZSBzdGlsbCBvYmplY3Rpb25zLg0KPg0K Pi1HYWJvcg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZXh0IE5hbmN5 IEJyYXZpbiBbbWFpbHRvOm5icmF2aW5AZWFydGhsaW5rLm5ldF0NCj5TZW50OiBTYXR1cmRheSwg U2VwdGVtYmVyIDAzLCAyMDExIDM6NDEgUE0NCj5UbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9T aWxpY29uVmFsbGV5KQ0KPkNjOiBUZWNvIEJvb3Q7IEdlcmFsZCBDaG91aW5hcmQ7IHBhd3NAaWV0 Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1 c2UgY2FzZXMgJiANCj5yZXF1aXJlbWVudHMNCj4NCj5EZWFyIEdhYm9yIGFuZCBBbGwsDQo+DQo+ SSB0aGluayBpdCBpcyBhcHByb3ByaWF0ZSB0byBwdXQgdGhlIHVzZSBjYXNlcyBiZWZvcmUgdGhl IFBTIGZvciANCj5vYnZpb3VzIHJlYXNvbnMsIGFuZCBpbmNsdWRpbmcgdGhlICJwcm94eSIgbmVl ZCBpbiB0aGUgZmlyc3QgZHJhZnQuIEkgDQo+c3VwcG9ydCBpbmNsdWRpbmcgYm90aCBHZXJhbGQn cyBzdWdnZXN0aW9ucyBhbmQgVGVjbydzIHByb3Bvc2FsIGluIHRoZSANCj5vcmlnaW5hbCBkcmFm dCBhbmQgbm90IHdhaXRpbmcgdW50aWwgYSBsYXRlciB0aW1lLiBJdCBpcyB0aGUgcHJvcGVyIA0K Pm9yZGVyLCBpbmNsdXNpdmUgYW5kIG5lZWRlZCBpbiB0aGUgaW5pdGlhbCBkcmFmdCBpbiBteSBv cGluaW9uLiBJIA0KPmJlbGlldmUgd2l0aCB0aGUgdGFsZW50IGluIHRoZSBncm91cCBpdCB3aWxs IG5vdCB0YWtlIGxvbmcgdG8gDQo+YWNjb21wbGlzaCB0aGlzIGFuZCB5b3Ugd2lsbCBoYXZlIGEg bW9yZSBjb2hlc2l2ZSBkcmFmdC4NCj4NCj5TSW5jZXJlbHksIE5hbmN5DQo+DQo+DQo+T24gU2Vw IDIsIDIwMTEsIGF0IDI6MTkgUE0sIDxHYWJvci5CYWprb0Bub2tpYS5jb20+IA0KPjxHYWJvci5C YWprb0Bub2tpYS5jb20+IHdyb3RlOg0KPg0KPiA+IFRlY28sIEdlcmFsZCwNCj4gPg0KPiA+IFRo YW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBJJ2Qgc3VnZ2VzdCB0aGF0IHdlIG1ha2UgdGhpcyBkcmFm dCBhIFdHIA0KPiA+IGl0ZW0sDQo+IHdpdGggR2VyYWxkJ3MgcHJvcG9zZWQgY2hhbmdlcyBpbiBp dC4gUmVnYXJkaW5nIHRoZSBvcmRlciBvZiB0aGUgDQo+IHByb2JsZW0gc3RhdGVtZW50IHZzIHVz ZSBjYXNlcywgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBsZWF2ZSBpdCBhcyANCj4gaXQgaXMg KGJ1dCB3ZSBjYW4gYWx3YXlzIGNoYW5nZSBpdCwgaWYgdGhhdCBpcyB3aGF0IHRoZSBXRyB3YW50 cykuDQo+ID4NCj4gPiBTbywgSSdkIGFzayBTY290dCB0byBzdWJtaXQgYSBXRyB2ZXJzaW9uIG9m IHRoaXMgZHJhZnQsIHRoZW4gaGF2ZQ0KPiBzb21lb25lIGNvbWUgdXAgd2l0aCB0ZXh0IGZvciB0 aGlzIGFkLWhvYyBuZXR3b3JrIHNjZW5hcmlvLCBoYXZlIHRoZSANCj4gV0cgYWdyZWUgd2l0aCB0 aGUgdGV4dCBhbmQgaW5jbHVkZSBpdCBpbiBvbmUgb2YgdGhlIHN1YnNlcXVlbnQgdmVyc2lvbnMu DQo+IFRlY28sIHdvdWxkIHlvdSB3cml0ZSB1cCBzb21lIHRleHQgZm9yIHRoaXMgYWQtaG9jIHVz ZSBjYXNlIHRoZSBXRyANCj4gY291bGQgZGlzY3Vzcz8NCj4gPg0KPiA+IFdlJ2xsIGFsc28gc2Vu ZCBhbiBpbml0aWFsIHZlcnNpb24gb2YgYSBsaXN0IG9mIHJlcXVpcmVtZW50cyB0byB0aGUNCj4g bGlzdCBuZXh0IHdlZWsuDQo+ID4NCj4gPiAtIEdhYm9yDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZXh0IFRlY28gQm9vdCBbbWFpbHRvOnRlY29A aW5mLW5ldC5ubF0NCj4gPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAxLCAyMDExIDExOjA2 IFBNDQo+ID4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNCj4gPiBD YzogcGF3c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxl bSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIA0KPiA+IHJlcXVpcmVtZW50cw0KPiA+DQo+ID4gSSB0 aGluayB0aGUgZG9jIGlzIGEgZ29vZCBzdGFydGluZyBwb2ludC4gSSBzdXBwb3J0IGFkb3B0aW9u Lg0KPiA+DQo+ID4gSSBzdWdnZXN0IHJlb3JkZXJpbmc6IHNwZWNpZnlpbmcgcHJvYmxlbSBzdGF0 ZW1lbnQgYWZ0ZXIgaW50cm9kdWNpbmcNCj4gdGhlIHVzZSBjYXNlcy4NCj4gPg0KPiA+IFNvbWUg YXNrZWQgZm9yIHRoZSBhZCBob2MgbmV0d29yayBzY2VuYXJpby4gVGhpcyBpbmNsdWRlcyBtZSA6 LSkuIA0KPiA+IFRoaXMNCj4gaXMgaW1wb3J0YW50LCBiZWNhdXNlIGl0IGRlbW9uc3RyYXRlcyB0 aGUgbmVlZCBmb3IgInByb3h5Ii4NCj4gPiBCVFcsIEkgd29uZGVyIHdoeSBzaW1pbGFyIHNjZW5h cmlvIGRvZXNuJ3QgcG9wIHVwIGZyb20gV2lGaQ0KPiBkZXBsb3ltZW50cy4gVXNhZ2Ugb2YgY29u dHJvbGxlcnMgaW4gbGFyZ2Ugc2l0ZXMgaXMgbm90IHVuY29tbW9uLiBOb3QgDQo+IHRvIG1lbnRp b24gMTFzLg0KPiA+DQo+ID4gVGhlIHJlcXVpcmVtZW50cyBpcyBsZWZ0IG9wZW4uIEknbSBsb29r aW5nIGZvcndhcmQgc2VlIHNvbWUgZHJhZnQgdGV4dC4NCj4gPg0KPiA+IFRoYW5rcywgVGVjbw0K PiA+DQo+ID4NCj4gPiBPcCAzMCBhdWcgMjAxMSwgb20gMTk6NDIgaGVlZnQgPEdhYm9yLkJhamtv QG5va2lhLmNvbT4NCj4gPEdhYm9yLkJhamtvQG5va2lhLmNvbT4gaGV0IHZvbGdlbmRlIGdlc2No cmV2ZW46DQo+ID4NCj4gPj4gSSBzZW50IHRoaXMgZW1haWwgdG8gdGhlIGxpc3Qgb25lIHdlZWsg YWdvLCBhc2tpbmcgZm9yIGZlZWRiYWNrIG9uIA0KPiA+PiBodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LXByb2Jhc2NvLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxDQo+ID4+IG10IHMg LTAwLnR4dCBidXQgdGhlcmUgd2FzIG5vdCBvbmUgZmVlZGJhY2sgcmVjZWl2ZWQuIEkgdGFrZSB0 aGF0IA0KPiA+PiBhcyBwZW9wbGUgaGF2ZSBubyBjb21tZW50cyB0byB0aGUgZHJhZnQgYXQgdGhp cyB0aW1lLg0KPiA+Pg0KPiA+PiBBbmQgSSBhbSBhc2tpbmcgYWdhaW46IGlzIHRoZXJlIGFueSBv YmplY3Rpb24gaW4gYWRvcHRpbmcgdGhlIGFib3ZlDQo+IGRyYWZ0IGFzIGEgd2cgZG9jdW1lbnQ/ DQo+ID4+DQo+ID4+IC1HYWJvcg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+PiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIA0KPiA+PiBCZWhhbGYgT2YgZXh0IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0K PiA+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSAyOjQzIFBNDQo+ID4+IFRvOiBwYXdz QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0 ZW1lbnQsIHVzZSBjYXNlcyAmIA0KPiA+PiByZXF1aXJlbWVudHMNCj4gPj4NCj4gPj4gRHVyaW5n IHRoZSBRdWViZWMgc2Vzc2lvbiwgd2UgaGFkIHByZXNlbnRhdGlvbnMgb2YgdGhlIFBTIGFuZCB0 aGUgDQo+ID4+IHVzZQ0KPiBjYXNlcyBkcmFmdHMuIFRoZSB3ZyB0aGVuIGRlY2lkZWQgaXQgd2Fu dHMgdG8gc2VlIHRoZXNlIGRyYWZ0cyBtZXJnZWQgDQo+IGludG8gb25lLiBTY290dCBqdXN0IGRp ZCB0aGF0IGFuZCBwb3N0ZWQgdGhlIG1lcmdlZCBkcmFmdDoNCj4gPj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycQ0KPiA+ PiBtdA0KPiA+PiBzDQo+ID4+IC0wMC50eHQNCj4gPj4NCj4gPj4gTm93IEkgd291bGQgbGlrZSB0 byBhc2sgaWYgdGhlIHdnIGZlZWxzIGxpa2UgdGhpcyBkb2N1bWVudCBpcyByZWFkeSANCj4gPj4g dG8NCj4gYmUgYWRvcHRlZCBhcyBhIHdnIGRvY3VtZW50LiBQbGVhc2Ugc2VuZCB5b3VyIGZlZWRi YWNrIGFuZCBodW0gdG8gdGhlIA0KPiBsaXN0IGJ5IHRoaXMgdGltZSBuZXh0IHdlZWsuDQo+ID4+ DQo+ID4+IC1HYWJvcg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0tDQo+ID4+IC0NCj4g Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IEZyb206IFByb2Jhc2Nv IFNjb3R0DQo+ID4+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDExIDk6MTggQU0NCj4gPj4g VG86IHBhd3NAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1l bnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cw0KPiA+Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4g QWNjb3JkaW5nIHRvIHRoZSByZXN1bHRzIG9mIHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZywgd2Ug aGF2ZSANCj4gPj4gY29tYmluZWQNCj4gdGhlIHByb2JsZW0gc3RhdGVtZW50IEktRCBhbmQgdXNl IGNhc2UgJiByZXF1aXJlbWVudCBJLUQgaW50byBhIHNpbmdsZSANCj4gSS1ELiAgWW91ciBjb21t ZW50cyBhcmUgd2VsY29tZWQuDQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IFNjb3R0DQo+ID4+ DQo+ID4+IFVSTDoNCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1w YXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycQ0KPiA+PiBtdA0KPiA+PiBzDQo+ID4+IC0wMC50 eHQNCj4gPj4NCj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+IFBvcnRpb25zIG9mIHRoZSByYWRp byBzcGVjdHJ1bSB0aGF0IGFyZSBhbGxvY2F0ZWQgdG8gYSBsaWNlbnNlZCwgDQo+ID4+IHByaW1h cnkgdXNlciBidXQgYXJlIHVudXNlZCBvciB1bm9jY3VwaWVkIGF0IHNwZWNpZmljIGxvY2F0aW9u cyBhbmQgDQo+ID4+IHRpbWVzIGFyZSBkZWZpbmVkIGFzICd3aGl0ZSBzcGFjZScuICBUaGUgY29u Y2VwdCBvZiBhbGxvd2luZyANCj4gPj4gc2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgKGxpY2Vuc2Vk IG9yIHVubGljZW5zZWQpIGluIHdoaXRlIHNwYWNlIGlzIA0KPiA+PiBhIHRlY2huaXF1ZSB0byAn dW5sb2NrJyBleGlzdGluZyBzcGVjdHJ1bSBmb3IgbmV3IHVzZS4gIEFuIG9idmlvdXMgDQo+ID4+ IHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlc2Ugc2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgZG8gbm90 IGludGVyZmVyZSANCj4gPj4gd2l0aCB0aGUgcHJpbWFyeSB1c2Ugb2YgdGhlIHNwZWN0cnVtLiAg T25lIGFwcHJvYWNoIHRvIHVzaW5nIHRoZSANCj4gPj4gd2hpdGUgc3BhY2Ugc3BlY3RydW0gYXQg YSBnaXZlbiB0aW1lIGFuZCBsb2NhdGlvbiBpcyB0byB2ZXJpZnkgd2l0aCANCj4gPj4gYSBkYXRh YmFzZSBhdmFpbGFibGUgY2hhbm5lbHMuDQo+ID4+DQo+ID4+IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSBjb25jZXB0IG9mIFRWIFdoaXRlIFNwYWNlcy4gIEl0IGFsc28gDQo+ID4+IGRlc2Ny aWJlcyB0aGUgcHJvYmxlbXMgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBmb3IgZW5hYmxpbmcg dGhlIA0KPiA+PiB1c2Ugb2YgdGhlIHByaW1hcnkgdXNlciBvd25lZCB3aGl0ZSBzcGFjZSBzcGVj dHJ1bSBmb3Igc2Vjb25kYXJ5IA0KPiA+PiB1c2Vycywgd2l0aG91dCBjYXVzaW5nIGludGVyZmVy ZW5jZSwgYnkgcXVlcnlpbmcgYSBkYXRhYmFzZSB3aGljaCANCj4gPj4ga25vd3MgdGhlIGNoYW5u ZWwgYXZhaWxhYmlsaXR5IGF0IGFueSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZS4gIEEgDQo+ID4+ IG51bWJlciBvZiBwb3NzaWJsZSB1c2UgY2FzZXMgb2YgdGhpcyBzcGVjdHJ1bSBhbmQgZGVyaXZl ZCANCj4gPj4gcmVxdWlyZW1lbnRzIGFyZSBhbHNvIGRlc2NyaWJlZC4NCj4gPj4NCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gcGF3cyBt YWlsaW5nIGxpc3QNCj4gPj4gcGF3c0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPj4gcGF3c0Bp ZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MN Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPiBwYXdzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From internet-drafts@ietf.org Fri Sep 9 10:08: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 6729B21F86DF; Fri, 9 Sep 2011 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 gtMIL6bKYZ8Q; Fri, 9 Sep 2011 10:08:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A01221F866A; Fri, 9 Sep 2011 10:08:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110909170804.21135.57550.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2011 10:08:04 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-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: Fri, 09 Sep 2011 17:08:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Workin= g Group of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Gabor Bajko Basavaraj Patil Brian Rosen Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt Pages : 25 Date : 2011-09-09 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq= mts-00.txt From stpeter@stpeter.im Fri Sep 9 10:30: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 66EB821F8560 for ; Fri, 9 Sep 2011 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 qP4xlLgmAb+S for ; Fri, 9 Sep 2011 10:30:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0604C21F855B for ; Fri, 9 Sep 2011 10:30:19 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F15FD4195A for ; Fri, 9 Sep 2011 11:35:16 -0600 (MDT) Message-ID: <4E6A4D97.2080306@stpeter.im> Date: Fri, 09 Sep 2011 11:32:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: paws@ietf.org References: <20110909170804.21135.57550.idtracker@ietfa.amsl.com> In-Reply-To: <20110909170804.21135.57550.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-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: Fri, 09 Sep 2011 17:30:19 -0000 On 9/9/11 11:08 AM, internet-drafts@ietf.org wrote: > > Title : Protocol to Access White Space database: PS, use cases and rqmts > Author(s) : Scott Probasco > Gabor Bajko > Basavaraj Patil > Brian Rosen > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt It's good to see this as a working group item. In general, it is problematic for working group chairs to also be document editors, since it becomes difficult for the chairs to objectively declare consensus and such. See RFC 2418: As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. Unless there is a good reason for Gabor and Brian to remain as document editors, I would suggest that they be mentioned in a new section entitled "Contributors" so that only Scott and Basavaraj would remain as document editors. Peter -- Peter Saint-Andre https://stpeter.im/ From Gabor.Bajko@nokia.com Fri Sep 9 12: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 CED0D21F85EF for ; Fri, 9 Sep 2011 12:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 gy7KbYGEqrQF for ; Fri, 9 Sep 2011 12:33:09 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6521F85C7 for ; Fri, 9 Sep 2011 12:33:08 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p89JZ22i020533; Fri, 9 Sep 2011 22:35:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 22:34:57 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 9 Sep 2011 21:34:57 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.245]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Fri, 9 Sep 2011 21:34:56 +0200 From: To: , Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt Thread-Index: AQHMbxNo80J3aeBzsEafcxrxLYwIyJVFLR2AgABDHIA= Date: Fri, 9 Sep 2011 19:34:55 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760FADDA@008-AM1MPN1-007.mgdnok.nokia.com> References: <20110909170804.21135.57550.idtracker@ietfa.amsl.com> <4E6A4D97.2080306@stpeter.im> In-Reply-To: <4E6A4D97.2080306@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.106.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 19:34:57.0794 (UTC) FILETIME=[8ED9AE20:01CC6F27] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-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: Fri, 09 Sep 2011 19:33:09 -0000 Removing my name from the top should not be a problem.=20 Next revision will have it as you suggested. -Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Peter Saint-Andre Sent: Friday, September 09, 2011 10:32 AM To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -00.txt On 9/9/11 11:08 AM, internet-drafts@ietf.org wrote: >=20 > Title : Protocol to Access White Space database: PS, use cases= and rqmts > Author(s) : Scott Probasco > Gabor Bajko > Basavaraj Patil > Brian Rosen > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt It's good to see this as a working group item. In general, it is problematic for working group chairs to also be document = editors, since it becomes difficult for the chairs to objectively declare c= onsensus and such. See RFC 2418: As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. Unless there is a good reason for Gabor and Brian to remain as document edi= tors, I would suggest that they be mentioned in a new section entitled "Con= tributors" so that only Scott and Basavaraj would remain as document editor= s. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Fri Sep 9 12:54:13 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 EEAA121F87FC for ; Fri, 9 Sep 2011 12:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 j6Cn-wiThT7U for ; Fri, 9 Sep 2011 12:54:13 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id E4BB721F86D0 for ; Fri, 9 Sep 2011 12:54:12 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p89JtsU8026301 for ; Fri, 9 Sep 2011 22:56:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 22:55:50 +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; Fri, 9 Sep 2011 21:55:12 +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; Fri, 9 Sep 2011 21:55:11 +0200 From: To: Thread-Topic: Requirements Thread-Index: AcxvKZlAc7p+3+DsTR20bWVYhgQVbw== Date: Fri, 9 Sep 2011 19:55:11 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760FADF7@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.62.106.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 19:55:50.0106 (UTC) FILETIME=[794953A0:01CC6F2A] X-Nokia-AV: Clean Subject: [paws] 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: Fri, 09 Sep 2011 19:54:14 -0000 Folks, If you'll read this draft, you'll notice that section 6, the requirements s= ection, is empty. During the Quebec meeting we agreed that these requiremen= ts will be reformulated and discussed on the list before including them ont= o the draft. I made a first attempt to reformulate the requirements and I'd= like to post them to the list to start a discussion on them. There are lot= s of requirements still missing, so I'd welcome proposals for additional re= quirements, as well as comments to these requirements: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Requirements D. Data Model Requirements: D.1: The Data Model MUST support specifying the antenna height parameter of= the subject D.2: The data model MUST support specifying an ID of the subject. This ID w= ould be the ID of the device used to be certified by a regulatory body for = a regulatory domain D.3: The Data Model MUST support specifying the location of the subject and= accuracy of location determination D.4: The Data Model MUST support specifying a list of available channel lis= t and time constrains for the channel list availability. D.5: The Data Model MUST support specifying the maximum output power of the= subject. D.6: The Data Model MUST support specifying channel availability informatio= n for multiple locations. D.7: The Data Model MUST support specifying channel availability informatio= n for an area around a specified location. P. Protocol Requirements: P.1: The protocol MUST provide a mechanism for the subject to discover the = WS Database it has to use at a given location. P.2: The protocol MUST support regulatory domain discovery. P.3: The protocol between the master device and the WS Database MUST suppor= t pushing updates in channel availability changes to subjects=20 P.4: The protocol between the master device and the WS Database MUST suppor= t mutual authentication and authorization. P.5: The protocol between the master device and the WS Database MUST suppor= t integrity and confidentiality protection. P.6: The protocol MUST support both username/password and digital certifica= tes based authentication. O. Operational Requirements: O.1: A master device MUST query the WS Database for the available channels = as often as required by the regulation (eg, FCC requires once per day) to v= erify that the operating=20 channels continue to remain available. O.2: A master device MUST determine its location with the accuracy required= by the regulation (eg, FCC requires +/- 100m) before placing a query to th= e DB O.3: A master device which changes its location during its operation, MUST = query the WS Database for available operating channels each time it moves m= ore than the distance=20 specified by the regulation (eg FCC specifies 100m) from the location it pr= eviously made the query from. O.4: The WS Database MUST provide the available channel list when requested= and MAY also provide time constraints for the channel list and maximum out= put power to the master=20 device. O.5: A master device MUST query the WS Database and include the FCC ID of t= he slave device in the query before allowing the slave device to use the av= ailable channel. O.6: A master device MUST be capable to validate the digital certificate of= the WS Database. O.7: A master device MUST be capable to check the validity of the WS Databa= se certificate and whether it has been revoked or not. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D -Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= internet-drafts@ietf.org Sent: Friday, September 09, 2011 10:08 AM To: i-d-announce@ietf.org Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-00.= txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Workin= g Group of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Gabor Bajko Basavaraj Patil Brian Rosen Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt Pages : 25 Date : 2011-09-09 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq= mts-00.txt _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From stpeter@stpeter.im Fri Sep 9 15: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 C0EE421F8556 for ; Fri, 9 Sep 2011 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 fTi7xQxxDc8Z for ; Fri, 9 Sep 2011 15:03:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0321F8551 for ; Fri, 9 Sep 2011 15:03:36 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E2E7841965; Fri, 9 Sep 2011 16:08:34 -0600 (MDT) Message-ID: <4E6A8DAA.1050700@stpeter.im> Date: Fri, 09 Sep 2011 16:05:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <20110909170804.21135.57550.idtracker@ietfa.amsl.com> <4E6A4D97.2080306@stpeter.im> <1ECAFF543A2FED4EA2BEB6CACE08E4760FADDA@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760FADDA@008-AM1MPN1-007.mgdnok.nokia.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-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: Fri, 09 Sep 2011 22:03:36 -0000 Thanks, Gabor. We will make sure that you and Brian receive proper attribution for all your hard work. :) On 9/9/11 1:34 PM, Gabor.Bajko@nokia.com wrote: > Removing my name from the top should not be a problem. Next revision > will have it as you suggested. -Gabor > > -----Original Message----- From: paws-bounces@ietf.org > [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter Saint-Andre > Sent: Friday, September 09, 2011 10:32 AM To: paws@ietf.org Subject: > Re: [paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt > > > > On 9/9/11 11:08 AM, internet-drafts@ietf.org wrote: >> >> Title : Protocol to Access White Space database: PS, use >> cases and rqmts Author(s) : Scott Probasco Gabor Bajko >> Basavaraj Patil Brian Rosen Filename : >> draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt > > It's good to see this as a working group item. > > In general, it is problematic for working group chairs to also be > document editors, since it becomes difficult for the chairs to > objectively declare consensus and such. See RFC 2418: > > As a general practice, the Working Group Chair and Document Editor > positions are filled by different individuals to help ensure that > the resulting documents accurately reflect the consensus of the > working group and that all processes are followed. > > Unless there is a good reason for Gabor and Brian to remain as > document editors, I would suggest that they be mentioned in a new > section entitled "Contributors" so that only Scott and Basavaraj > would remain as document editors. > > Peter > > -- Peter Saint-Andre https://stpeter.im/ > From lei.zhu@huawei.com Tue Sep 13 00:09: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 8499321F8AD8 for ; Tue, 13 Sep 2011 00:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 JljO2jFtIWuX for ; Tue, 13 Sep 2011 00:09:06 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9B921F8B00 for ; Tue, 13 Sep 2011 00:09:05 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRG00NAV97R0W@szxga05-in.huawei.com> for paws@ietf.org; Tue, 13 Sep 2011 15:09:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRG00ARK97MY0@szxga05-in.huawei.com> for paws@ietf.org; Tue, 13 Sep 2011 15:09:27 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADR83247; Tue, 13 Sep 2011 15:09:26 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 13 Sep 2011 15:09:24 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.189]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 15:09:25 +0800 Date: Tue, 13 Sep 2011 07:09:24 +0000 From: ZhuLei In-reply-to: X-Originating-IP: [10.108.64.160] To: "scott.probasco@nokia.com" Message-id: <470F27D1263A1B4EB73491ED995DE62539C33E@szxeml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [paws] combined problem statement, use cases & requirements Thread-index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3AgAB8ZQCAB4F8QA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <470F27D1263A1B4EB73491ED995DE62538DC51@szxeml504-mbx.china.huawei.com> Cc: "paws@ietf.org" 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, 13 Sep 2011 07:09:07 -0000 SGkgU2NvdHQgYW5kIGFsbCwNCg0KRm9yIHNvbWUgcmVhc29ucywgSSB0aGluayB0aGF0IFBBV1Mg cHJvdG9jb2wgd291bGQgYmUgZGV2ZWxvcGVkIHdpdGggcXVpdGUgc3RhYmxlIHNjZW5hcmlvIGRl c2NyaXB0aW9ucyBvZiBpbmRvb3IgY292ZXJhZ2UuIA0KDQpBY2NvcmRpbmcgdG8gcHJldmlvdXMg ZS1tYWlsIGRpc2N1c3Npb24gaW4gdGhlIGxpc3QsIGl0IHNlZW1zIHRoYXQgd29ya2luZyBncm91 cCB3b3VsZCBkZXZlbG9wIGdlbmVyaWMgYW5kIGdsb2JhbGx5IGFwcGxpY2FibGUgc3BlY3RydW0g ZGF0YWJhc2UgcXVlcnkgcHJvdG9jb2wgd2hpY2ggaG9wZWx5IGlzIGFjY2VwdGVkIGJ5IG90aGVy IHJlZ3VsYXRvcnMgYnV0IG9ubHkgRkNDLiA3MDBNSHotODAwTUh6IGNhbiBiZSBzaGFyZWQgdG8g cGFydGljdWxhciB3aXJlbGVzcyBhY2Nlc3MgdGVjaG5vbG9naWVzIGxpa2UgODAyLjExLCA4MDIu MjIgYW5kIGV2ZW4gTFRFLiBQbGVhc2UgY29ycmVjdCBtZSBpZiBzb21ldGhpbmcgd3JvbmcuDQoN ClRoZSBnZW5lcmljIHVzZSBjYXNlcyBjb3VsZCBiZSBzYWZlIHdoZW4gZGVjaWRpbmcgd29ya2lu ZyBncm91cCBkcmFmdC4gQnV0IGhvdHNwb3QgYW5kIHVyYmFuIGludGVybmV0IGNvbm5lY3Rpb24g ZGVzY3JpcHRpb24gaXMgc3RpbGwgbm90IGNyZWRpdGFibGUgdG8gZGV2ZWxvcCBQQVdTIHByb3Rv Y29sIGZvciB0aGUgcmVhc29uIDcwME1IeiBoYXMgZmFyIGRpZmZlcmVudCBwcm9wYWdhdGlvbiBj aGFyYWN0ZXJpc3RpY3MgZnJvbSB0aGUgbmVlZHMgb2YgaW5kb29yIGNvdmVyYWdlIGFuZCB1cmJh biBob3RzcG90IHVzZSBjYXNlLiBJbiBnZW5lcmFsLCBpbmRvb3IgdXNlIGNhc2Ugc2F5cyB0aGF0 IGRhdGFiYXNlIHNob3VsZCB0byByZXNwb25zZSBwcm9wZXIgc3BlY3RydW0gaWYgQVBzIHJlcXVl c3QgY2hhbm5lbHMgZm9yIGluZG9vciBJbnRlcm5ldCBjb25uZWN0aW9uLiBJZiBpdCBpcyBub3Qg cG9zc2libGUsIHJlZ3VsYXRvcnMgbXVzdCB0byBmYWNlIHByb2JsZW1zIG9mIGludGVyZmVyZW5j ZSBhbW9uZyBBUHMgYW5kIE1pY3JvIGNlbGwgQlNzLiBUaGVuLCBQQVdTIG5vdyBoYXMgdG8gcmVj b2duaXplIHNjZW5hcmlvIGRlc2NyaXB0aW9uIGFuZCByZXF1aXJlbWVudHMgYmVmb3JlIGRldmVs b3AgcHJvdG9jb2wgdGhhdCBvdGhlciBoaWdoZXIgZnJlcXVlbnQgYmFuZHMgKGF0IGxlYXN0IGhp Z2hlciB0aGFuIDIuMUdIeikgc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gaW5kb29yIGNvdmVyYWdl LiBJIHdvdWxkIGxpa2UgdG8gcmVtaW5kIHRoYXQgaXMgZGlmZmVyZW50IG5lZWQgZm9yIGluZG9v ciBjb3ZlcmFnZSBmcm9tIGdlbmVyaWMgaG90c3BvdCBhbmQgdXJiYW4gY292ZXJhZ2Ugd2hpY2gg aXMgc3RpbGwgdG8gYmUgZGl2aWRlZC4NCg0KRnJvbSBwcm90b2NvbCBwZXJzcGVjdGl2ZSwgaXQg d2lsbCBkZXBlbmQgb24gdGhlIGNvbmNsdXNpb24gb2Ygd29ya2luZyBncm91cCB3aGljaCBJRXMg YXJlIHJlc2VydmVkIGZvciBpbmRvb3IgcXVlcnkgdXNhZ2VzLg0KDQpUaHJlZSB0aGluZ3MgYXJl IHBhcnRpY3VsYXIgZm9yIGluZG9vciBjb3ZlcmFnZSB1c2UgY2FzZSBpZiBkZXZlbG9wIFBBV1Mg cHJvdG9jb2wuIEZpcnN0IG9uZSBpcyB0aGF0IHRoZSBsb2NhdGlvbiBpbiBhIGJ1aWxkaW5nIGlz IGRpZmZlcmVudCBmcm9tIEdQUyBwb3NpdGlvbmluZy4gU2Vjb25kIG9uZSBpcyB0aGF0IHRoZSBk YXRhYmFzZSBzaG91bGQgYmUgYWJsZSB0byBjYWxjdWxhdGUgdGhlIHByb3BlciBiYW5kIGZvciBp bmRvb3IgY292ZXJhZ2UuIFRoaXJkIG9uZSBpcyB0aGF0IGRhdGFiYXNlIHNob3VsZCBiZSBhYmxl IHRvIGNvbnNpZGVyIChvciBjYWxjdWxhdGUpIGFuZCBhdm9pZCB1bmV4cGVjdGVkIGludGVyZmVy ZW5jZSBhbW9uZyBkaWZmZXJlbnQgaW5kb29yIEFQcyBhbmQgbWljcm8gY2VsbCBCU3MuDQoNCkJl c3QgcmVnYXJkcywNClpodSBMZWkNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzogc2Nv dHQucHJvYmFzY29Abm9raWEuY29tIFttYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEuY29tXSAN Creiy83KsbzkOiAyMDExxOo51MI4yNUgMjM6NDkNCsrVvP7IyzogWmh1TGVpDQqzrcvNOiBwYXdz QGlldGYub3JnDQrW98ziOiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1 c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCg0KSGVsbG8gTGVpLA0KDQpJIGhhdmUgc3R1ZGllZCB0 aGUgdGV4dCBiZWxvdywgYnV0IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHlvdQ0K YXJlIHByb3Bvc2luZy4gSXQgc2VlbXMgdG8gbWUgdGhhdCB5b3UgYXJlIGRlc2NyaWJpbmcgYSBk ZXBsb3ltZW50DQpzY2VuYXJpbyAod2hpY2ggaXMgZmluZSkuIEkgZG8gbm90IHVuZGVyc3RhbmQg d2hhdCBpcyB0aGUgdXNlIGNhc2UsIG9yIGhvdw0KdGhpcyBjYXNlIGlzIGRpZmZlcmVudCBmcm9t ICJIb3RzcG90IiB1c2UgY2FzZSAoQVAgaXMgaW5kb29yKSB3aXRoIGENCiJXaWRlLWFyZWEgb3Ig cnVyYWwiIHVzZSBjYXNlIGRlcGxveWVkIGluIHRoZSBzYW1lIGdlbmVyYWwgYXJlYSAobWljcm9j ZWxsDQppcyBvdXRkb29yKS4NCg0KSSBhbSBub3Qgc3BlYWtpbmcgYWdhaW5zdCB0aGUgdXNlIGNh c2UsIHNpbXBseSBzYXlpbmcgdGhhdCBJIGRvbid0DQp1bmRlcnN0YW5kIGl0IHdlbGwgZW5vdWdo IHRvIGNvbW1lbnQgb24gaXQuIEl0IG1pZ2h0IGhlbHAgZnVydGhlcg0KZGlzY3Vzc2lvbiBpZiB5 b3UgY2FuIGRlc2NyaWJlIGluIG1vcmUgZGV0YWlsIHRoZSB1c2UgY2FzZSwgYW5kIGluY2x1ZGUN CnNwZWNpZmljIGFjdGlvbnMgdGhhdCBlYWNoIGVsZW1lbnQgKG1pY3JvY2VsbCwgQVAsIGRldmlj ZSwgZGF0YWJhc2UsIGV0YykNCm11c3QgY29tcGxldGUgaW4gb3JkZXIgdG8gZGVwbG95IHRoaXMg dXNlIGNhc2UuDQoNClJlZ2FyZHMsDQpTY290dA0KDQoNCk9uIDkvNy8xMSA4OjM1IFBNLCAiZXh0 IFpodUxlaSIgPGxlaS56aHVAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBhbGwsDQo+DQo+SSB0 aGluayB0aGF0IHdlIGRvIHNvbWUgd29ya3Mgb24gaW1wcm92aW5nIG9yaWdpbmFsIHVzZSBjYXNl IGRyYWZ0IGJ5DQo+YWRkaW5nIHRocmVlIGFkZGl0aW9uYWwgdXNlIGNhc2VzLCBpbmNsdWRpbmcg aW5kb29yIGNvdmVyYWdlLCBhZCBob2MNCj5uZXR3b3JrIGFuZCBsdGUgbWJtcyBpc3N1ZS4NCj4N Cj5Ob3csIEkgYW0gYXNraW5nIHRvIGFkZCBpbmRvb3IgY292ZXJhZ2Ugc2NlbmFyaW8gd2hpY2gg aXMgbmVjZXNzYXJ5IGZvcg0KPlBBV1MgcHJvdG9jb2wgdG8gY29uc2lkZXIgaW4gbmV4dCBzdGFn ZS4gVGhlIHByb3Bvc2VkIHVzZSBjYXNlIGlzIHNlZW4NCj5iZWxvdy4gVGhlIHVwZGF0ZWQgdmVy c2lvbiBvZiB0aGlzIGRyYWZ0IGlzIHRvIGJlIHN1Ym1pdHRlZCBzb29uIGJ5DQo+YWRkaW5nIHNv bWUgd29yZGluZyBtb2RpZmljYXRpb25zLiBTbywgSSBkb24ndCB0aGluayB3ZSBhcmUgdG8gc2tp cCB0aGUNCj5hZGRpdGlvbmFsIHVzZSBjYXNlcyBldmVuIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwg dXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50DQo+cHJvcG9zYWwgaGF2ZSBiZWVuIGludGVncmF0ZWQg bm93Lg0KPg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPngueC4gIEluZG9vciB1c2FnZSBvZiBUVldTDQo+DQo+ICAgQXQgcHJlc2VudCwg dGhlIGluZG9vciB3aXJlbGVzcyBjb3ZlcmFnZSBlcXVpcG1lbnRzIGNvbnNpc3Qgb2YgV2ktRmkt DQo+ICAgbGlrZSBhY2Nlc3MgcG9pbnRzIGFuZCBtaWNybyBjZWxscywgYWxsIG9mIHRoZXNlIHV0 aWxpemUgc2VnbWVudHMgb2YNCj4gICBmcmVxdWVuY3ksIGZvcm1lciBhdCBhYm91dCAyLjRHSHog b3IgNUdoeiBhbmQgdGhlIGxhdHRlciwgZm9yDQo+ICAgZXhhbXBsZSwgODAyLjExbiBhdCBhYm91 dCAyLjRHSHouICBBcyBhIHJlc3VsdCBvZiB0aGUgYmxvY2sgb2YNCj4gICBidWlsZGluZ3MgYW5k IG90aGVyIG9ic3RydWN0aW9uIGFuZCBpbnRlcmZlcmVjZSwgaXQgbWF5IG5vdCBiZSB0aGF0DQo+ ICAgb3B0aW1pc3RpYyB3aGVuIDgwMi4xMSBkZXZpY2VzIGV4YW1pbmUgdGhlIHN0YXR1cyBvZiB3 aXJlbGVzcw0KPg0KPg0KPg0KPlpodSAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KPg0KPg0KPkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgUEFXUyB1c2UgY2FzZXMgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAx MQ0KPg0KPg0KPiAgIGludGVyZmVyZXMuICBUaGlzIHVzZSBjYXNlIHRha2VzIHRoZSBiZW5lZml0 IG9mIFRWIFdoaXRlIFNwYWNlIHRvDQo+ICAgcHJvdmlkZSBhZGRpdGlvbmFsIGNhcGFjaXR5IHRv IGluZG9vciBjb3ZlcmFnZSBhbmQgcmVkdWNlIGNoYW5uZWwNCj4gICBpbnRlcmZlcmVjZS4NCj4N Cj4gICBUaGUgZmlndXJlIGJlbG93IHNob3dzIGFuIGV4YW1wbGUgZGVwbG95bWVudCBvZiB0aGlz IHNjZW5hcmlvLg0KPg0KPiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCj4gICAgICAgICAgICAgICB8ICAgICAgICAgICAgaW5kb29yICAgICAgICAgICAg ICB8DQo+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K PiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAg ICAgICAgfCAgICArLS0tLS0tKyAgIHdoaXRlIHNwYWNlICAgICAgfCAgICstLS0tLS0tLS0tLS0t Kw0KPiAgICAgICAgICAgICAgIHwgICAgfERldmljZXwgLSAtIC0gLSAtIC0gLSAtIC0gLXwtIC18 IE1pY3JvIGNlbGwgIHwNCj4gICAgICAgICAgICAgICB8ICAgICstLS0tLS0rICBcICAgICAgICAg ICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAgICAgfCAgICArLS0tLS0t KyAgIFx3aGl0ZSBzcGFjZSAgICAgfCAgICAgKC0tLS0tKQ0KPiAgICAgICAgICAgICAgIHwgICAg fERldmljZXwgICAgXCArLS0tLS0tLS0tLS0tK3wgICAgLyAgICAgICBcDQo+ICAgICAgICAgICAg ICAgfCAgICArLS0tLS0tKyAgICAgIHxhY2Nlc3MgcG9pbnR8fD09PSggSW50ZXJuZXQpDQo+ICAg ICAgICAgICAgICAgfCAgICAgICAgbyAgICAgICAvICstLS0tLS0tLS0tLS0rfCAgICBcICAgICAg IC8NCj4gICAgICAgICAgICAgICB8ICAgICAgICBvICAgICAgLyAgICAgICAgICAgICAgICB8ICAg ICAoLS0tLS0pDQo+ICAgICAgICAgICAgICAgfCAgICAgICAgbyAgICAgLyAgICAgICAgICAgICAg ICAgfA0KPiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN Cj4gICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+DQo+ DQo+ICAgICAgICAgICAgICAgICAgICAgICBHcmFwaCAxIEluZG9vciB1c2FnZSBvZiBUVldTDQo+ DQo+ICAgVGhlIGFjY2VzcyBwb2ludCBjb3VsZCBiZSBhIFdJLUZJIHJvdXRlciwgYW5kIHRoZSBt aWNybyBjZWxsIGlzIGENCj4gICBzaG9ydCByYW5nZSB3aXJlbGVzcyBjb3ZlcmFnZShlLmcuIGlu IHJhbmdlIG9mIDAtNTBtKSBiYXNlIHN0YXRpb24sDQo+ICAgYm90aCBvZiB0aGVtIGFjdCBhcyBt YXN0ZXIgZGV2aWNlcywgcXVlcnlpbmcgdGhlIGludGVybmV0IGNvbm5lY3RlZA0KPiAgIGRhdGFi YXNlIGZvciBhdmFpbGFibGUgd2hpdGUgc3BhY2Ugc3BlY3RydW0gYmFzZWQgb24gaXRzIGdlby0N Cj4gICBsb2NhdGlvbiwgYW5kIHByb3ZpZGluZyBUVldTIGFjY2VzcyB0byBpbmRvb3IgdXNlci4N Cj4NCj4gICBUaGUgVFZXUyBzcGVjdHJ1bSBoYXMgZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNoYXJh Y3RlcmlzdGljcyBjb21wYXJlZA0KPiAgIHRvIGhpZ2hlciBmcmVxdWVuY3kgYmFuZCwgZm9yIGV4 YW1wbGUsIHRoZSB0cmFuc21pc3Npb24gZGlzdGFuY2UNCj4gICB1c2luZyBUVldTIGNhbiBiZSBz ZXZlcmFsIHRpbWVzIGxvbmdlciB0aGFuIHRob3NlIGluIHRoZSBoaWdoZXIgYmFuZC4NCj4gICBJ biB0aGlzIGNhc2UsIGdvb2QgcGVuZXRyYXRpb24gY2hhcmFjdGVyaXN0aWMgb2YgVFZXUyBtYWtl cyBpdA0KPiAgIGRpZmZpY3VsdCB0byBsb2NrIHRoZSBzaWduYWxzIGluIHRoZSByb29tLCB0aGVu IGRpZmZpY3VsdCB0byBsb2NhbGl6ZQ0KPiAgIGFuZCBkaWZmZXJlbnRpYXRlIHNpZ25hbHMsIGFu ZCBmaW5hbGx5IGNhdXNlIGludGVyZmVyZXMgYW1vbmcNCj4gICBuZWlnaGJvcmluZyBuZXR3b3Jr cy4gIFJlcXVpcmVtZW50cyB0byBpbmRvb3IgV1MgZGF0ZWJhc2UgdXNhZ2Ugd291bGQNCj4gICBi ZToNCj4NCj4NCj4gICAxLiAgQSBmcmVxdWVuY3kgcHJvdGVjdGlvbiBnYXAgYmV0d2VlbiBuZWln aGJvcnMocGFydGljdWxhciBzcGVjdHJ1bQ0KPiAgICAgICBhbGxvY2F0aW9uIGFsZ29yaXRobSBp cyBuZWVkZWQgaGVyZSkuDQo+DQo+ICAgMi4gIGxvd2VyIG91dHB1dCBwb3dlciBvZiBBUC9taWNy byBjZWxsLCBpdCBzZWVtcyB0aGF0IG9ubHkgY2VydGFpbg0KPiAgICAgICBwaWNvIG9yIGZlbXRv IGNlbGxzIGJlIGZlYXNpYmxlIGhlcmUuDQo+DQo+ICAgMy4gIFBBV1MgbXVzdCBub3QgYmUgdGll ZCB0byBhIHNwZWNpZmljIGZyZXF1ZW5jeSBiYW5kLg0KPg0KPiAgIDQuICBQQVdTIG11c3QgcmVz cG9uc2UgdGhlIHByb3BlciBmcmVxdWVuY3kgYmFuZCBsaXN0IHRvIHBhcnRpY3VsYXINCj4gICAg ICAgY292ZXJhZ2Ugd2hpdGUgc3BhY2UgZGV2aWNlcy4NCj4NCj4gICA1LiAgTWFzdGVyIGRldmlj ZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29udHJvbC4NCj4NCj4gICA2LiAgU2xhdmUgZGV2aWNl cyBzaG91bGQgc3VwcG9ydCBwb3dlciBjb250cm9sLg0KPg0KPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPlpodSBMZWkNCj4NCj4NCj4t LS0tLdPKvP7Urbz+LS0tLS0NCj63orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBHZXJhbGQNCj5DaG91aW5hcmQNCj63osvNyrG8 5DogMjAxMcTqOdTCOMjVIDg6MDENCj7K1bz+yMs6IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPrOt y806IHBhd3NAaWV0Zi5vcmcNCj7W98ziOiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3Rh dGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4NCj5HYWJvciwNCj4NCj5DYW4gSSBh c2sgdGhhdCB0aGUgdGV4dCBtb2RpZmljYXRpb25zIHRoYXQgSSBoYXZlIHN1Ym1pdHRlZCB0byBz Y290dCBhbmQNCj5jb3BpZWQgdG8gdGhlIHBhd3MgcmVmbGVjdG9yIGluIG15IGVtYWlsIGRhdGVk IDggQXVndXN0IGJlIGluY2x1ZGVkIGFzDQo+d2VsbD8NCj4NCj5UaGFuaydzLA0KPg0KPkdlcmFs ZA0KPg0KPg0KPkF0IDIwOjMyIDA3LTA5LTExICswMDAwLCBHYWJvci5CYWprb0Bub2tpYS5jb20g d3JvdGU6DQo+Pk9rLCBsZXQncyB0cnkgdGhhdCB0aGVuLg0KPj5TY290dCwgY2FuIHlvdSBwdXQg dXNlIGNhc2VzIGJlZm9yZSBQUywgYW5kIGFkZCB0aGUgYWQtaG9jIHVzZSBjYXNlLiBJDQo+Pmp1 c3Qgc2Nhbm5lZCB0aHJvdWdoIHRoZSBsaXN0IGFuZCBzcG90dGVkIHRoYXQgVGVjbyBpbmRlZWQg cHJvdmlkZWQgYQ0KPj5kZXNjcmlwdGlvbiBmb3IgdGhhdCB1c2UgY2FzZSBvbiBBdWcgM3JkLg0K Pj5BbmQgc3VibWl0IHRoZSBkcmFmdCBhcyBhIHdnIGl0ZW0sIHVubGVzcyB0aGVyZSBhcmUgc3Rp bGwgb2JqZWN0aW9ucy4NCj4+DQo+Pi1HYWJvcg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+RnJvbTogZXh0IE5hbmN5IEJyYXZpbiBbbWFpbHRvOm5icmF2aW5AZWFydGhsaW5r Lm5ldF0NCj4+U2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAwMywgMjAxMSAzOjQxIFBNDQo+PlRv OiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+PkNjOiBUZWNvIEJvb3Q7 IEdlcmFsZCBDaG91aW5hcmQ7IHBhd3NAaWV0Zi5vcmcNCj4+U3ViamVjdDogUmU6IFtwYXdzXSBj b21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWlyZW1lbnRzDQo+Pg0K Pj5EZWFyIEdhYm9yIGFuZCBBbGwsDQo+Pg0KPj5JIHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRv IHB1dCB0aGUgdXNlIGNhc2VzIGJlZm9yZSB0aGUgUFMgZm9yIG9idmlvdXMNCj4+cmVhc29ucywg YW5kIGluY2x1ZGluZyB0aGUgInByb3h5IiBuZWVkIGluIHRoZSBmaXJzdCBkcmFmdC4gSSBzdXBw b3J0DQo+PmluY2x1ZGluZyBib3RoIEdlcmFsZCdzIHN1Z2dlc3Rpb25zIGFuZCBUZWNvJ3MgcHJv cG9zYWwgaW4gdGhlIG9yaWdpbmFsDQo+PmRyYWZ0IGFuZCBub3Qgd2FpdGluZyB1bnRpbCBhIGxh dGVyIHRpbWUuIEl0IGlzIHRoZSBwcm9wZXIgb3JkZXIsDQo+PmluY2x1c2l2ZSBhbmQgbmVlZGVk IGluIHRoZSBpbml0aWFsIGRyYWZ0IGluIG15IG9waW5pb24uIEkgYmVsaWV2ZSB3aXRoDQo+PnRo ZSB0YWxlbnQgaW4gdGhlIGdyb3VwIGl0IHdpbGwgbm90IHRha2UgbG9uZyB0byBhY2NvbXBsaXNo IHRoaXMgYW5kIHlvdQ0KPj53aWxsIGhhdmUgYSBtb3JlIGNvaGVzaXZlIGRyYWZ0Lg0KPj4NCj4+ U0luY2VyZWx5LCBOYW5jeQ0KPj4NCj4+DQo+Pk9uIFNlcCAyLCAyMDExLCBhdCAyOjE5IFBNLCA8 R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj48R2Fib3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToN Cj4+DQo+PiA+IFRlY28sIEdlcmFsZCwNCj4+ID4NCj4+ID4gVGhhbmtzIGZvciB0aGUgZmVlZGJh Y2suIEknZCBzdWdnZXN0IHRoYXQgd2UgbWFrZSB0aGlzIGRyYWZ0IGEgV0cNCj4+aXRlbSwgDQo+ PiB3aXRoIEdlcmFsZCdzIHByb3Bvc2VkIGNoYW5nZXMgaW4gaXQuIFJlZ2FyZGluZyB0aGUgb3Jk ZXIgb2YgdGhlDQo+PnByb2JsZW0gDQo+PiBzdGF0ZW1lbnQgdnMgdXNlIGNhc2VzLCBteSBwcmVm ZXJlbmNlIHdvdWxkIGJlIHRvIGxlYXZlIGl0IGFzIGl0IGlzDQo+PihidXQgDQo+PiB3ZSBjYW4g YWx3YXlzIGNoYW5nZSBpdCwgaWYgdGhhdCBpcyB3aGF0IHRoZSBXRyB3YW50cykuDQo+PiA+DQo+ PiA+IFNvLCBJJ2QgYXNrIFNjb3R0IHRvIHN1Ym1pdCBhIFdHIHZlcnNpb24gb2YgdGhpcyBkcmFm dCwgdGhlbiBoYXZlDQo+PiBzb21lb25lIGNvbWUgdXAgd2l0aCB0ZXh0IGZvciB0aGlzIGFkLWhv YyBuZXR3b3JrIHNjZW5hcmlvLCBoYXZlIHRoZSBXRw0KPj4gYWdyZWUgd2l0aCB0aGUgdGV4dCBh bmQgaW5jbHVkZSBpdCBpbiBvbmUgb2YgdGhlIHN1YnNlcXVlbnQgdmVyc2lvbnMuDQo+PiBUZWNv LCB3b3VsZCB5b3Ugd3JpdGUgdXAgc29tZSB0ZXh0IGZvciB0aGlzIGFkLWhvYyB1c2UgY2FzZSB0 aGUgV0cNCj4+Y291bGQgDQo+PiBkaXNjdXNzPw0KPj4gPg0KPj4gPiBXZSdsbCBhbHNvIHNlbmQg YW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgbGlzdCBvZiByZXF1aXJlbWVudHMgdG8gdGhlDQo+PiBs aXN0IG5leHQgd2Vlay4NCj4+ID4NCj4+ID4gLSBHYWJvcg0KPj4gPg0KPj4gPg0KPj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPiBGcm9tOiBleHQgVGVjbyBCb290IFttYWlsdG86 dGVjb0BpbmYtbmV0Lm5sXQ0KPj4gPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAxLCAyMDEx IDExOjA2IFBNDQo+PiA+IFRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkp DQo+PiA+IENjOiBwYXdzQGlldGYub3JnDQo+PiA+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmlu ZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+PiA+IHJlcXVpcmVtZW50cw0KPj4g Pg0KPj4gPiBJIHRoaW5rIHRoZSBkb2MgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50LiBJIHN1cHBv cnQgYWRvcHRpb24uDQo+PiA+DQo+PiA+IEkgc3VnZ2VzdCByZW9yZGVyaW5nOiBzcGVjaWZ5aW5n IHByb2JsZW0gc3RhdGVtZW50IGFmdGVyIGludHJvZHVjaW5nDQo+PiB0aGUgdXNlIGNhc2VzLg0K Pj4gPg0KPj4gPiBTb21lIGFza2VkIGZvciB0aGUgYWQgaG9jIG5ldHdvcmsgc2NlbmFyaW8uIFRo aXMgaW5jbHVkZXMgbWUgOi0pLg0KPj5UaGlzIA0KPj4gaXMgaW1wb3J0YW50LCBiZWNhdXNlIGl0 IGRlbW9uc3RyYXRlcyB0aGUgbmVlZCBmb3IgInByb3h5Ii4NCj4+ID4gQlRXLCBJIHdvbmRlciB3 aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0IHBvcCB1cCBmcm9tIFdpRmkNCj4+IGRlcGxveW1l bnRzLiBVc2FnZSBvZiBjb250cm9sbGVycyBpbiBsYXJnZSBzaXRlcyBpcyBub3QgdW5jb21tb24u IE5vdA0KPj50byANCj4+IG1lbnRpb24gMTFzLg0KPj4gPg0KPj4gPiBUaGUgcmVxdWlyZW1lbnRz IGlzIGxlZnQgb3Blbi4gSSdtIGxvb2tpbmcgZm9yd2FyZCBzZWUgc29tZSBkcmFmdA0KPj50ZXh0 Lg0KPj4gPg0KPj4gPiBUaGFua3MsIFRlY28NCj4+ID4NCj4+ID4NCj4+ID4gT3AgMzAgYXVnIDIw MTEsIG9tIDE5OjQyIGhlZWZ0IDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+PiA8R2Fib3IuQmFq a29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoNCj4+ID4NCj4+ID4+IEkgc2Vu dCB0aGlzIGVtYWlsIHRvIHRoZSBsaXN0IG9uZSB3ZWVrIGFnbywgYXNraW5nIGZvciBmZWVkYmFj ayBvbg0KPj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXBy b2JsZW0tc3RtdC11c2VjYXNlcy1ycW10DQo+PiA+PiBzIC0wMC50eHQgYnV0IHRoZXJlIHdhcyBu b3Qgb25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJIHRha2UgdGhhdCBhcw0KPj4gPj4gcGVvcGxlIGhh dmUgbm8gY29tbWVudHMgdG8gdGhlIGRyYWZ0IGF0IHRoaXMgdGltZS4NCj4+ID4+DQo+PiA+PiBB bmQgSSBhbSBhc2tpbmcgYWdhaW46IGlzIHRoZXJlIGFueSBvYmplY3Rpb24gaW4gYWRvcHRpbmcg dGhlIGFib3ZlDQo+PiBkcmFmdCBhcyBhIHdnIGRvY3VtZW50Pw0KPj4gPj4NCj4+ID4+IC1HYWJv cg0KPj4gPj4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBw YXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZg0KPj4gPj4gT2YgZXh0IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj4gPj4gU2VudDogTW9u ZGF5LCBBdWd1c3QgMjIsIDIwMTEgMjo0MyBQTQ0KPj4gPj4gVG86IHBhd3NAaWV0Zi5vcmcNCj4+ ID4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBj YXNlcyAmDQo+PiA+PiByZXF1aXJlbWVudHMNCj4+ID4+DQo+PiA+PiBEdXJpbmcgdGhlIFF1ZWJl YyBzZXNzaW9uLCB3ZSBoYWQgcHJlc2VudGF0aW9ucyBvZiB0aGUgUFMgYW5kIHRoZQ0KPj51c2Ug DQo+PiBjYXNlcyBkcmFmdHMuIFRoZSB3ZyB0aGVuIGRlY2lkZWQgaXQgd2FudHMgdG8gc2VlIHRo ZXNlIGRyYWZ0cyBtZXJnZWQNCj4+IGludG8gb25lLiBTY290dCBqdXN0IGRpZCB0aGF0IGFuZCBw b3N0ZWQgdGhlIG1lcmdlZCBkcmFmdDoNCj4+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4gPj4gcw0KPj4g Pj4gLTAwLnR4dA0KPj4gPj4NCj4+ID4+IE5vdyBJIHdvdWxkIGxpa2UgdG8gYXNrIGlmIHRoZSB3 ZyBmZWVscyBsaWtlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkNCj4+dG8gDQo+PiBiZSBhZG9wdGVk IGFzIGEgd2cgZG9jdW1lbnQuIFBsZWFzZSBzZW5kIHlvdXIgZmVlZGJhY2sgYW5kIGh1bSB0byB0 aGUNCj4+IGxpc3QgYnkgdGhpcyB0aW1lIG5leHQgd2Vlay4NCj4+ID4+DQo+PiA+PiAtR2Fib3IN Cj4+ID4+DQo+PiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ID4+IC0NCj4+ID4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPj4gRnJvbTogUHJvYmFzY28gU2NvdHQNCj4+ID4+IFNl bnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDExIDk6MTggQU0NCj4+ID4+IFRvOiBwYXdzQGlldGYu b3JnDQo+PiA+PiBTdWJqZWN0OiBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2Vz ICYgcmVxdWlyZW1lbnRzDQo+PiA+Pg0KPj4gPj4gSGksDQo+PiA+Pg0KPj4gPj4gQWNjb3JkaW5n IHRvIHRoZSByZXN1bHRzIG9mIHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZywgd2UgaGF2ZQ0KPj5j b21iaW5lZCANCj4+IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBJLUQgYW5kIHVzZSBjYXNlICYgcmVx dWlyZW1lbnQgSS1EIGludG8gYSBzaW5nbGUNCj4+IEktRC4gIFlvdXIgY29tbWVudHMgYXJlIHdl bGNvbWVkLg0KPj4gPj4NCj4+ID4+IFJlZ2FyZHMsDQo+PiA+PiBTY290dA0KPj4gPj4NCj4+ID4+ IFVSTDoNCj4+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1w cm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4gPj4gcw0KPj4gPj4gLTAwLnR4dA0KPj4gPj4N Cj4+ID4+DQo+PiA+PiBBYnN0cmFjdDoNCj4+ID4+IFBvcnRpb25zIG9mIHRoZSByYWRpbyBzcGVj dHJ1bSB0aGF0IGFyZSBhbGxvY2F0ZWQgdG8gYSBsaWNlbnNlZCwNCj4+ID4+IHByaW1hcnkgdXNl ciBidXQgYXJlIHVudXNlZCBvciB1bm9jY3VwaWVkIGF0IHNwZWNpZmljIGxvY2F0aW9ucyBhbmQN Cj4+ID4+IHRpbWVzIGFyZSBkZWZpbmVkIGFzICd3aGl0ZSBzcGFjZScuICBUaGUgY29uY2VwdCBv ZiBhbGxvd2luZw0KPj4gPj4gc2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgKGxpY2Vuc2VkIG9yIHVu bGljZW5zZWQpIGluIHdoaXRlIHNwYWNlIGlzIGENCj4+ID4+IHRlY2huaXF1ZSB0byAndW5sb2Nr JyBleGlzdGluZyBzcGVjdHJ1bSBmb3IgbmV3IHVzZS4gIEFuIG9idmlvdXMNCj4+ID4+IHJlcXVp cmVtZW50IGlzIHRoYXQgdGhlc2Ugc2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgZG8gbm90IGludGVy ZmVyZQ0KPj4gPj4gd2l0aCB0aGUgcHJpbWFyeSB1c2Ugb2YgdGhlIHNwZWN0cnVtLiAgT25lIGFw cHJvYWNoIHRvIHVzaW5nIHRoZQ0KPj4gPj4gd2hpdGUgc3BhY2Ugc3BlY3RydW0gYXQgYSBnaXZl biB0aW1lIGFuZCBsb2NhdGlvbiBpcyB0byB2ZXJpZnkgd2l0aCBhDQo+PiA+PiBkYXRhYmFzZSBh dmFpbGFibGUgY2hhbm5lbHMuDQo+PiA+Pg0KPj4gPj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg dGhlIGNvbmNlcHQgb2YgVFYgV2hpdGUgU3BhY2VzLiAgSXQgYWxzbw0KPj4gPj4gZGVzY3JpYmVz IHRoZSBwcm9ibGVtcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGZvciBlbmFibGluZyB0aGUg dXNlDQo+PiA+PiBvZiB0aGUgcHJpbWFyeSB1c2VyIG93bmVkIHdoaXRlIHNwYWNlIHNwZWN0cnVt IGZvciBzZWNvbmRhcnkgdXNlcnMsDQo+PiA+PiB3aXRob3V0IGNhdXNpbmcgaW50ZXJmZXJlbmNl LCBieSBxdWVyeWluZyBhIGRhdGFiYXNlIHdoaWNoIGtub3dzIHRoZQ0KPj4gPj4gY2hhbm5lbCBh dmFpbGFiaWxpdHkgYXQgYW55IGdpdmVuIGxvY2F0aW9uIGFuZCB0aW1lLiAgQSBudW1iZXIgb2YN Cj4+ID4+IHBvc3NpYmxlIHVzZSBjYXNlcyBvZiB0aGlzIHNwZWN0cnVtIGFuZCBkZXJpdmVkIHJl cXVpcmVtZW50cyBhcmUgYWxzbw0KPj4gPj4gZGVzY3JpYmVkLg0KPj4gPj4NCj4+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBwYXdzIG1h aWxpbmcgbGlzdA0KPj4gPj4gcGF3c0BpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+ID4+IHBh d3NAaWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KPj4gPg0KPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPiBwYXdzIG1haWxpbmcgbGlzdA0KPj4gPiBwYXdzQGlldGYub3JnDQo+PiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPg0KPg0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+cGF3cyBtYWls aW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wYXdzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5wYXdzIG1haWxpbmcgbGlzdA0KPnBhd3NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0K From peter@spectrumbridge.com Tue Sep 13 05:24:29 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 4C50921F8B2D for ; Tue, 13 Sep 2011 05:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=-1.971, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 Vu+UToDMKoSF for ; Tue, 13 Sep 2011 05:24:25 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id D36C021F8B19 for ; Tue, 13 Sep 2011 05:24:24 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 13 Sep 2011 08:27:56 -0400 From: Peter Stanforth To: ZhuLei , "scott.probasco@nokia.com" Date: Tue, 13 Sep 2011 08:26:26 -0400 Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AcxyEJBuYBkdUtN8QLOn5TM+9mnDuw== Message-ID: In-Reply-To: <470F27D1263A1B4EB73491ED995DE62539C33E@szxeml504-mbx.china.huawei.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 acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "paws@ietf.org" 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, 13 Sep 2011 12:24:29 -0000 UmVndWxhdGlvbiBvZiBUVldTIGlzIGN1cnJlbnRseSBwcm9wb3NlZCBieSAzIFJlZ3VsYXRvcnMs IFVTLCBVSyBhbmQNCkNhbmFkYSwgd2l0aCB3b3JrIG9uZ29pbmcgaW4gU2luZ2Fwb3JlLCBGaW5s YW5kIGFuZCBzZXZlcmFsIG90aGVyDQpjb3VudHJpZXMuIFRoZXJlIGFyZSBzdWJ0bGUgZGlmZmVy ZW5jZXMgaW4gYXBwcm9hY2ggYW5kIHJlcXVpcmVtZW50cyBidXQNCnRoZSBiYXNpYyBjb25jZXB0 IGlzIHRoZSBzYW1lIGluIGFsbCBjYXNlcy4gUEFXUyBzaG91bGQgYmUgYWJsZSB0byBhZGRyZXNz DQphbGwgY2FzZXMuDQpBbGwgcmVndWxhdG9ycyBhbGxvdyBmb3IgaW5kb29yIHVzZSBhcyB3ZWxs IGFzIG91dGRvb3IgdXNlLiBQQVdTIHNob3VsZA0KYWRkcmVzcyBhbGwgdGhlc2UgY2FzZXMuIEFs bCByZWd1bGF0b3JzIHByb3Bvc2UgdGhhdCBhIGNvbXBvbmVudCBvZiB0aGUNCmRlY2lzaW9uIGJl IGJhc2VkIG9uIHRoZSAiZGV2aWNlIHR5cGUiIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcmVzdWx0 cw0KYmFzZWQgb24gdGhlIGNhcGFiaWxpdHkgYW5kLCBpbiBzb21lIHJlZ3VsYXRpb24sIHRoZSBt YXhpbXVtIHBvd2VyIG91dHB1dA0Kb2YgdGhlIGRldmljZS4gVGhlcmUgaXMgbm8gcmVhc29uIFBB V1MgY2Fubm90IGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyBmb3INCmluZG9vciB1c2UgYXMgd2Vs bCBhcyBvdXRkb29yIHVzZS4gQXQgNDUwLTcwME1IeiB0aGUgaXNzdWUgb2YgY28tZXhpc3RlbmNl DQpiZXR3ZWVuIDIgYXBhcnRtZW50cyBpcyByZWFsbHkgbm8gZGlmZmVyZW50IHRoYW4gdGhlIGNv LWV4aXN0ZW5jZSBiZXR3ZWVuDQoyIG91dGRvb3IgYWNjZXNzIHBvaW50cyBzZXZlcmFsIGh1bmRy ZWQgbWV0ZXJzIGFwYXJ0LiBUaGF0IHNhaWQsIGl0IHdhcyBteQ0KdW5kZXJzdGFuZGluZyB0aGF0 IFBBV1Mgd2FzIGFsc28gZnJlcXVlbmN5IGFuZCBtb2R1bGF0aW9uIGluZGVwZW5kZW50LA0Kd2hp Y2ggaXQgc2hvdWxkIGJlLg0KUGV0ZXIgU3RhbmZvcnRoDQpTcGVjdHJ1bSBCcmlkZ2UgSW5jLg0K DQpPbiBUdWVTZXAvMTMvMTEgVHVlIFNlcCAxMywgMzowOSBBTSwgIlpodUxlaSIgPGxlaS56aHVA aHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBTY290dCBhbmQgYWxsLA0KPg0KPkZvciBzb21lIHJl YXNvbnMsIEkgdGhpbmsgdGhhdCBQQVdTIHByb3RvY29sIHdvdWxkIGJlIGRldmVsb3BlZCB3aXRo DQo+cXVpdGUgc3RhYmxlIHNjZW5hcmlvIGRlc2NyaXB0aW9ucyBvZiBpbmRvb3IgY292ZXJhZ2Uu DQo+DQo+QWNjb3JkaW5nIHRvIHByZXZpb3VzIGUtbWFpbCBkaXNjdXNzaW9uIGluIHRoZSBsaXN0 LCBpdCBzZWVtcyB0aGF0DQo+d29ya2luZyBncm91cCB3b3VsZCBkZXZlbG9wIGdlbmVyaWMgYW5k IGdsb2JhbGx5IGFwcGxpY2FibGUgc3BlY3RydW0NCj5kYXRhYmFzZSBxdWVyeSBwcm90b2NvbCB3 aGljaCBob3BlbHkgaXMgYWNjZXB0ZWQgYnkgb3RoZXIgcmVndWxhdG9ycyBidXQNCj5vbmx5IEZD Qy4gNzAwTUh6LTgwME1IeiBjYW4gYmUgc2hhcmVkIHRvIHBhcnRpY3VsYXIgd2lyZWxlc3MgYWNj ZXNzDQo+dGVjaG5vbG9naWVzIGxpa2UgODAyLjExLCA4MDIuMjIgYW5kIGV2ZW4gTFRFLiBQbGVh c2UgY29ycmVjdCBtZSBpZg0KPnNvbWV0aGluZyB3cm9uZy4NCj4NCj5UaGUgZ2VuZXJpYyB1c2Ug Y2FzZXMgY291bGQgYmUgc2FmZSB3aGVuIGRlY2lkaW5nIHdvcmtpbmcgZ3JvdXAgZHJhZnQuDQo+ QnV0IGhvdHNwb3QgYW5kIHVyYmFuIGludGVybmV0IGNvbm5lY3Rpb24gZGVzY3JpcHRpb24gaXMg c3RpbGwgbm90DQo+Y3JlZGl0YWJsZSB0byBkZXZlbG9wIFBBV1MgcHJvdG9jb2wgZm9yIHRoZSBy ZWFzb24gNzAwTUh6IGhhcyBmYXINCj5kaWZmZXJlbnQgcHJvcGFnYXRpb24gY2hhcmFjdGVyaXN0 aWNzIGZyb20gdGhlIG5lZWRzIG9mIGluZG9vciBjb3ZlcmFnZQ0KPmFuZCB1cmJhbiBob3RzcG90 IHVzZSBjYXNlLiBJbiBnZW5lcmFsLCBpbmRvb3IgdXNlIGNhc2Ugc2F5cyB0aGF0DQo+ZGF0YWJh c2Ugc2hvdWxkIHRvIHJlc3BvbnNlIHByb3BlciBzcGVjdHJ1bSBpZiBBUHMgcmVxdWVzdCBjaGFu bmVscyBmb3INCj5pbmRvb3IgSW50ZXJuZXQgY29ubmVjdGlvbi4gSWYgaXQgaXMgbm90IHBvc3Np YmxlLCByZWd1bGF0b3JzIG11c3QgdG8NCj5mYWNlIHByb2JsZW1zIG9mIGludGVyZmVyZW5jZSBh bW9uZyBBUHMgYW5kIE1pY3JvIGNlbGwgQlNzLiBUaGVuLCBQQVdTDQo+bm93IGhhcyB0byByZWNv Z25pemUgc2NlbmFyaW8gZGVzY3JpcHRpb24gYW5kIHJlcXVpcmVtZW50cyBiZWZvcmUgZGV2ZWxv cA0KPnByb3RvY29sIHRoYXQgb3RoZXIgaGlnaGVyIGZyZXF1ZW50IGJhbmRzIChhdCBsZWFzdCBo aWdoZXIgdGhhbiAyLjFHSHopDQo+c2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gaW5kb29yIGNvdmVy YWdlLiBJIHdvdWxkIGxpa2UgdG8gcmVtaW5kIHRoYXQgaXMNCj5kaWZmZXJlbnQgbmVlZCBmb3Ig aW5kb29yIGNvdmVyYWdlIGZyb20gZ2VuZXJpYyBob3RzcG90IGFuZCB1cmJhbg0KPmNvdmVyYWdl IHdoaWNoIGlzIHN0aWxsIHRvIGJlIGRpdmlkZWQuDQo+DQo+RnJvbSBwcm90b2NvbCBwZXJzcGVj dGl2ZSwgaXQgd2lsbCBkZXBlbmQgb24gdGhlIGNvbmNsdXNpb24gb2Ygd29ya2luZw0KPmdyb3Vw IHdoaWNoIElFcyBhcmUgcmVzZXJ2ZWQgZm9yIGluZG9vciBxdWVyeSB1c2FnZXMuDQo+DQo+VGhy ZWUgdGhpbmdzIGFyZSBwYXJ0aWN1bGFyIGZvciBpbmRvb3IgY292ZXJhZ2UgdXNlIGNhc2UgaWYg ZGV2ZWxvcCBQQVdTDQo+cHJvdG9jb2wuIEZpcnN0IG9uZSBpcyB0aGF0IHRoZSBsb2NhdGlvbiBp biBhIGJ1aWxkaW5nIGlzIGRpZmZlcmVudCBmcm9tDQo+R1BTIHBvc2l0aW9uaW5nLiBTZWNvbmQg b25lIGlzIHRoYXQgdGhlIGRhdGFiYXNlIHNob3VsZCBiZSBhYmxlIHRvDQo+Y2FsY3VsYXRlIHRo ZSBwcm9wZXIgYmFuZCBmb3IgaW5kb29yIGNvdmVyYWdlLiBUaGlyZCBvbmUgaXMgdGhhdCBkYXRh YmFzZQ0KPnNob3VsZCBiZSBhYmxlIHRvIGNvbnNpZGVyIChvciBjYWxjdWxhdGUpIGFuZCBhdm9p ZCB1bmV4cGVjdGVkDQo+aW50ZXJmZXJlbmNlIGFtb25nIGRpZmZlcmVudCBpbmRvb3IgQVBzIGFu ZCBtaWNybyBjZWxsIEJTcy4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+Wmh1IExlaQ0KPg0KPg0KPi0t LS0t08q8/tStvP4tLS0tLQ0KPreivP7Iyzogc2NvdHQucHJvYmFzY29Abm9raWEuY29tIFttYWls dG86c2NvdHQucHJvYmFzY29Abm9raWEuY29tXQ0KPreiy83KsbzkOiAyMDExxOo51MI4yNUgMjM6 NDkNCj7K1bz+yMs6IFpodUxlaQ0KPrOty806IHBhd3NAaWV0Zi5vcmcNCj7W98ziOiBSZTogW3Bh d3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMN Cj4NCj5IZWxsbyBMZWksDQo+DQo+SSBoYXZlIHN0dWRpZWQgdGhlIHRleHQgYmVsb3csIGJ1dCBJ IGRvIG5vdCB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3UNCj5hcmUgcHJvcG9zaW5nLiBJdCBz ZWVtcyB0byBtZSB0aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBhIGRlcGxveW1lbnQNCj5zY2VuYXJp byAod2hpY2ggaXMgZmluZSkuIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCBpcyB0aGUgdXNlIGNh c2UsIG9yIGhvdw0KPnRoaXMgY2FzZSBpcyBkaWZmZXJlbnQgZnJvbSAiSG90c3BvdCIgdXNlIGNh c2UgKEFQIGlzIGluZG9vcikgd2l0aCBhDQo+IldpZGUtYXJlYSBvciBydXJhbCIgdXNlIGNhc2Ug ZGVwbG95ZWQgaW4gdGhlIHNhbWUgZ2VuZXJhbCBhcmVhIChtaWNyb2NlbGwNCj5pcyBvdXRkb29y KS4NCj4NCj5JIGFtIG5vdCBzcGVha2luZyBhZ2FpbnN0IHRoZSB1c2UgY2FzZSwgc2ltcGx5IHNh eWluZyB0aGF0IEkgZG9uJ3QNCj51bmRlcnN0YW5kIGl0IHdlbGwgZW5vdWdoIHRvIGNvbW1lbnQg b24gaXQuIEl0IG1pZ2h0IGhlbHAgZnVydGhlcg0KPmRpc2N1c3Npb24gaWYgeW91IGNhbiBkZXNj cmliZSBpbiBtb3JlIGRldGFpbCB0aGUgdXNlIGNhc2UsIGFuZCBpbmNsdWRlDQo+c3BlY2lmaWMg YWN0aW9ucyB0aGF0IGVhY2ggZWxlbWVudCAobWljcm9jZWxsLCBBUCwgZGV2aWNlLCBkYXRhYmFz ZSwgZXRjKQ0KPm11c3QgY29tcGxldGUgaW4gb3JkZXIgdG8gZGVwbG95IHRoaXMgdXNlIGNhc2Uu DQo+DQo+UmVnYXJkcywNCj5TY290dA0KPg0KPg0KPk9uIDkvNy8xMSA4OjM1IFBNLCAiZXh0IFpo dUxlaSIgPGxlaS56aHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+PkhpIGFsbCwNCj4+DQo+Pkkg dGhpbmsgdGhhdCB3ZSBkbyBzb21lIHdvcmtzIG9uIGltcHJvdmluZyBvcmlnaW5hbCB1c2UgY2Fz ZSBkcmFmdCBieQ0KPj5hZGRpbmcgdGhyZWUgYWRkaXRpb25hbCB1c2UgY2FzZXMsIGluY2x1ZGlu ZyBpbmRvb3IgY292ZXJhZ2UsIGFkIGhvYw0KPj5uZXR3b3JrIGFuZCBsdGUgbWJtcyBpc3N1ZS4N Cj4+DQo+Pk5vdywgSSBhbSBhc2tpbmcgdG8gYWRkIGluZG9vciBjb3ZlcmFnZSBzY2VuYXJpbyB3 aGljaCBpcyBuZWNlc3NhcnkgZm9yDQo+PlBBV1MgcHJvdG9jb2wgdG8gY29uc2lkZXIgaW4gbmV4 dCBzdGFnZS4gVGhlIHByb3Bvc2VkIHVzZSBjYXNlIGlzIHNlZW4NCj4+YmVsb3cuIFRoZSB1cGRh dGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBiZSBzdWJtaXR0ZWQgc29vbiBieQ0KPj5h ZGRpbmcgc29tZSB3b3JkaW5nIG1vZGlmaWNhdGlvbnMuIFNvLCBJIGRvbid0IHRoaW5rIHdlIGFy ZSB0byBza2lwIHRoZQ0KPj5hZGRpdGlvbmFsIHVzZSBjYXNlcyBldmVuIHRoZSBwcm9ibGVtIHN0 YXRlbWVudCwgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50DQo+PnByb3Bvc2FsIGhhdmUgYmVlbiBp bnRlZ3JhdGVkIG5vdy4NCj4+DQo+Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KPj54LnguICBJbmRvb3IgdXNhZ2Ugb2YgVFZXUw0KPj4NCj4+ ICAgQXQgcHJlc2VudCwgdGhlIGluZG9vciB3aXJlbGVzcyBjb3ZlcmFnZSBlcXVpcG1lbnRzIGNv bnNpc3Qgb2YgV2ktRmktDQo+PiAgIGxpa2UgYWNjZXNzIHBvaW50cyBhbmQgbWljcm8gY2VsbHMs IGFsbCBvZiB0aGVzZSB1dGlsaXplIHNlZ21lbnRzIG9mDQo+PiAgIGZyZXF1ZW5jeSwgZm9ybWVy IGF0IGFib3V0IDIuNEdIeiBvciA1R2h6IGFuZCB0aGUgbGF0dGVyLCBmb3INCj4+ICAgZXhhbXBs ZSwgODAyLjExbiBhdCBhYm91dCAyLjRHSHouICBBcyBhIHJlc3VsdCBvZiB0aGUgYmxvY2sgb2YN Cj4+ICAgYnVpbGRpbmdzIGFuZCBvdGhlciBvYnN0cnVjdGlvbiBhbmQgaW50ZXJmZXJlY2UsIGl0 IG1heSBub3QgYmUgdGhhdA0KPj4gICBvcHRpbWlzdGljIHdoZW4gODAyLjExIGRldmljZXMgZXhh bWluZSB0aGUgc3RhdHVzIG9mIHdpcmVsZXNzDQo+Pg0KPj4NCj4+DQo+PlpodSAgICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAz XQ0KPj4NCj4+DQo+PkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUEFXUyB1c2UgY2FzZXMg ICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMQ0KPj4NCj4+DQo+PiAgIGludGVyZmVyZXMuICBU aGlzIHVzZSBjYXNlIHRha2VzIHRoZSBiZW5lZml0IG9mIFRWIFdoaXRlIFNwYWNlIHRvDQo+PiAg IHByb3ZpZGUgYWRkaXRpb25hbCBjYXBhY2l0eSB0byBpbmRvb3IgY292ZXJhZ2UgYW5kIHJlZHVj ZSBjaGFubmVsDQo+PiAgIGludGVyZmVyZWNlLg0KPj4NCj4+ICAgVGhlIGZpZ3VyZSBiZWxvdyBz aG93cyBhbiBleGFtcGxlIGRlcGxveW1lbnQgb2YgdGhpcyBzY2VuYXJpby4NCj4+DQo+PiAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ICAgICAgICAg ICAgICAgfCAgICAgICAgICAgIGluZG9vciAgICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICAgICB8ICAgICstLS0t LS0rICAgd2hpdGUgc3BhY2UgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0rDQo+PiAgICAgICAgICAg ICAgIHwgICAgfERldmljZXwgLSAtIC0gLSAtIC0gLSAtIC0gLXwtIC18IE1pY3JvIGNlbGwgIHwN Cj4+ICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgXCAgICAgICAgICAgICAgICAgfCAgICst LS0tLS0tLS0tLS0tKw0KPj4gICAgICAgICAgICAgICB8ICAgICstLS0tLS0rICAgXHdoaXRlIHNw YWNlICAgICB8ICAgICAoLS0tLS0pDQo+PiAgICAgICAgICAgICAgIHwgICAgfERldmljZXwgICAg XCArLS0tLS0tLS0tLS0tK3wgICAgLyAgICAgICBcDQo+PiAgICAgICAgICAgICAgIHwgICAgKy0t LS0tLSsgICAgICB8YWNjZXNzIHBvaW50fHw9PT0oIEludGVybmV0KQ0KPj4gICAgICAgICAgICAg ICB8ICAgICAgICBvICAgICAgIC8gKy0tLS0tLS0tLS0tLSt8ICAgIFwgICAgICAgLw0KPj4gICAg ICAgICAgICAgICB8ICAgICAgICBvICAgICAgLyAgICAgICAgICAgICAgICB8ICAgICAoLS0tLS0p DQo+PiAgICAgICAgICAgICAgIHwgICAgICAgIG8gICAgIC8gICAgICAgICAgICAgICAgIHwNCj4+ ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pg0KPj4NCj4+ ICAgICAgICAgICAgICAgICAgICAgICBHcmFwaCAxIEluZG9vciB1c2FnZSBvZiBUVldTDQo+Pg0K Pj4gICBUaGUgYWNjZXNzIHBvaW50IGNvdWxkIGJlIGEgV0ktRkkgcm91dGVyLCBhbmQgdGhlIG1p Y3JvIGNlbGwgaXMgYQ0KPj4gICBzaG9ydCByYW5nZSB3aXJlbGVzcyBjb3ZlcmFnZShlLmcuIGlu IHJhbmdlIG9mIDAtNTBtKSBiYXNlIHN0YXRpb24sDQo+PiAgIGJvdGggb2YgdGhlbSBhY3QgYXMg bWFzdGVyIGRldmljZXMsIHF1ZXJ5aW5nIHRoZSBpbnRlcm5ldCBjb25uZWN0ZWQNCj4+ICAgZGF0 YWJhc2UgZm9yIGF2YWlsYWJsZSB3aGl0ZSBzcGFjZSBzcGVjdHJ1bSBiYXNlZCBvbiBpdHMgZ2Vv LQ0KPj4gICBsb2NhdGlvbiwgYW5kIHByb3ZpZGluZyBUVldTIGFjY2VzcyB0byBpbmRvb3IgdXNl ci4NCj4+DQo+PiAgIFRoZSBUVldTIHNwZWN0cnVtIGhhcyBkaWZmZXJlbnQgcHJvcGFnYXRpb24g Y2hhcmFjdGVyaXN0aWNzIGNvbXBhcmVkDQo+PiAgIHRvIGhpZ2hlciBmcmVxdWVuY3kgYmFuZCwg Zm9yIGV4YW1wbGUsIHRoZSB0cmFuc21pc3Npb24gZGlzdGFuY2UNCj4+ICAgdXNpbmcgVFZXUyBj YW4gYmUgc2V2ZXJhbCB0aW1lcyBsb25nZXIgdGhhbiB0aG9zZSBpbiB0aGUgaGlnaGVyIGJhbmQu DQo+PiAgIEluIHRoaXMgY2FzZSwgZ29vZCBwZW5ldHJhdGlvbiBjaGFyYWN0ZXJpc3RpYyBvZiBU VldTIG1ha2VzIGl0DQo+PiAgIGRpZmZpY3VsdCB0byBsb2NrIHRoZSBzaWduYWxzIGluIHRoZSBy b29tLCB0aGVuIGRpZmZpY3VsdCB0byBsb2NhbGl6ZQ0KPj4gICBhbmQgZGlmZmVyZW50aWF0ZSBz aWduYWxzLCBhbmQgZmluYWxseSBjYXVzZSBpbnRlcmZlcmVzIGFtb25nDQo+PiAgIG5laWdoYm9y aW5nIG5ldHdvcmtzLiAgUmVxdWlyZW1lbnRzIHRvIGluZG9vciBXUyBkYXRlYmFzZSB1c2FnZSB3 b3VsZA0KPj4gICBiZToNCj4+DQo+Pg0KPj4gICAxLiAgQSBmcmVxdWVuY3kgcHJvdGVjdGlvbiBn YXAgYmV0d2VlbiBuZWlnaGJvcnMocGFydGljdWxhciBzcGVjdHJ1bQ0KPj4gICAgICAgYWxsb2Nh dGlvbiBhbGdvcml0aG0gaXMgbmVlZGVkIGhlcmUpLg0KPj4NCj4+ICAgMi4gIGxvd2VyIG91dHB1 dCBwb3dlciBvZiBBUC9taWNybyBjZWxsLCBpdCBzZWVtcyB0aGF0IG9ubHkgY2VydGFpbg0KPj4g ICAgICAgcGljbyBvciBmZW10byBjZWxscyBiZSBmZWFzaWJsZSBoZXJlLg0KPj4NCj4+ICAgMy4g IFBBV1MgbXVzdCBub3QgYmUgdGllZCB0byBhIHNwZWNpZmljIGZyZXF1ZW5jeSBiYW5kLg0KPj4N Cj4+ICAgNC4gIFBBV1MgbXVzdCByZXNwb25zZSB0aGUgcHJvcGVyIGZyZXF1ZW5jeSBiYW5kIGxp c3QgdG8gcGFydGljdWxhcg0KPj4gICAgICAgY292ZXJhZ2Ugd2hpdGUgc3BhY2UgZGV2aWNlcy4N Cj4+DQo+PiAgIDUuICBNYXN0ZXIgZGV2aWNlcyBzaG91bGQgc3VwcG9ydCBwb3dlciBjb250cm9s Lg0KPj4NCj4+ICAgNi4gIFNsYXZlIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29udHJv bC4NCj4+DQo+Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPj4NCj4+Wmh1IExlaQ0KPj4NCj4+DQo+Pi0tLS0t08q8/tStvP4tLS0tLQ0KPj63 orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBHZXJhbGQNCj4+Q2hvdWluYXJkDQo+Preiy83KsbzkOiAyMDExxOo51MI4yNUgODow MQ0KPj7K1bz+yMs6IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj6zrcvNOiBwYXdzQGlldGYub3Jn DQo+Ptb3zOI6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNl cyAmIHJlcXVpcmVtZW50cw0KPj4NCj4+R2Fib3IsDQo+Pg0KPj5DYW4gSSBhc2sgdGhhdCB0aGUg dGV4dCBtb2RpZmljYXRpb25zIHRoYXQgSSBoYXZlIHN1Ym1pdHRlZCB0byBzY290dCBhbmQNCj4+ Y29waWVkIHRvIHRoZSBwYXdzIHJlZmxlY3RvciBpbiBteSBlbWFpbCBkYXRlZCA4IEF1Z3VzdCBi ZSBpbmNsdWRlZCBhcw0KPj53ZWxsPw0KPj4NCj4+VGhhbmsncywNCj4+DQo+PkdlcmFsZA0KPj4N Cj4+DQo+PkF0IDIwOjMyIDA3LTA5LTExICswMDAwLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3Jv dGU6DQo+Pj5PaywgbGV0J3MgdHJ5IHRoYXQgdGhlbi4NCj4+PlNjb3R0LCBjYW4geW91IHB1dCB1 c2UgY2FzZXMgYmVmb3JlIFBTLCBhbmQgYWRkIHRoZSBhZC1ob2MgdXNlIGNhc2UuIEkNCj4+Pmp1 c3Qgc2Nhbm5lZCB0aHJvdWdoIHRoZSBsaXN0IGFuZCBzcG90dGVkIHRoYXQgVGVjbyBpbmRlZWQg cHJvdmlkZWQgYQ0KPj4+ZGVzY3JpcHRpb24gZm9yIHRoYXQgdXNlIGNhc2Ugb24gQXVnIDNyZC4N Cj4+PkFuZCBzdWJtaXQgdGhlIGRyYWZ0IGFzIGEgd2cgaXRlbSwgdW5sZXNzIHRoZXJlIGFyZSBz dGlsbCBvYmplY3Rpb25zLg0KPj4+DQo+Pj4tR2Fib3INCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+PkZyb206IGV4dCBOYW5jeSBCcmF2aW4gW21haWx0bzpuYnJhdmluQGVh cnRobGluay5uZXRdDQo+Pj5TZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDAzLCAyMDExIDM6NDEg UE0NCj4+PlRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+Pj5DYzog VGVjbyBCb290OyBHZXJhbGQgQ2hvdWluYXJkOyBwYXdzQGlldGYub3JnDQo+Pj5TdWJqZWN0OiBS ZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJl bWVudHMNCj4+Pg0KPj4+RGVhciBHYWJvciBhbmQgQWxsLA0KPj4+DQo+Pj5JIHRoaW5rIGl0IGlz IGFwcHJvcHJpYXRlIHRvIHB1dCB0aGUgdXNlIGNhc2VzIGJlZm9yZSB0aGUgUFMgZm9yIG9idmlv dXMNCj4+PnJlYXNvbnMsIGFuZCBpbmNsdWRpbmcgdGhlICJwcm94eSIgbmVlZCBpbiB0aGUgZmly c3QgZHJhZnQuIEkgc3VwcG9ydA0KPj4+aW5jbHVkaW5nIGJvdGggR2VyYWxkJ3Mgc3VnZ2VzdGlv bnMgYW5kIFRlY28ncyBwcm9wb3NhbCBpbiB0aGUgb3JpZ2luYWwNCj4+PmRyYWZ0IGFuZCBub3Qg d2FpdGluZyB1bnRpbCBhIGxhdGVyIHRpbWUuIEl0IGlzIHRoZSBwcm9wZXIgb3JkZXIsDQo+Pj5p bmNsdXNpdmUgYW5kIG5lZWRlZCBpbiB0aGUgaW5pdGlhbCBkcmFmdCBpbiBteSBvcGluaW9uLiBJ IGJlbGlldmUgd2l0aA0KPj4+dGhlIHRhbGVudCBpbiB0aGUgZ3JvdXAgaXQgd2lsbCBub3QgdGFr ZSBsb25nIHRvIGFjY29tcGxpc2ggdGhpcyBhbmQgeW91DQo+Pj53aWxsIGhhdmUgYSBtb3JlIGNv aGVzaXZlIGRyYWZ0Lg0KPj4+DQo+Pj5TSW5jZXJlbHksIE5hbmN5DQo+Pj4NCj4+Pg0KPj4+T24g U2VwIDIsIDIwMTEsIGF0IDI6MTkgUE0sIDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+Pj48R2Fi b3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToNCj4+Pg0KPj4+ID4gVGVjbywgR2VyYWxkLA0KPj4+ ID4NCj4+PiA+IFRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBJJ2Qgc3VnZ2VzdCB0aGF0IHdlIG1h a2UgdGhpcyBkcmFmdCBhIFdHDQo+Pj5pdGVtLA0KPj4+IHdpdGggR2VyYWxkJ3MgcHJvcG9zZWQg Y2hhbmdlcyBpbiBpdC4gUmVnYXJkaW5nIHRoZSBvcmRlciBvZiB0aGUNCj4+PnByb2JsZW0NCj4+ PiBzdGF0ZW1lbnQgdnMgdXNlIGNhc2VzLCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGxlYXZl IGl0IGFzIGl0IGlzDQo+Pj4oYnV0DQo+Pj4gd2UgY2FuIGFsd2F5cyBjaGFuZ2UgaXQsIGlmIHRo YXQgaXMgd2hhdCB0aGUgV0cgd2FudHMpLg0KPj4+ID4NCj4+PiA+IFNvLCBJJ2QgYXNrIFNjb3R0 IHRvIHN1Ym1pdCBhIFdHIHZlcnNpb24gb2YgdGhpcyBkcmFmdCwgdGhlbiBoYXZlDQo+Pj4gc29t ZW9uZSBjb21lIHVwIHdpdGggdGV4dCBmb3IgdGhpcyBhZC1ob2MgbmV0d29yayBzY2VuYXJpbywg aGF2ZSB0aGUgV0cNCj4+PiBhZ3JlZSB3aXRoIHRoZSB0ZXh0IGFuZCBpbmNsdWRlIGl0IGluIG9u ZSBvZiB0aGUgc3Vic2VxdWVudCB2ZXJzaW9ucy4NCj4+PiBUZWNvLCB3b3VsZCB5b3Ugd3JpdGUg dXAgc29tZSB0ZXh0IGZvciB0aGlzIGFkLWhvYyB1c2UgY2FzZSB0aGUgV0cNCj4+PmNvdWxkDQo+ Pj4gZGlzY3Vzcz8NCj4+PiA+DQo+Pj4gPiBXZSdsbCBhbHNvIHNlbmQgYW4gaW5pdGlhbCB2ZXJz aW9uIG9mIGEgbGlzdCBvZiByZXF1aXJlbWVudHMgdG8gdGhlDQo+Pj4gbGlzdCBuZXh0IHdlZWsu DQo+Pj4gPg0KPj4+ID4gLSBHYWJvcg0KPj4+ID4NCj4+PiA+DQo+Pj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+ID4gRnJvbTogZXh0IFRlY28gQm9vdCBbbWFpbHRvOnRlY29AaW5m LW5ldC5ubF0NCj4+PiA+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTEgMTE6MDYg UE0NCj4+PiA+IFRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+Pj4g PiBDYzogcGF3c0BpZXRmLm9yZw0KPj4+ID4gU3ViamVjdDogUmU6IFtwYXdzXSBjb21iaW5lZCBw cm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYNCj4+PiA+IHJlcXVpcmVtZW50cw0KPj4+ID4N Cj4+PiA+IEkgdGhpbmsgdGhlIGRvYyBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQuIEkgc3VwcG9y dCBhZG9wdGlvbi4NCj4+PiA+DQo+Pj4gPiBJIHN1Z2dlc3QgcmVvcmRlcmluZzogc3BlY2lmeWlu ZyBwcm9ibGVtIHN0YXRlbWVudCBhZnRlciBpbnRyb2R1Y2luZw0KPj4+IHRoZSB1c2UgY2FzZXMu DQo+Pj4gPg0KPj4+ID4gU29tZSBhc2tlZCBmb3IgdGhlIGFkIGhvYyBuZXR3b3JrIHNjZW5hcmlv LiBUaGlzIGluY2x1ZGVzIG1lIDotKS4NCj4+PlRoaXMNCj4+PiBpcyBpbXBvcnRhbnQsIGJlY2F1 c2UgaXQgZGVtb25zdHJhdGVzIHRoZSBuZWVkIGZvciAicHJveHkiLg0KPj4+ID4gQlRXLCBJIHdv bmRlciB3aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0IHBvcCB1cCBmcm9tIFdpRmkNCj4+PiBk ZXBsb3ltZW50cy4gVXNhZ2Ugb2YgY29udHJvbGxlcnMgaW4gbGFyZ2Ugc2l0ZXMgaXMgbm90IHVu Y29tbW9uLiBOb3QNCj4+PnRvDQo+Pj4gbWVudGlvbiAxMXMuDQo+Pj4gPg0KPj4+ID4gVGhlIHJl cXVpcmVtZW50cyBpcyBsZWZ0IG9wZW4uIEknbSBsb29raW5nIGZvcndhcmQgc2VlIHNvbWUgZHJh ZnQNCj4+PnRleHQuDQo+Pj4gPg0KPj4+ID4gVGhhbmtzLCBUZWNvDQo+Pj4gPg0KPj4+ID4NCj4+ PiA+IE9wIDMwIGF1ZyAyMDExLCBvbSAxOTo0MiBoZWVmdCA8R2Fib3IuQmFqa29Abm9raWEuY29t Pg0KPj4+IDxHYWJvci5CYWprb0Bub2tpYS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0K Pj4+ID4NCj4+PiA+PiBJIHNlbnQgdGhpcyBlbWFpbCB0byB0aGUgbGlzdCBvbmUgd2VlayBhZ28s IGFza2luZyBmb3IgZmVlZGJhY2sgb24NCj4+PiA+Pg0KPj4+aHR0cDovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10DQo+Pj4gPj4g cyAtMDAudHh0IGJ1dCB0aGVyZSB3YXMgbm90IG9uZSBmZWVkYmFjayByZWNlaXZlZC4gSSB0YWtl IHRoYXQgYXMNCj4+PiA+PiBwZW9wbGUgaGF2ZSBubyBjb21tZW50cyB0byB0aGUgZHJhZnQgYXQg dGhpcyB0aW1lLg0KPj4+ID4+DQo+Pj4gPj4gQW5kIEkgYW0gYXNraW5nIGFnYWluOiBpcyB0aGVy ZSBhbnkgb2JqZWN0aW9uIGluIGFkb3B0aW5nIHRoZSBhYm92ZQ0KPj4+IGRyYWZ0IGFzIGEgd2cg ZG9jdW1lbnQ/DQo+Pj4gPj4NCj4+PiA+PiAtR2Fib3INCj4+PiA+Pg0KPj4+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gPj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+PiA+PiBPZiBleHQgR2Fi b3IuQmFqa29Abm9raWEuY29tDQo+Pj4gPj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEg Mjo0MyBQTQ0KPj4+ID4+IFRvOiBwYXdzQGlldGYub3JnDQo+Pj4gPj4gU3ViamVjdDogUmU6IFtw YXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYNCj4+PiA+PiByZXF1 aXJlbWVudHMNCj4+PiA+Pg0KPj4+ID4+IER1cmluZyB0aGUgUXVlYmVjIHNlc3Npb24sIHdlIGhh ZCBwcmVzZW50YXRpb25zIG9mIHRoZSBQUyBhbmQgdGhlDQo+Pj51c2UNCj4+PiBjYXNlcyBkcmFm dHMuIFRoZSB3ZyB0aGVuIGRlY2lkZWQgaXQgd2FudHMgdG8gc2VlIHRoZXNlIGRyYWZ0cyBtZXJn ZWQNCj4+PiBpbnRvIG9uZS4gU2NvdHQganVzdCBkaWQgdGhhdCBhbmQgcG9zdGVkIHRoZSBtZXJn ZWQgZHJhZnQ6DQo+Pj4gPj4NCj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFz Y28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4+ID4+IHMNCj4+PiA+PiAtMDAu dHh0DQo+Pj4gPj4NCj4+PiA+PiBOb3cgSSB3b3VsZCBsaWtlIHRvIGFzayBpZiB0aGUgd2cgZmVl bHMgbGlrZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5DQo+Pj50bw0KPj4+IGJlIGFkb3B0ZWQgYXMg YSB3ZyBkb2N1bWVudC4gUGxlYXNlIHNlbmQgeW91ciBmZWVkYmFjayBhbmQgaHVtIHRvIHRoZQ0K Pj4+IGxpc3QgYnkgdGhpcyB0aW1lIG5leHQgd2Vlay4NCj4+PiA+Pg0KPj4+ID4+IC1HYWJvcg0K Pj4+ID4+DQo+Pj4gPj4NCj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ID4+IC0NCj4+PiA+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiA+PiBGcm9tOiBQcm9iYXNjbyBTY290dA0K Pj4+ID4+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDExIDk6MTggQU0NCj4+PiA+PiBUbzog cGF3c0BpZXRmLm9yZw0KPj4+ID4+IFN1YmplY3Q6IGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50 LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4+PiA+Pg0KPj4+ID4+IEhpLA0KPj4+ID4+DQo+ Pj4gPj4gQWNjb3JkaW5nIHRvIHRoZSByZXN1bHRzIG9mIHRoZSBmYWNlLXRvLWZhY2UgbWVldGlu Zywgd2UgaGF2ZQ0KPj4+Y29tYmluZWQNCj4+PiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgSS1EIGFu ZCB1c2UgY2FzZSAmIHJlcXVpcmVtZW50IEktRCBpbnRvIGEgc2luZ2xlDQo+Pj4gSS1ELiAgWW91 ciBjb21tZW50cyBhcmUgd2VsY29tZWQuDQo+Pj4gPj4NCj4+PiA+PiBSZWdhcmRzLA0KPj4+ID4+ IFNjb3R0DQo+Pj4gPj4NCj4+PiA+PiBVUkw6DQo+Pj4gPj4NCj4+Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4+ ID4+IHMNCj4+PiA+PiAtMDAudHh0DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+IEFic3RyYWN0Og0K Pj4+ID4+IFBvcnRpb25zIG9mIHRoZSByYWRpbyBzcGVjdHJ1bSB0aGF0IGFyZSBhbGxvY2F0ZWQg dG8gYSBsaWNlbnNlZCwNCj4+PiA+PiBwcmltYXJ5IHVzZXIgYnV0IGFyZSB1bnVzZWQgb3IgdW5v Y2N1cGllZCBhdCBzcGVjaWZpYyBsb2NhdGlvbnMgYW5kDQo+Pj4gPj4gdGltZXMgYXJlIGRlZmlu ZWQgYXMgJ3doaXRlIHNwYWNlJy4gIFRoZSBjb25jZXB0IG9mIGFsbG93aW5nDQo+Pj4gPj4gc2Vj b25kYXJ5IHRyYW5zbWlzc2lvbnMgKGxpY2Vuc2VkIG9yIHVubGljZW5zZWQpIGluIHdoaXRlIHNw YWNlIGlzIGENCj4+PiA+PiB0ZWNobmlxdWUgdG8gJ3VubG9jaycgZXhpc3Rpbmcgc3BlY3RydW0g Zm9yIG5ldyB1c2UuICBBbiBvYnZpb3VzDQo+Pj4gPj4gcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGVz ZSBzZWNvbmRhcnkgdHJhbnNtaXNzaW9ucyBkbyBub3QgaW50ZXJmZXJlDQo+Pj4gPj4gd2l0aCB0 aGUgcHJpbWFyeSB1c2Ugb2YgdGhlIHNwZWN0cnVtLiAgT25lIGFwcHJvYWNoIHRvIHVzaW5nIHRo ZQ0KPj4+ID4+IHdoaXRlIHNwYWNlIHNwZWN0cnVtIGF0IGEgZ2l2ZW4gdGltZSBhbmQgbG9jYXRp b24gaXMgdG8gdmVyaWZ5IHdpdGgNCj4+PmENCj4+PiA+PiBkYXRhYmFzZSBhdmFpbGFibGUgY2hh bm5lbHMuDQo+Pj4gPj4NCj4+PiA+PiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgY29uY2Vw dCBvZiBUViBXaGl0ZSBTcGFjZXMuICBJdCBhbHNvDQo+Pj4gPj4gZGVzY3JpYmVzIHRoZSBwcm9i bGVtcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGZvciBlbmFibGluZyB0aGUNCj4+PnVzZQ0K Pj4+ID4+IG9mIHRoZSBwcmltYXJ5IHVzZXIgb3duZWQgd2hpdGUgc3BhY2Ugc3BlY3RydW0gZm9y IHNlY29uZGFyeSB1c2VycywNCj4+PiA+PiB3aXRob3V0IGNhdXNpbmcgaW50ZXJmZXJlbmNlLCBi eSBxdWVyeWluZyBhIGRhdGFiYXNlIHdoaWNoIGtub3dzIHRoZQ0KPj4+ID4+IGNoYW5uZWwgYXZh aWxhYmlsaXR5IGF0IGFueSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZS4gIEEgbnVtYmVyIG9mDQo+ Pj4gPj4gcG9zc2libGUgdXNlIGNhc2VzIG9mIHRoaXMgc3BlY3RydW0gYW5kIGRlcml2ZWQgcmVx dWlyZW1lbnRzIGFyZQ0KPj4+YWxzbw0KPj4+ID4+IGRlc2NyaWJlZC4NCj4+PiA+Pg0KPj4+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPj4g cGF3cyBtYWlsaW5nIGxpc3QNCj4+PiA+PiBwYXdzQGlldGYub3JnDQo+Pj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+PiBwYXdzIG1haWxpbmcgbGlz dA0KPj4+ID4+IHBhd3NAaWV0Zi5vcmcNCj4+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCj4+PiA+DQo+Pj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+PiA+IHBh d3NAaWV0Zi5vcmcNCj4+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KPj4NCj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj5wYXdzIG1haWxpbmcgbGlzdA0KPj5wYXdzQGlldGYub3JnDQo+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5wYXdzIG1haWxpbmcgbGlzdA0KPj5w YXdzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3 cw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ cGF3cyBtYWlsaW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg== From scott.probasco@nokia.com Tue Sep 13 06:17: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 34B8D21F8AF3 for ; Tue, 13 Sep 2011 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-2.292, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 btr0vsCY8soJ for ; Tue, 13 Sep 2011 06:17:37 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80521F8ACC for ; Tue, 13 Sep 2011 06:17:35 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8DDJ4RM000755; Tue, 13 Sep 2011 16:19:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 16:18:31 +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, 13 Sep 2011 15:18:30 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 15:18:30 +0200 From: To: , Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3AgAB8ZQCAB4F8QIAAdVwA//+6w4A= Date: Tue, 13 Sep 2011 13:18:30 +0000 Message-ID: In-Reply-To: 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="gb2312" Content-ID: <2C61449377B79449810CDBA5B0D3DF29@nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 13:18:31.0543 (UTC) FILETIME=[A20C4870:01CC7217] X-Nokia-AV: Clean Cc: paws@ietf.org 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, 13 Sep 2011 13:17:41 -0000 SGksDQoNClBBV1MgaXMgaW5kZXBlbmRlbnQgb2YgYW55IHNwZWNpZmljIHNwZWN0cnVtLCBjb3Vu dHJ5LCBvciBwaHkvbWFjL2Fpcg0KaW50ZXJmYWNlLiBUaGlzIGlzIHN0YXRlZCBpbiB0aGUgY2hh cnRlci4NCg0KSSBhZ3JlZSB3aXRoIFBldGVyIHRoYXQgUEFXUyBjYW4gYWRkcmVzcyBpbmRvb3Ig YW5kIG91dGRvb3IgdXNlLg0KDQpGcm9tIExlaToNCj4NCj5UaHJlZSB0aGluZ3MgYXJlIHBhcnRp Y3VsYXIgZm9yIGluZG9vciBjb3ZlcmFnZSB1c2UgY2FzZSBpZiBkZXZlbG9wIFBBV1MNCj5wcm90 b2NvbC4gRmlyc3Qgb25lIGlzIHRoYXQgdGhlIGxvY2F0aW9uIGluIGEgYnVpbGRpbmcgaXMgZGlm ZmVyZW50IGZyb20NCj5HUFMgcG9zaXRpb25pbmcuIFNlY29uZCBvbmUgaXMgdGhhdCB0aGUgZGF0 YWJhc2Ugc2hvdWxkIGJlIGFibGUgdG8NCj5jYWxjdWxhdGUgdGhlIHByb3BlciBiYW5kIGZvciBp bmRvb3IgY292ZXJhZ2UuIFRoaXJkIG9uZSBpcyB0aGF0IGRhdGFiYXNlDQo+c2hvdWxkIGJlIGFi bGUgdG8gY29uc2lkZXIgKG9yIGNhbGN1bGF0ZSkgYW5kIGF2b2lkIHVuZXhwZWN0ZWQNCj5pbnRl cmZlcmVuY2UgYW1vbmcgZGlmZmVyZW50IGluZG9vciBBUHMgYW5kIG1pY3JvIGNlbGwgQlNzLg0K Pg0KDQpJdCBpcyBmYWlyIHRvIHNheSB0aGF0IGl0IG1heSBiZSBlYXNpZXIgZm9yIGFuICJvdXRk b29yIGRldmljZSIgdG8NCmRldGVybWluZSBpdHMgbG9jYXRpb24gdXNpbmcgR1BTIHRoYW4gYW4g ImluZG9vciBkZXZpY2UiLiBIb3dldmVyLCB0aGlzIGlzDQpub3QgaW4gdGhlIHNjb3BlIG9mIFBB V1MuIEEgbWFzdGVyIGRldmljZSBtdXN0IGhhdmUgYWNjZXNzIHRvIGl0cyBsb2NhdGlvbg0KaW4g b3JkZXIgdG8gdXNlIFBBV1MsIGJ1dCBob3cgdGhlIGRldmljZSAia25vd3MiIGl0cyBwb3NpdGlv biBkb2VzIG5vdA0KbWF0dGVyIGZvciBQQVdTLiBSZXF1aXJlbWVudHMgb24gdGhlIGRhdGFiYXNl ICgnZGF0YWJhc2Ugc2hvdWxkIGJlIGFibGUgdG8NCmNhbGN1bGF0ZS4uLicgJiAnZGF0YWJhc2Ug c2hvdWxkIGJlIGFibGUgdG8gY29uc2lkZXIuLi4nKSBhcmUgcmVndWxhdG9yeQ0KcmVxdWlyZW1l bnRzIChpbiBzY29wZSBmb3IgRkNDLCBPZmNvbSwgSW5kdXN0cnkgQ2FuYWRheSwgRmljb3JhLCBl dGMpIGJ1dA0KYXJlIGJleW9uZCBzY29wZSBvZiBQQVdTLg0KDQpJIHN1cHBvcnQgUEFXUyBmb3Ig bWFueSB1c2UgY2FzZXMsIGJvdGggaW5kb29yIGFuZCBvdXRkb29yLiBJIGFtDQppbnRlcmVzdGVk IHRvIGRpc2N1c3MgYW5kIGNvbnNpZGVyIHNwZWNpZmljIHVzZSBjYXNlcywgZGVzY3JpYmVkIGlu DQpkZXRhaWxzIHdoaWNoIGluY2x1ZGUgYWN0aW9ucyB0aGF0IGVhY2ggZWxlbWVudCAobWljcm9j ZWxsLCBBUCwgZGV2aWNlLA0KZGF0YWJhc2UsIGV0YykgbXVzdCBjb21wbGV0ZSBpbiBvcmRlciB0 byBkZXBsb3kgdGhlIHVzZSBjYXNlLiBXZWxsDQpkZXNjcmliZWQgdXNlIGNhc2VzIGFyZSBuZWVk ZWQgaW4gb3JkZXIgdG8gaWRlbnRpZnksIGp1c3RpZnkgYW5kIGFncmVlIHRoZQ0KcmVxdWlyZW1l bnRzIG9uIFBBV1MuDQoNClJlZ2FyZHMsDQpTY290dA0KDQoNCg0KT24gOS8xMy8xMSA3OjI2IEFN LCAiZXh0IFBldGVyIFN0YW5mb3J0aCIgPHBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbT4gd3JvdGU6 DQoNCj5SZWd1bGF0aW9uIG9mIFRWV1MgaXMgY3VycmVudGx5IHByb3Bvc2VkIGJ5IDMgUmVndWxh dG9ycywgVVMsIFVLIGFuZA0KPkNhbmFkYSwgd2l0aCB3b3JrIG9uZ29pbmcgaW4gU2luZ2Fwb3Jl LCBGaW5sYW5kIGFuZCBzZXZlcmFsIG90aGVyDQo+Y291bnRyaWVzLiBUaGVyZSBhcmUgc3VidGxl IGRpZmZlcmVuY2VzIGluIGFwcHJvYWNoIGFuZCByZXF1aXJlbWVudHMgYnV0DQo+dGhlIGJhc2lj IGNvbmNlcHQgaXMgdGhlIHNhbWUgaW4gYWxsIGNhc2VzLiBQQVdTIHNob3VsZCBiZSBhYmxlIHRv IGFkZHJlc3MNCj5hbGwgY2FzZXMuDQo+QWxsIHJlZ3VsYXRvcnMgYWxsb3cgZm9yIGluZG9vciB1 c2UgYXMgd2VsbCBhcyBvdXRkb29yIHVzZS4gUEFXUyBzaG91bGQNCj5hZGRyZXNzIGFsbCB0aGVz ZSBjYXNlcy4gQWxsIHJlZ3VsYXRvcnMgcHJvcG9zZSB0aGF0IGEgY29tcG9uZW50IG9mIHRoZQ0K PmRlY2lzaW9uIGJlIGJhc2VkIG9uIHRoZSAiZGV2aWNlIHR5cGUiIGFsbG93aW5nIGZvciBkaWZm ZXJlbnQgcmVzdWx0cw0KPmJhc2VkIG9uIHRoZSBjYXBhYmlsaXR5IGFuZCwgaW4gc29tZSByZWd1 bGF0aW9uLCB0aGUgbWF4aW11bSBwb3dlciBvdXRwdXQNCj5vZiB0aGUgZGV2aWNlLiBUaGVyZSBp cyBubyByZWFzb24gUEFXUyBjYW5ub3QgYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnRzIGZvcg0KPmlu ZG9vciB1c2UgYXMgd2VsbCBhcyBvdXRkb29yIHVzZS4gQXQgNDUwLTcwME1IeiB0aGUgaXNzdWUg b2YgY28tZXhpc3RlbmNlDQo+YmV0d2VlbiAyIGFwYXJ0bWVudHMgaXMgcmVhbGx5IG5vIGRpZmZl cmVudCB0aGFuIHRoZSBjby1leGlzdGVuY2UgYmV0d2Vlbg0KPjIgb3V0ZG9vciBhY2Nlc3MgcG9p bnRzIHNldmVyYWwgaHVuZHJlZCBtZXRlcnMgYXBhcnQuIFRoYXQgc2FpZCwgaXQgd2FzIG15DQo+ dW5kZXJzdGFuZGluZyB0aGF0IFBBV1Mgd2FzIGFsc28gZnJlcXVlbmN5IGFuZCBtb2R1bGF0aW9u IGluZGVwZW5kZW50LA0KPndoaWNoIGl0IHNob3VsZCBiZS4NCj5QZXRlciBTdGFuZm9ydGgNCj5T cGVjdHJ1bSBCcmlkZ2UgSW5jLg0KPg0KPk9uIFR1ZVNlcC8xMy8xMSBUdWUgU2VwIDEzLCAzOjA5 IEFNLCAiWmh1TGVpIiA8bGVpLnpodUBodWF3ZWkuY29tPiB3cm90ZToNCj4NCj4+SGkgU2NvdHQg YW5kIGFsbCwNCj4+DQo+PkZvciBzb21lIHJlYXNvbnMsIEkgdGhpbmsgdGhhdCBQQVdTIHByb3Rv Y29sIHdvdWxkIGJlIGRldmVsb3BlZCB3aXRoDQo+PnF1aXRlIHN0YWJsZSBzY2VuYXJpbyBkZXNj cmlwdGlvbnMgb2YgaW5kb29yIGNvdmVyYWdlLg0KPj4NCj4+QWNjb3JkaW5nIHRvIHByZXZpb3Vz IGUtbWFpbCBkaXNjdXNzaW9uIGluIHRoZSBsaXN0LCBpdCBzZWVtcyB0aGF0DQo+Pndvcmtpbmcg Z3JvdXAgd291bGQgZGV2ZWxvcCBnZW5lcmljIGFuZCBnbG9iYWxseSBhcHBsaWNhYmxlIHNwZWN0 cnVtDQo+PmRhdGFiYXNlIHF1ZXJ5IHByb3RvY29sIHdoaWNoIGhvcGVseSBpcyBhY2NlcHRlZCBi eSBvdGhlciByZWd1bGF0b3JzIGJ1dA0KPj5vbmx5IEZDQy4gNzAwTUh6LTgwME1IeiBjYW4gYmUg c2hhcmVkIHRvIHBhcnRpY3VsYXIgd2lyZWxlc3MgYWNjZXNzDQo+PnRlY2hub2xvZ2llcyBsaWtl IDgwMi4xMSwgODAyLjIyIGFuZCBldmVuIExURS4gUGxlYXNlIGNvcnJlY3QgbWUgaWYNCj4+c29t ZXRoaW5nIHdyb25nLg0KPj4NCj4+VGhlIGdlbmVyaWMgdXNlIGNhc2VzIGNvdWxkIGJlIHNhZmUg d2hlbiBkZWNpZGluZyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KPj5CdXQgaG90c3BvdCBhbmQgdXJi YW4gaW50ZXJuZXQgY29ubmVjdGlvbiBkZXNjcmlwdGlvbiBpcyBzdGlsbCBub3QNCj4+Y3JlZGl0 YWJsZSB0byBkZXZlbG9wIFBBV1MgcHJvdG9jb2wgZm9yIHRoZSByZWFzb24gNzAwTUh6IGhhcyBm YXINCj4+ZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNoYXJhY3RlcmlzdGljcyBmcm9tIHRoZSBuZWVk cyBvZiBpbmRvb3IgY292ZXJhZ2UNCj4+YW5kIHVyYmFuIGhvdHNwb3QgdXNlIGNhc2UuIEluIGdl bmVyYWwsIGluZG9vciB1c2UgY2FzZSBzYXlzIHRoYXQNCj4+ZGF0YWJhc2Ugc2hvdWxkIHRvIHJl c3BvbnNlIHByb3BlciBzcGVjdHJ1bSBpZiBBUHMgcmVxdWVzdCBjaGFubmVscyBmb3INCj4+aW5k b29yIEludGVybmV0IGNvbm5lY3Rpb24uIElmIGl0IGlzIG5vdCBwb3NzaWJsZSwgcmVndWxhdG9y cyBtdXN0IHRvDQo+PmZhY2UgcHJvYmxlbXMgb2YgaW50ZXJmZXJlbmNlIGFtb25nIEFQcyBhbmQg TWljcm8gY2VsbCBCU3MuIFRoZW4sIFBBV1MNCj4+bm93IGhhcyB0byByZWNvZ25pemUgc2NlbmFy aW8gZGVzY3JpcHRpb24gYW5kIHJlcXVpcmVtZW50cyBiZWZvcmUgZGV2ZWxvcA0KPj5wcm90b2Nv bCB0aGF0IG90aGVyIGhpZ2hlciBmcmVxdWVudCBiYW5kcyAoYXQgbGVhc3QgaGlnaGVyIHRoYW4g Mi4xR0h6KQ0KPj5zaG91bGQgYmUgY29uc2lkZXJlZCB0byBpbmRvb3IgY292ZXJhZ2UuIEkgd291 bGQgbGlrZSB0byByZW1pbmQgdGhhdCBpcw0KPj5kaWZmZXJlbnQgbmVlZCBmb3IgaW5kb29yIGNv dmVyYWdlIGZyb20gZ2VuZXJpYyBob3RzcG90IGFuZCB1cmJhbg0KPj5jb3ZlcmFnZSB3aGljaCBp cyBzdGlsbCB0byBiZSBkaXZpZGVkLg0KPj4NCj4+RnJvbSBwcm90b2NvbCBwZXJzcGVjdGl2ZSwg aXQgd2lsbCBkZXBlbmQgb24gdGhlIGNvbmNsdXNpb24gb2Ygd29ya2luZw0KPj5ncm91cCB3aGlj aCBJRXMgYXJlIHJlc2VydmVkIGZvciBpbmRvb3IgcXVlcnkgdXNhZ2VzLg0KPj4NCj4+VGhyZWUg dGhpbmdzIGFyZSBwYXJ0aWN1bGFyIGZvciBpbmRvb3IgY292ZXJhZ2UgdXNlIGNhc2UgaWYgZGV2 ZWxvcCBQQVdTDQo+PnByb3RvY29sLiBGaXJzdCBvbmUgaXMgdGhhdCB0aGUgbG9jYXRpb24gaW4g YSBidWlsZGluZyBpcyBkaWZmZXJlbnQgZnJvbQ0KPj5HUFMgcG9zaXRpb25pbmcuIFNlY29uZCBv bmUgaXMgdGhhdCB0aGUgZGF0YWJhc2Ugc2hvdWxkIGJlIGFibGUgdG8NCj4+Y2FsY3VsYXRlIHRo ZSBwcm9wZXIgYmFuZCBmb3IgaW5kb29yIGNvdmVyYWdlLiBUaGlyZCBvbmUgaXMgdGhhdCBkYXRh YmFzZQ0KPj5zaG91bGQgYmUgYWJsZSB0byBjb25zaWRlciAob3IgY2FsY3VsYXRlKSBhbmQgYXZv aWQgdW5leHBlY3RlZA0KPj5pbnRlcmZlcmVuY2UgYW1vbmcgZGlmZmVyZW50IGluZG9vciBBUHMg YW5kIG1pY3JvIGNlbGwgQlNzLg0KPj4NCj4+QmVzdCByZWdhcmRzLA0KPj5aaHUgTGVpDQo+Pg0K Pj4NCj4+LS0tLS3Tyrz+1K28/i0tLS0tDQo+PreivP7Iyzogc2NvdHQucHJvYmFzY29Abm9raWEu Y29tIFttYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEuY29tXQ0KPj63osvNyrG85DogMjAxMcTq OdTCOMjVIDIzOjQ5DQo+PsrVvP7IyzogWmh1TGVpDQo+PrOty806IHBhd3NAaWV0Zi5vcmcNCj4+ 1vfM4jogUmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYg cmVxdWlyZW1lbnRzDQo+Pg0KPj5IZWxsbyBMZWksDQo+Pg0KPj5JIGhhdmUgc3R1ZGllZCB0aGUg dGV4dCBiZWxvdywgYnV0IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHlvdQ0KPj5h cmUgcHJvcG9zaW5nLiBJdCBzZWVtcyB0byBtZSB0aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBhIGRl cGxveW1lbnQNCj4+c2NlbmFyaW8gKHdoaWNoIGlzIGZpbmUpLiBJIGRvIG5vdCB1bmRlcnN0YW5k IHdoYXQgaXMgdGhlIHVzZSBjYXNlLCBvcg0KPj5ob3cNCj4+dGhpcyBjYXNlIGlzIGRpZmZlcmVu dCBmcm9tICJIb3RzcG90IiB1c2UgY2FzZSAoQVAgaXMgaW5kb29yKSB3aXRoIGENCj4+IldpZGUt YXJlYSBvciBydXJhbCIgdXNlIGNhc2UgZGVwbG95ZWQgaW4gdGhlIHNhbWUgZ2VuZXJhbCBhcmVh DQo+PihtaWNyb2NlbGwNCj4+aXMgb3V0ZG9vcikuDQo+Pg0KPj5JIGFtIG5vdCBzcGVha2luZyBh Z2FpbnN0IHRoZSB1c2UgY2FzZSwgc2ltcGx5IHNheWluZyB0aGF0IEkgZG9uJ3QNCj4+dW5kZXJz dGFuZCBpdCB3ZWxsIGVub3VnaCB0byBjb21tZW50IG9uIGl0LiBJdCBtaWdodCBoZWxwIGZ1cnRo ZXINCj4+ZGlzY3Vzc2lvbiBpZiB5b3UgY2FuIGRlc2NyaWJlIGluIG1vcmUgZGV0YWlsIHRoZSB1 c2UgY2FzZSwgYW5kIGluY2x1ZGUNCj4+c3BlY2lmaWMgYWN0aW9ucyB0aGF0IGVhY2ggZWxlbWVu dCAobWljcm9jZWxsLCBBUCwgZGV2aWNlLCBkYXRhYmFzZSwgZXRjKQ0KPj5tdXN0IGNvbXBsZXRl IGluIG9yZGVyIHRvIGRlcGxveSB0aGlzIHVzZSBjYXNlLg0KPj4NCj4+UmVnYXJkcywNCj4+U2Nv dHQNCj4+DQo+Pg0KPj5PbiA5LzcvMTEgODozNSBQTSwgImV4dCBaaHVMZWkiIDxsZWkuemh1QGh1 YXdlaS5jb20+IHdyb3RlOg0KPj4NCj4+PkhpIGFsbCwNCj4+Pg0KPj4+SSB0aGluayB0aGF0IHdl IGRvIHNvbWUgd29ya3Mgb24gaW1wcm92aW5nIG9yaWdpbmFsIHVzZSBjYXNlIGRyYWZ0IGJ5DQo+ Pj5hZGRpbmcgdGhyZWUgYWRkaXRpb25hbCB1c2UgY2FzZXMsIGluY2x1ZGluZyBpbmRvb3IgY292 ZXJhZ2UsIGFkIGhvYw0KPj4+bmV0d29yayBhbmQgbHRlIG1ibXMgaXNzdWUuDQo+Pj4NCj4+Pk5v dywgSSBhbSBhc2tpbmcgdG8gYWRkIGluZG9vciBjb3ZlcmFnZSBzY2VuYXJpbyB3aGljaCBpcyBu ZWNlc3NhcnkgZm9yDQo+Pj5QQVdTIHByb3RvY29sIHRvIGNvbnNpZGVyIGluIG5leHQgc3RhZ2Uu IFRoZSBwcm9wb3NlZCB1c2UgY2FzZSBpcyBzZWVuDQo+Pj5iZWxvdy4gVGhlIHVwZGF0ZWQgdmVy c2lvbiBvZiB0aGlzIGRyYWZ0IGlzIHRvIGJlIHN1Ym1pdHRlZCBzb29uIGJ5DQo+Pj5hZGRpbmcg c29tZSB3b3JkaW5nIG1vZGlmaWNhdGlvbnMuIFNvLCBJIGRvbid0IHRoaW5rIHdlIGFyZSB0byBz a2lwIHRoZQ0KPj4+YWRkaXRpb25hbCB1c2UgY2FzZXMgZXZlbiB0aGUgcHJvYmxlbSBzdGF0ZW1l bnQsIHVzZSBjYXNlIGFuZA0KPj4+cmVxdWlyZW1lbnQNCj4+PnByb3Bvc2FsIGhhdmUgYmVlbiBp bnRlZ3JhdGVkIG5vdy4NCj4+Pg0KPj4+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo+Pj54LnguICBJbmRvb3IgdXNhZ2Ugb2YgVFZXUw0KPj4+ DQo+Pj4gICBBdCBwcmVzZW50LCB0aGUgaW5kb29yIHdpcmVsZXNzIGNvdmVyYWdlIGVxdWlwbWVu dHMgY29uc2lzdCBvZiBXaS1GaS0NCj4+PiAgIGxpa2UgYWNjZXNzIHBvaW50cyBhbmQgbWljcm8g Y2VsbHMsIGFsbCBvZiB0aGVzZSB1dGlsaXplIHNlZ21lbnRzIG9mDQo+Pj4gICBmcmVxdWVuY3ks IGZvcm1lciBhdCBhYm91dCAyLjRHSHogb3IgNUdoeiBhbmQgdGhlIGxhdHRlciwgZm9yDQo+Pj4g ICBleGFtcGxlLCA4MDIuMTFuIGF0IGFib3V0IDIuNEdIei4gIEFzIGEgcmVzdWx0IG9mIHRoZSBi bG9jayBvZg0KPj4+ICAgYnVpbGRpbmdzIGFuZCBvdGhlciBvYnN0cnVjdGlvbiBhbmQgaW50ZXJm ZXJlY2UsIGl0IG1heSBub3QgYmUgdGhhdA0KPj4+ICAgb3B0aW1pc3RpYyB3aGVuIDgwMi4xMSBk ZXZpY2VzIGV4YW1pbmUgdGhlIHN0YXR1cyBvZiB3aXJlbGVzcw0KPj4+DQo+Pj4NCj4+Pg0KPj4+ Wmh1ICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyLCAyMDEyICAgICAgICAg ICAgICAgIFtQYWdlIDNdDQo+Pj4NCj4+Pg0KPj4+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICBQQVdTIHVzZSBjYXNlcyAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExDQo+Pj4NCj4+Pg0K Pj4+ICAgaW50ZXJmZXJlcy4gIFRoaXMgdXNlIGNhc2UgdGFrZXMgdGhlIGJlbmVmaXQgb2YgVFYg V2hpdGUgU3BhY2UgdG8NCj4+PiAgIHByb3ZpZGUgYWRkaXRpb25hbCBjYXBhY2l0eSB0byBpbmRv b3IgY292ZXJhZ2UgYW5kIHJlZHVjZSBjaGFubmVsDQo+Pj4gICBpbnRlcmZlcmVjZS4NCj4+Pg0K Pj4+ICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlIGRlcGxveW1lbnQgb2YgdGhp cyBzY2VuYXJpby4NCj4+Pg0KPj4+ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KPj4+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgIGluZG9vciAgICAg ICAgICAgICAgfA0KPj4+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KPj4+ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KPj4+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPj4+ICAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgIHdoaXRlIHNwYWNlICAgICAgfCAg ICstLS0tLS0tLS0tLS0tKw0KPj4+ICAgICAgICAgICAgICAgfCAgICB8RGV2aWNlfCAtIC0gLSAt IC0gLSAtIC0gLSAtfC0gLXwgTWljcm8gY2VsbCAgfA0KPj4+ICAgICAgICAgICAgICAgfCAgICAr LS0tLS0tKyAgXCAgICAgICAgICAgICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KPj4+ICAgICAg ICAgICAgICAgfCAgICArLS0tLS0tKyAgIFx3aGl0ZSBzcGFjZSAgICAgfCAgICAgKC0tLS0tKQ0K Pj4+ICAgICAgICAgICAgICAgfCAgICB8RGV2aWNlfCAgICBcICstLS0tLS0tLS0tLS0rfCAgICAv ICAgICAgIFwNCj4+PiAgICAgICAgICAgICAgIHwgICAgKy0tLS0tLSsgICAgICB8YWNjZXNzIHBv aW50fHw9PT0oIEludGVybmV0KQ0KPj4+ICAgICAgICAgICAgICAgfCAgICAgICAgbyAgICAgICAv ICstLS0tLS0tLS0tLS0rfCAgICBcICAgICAgIC8NCj4+PiAgICAgICAgICAgICAgIHwgICAgICAg IG8gICAgICAvICAgICAgICAgICAgICAgIHwgICAgICgtLS0tLSkNCj4+PiAgICAgICAgICAgICAg IHwgICAgICAgIG8gICAgIC8gICAgICAgICAgICAgICAgIHwNCj4+PiAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+PiAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pg0KPj4+DQo+Pj4gICAgICAgICAgICAg ICAgICAgICAgIEdyYXBoIDEgSW5kb29yIHVzYWdlIG9mIFRWV1MNCj4+Pg0KPj4+ICAgVGhlIGFj Y2VzcyBwb2ludCBjb3VsZCBiZSBhIFdJLUZJIHJvdXRlciwgYW5kIHRoZSBtaWNybyBjZWxsIGlz IGENCj4+PiAgIHNob3J0IHJhbmdlIHdpcmVsZXNzIGNvdmVyYWdlKGUuZy4gaW4gcmFuZ2Ugb2Yg MC01MG0pIGJhc2Ugc3RhdGlvbiwNCj4+PiAgIGJvdGggb2YgdGhlbSBhY3QgYXMgbWFzdGVyIGRl dmljZXMsIHF1ZXJ5aW5nIHRoZSBpbnRlcm5ldCBjb25uZWN0ZWQNCj4+PiAgIGRhdGFiYXNlIGZv ciBhdmFpbGFibGUgd2hpdGUgc3BhY2Ugc3BlY3RydW0gYmFzZWQgb24gaXRzIGdlby0NCj4+PiAg IGxvY2F0aW9uLCBhbmQgcHJvdmlkaW5nIFRWV1MgYWNjZXNzIHRvIGluZG9vciB1c2VyLg0KPj4+ DQo+Pj4gICBUaGUgVFZXUyBzcGVjdHJ1bSBoYXMgZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNoYXJh Y3RlcmlzdGljcyBjb21wYXJlZA0KPj4+ICAgdG8gaGlnaGVyIGZyZXF1ZW5jeSBiYW5kLCBmb3Ig ZXhhbXBsZSwgdGhlIHRyYW5zbWlzc2lvbiBkaXN0YW5jZQ0KPj4+ICAgdXNpbmcgVFZXUyBjYW4g YmUgc2V2ZXJhbCB0aW1lcyBsb25nZXIgdGhhbiB0aG9zZSBpbiB0aGUgaGlnaGVyIGJhbmQuDQo+ Pj4gICBJbiB0aGlzIGNhc2UsIGdvb2QgcGVuZXRyYXRpb24gY2hhcmFjdGVyaXN0aWMgb2YgVFZX UyBtYWtlcyBpdA0KPj4+ICAgZGlmZmljdWx0IHRvIGxvY2sgdGhlIHNpZ25hbHMgaW4gdGhlIHJv b20sIHRoZW4gZGlmZmljdWx0IHRvIGxvY2FsaXplDQo+Pj4gICBhbmQgZGlmZmVyZW50aWF0ZSBz aWduYWxzLCBhbmQgZmluYWxseSBjYXVzZSBpbnRlcmZlcmVzIGFtb25nDQo+Pj4gICBuZWlnaGJv cmluZyBuZXR3b3Jrcy4gIFJlcXVpcmVtZW50cyB0byBpbmRvb3IgV1MgZGF0ZWJhc2UgdXNhZ2Ug d291bGQNCj4+PiAgIGJlOg0KPj4+DQo+Pj4NCj4+PiAgIDEuICBBIGZyZXF1ZW5jeSBwcm90ZWN0 aW9uIGdhcCBiZXR3ZWVuIG5laWdoYm9ycyhwYXJ0aWN1bGFyIHNwZWN0cnVtDQo+Pj4gICAgICAg YWxsb2NhdGlvbiBhbGdvcml0aG0gaXMgbmVlZGVkIGhlcmUpLg0KPj4+DQo+Pj4gICAyLiAgbG93 ZXIgb3V0cHV0IHBvd2VyIG9mIEFQL21pY3JvIGNlbGwsIGl0IHNlZW1zIHRoYXQgb25seSBjZXJ0 YWluDQo+Pj4gICAgICAgcGljbyBvciBmZW10byBjZWxscyBiZSBmZWFzaWJsZSBoZXJlLg0KPj4+ DQo+Pj4gICAzLiAgUEFXUyBtdXN0IG5vdCBiZSB0aWVkIHRvIGEgc3BlY2lmaWMgZnJlcXVlbmN5 IGJhbmQuDQo+Pj4NCj4+PiAgIDQuICBQQVdTIG11c3QgcmVzcG9uc2UgdGhlIHByb3BlciBmcmVx dWVuY3kgYmFuZCBsaXN0IHRvIHBhcnRpY3VsYXINCj4+PiAgICAgICBjb3ZlcmFnZSB3aGl0ZSBz cGFjZSBkZXZpY2VzLg0KPj4+DQo+Pj4gICA1LiAgTWFzdGVyIGRldmljZXMgc2hvdWxkIHN1cHBv cnQgcG93ZXIgY29udHJvbC4NCj4+Pg0KPj4+ICAgNi4gIFNsYXZlIGRldmljZXMgc2hvdWxkIHN1 cHBvcnQgcG93ZXIgY29udHJvbC4NCj4+Pg0KPj4+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4NCj4+PlpodSBMZWkNCj4+Pg0KPj4+DQo+ Pj4tLS0tLdPKvP7Urbz+LS0tLS0NCj4+PreivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEdlcmFsZA0KPj4+Q2hvdWluYXJkDQo+ Pj63osvNyrG85DogMjAxMcTqOdTCOMjVIDg6MDENCj4+PsrVvP7IyzogR2Fib3IuQmFqa29Abm9r aWEuY29tDQo+Pj6zrcvNOiBwYXdzQGlldGYub3JnDQo+Pj7W98ziOiBSZTogW3Bhd3NdIGNvbWJp bmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4+Pg0KPj4+ R2Fib3IsDQo+Pj4NCj4+PkNhbiBJIGFzayB0aGF0IHRoZSB0ZXh0IG1vZGlmaWNhdGlvbnMgdGhh dCBJIGhhdmUgc3VibWl0dGVkIHRvIHNjb3R0IGFuZA0KPj4+Y29waWVkIHRvIHRoZSBwYXdzIHJl ZmxlY3RvciBpbiBteSBlbWFpbCBkYXRlZCA4IEF1Z3VzdCBiZSBpbmNsdWRlZCBhcw0KPj4+d2Vs bD8NCj4+Pg0KPj4+VGhhbmsncywNCj4+Pg0KPj4+R2VyYWxkDQo+Pj4NCj4+Pg0KPj4+QXQgMjA6 MzIgMDctMDktMTEgKzAwMDAsIEdhYm9yLkJhamtvQG5va2lhLmNvbSB3cm90ZToNCj4+Pj5Paywg bGV0J3MgdHJ5IHRoYXQgdGhlbi4NCj4+Pj5TY290dCwgY2FuIHlvdSBwdXQgdXNlIGNhc2VzIGJl Zm9yZSBQUywgYW5kIGFkZCB0aGUgYWQtaG9jIHVzZSBjYXNlLiBJDQo+Pj4+anVzdCBzY2FubmVk IHRocm91Z2ggdGhlIGxpc3QgYW5kIHNwb3R0ZWQgdGhhdCBUZWNvIGluZGVlZCBwcm92aWRlZCBh DQo+Pj4+ZGVzY3JpcHRpb24gZm9yIHRoYXQgdXNlIGNhc2Ugb24gQXVnIDNyZC4NCj4+Pj5BbmQg c3VibWl0IHRoZSBkcmFmdCBhcyBhIHdnIGl0ZW0sIHVubGVzcyB0aGVyZSBhcmUgc3RpbGwgb2Jq ZWN0aW9ucy4NCj4+Pj4NCj4+Pj4tR2Fib3INCj4+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+PkZyb206IGV4dCBOYW5jeSBCcmF2aW4gW21haWx0bzpuYnJhdmluQGVhcnRo bGluay5uZXRdDQo+Pj4+U2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAwMywgMjAxMSAzOjQxIFBN DQo+Pj4+VG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNCj4+Pj5DYzog VGVjbyBCb290OyBHZXJhbGQgQ2hvdWluYXJkOyBwYXdzQGlldGYub3JnDQo+Pj4+U3ViamVjdDog UmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYNCj4+Pj5y ZXF1aXJlbWVudHMNCj4+Pj4NCj4+Pj5EZWFyIEdhYm9yIGFuZCBBbGwsDQo+Pj4+DQo+Pj4+SSB0 aGluayBpdCBpcyBhcHByb3ByaWF0ZSB0byBwdXQgdGhlIHVzZSBjYXNlcyBiZWZvcmUgdGhlIFBT IGZvcg0KPj4+Pm9idmlvdXMNCj4+Pj5yZWFzb25zLCBhbmQgaW5jbHVkaW5nIHRoZSAicHJveHki IG5lZWQgaW4gdGhlIGZpcnN0IGRyYWZ0LiBJIHN1cHBvcnQNCj4+Pj5pbmNsdWRpbmcgYm90aCBH ZXJhbGQncyBzdWdnZXN0aW9ucyBhbmQgVGVjbydzIHByb3Bvc2FsIGluIHRoZSBvcmlnaW5hbA0K Pj4+PmRyYWZ0IGFuZCBub3Qgd2FpdGluZyB1bnRpbCBhIGxhdGVyIHRpbWUuIEl0IGlzIHRoZSBw cm9wZXIgb3JkZXIsDQo+Pj4+aW5jbHVzaXZlIGFuZCBuZWVkZWQgaW4gdGhlIGluaXRpYWwgZHJh ZnQgaW4gbXkgb3Bpbmlvbi4gSSBiZWxpZXZlIHdpdGgNCj4+Pj50aGUgdGFsZW50IGluIHRoZSBn cm91cCBpdCB3aWxsIG5vdCB0YWtlIGxvbmcgdG8gYWNjb21wbGlzaCB0aGlzIGFuZA0KPj4+Pnlv dQ0KPj4+PndpbGwgaGF2ZSBhIG1vcmUgY29oZXNpdmUgZHJhZnQuDQo+Pj4+DQo+Pj4+U0luY2Vy ZWx5LCBOYW5jeQ0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIFNlcCAyLCAyMDExLCBhdCAyOjE5IFBNLCA8 R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj4+PjxHYWJvci5CYWprb0Bub2tpYS5jb20+IHdyb3Rl Og0KPj4+Pg0KPj4+PiA+IFRlY28sIEdlcmFsZCwNCj4+Pj4gPg0KPj4+PiA+IFRoYW5rcyBmb3Ig dGhlIGZlZWRiYWNrLiBJJ2Qgc3VnZ2VzdCB0aGF0IHdlIG1ha2UgdGhpcyBkcmFmdCBhIFdHDQo+ Pj4+aXRlbSwNCj4+Pj4gd2l0aCBHZXJhbGQncyBwcm9wb3NlZCBjaGFuZ2VzIGluIGl0LiBSZWdh cmRpbmcgdGhlIG9yZGVyIG9mIHRoZQ0KPj4+PnByb2JsZW0NCj4+Pj4gc3RhdGVtZW50IHZzIHVz ZSBjYXNlcywgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBsZWF2ZSBpdCBhcyBpdCBpcw0KPj4+ PihidXQNCj4+Pj4gd2UgY2FuIGFsd2F5cyBjaGFuZ2UgaXQsIGlmIHRoYXQgaXMgd2hhdCB0aGUg V0cgd2FudHMpLg0KPj4+PiA+DQo+Pj4+ID4gU28sIEknZCBhc2sgU2NvdHQgdG8gc3VibWl0IGEg V0cgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0LCB0aGVuIGhhdmUNCj4+Pj4gc29tZW9uZSBjb21lIHVw IHdpdGggdGV4dCBmb3IgdGhpcyBhZC1ob2MgbmV0d29yayBzY2VuYXJpbywgaGF2ZSB0aGUNCj4+ Pj5XRw0KPj4+PiBhZ3JlZSB3aXRoIHRoZSB0ZXh0IGFuZCBpbmNsdWRlIGl0IGluIG9uZSBvZiB0 aGUgc3Vic2VxdWVudCB2ZXJzaW9ucy4NCj4+Pj4gVGVjbywgd291bGQgeW91IHdyaXRlIHVwIHNv bWUgdGV4dCBmb3IgdGhpcyBhZC1ob2MgdXNlIGNhc2UgdGhlIFdHDQo+Pj4+Y291bGQNCj4+Pj4g ZGlzY3Vzcz8NCj4+Pj4gPg0KPj4+PiA+IFdlJ2xsIGFsc28gc2VuZCBhbiBpbml0aWFsIHZlcnNp b24gb2YgYSBsaXN0IG9mIHJlcXVpcmVtZW50cyB0byB0aGUNCj4+Pj4gbGlzdCBuZXh0IHdlZWsu DQo+Pj4+ID4NCj4+Pj4gPiAtIEdhYm9yDQo+Pj4+ID4NCj4+Pj4gPg0KPj4+PiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4gRnJvbTogZXh0IFRlY28gQm9vdCBbbWFpbHRvOnRl Y29AaW5mLW5ldC5ubF0NCj4+Pj4gPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAxLCAyMDEx IDExOjA2IFBNDQo+Pj4+ID4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxl eSkNCj4+Pj4gPiBDYzogcGF3c0BpZXRmLm9yZw0KPj4+PiA+IFN1YmplY3Q6IFJlOiBbcGF3c10g Y29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+Pj4+ID4gcmVxdWlyZW1l bnRzDQo+Pj4+ID4NCj4+Pj4gPiBJIHRoaW5rIHRoZSBkb2MgaXMgYSBnb29kIHN0YXJ0aW5nIHBv aW50LiBJIHN1cHBvcnQgYWRvcHRpb24uDQo+Pj4+ID4NCj4+Pj4gPiBJIHN1Z2dlc3QgcmVvcmRl cmluZzogc3BlY2lmeWluZyBwcm9ibGVtIHN0YXRlbWVudCBhZnRlciBpbnRyb2R1Y2luZw0KPj4+ PiB0aGUgdXNlIGNhc2VzLg0KPj4+PiA+DQo+Pj4+ID4gU29tZSBhc2tlZCBmb3IgdGhlIGFkIGhv YyBuZXR3b3JrIHNjZW5hcmlvLiBUaGlzIGluY2x1ZGVzIG1lIDotKS4NCj4+Pj5UaGlzDQo+Pj4+ IGlzIGltcG9ydGFudCwgYmVjYXVzZSBpdCBkZW1vbnN0cmF0ZXMgdGhlIG5lZWQgZm9yICJwcm94 eSIuDQo+Pj4+ID4gQlRXLCBJIHdvbmRlciB3aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0IHBv cCB1cCBmcm9tIFdpRmkNCj4+Pj4gZGVwbG95bWVudHMuIFVzYWdlIG9mIGNvbnRyb2xsZXJzIGlu IGxhcmdlIHNpdGVzIGlzIG5vdCB1bmNvbW1vbi4gTm90DQo+Pj4+dG8NCj4+Pj4gbWVudGlvbiAx MXMuDQo+Pj4+ID4NCj4+Pj4gPiBUaGUgcmVxdWlyZW1lbnRzIGlzIGxlZnQgb3Blbi4gSSdtIGxv b2tpbmcgZm9yd2FyZCBzZWUgc29tZSBkcmFmdA0KPj4+PnRleHQuDQo+Pj4+ID4NCj4+Pj4gPiBU aGFua3MsIFRlY28NCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID4gT3AgMzAgYXVnIDIwMTEsIG9tIDE5 OjQyIGhlZWZ0IDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+Pj4+IDxHYWJvci5CYWprb0Bub2tp YS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPj4+PiA+DQo+Pj4+ID4+IEkgc2VudCB0 aGlzIGVtYWlsIHRvIHRoZSBsaXN0IG9uZSB3ZWVrIGFnbywgYXNraW5nIGZvciBmZWVkYmFjayBv bg0KPj4+PiA+Pg0KPj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3 cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4+PiA+PiBzIC0wMC50eHQgYnV0IHRoZXJl IHdhcyBub3Qgb25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJIHRha2UgdGhhdCBhcw0KPj4+PiA+PiBw ZW9wbGUgaGF2ZSBubyBjb21tZW50cyB0byB0aGUgZHJhZnQgYXQgdGhpcyB0aW1lLg0KPj4+PiA+ Pg0KPj4+PiA+PiBBbmQgSSBhbSBhc2tpbmcgYWdhaW46IGlzIHRoZXJlIGFueSBvYmplY3Rpb24g aW4gYWRvcHRpbmcgdGhlIGFib3ZlDQo+Pj4+IGRyYWZ0IGFzIGEgd2cgZG9jdW1lbnQ/DQo+Pj4+ ID4+DQo+Pj4+ID4+IC1HYWJvcg0KPj4+PiA+Pg0KPj4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+PiA+PiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+QmVoYWxmDQo+Pj4+ID4+IE9mIGV4dCBHYWJvci5C YWprb0Bub2tpYS5jb20NCj4+Pj4gPj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEgMjo0 MyBQTQ0KPj4+PiA+PiBUbzogcGF3c0BpZXRmLm9yZw0KPj4+PiA+PiBTdWJqZWN0OiBSZTogW3Bh d3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJg0KPj4+PiA+PiByZXF1 aXJlbWVudHMNCj4+Pj4gPj4NCj4+Pj4gPj4gRHVyaW5nIHRoZSBRdWViZWMgc2Vzc2lvbiwgd2Ug aGFkIHByZXNlbnRhdGlvbnMgb2YgdGhlIFBTIGFuZCB0aGUNCj4+Pj51c2UNCj4+Pj4gY2FzZXMg ZHJhZnRzLiBUaGUgd2cgdGhlbiBkZWNpZGVkIGl0IHdhbnRzIHRvIHNlZSB0aGVzZSBkcmFmdHMg bWVyZ2VkDQo+Pj4+IGludG8gb25lLiBTY290dCBqdXN0IGRpZCB0aGF0IGFuZCBwb3N0ZWQgdGhl IG1lcmdlZCBkcmFmdDoNCj4+Pj4gPj4NCj4+Pj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LXByb2Jhc2NvLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXQNCj4+Pj4gPj4gcw0KPj4+ PiA+PiAtMDAudHh0DQo+Pj4+ID4+DQo+Pj4+ID4+IE5vdyBJIHdvdWxkIGxpa2UgdG8gYXNrIGlm IHRoZSB3ZyBmZWVscyBsaWtlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkNCj4+Pj50bw0KPj4+PiBi ZSBhZG9wdGVkIGFzIGEgd2cgZG9jdW1lbnQuIFBsZWFzZSBzZW5kIHlvdXIgZmVlZGJhY2sgYW5k IGh1bSB0byB0aGUNCj4+Pj4gbGlzdCBieSB0aGlzIHRpbWUgbmV4dCB3ZWVrLg0KPj4+PiA+Pg0K Pj4+PiA+PiAtR2Fib3INCj4+Pj4gPj4NCj4+Pj4gPj4NCj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4g Pj4gLQ0KPj4+PiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gPj4g RnJvbTogUHJvYmFzY28gU2NvdHQNCj4+Pj4gPj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIw MTEgOToxOCBBTQ0KPj4+PiA+PiBUbzogcGF3c0BpZXRmLm9yZw0KPj4+PiA+PiBTdWJqZWN0OiBj b21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWlyZW1lbnRzDQo+Pj4+ ID4+DQo+Pj4+ID4+IEhpLA0KPj4+PiA+Pg0KPj4+PiA+PiBBY2NvcmRpbmcgdG8gdGhlIHJlc3Vs dHMgb2YgdGhlIGZhY2UtdG8tZmFjZSBtZWV0aW5nLCB3ZSBoYXZlDQo+Pj4+Y29tYmluZWQNCj4+ Pj4gdGhlIHByb2JsZW0gc3RhdGVtZW50IEktRCBhbmQgdXNlIGNhc2UgJiByZXF1aXJlbWVudCBJ LUQgaW50byBhIHNpbmdsZQ0KPj4+PiBJLUQuICBZb3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21lZC4N Cj4+Pj4gPj4NCj4+Pj4gPj4gUmVnYXJkcywNCj4+Pj4gPj4gU2NvdHQNCj4+Pj4gPj4NCj4+Pj4g Pj4gVVJMOg0KPj4+PiA+Pg0KPj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFz Y28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4+PiA+PiBzDQo+Pj4+ID4+IC0w MC50eHQNCj4+Pj4gPj4NCj4+Pj4gPj4NCj4+Pj4gPj4gQWJzdHJhY3Q6DQo+Pj4+ID4+IFBvcnRp b25zIG9mIHRoZSByYWRpbyBzcGVjdHJ1bSB0aGF0IGFyZSBhbGxvY2F0ZWQgdG8gYSBsaWNlbnNl ZCwNCj4+Pj4gPj4gcHJpbWFyeSB1c2VyIGJ1dCBhcmUgdW51c2VkIG9yIHVub2NjdXBpZWQgYXQg c3BlY2lmaWMgbG9jYXRpb25zIGFuZA0KPj4+PiA+PiB0aW1lcyBhcmUgZGVmaW5lZCBhcyAnd2hp dGUgc3BhY2UnLiAgVGhlIGNvbmNlcHQgb2YgYWxsb3dpbmcNCj4+Pj4gPj4gc2Vjb25kYXJ5IHRy YW5zbWlzc2lvbnMgKGxpY2Vuc2VkIG9yIHVubGljZW5zZWQpIGluIHdoaXRlIHNwYWNlIGlzDQo+ Pj4+YQ0KPj4+PiA+PiB0ZWNobmlxdWUgdG8gJ3VubG9jaycgZXhpc3Rpbmcgc3BlY3RydW0gZm9y IG5ldyB1c2UuICBBbiBvYnZpb3VzDQo+Pj4+ID4+IHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlc2Ug c2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgZG8gbm90IGludGVyZmVyZQ0KPj4+PiA+PiB3aXRoIHRo ZSBwcmltYXJ5IHVzZSBvZiB0aGUgc3BlY3RydW0uICBPbmUgYXBwcm9hY2ggdG8gdXNpbmcgdGhl DQo+Pj4+ID4+IHdoaXRlIHNwYWNlIHNwZWN0cnVtIGF0IGEgZ2l2ZW4gdGltZSBhbmQgbG9jYXRp b24gaXMgdG8gdmVyaWZ5IHdpdGgNCj4+Pj5hDQo+Pj4+ID4+IGRhdGFiYXNlIGF2YWlsYWJsZSBj aGFubmVscy4NCj4+Pj4gPj4NCj4+Pj4gPj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGNv bmNlcHQgb2YgVFYgV2hpdGUgU3BhY2VzLiAgSXQgYWxzbw0KPj4+PiA+PiBkZXNjcmliZXMgdGhl IHByb2JsZW1zIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgZm9yIGVuYWJsaW5nIHRoZQ0KPj4+ PnVzZQ0KPj4+PiA+PiBvZiB0aGUgcHJpbWFyeSB1c2VyIG93bmVkIHdoaXRlIHNwYWNlIHNwZWN0 cnVtIGZvciBzZWNvbmRhcnkgdXNlcnMsDQo+Pj4+ID4+IHdpdGhvdXQgY2F1c2luZyBpbnRlcmZl cmVuY2UsIGJ5IHF1ZXJ5aW5nIGEgZGF0YWJhc2Ugd2hpY2gga25vd3MNCj4+Pj50aGUNCj4+Pj4g Pj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgYXQgYW55IGdpdmVuIGxvY2F0aW9uIGFuZCB0aW1lLiAg QSBudW1iZXIgb2YNCj4+Pj4gPj4gcG9zc2libGUgdXNlIGNhc2VzIG9mIHRoaXMgc3BlY3RydW0g YW5kIGRlcml2ZWQgcmVxdWlyZW1lbnRzIGFyZQ0KPj4+PmFsc28NCj4+Pj4gPj4gZGVzY3JpYmVk Lg0KPj4+PiA+Pg0KPj4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiA+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+PiA+PiBwYXdzQGlldGYu b3JnDQo+Pj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K Pj4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiA+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+PiA+PiBwYXdzQGlldGYub3JnDQo+Pj4+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+PiA+DQo+Pj4+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4g PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+PiA+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pg0KPj4+DQo+Pj4NCj4+Pl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5wYXdzIG1h aWxpbmcgbGlzdA0KPj4+cGF3c0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzDQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+cGF3cyBtYWlsaW5nIGxpc3QNCj4+PnBhd3NAaWV0Zi5vcmcNCj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4NCj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+cGF3cyBtYWlsaW5n IGxpc3QNCj4+cGF3c0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Bhd3MNCj4NCg0K From brian.rosen@neustar.biz Tue Sep 13 06:25:05 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 82F3E21F873A for ; Tue, 13 Sep 2011 06:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.153 X-Spam-Level: X-Spam-Status: No, score=-4.153 tagged_above=-999 required=5 tests=[AWL=-2.096, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 YqNbVL53tO8Z for ; Tue, 13 Sep 2011 06:25:01 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8676121F85F7 for ; Tue, 13 Sep 2011 06:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1315920408; x=1631198311; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=yl2LWV0GOhUqFsGABS4B/ zGEGPCz3Is3GPpllLo2r4o=; b=lL8HCNUNUy3+SMu4fbx7g0N9sENOvhB26GQCV TkL2YOEEJJyDO7l1oVNwZLl4j4nh3C/wWhTb0xf3lDCuGdCVw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49519195; Tue, 13 Sep 2011 09:26:47 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 13 Sep 2011 09:26:46 -0400 From: "Rosen, Brian" To: Peter Stanforth Date: Tue, 13 Sep 2011 09:26:45 -0400 Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: AcxyGMhjJdhIp7vRR02xWCEyQWiTEQ== Message-ID: <35D7EFC3-8EBD-428A-B579-8C4D783ED7BB@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: dwI9oZaj9K9fmG3bous2wQ== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "paws@ietf.org" 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, 13 Sep 2011 13:25:05 -0000 T3VyIGNoYXJ0ZXIgc2F5cyB0aGF0IHdlIHdpbGwgZGV2ZWxvcCBhIHByb3RvY29sIHdoaWNoIGlz IHNwZWN0cnVtIGluZGVwZW5kZW50IChkaWZmZXJlbnQgYmFuZHMpLCBwaGkgaW5kZXBlbmRlbnQg KGRpZmZlcmVudCB0eXBlcyBvZiBkZXZpY2VzIHVzaW5nIGRpZmZlcmVudCBvdmVyIHRoZSBhaXIg aW50ZXJmYWNlcykgYW5kIG5hdGlvbiBpbmRlcGVuZGVudC4NCg0KVGhhdCBtZWFucywgYXMgUGV0 ZXIgc2F5cywgaW5kb29yIGFuZCBvdXRkb29yIHVzZSB3b3VsZCBiZSBjb3ZlcmVkLg0KDQpJIGRv IHRoaW5rIHRoZSBxdWVyeSB3aWxsIGhhdmUgc29tZSBraW5kIG9mICJ0eXBlIiB3aGljaCBpcyB0 aGUgcGh5IGluZGVwZW5kZW5jZSwgYnV0IGFsc28gdGFrZXMgaW50byBhY2NvdW50IHRoZSByZWd1 bGF0b3JzIHJ1bGVzIG9uIHBvd2VyLCBhbnRlbm5hIGFuZCBvdGhlciBwYXJhbWV0ZXJzLg0KVGhl IFVTIHJ1bGVzIHdvcmsgdGhhdCB3YXksIGFuZCBJIGV4cGVjdCBtYW55IG90aGVyIG5hdGlvbnMg d2lsbCBoYXZlIHNpbWlsYXIga2luZHMgb2YgcnVsZXMuICBZb3UgY2FuIGltYWdpbmUgcnVsZXMg d2hlcmUgbW9yZSBhbnRlbm5hIGluZm9ybWF0aW9uIGlzIG5lZWRlZCBpbiB0aGUgcXVlcnkgdG8g ZGV0ZXJtaW5lIHdoYXQgc3BlY3RydW0gaXMgYXZhaWxhYmxlLCBidXQgc28gZmFyLCB0aGVyZSBh cmUgbWVyZWx5IGxpbWl0cyBmb3IgZWFjaCB0eXBlLg0KDQpCcmlhbg0KDQpPbiBTZXAgMTMsIDIw MTEsIGF0IDg6MjYgQU0sIFBldGVyIFN0YW5mb3J0aCB3cm90ZToNCg0KPiBSZWd1bGF0aW9uIG9m IFRWV1MgaXMgY3VycmVudGx5IHByb3Bvc2VkIGJ5IDMgUmVndWxhdG9ycywgVVMsIFVLIGFuZA0K PiBDYW5hZGEsIHdpdGggd29yayBvbmdvaW5nIGluIFNpbmdhcG9yZSwgRmlubGFuZCBhbmQgc2V2 ZXJhbCBvdGhlcg0KPiBjb3VudHJpZXMuIFRoZXJlIGFyZSBzdWJ0bGUgZGlmZmVyZW5jZXMgaW4g YXBwcm9hY2ggYW5kIHJlcXVpcmVtZW50cyBidXQNCj4gdGhlIGJhc2ljIGNvbmNlcHQgaXMgdGhl IHNhbWUgaW4gYWxsIGNhc2VzLiBQQVdTIHNob3VsZCBiZSBhYmxlIHRvIGFkZHJlc3MNCj4gYWxs IGNhc2VzLg0KPiBBbGwgcmVndWxhdG9ycyBhbGxvdyBmb3IgaW5kb29yIHVzZSBhcyB3ZWxsIGFz IG91dGRvb3IgdXNlLiBQQVdTIHNob3VsZA0KPiBhZGRyZXNzIGFsbCB0aGVzZSBjYXNlcy4gQWxs IHJlZ3VsYXRvcnMgcHJvcG9zZSB0aGF0IGEgY29tcG9uZW50IG9mIHRoZQ0KPiBkZWNpc2lvbiBi ZSBiYXNlZCBvbiB0aGUgImRldmljZSB0eXBlIiBhbGxvd2luZyBmb3IgZGlmZmVyZW50IHJlc3Vs dHMNCj4gYmFzZWQgb24gdGhlIGNhcGFiaWxpdHkgYW5kLCBpbiBzb21lIHJlZ3VsYXRpb24sIHRo ZSBtYXhpbXVtIHBvd2VyIG91dHB1dA0KPiBvZiB0aGUgZGV2aWNlLiBUaGVyZSBpcyBubyByZWFz b24gUEFXUyBjYW5ub3QgYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnRzIGZvcg0KPiBpbmRvb3IgdXNl IGFzIHdlbGwgYXMgb3V0ZG9vciB1c2UuIEF0IDQ1MC03MDBNSHogdGhlIGlzc3VlIG9mIGNvLWV4 aXN0ZW5jZQ0KPiBiZXR3ZWVuIDIgYXBhcnRtZW50cyBpcyByZWFsbHkgbm8gZGlmZmVyZW50IHRo YW4gdGhlIGNvLWV4aXN0ZW5jZSBiZXR3ZWVuDQo+IDIgb3V0ZG9vciBhY2Nlc3MgcG9pbnRzIHNl dmVyYWwgaHVuZHJlZCBtZXRlcnMgYXBhcnQuIFRoYXQgc2FpZCwgaXQgd2FzIG15DQo+IHVuZGVy c3RhbmRpbmcgdGhhdCBQQVdTIHdhcyBhbHNvIGZyZXF1ZW5jeSBhbmQgbW9kdWxhdGlvbiBpbmRl cGVuZGVudCwNCj4gd2hpY2ggaXQgc2hvdWxkIGJlLg0KPiBQZXRlciBTdGFuZm9ydGgNCj4gU3Bl Y3RydW0gQnJpZGdlIEluYy4NCj4NCj4gT24gVHVlU2VwLzEzLzExIFR1ZSBTZXAgMTMsIDM6MDkg QU0sICJaaHVMZWkiIDxsZWkuemh1QGh1YXdlaS5jb20+IHdyb3RlOg0KPg0KPj4gSGkgU2NvdHQg YW5kIGFsbCwNCj4+DQo+PiBGb3Igc29tZSByZWFzb25zLCBJIHRoaW5rIHRoYXQgUEFXUyBwcm90 b2NvbCB3b3VsZCBiZSBkZXZlbG9wZWQgd2l0aA0KPj4gcXVpdGUgc3RhYmxlIHNjZW5hcmlvIGRl c2NyaXB0aW9ucyBvZiBpbmRvb3IgY292ZXJhZ2UuDQo+Pg0KPj4gQWNjb3JkaW5nIHRvIHByZXZp b3VzIGUtbWFpbCBkaXNjdXNzaW9uIGluIHRoZSBsaXN0LCBpdCBzZWVtcyB0aGF0DQo+PiB3b3Jr aW5nIGdyb3VwIHdvdWxkIGRldmVsb3AgZ2VuZXJpYyBhbmQgZ2xvYmFsbHkgYXBwbGljYWJsZSBz cGVjdHJ1bQ0KPj4gZGF0YWJhc2UgcXVlcnkgcHJvdG9jb2wgd2hpY2ggaG9wZWx5IGlzIGFjY2Vw dGVkIGJ5IG90aGVyIHJlZ3VsYXRvcnMgYnV0DQo+PiBvbmx5IEZDQy4gNzAwTUh6LTgwME1IeiBj YW4gYmUgc2hhcmVkIHRvIHBhcnRpY3VsYXIgd2lyZWxlc3MgYWNjZXNzDQo+PiB0ZWNobm9sb2dp ZXMgbGlrZSA4MDIuMTEsIDgwMi4yMiBhbmQgZXZlbiBMVEUuIFBsZWFzZSBjb3JyZWN0IG1lIGlm DQo+PiBzb21ldGhpbmcgd3JvbmcuDQo+Pg0KPj4gVGhlIGdlbmVyaWMgdXNlIGNhc2VzIGNvdWxk IGJlIHNhZmUgd2hlbiBkZWNpZGluZyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KPj4gQnV0IGhvdHNw b3QgYW5kIHVyYmFuIGludGVybmV0IGNvbm5lY3Rpb24gZGVzY3JpcHRpb24gaXMgc3RpbGwgbm90 DQo+PiBjcmVkaXRhYmxlIHRvIGRldmVsb3AgUEFXUyBwcm90b2NvbCBmb3IgdGhlIHJlYXNvbiA3 MDBNSHogaGFzIGZhcg0KPj4gZGlmZmVyZW50IHByb3BhZ2F0aW9uIGNoYXJhY3RlcmlzdGljcyBm cm9tIHRoZSBuZWVkcyBvZiBpbmRvb3IgY292ZXJhZ2UNCj4+IGFuZCB1cmJhbiBob3RzcG90IHVz ZSBjYXNlLiBJbiBnZW5lcmFsLCBpbmRvb3IgdXNlIGNhc2Ugc2F5cyB0aGF0DQo+PiBkYXRhYmFz ZSBzaG91bGQgdG8gcmVzcG9uc2UgcHJvcGVyIHNwZWN0cnVtIGlmIEFQcyByZXF1ZXN0IGNoYW5u ZWxzIGZvcg0KPj4gaW5kb29yIEludGVybmV0IGNvbm5lY3Rpb24uIElmIGl0IGlzIG5vdCBwb3Nz aWJsZSwgcmVndWxhdG9ycyBtdXN0IHRvDQo+PiBmYWNlIHByb2JsZW1zIG9mIGludGVyZmVyZW5j ZSBhbW9uZyBBUHMgYW5kIE1pY3JvIGNlbGwgQlNzLiBUaGVuLCBQQVdTDQo+PiBub3cgaGFzIHRv IHJlY29nbml6ZSBzY2VuYXJpbyBkZXNjcmlwdGlvbiBhbmQgcmVxdWlyZW1lbnRzIGJlZm9yZSBk ZXZlbG9wDQo+PiBwcm90b2NvbCB0aGF0IG90aGVyIGhpZ2hlciBmcmVxdWVudCBiYW5kcyAoYXQg bGVhc3QgaGlnaGVyIHRoYW4gMi4xR0h6KQ0KPj4gc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gaW5k b29yIGNvdmVyYWdlLiBJIHdvdWxkIGxpa2UgdG8gcmVtaW5kIHRoYXQgaXMNCj4+IGRpZmZlcmVu dCBuZWVkIGZvciBpbmRvb3IgY292ZXJhZ2UgZnJvbSBnZW5lcmljIGhvdHNwb3QgYW5kIHVyYmFu DQo+PiBjb3ZlcmFnZSB3aGljaCBpcyBzdGlsbCB0byBiZSBkaXZpZGVkLg0KPj4NCj4+IEZyb20g cHJvdG9jb2wgcGVyc3BlY3RpdmUsIGl0IHdpbGwgZGVwZW5kIG9uIHRoZSBjb25jbHVzaW9uIG9m IHdvcmtpbmcNCj4+IGdyb3VwIHdoaWNoIElFcyBhcmUgcmVzZXJ2ZWQgZm9yIGluZG9vciBxdWVy eSB1c2FnZXMuDQo+Pg0KPj4gVGhyZWUgdGhpbmdzIGFyZSBwYXJ0aWN1bGFyIGZvciBpbmRvb3Ig Y292ZXJhZ2UgdXNlIGNhc2UgaWYgZGV2ZWxvcCBQQVdTDQo+PiBwcm90b2NvbC4gRmlyc3Qgb25l IGlzIHRoYXQgdGhlIGxvY2F0aW9uIGluIGEgYnVpbGRpbmcgaXMgZGlmZmVyZW50IGZyb20NCj4+ IEdQUyBwb3NpdGlvbmluZy4gU2Vjb25kIG9uZSBpcyB0aGF0IHRoZSBkYXRhYmFzZSBzaG91bGQg YmUgYWJsZSB0bw0KPj4gY2FsY3VsYXRlIHRoZSBwcm9wZXIgYmFuZCBmb3IgaW5kb29yIGNvdmVy YWdlLiBUaGlyZCBvbmUgaXMgdGhhdCBkYXRhYmFzZQ0KPj4gc2hvdWxkIGJlIGFibGUgdG8gY29u c2lkZXIgKG9yIGNhbGN1bGF0ZSkgYW5kIGF2b2lkIHVuZXhwZWN0ZWQNCj4+IGludGVyZmVyZW5j ZSBhbW9uZyBkaWZmZXJlbnQgaW5kb29yIEFQcyBhbmQgbWljcm8gY2VsbCBCU3MuDQo+Pg0KPj4g QmVzdCByZWdhcmRzLA0KPj4gWmh1IExlaQ0KPj4NCj4+DQo+PiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4+ILeivP7Iyzogc2NvdHQucHJvYmFzY29Abm9raWEuY29tIFttYWlsdG86c2NvdHQucHJvYmFz Y29Abm9raWEuY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTHE6jnUwjjI1SAyMzo0OQ0KPj4gytW8/sjL OiBaaHVMZWkNCj4+ILOty806IHBhd3NAaWV0Zi5vcmcNCj4+INb3zOI6IFJlOiBbcGF3c10gY29t YmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cw0KPj4NCj4+ IEhlbGxvIExlaSwNCj4+DQo+PiBJIGhhdmUgc3R1ZGllZCB0aGUgdGV4dCBiZWxvdywgYnV0IEkg ZG8gbm90IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHlvdQ0KPj4gYXJlIHByb3Bvc2luZy4gSXQg c2VlbXMgdG8gbWUgdGhhdCB5b3UgYXJlIGRlc2NyaWJpbmcgYSBkZXBsb3ltZW50DQo+PiBzY2Vu YXJpbyAod2hpY2ggaXMgZmluZSkuIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCBpcyB0aGUgdXNl IGNhc2UsIG9yIGhvdw0KPj4gdGhpcyBjYXNlIGlzIGRpZmZlcmVudCBmcm9tICJIb3RzcG90IiB1 c2UgY2FzZSAoQVAgaXMgaW5kb29yKSB3aXRoIGENCj4+ICJXaWRlLWFyZWEgb3IgcnVyYWwiIHVz ZSBjYXNlIGRlcGxveWVkIGluIHRoZSBzYW1lIGdlbmVyYWwgYXJlYSAobWljcm9jZWxsDQo+PiBp cyBvdXRkb29yKS4NCj4+DQo+PiBJIGFtIG5vdCBzcGVha2luZyBhZ2FpbnN0IHRoZSB1c2UgY2Fz ZSwgc2ltcGx5IHNheWluZyB0aGF0IEkgZG9uJ3QNCj4+IHVuZGVyc3RhbmQgaXQgd2VsbCBlbm91 Z2ggdG8gY29tbWVudCBvbiBpdC4gSXQgbWlnaHQgaGVscCBmdXJ0aGVyDQo+PiBkaXNjdXNzaW9u IGlmIHlvdSBjYW4gZGVzY3JpYmUgaW4gbW9yZSBkZXRhaWwgdGhlIHVzZSBjYXNlLCBhbmQgaW5j bHVkZQ0KPj4gc3BlY2lmaWMgYWN0aW9ucyB0aGF0IGVhY2ggZWxlbWVudCAobWljcm9jZWxsLCBB UCwgZGV2aWNlLCBkYXRhYmFzZSwgZXRjKQ0KPj4gbXVzdCBjb21wbGV0ZSBpbiBvcmRlciB0byBk ZXBsb3kgdGhpcyB1c2UgY2FzZS4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gU2NvdHQNCj4+DQo+Pg0K Pj4gT24gOS83LzExIDg6MzUgUE0sICJleHQgWmh1TGVpIiA8bGVpLnpodUBodWF3ZWkuY29tPiB3 cm90ZToNCj4+DQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4gSSB0aGluayB0aGF0IHdlIGRvIHNvbWUg d29ya3Mgb24gaW1wcm92aW5nIG9yaWdpbmFsIHVzZSBjYXNlIGRyYWZ0IGJ5DQo+Pj4gYWRkaW5n IHRocmVlIGFkZGl0aW9uYWwgdXNlIGNhc2VzLCBpbmNsdWRpbmcgaW5kb29yIGNvdmVyYWdlLCBh ZCBob2MNCj4+PiBuZXR3b3JrIGFuZCBsdGUgbWJtcyBpc3N1ZS4NCj4+Pg0KPj4+IE5vdywgSSBh bSBhc2tpbmcgdG8gYWRkIGluZG9vciBjb3ZlcmFnZSBzY2VuYXJpbyB3aGljaCBpcyBuZWNlc3Nh cnkgZm9yDQo+Pj4gUEFXUyBwcm90b2NvbCB0byBjb25zaWRlciBpbiBuZXh0IHN0YWdlLiBUaGUg cHJvcG9zZWQgdXNlIGNhc2UgaXMgc2Vlbg0KPj4+IGJlbG93LiBUaGUgdXBkYXRlZCB2ZXJzaW9u IG9mIHRoaXMgZHJhZnQgaXMgdG8gYmUgc3VibWl0dGVkIHNvb24gYnkNCj4+PiBhZGRpbmcgc29t ZSB3b3JkaW5nIG1vZGlmaWNhdGlvbnMuIFNvLCBJIGRvbid0IHRoaW5rIHdlIGFyZSB0byBza2lw IHRoZQ0KPj4+IGFkZGl0aW9uYWwgdXNlIGNhc2VzIGV2ZW4gdGhlIHByb2JsZW0gc3RhdGVtZW50 LCB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnQNCj4+PiBwcm9wb3NhbCBoYXZlIGJlZW4gaW50ZWdy YXRlZCBub3cuDQo+Pj4NCj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCj4+PiB4LnguICBJbmRvb3IgdXNhZ2Ugb2YgVFZXUw0KPj4+DQo+ Pj4gIEF0IHByZXNlbnQsIHRoZSBpbmRvb3Igd2lyZWxlc3MgY292ZXJhZ2UgZXF1aXBtZW50cyBj b25zaXN0IG9mIFdpLUZpLQ0KPj4+ICBsaWtlIGFjY2VzcyBwb2ludHMgYW5kIG1pY3JvIGNlbGxz LCBhbGwgb2YgdGhlc2UgdXRpbGl6ZSBzZWdtZW50cyBvZg0KPj4+ICBmcmVxdWVuY3ksIGZvcm1l ciBhdCBhYm91dCAyLjRHSHogb3IgNUdoeiBhbmQgdGhlIGxhdHRlciwgZm9yDQo+Pj4gIGV4YW1w bGUsIDgwMi4xMW4gYXQgYWJvdXQgMi40R0h6LiAgQXMgYSByZXN1bHQgb2YgdGhlIGJsb2NrIG9m DQo+Pj4gIGJ1aWxkaW5ncyBhbmQgb3RoZXIgb2JzdHJ1Y3Rpb24gYW5kIGludGVyZmVyZWNlLCBp dCBtYXkgbm90IGJlIHRoYXQNCj4+PiAgb3B0aW1pc3RpYyB3aGVuIDgwMi4xMSBkZXZpY2VzIGV4 YW1pbmUgdGhlIHN0YXR1cyBvZiB3aXJlbGVzcw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFpodSAgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMiAgICAgICAgICAgICAgICBb UGFnZSAzXQ0KPj4+DQo+Pj4NCj4+PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFBBV1Mg dXNlIGNhc2VzICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTENCj4+Pg0KPj4+DQo+Pj4gIGlu dGVyZmVyZXMuICBUaGlzIHVzZSBjYXNlIHRha2VzIHRoZSBiZW5lZml0IG9mIFRWIFdoaXRlIFNw YWNlIHRvDQo+Pj4gIHByb3ZpZGUgYWRkaXRpb25hbCBjYXBhY2l0eSB0byBpbmRvb3IgY292ZXJh Z2UgYW5kIHJlZHVjZSBjaGFubmVsDQo+Pj4gIGludGVyZmVyZWNlLg0KPj4+DQo+Pj4gIFRoZSBm aWd1cmUgYmVsb3cgc2hvd3MgYW4gZXhhbXBsZSBkZXBsb3ltZW50IG9mIHRoaXMgc2NlbmFyaW8u DQo+Pj4NCj4+PiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPj4+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgaW5kb29yICAgICAgICAgICAgICB8DQo+ Pj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+PiAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+ICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4gICAgICAgICAg ICAgIHwgICAgKy0tLS0tLSsgICB3aGl0ZSBzcGFjZSAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsN Cj4+PiAgICAgICAgICAgICAgfCAgICB8RGV2aWNlfCAtIC0gLSAtIC0gLSAtIC0gLSAtfC0gLXwg TWljcm8gY2VsbCAgfA0KPj4+ICAgICAgICAgICAgICB8ICAgICstLS0tLS0rICBcICAgICAgICAg ICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0rDQo+Pj4gICAgICAgICAgICAgIHwgICAgKy0tLS0t LSsgICBcd2hpdGUgc3BhY2UgICAgIHwgICAgICgtLS0tLSkNCj4+PiAgICAgICAgICAgICAgfCAg ICB8RGV2aWNlfCAgICBcICstLS0tLS0tLS0tLS0rfCAgICAvICAgICAgIFwNCj4+PiAgICAgICAg ICAgICAgfCAgICArLS0tLS0tKyAgICAgIHxhY2Nlc3MgcG9pbnR8fD09PSggSW50ZXJuZXQpDQo+ Pj4gICAgICAgICAgICAgIHwgICAgICAgIG8gICAgICAgLyArLS0tLS0tLS0tLS0tK3wgICAgXCAg ICAgICAvDQo+Pj4gICAgICAgICAgICAgIHwgICAgICAgIG8gICAgICAvICAgICAgICAgICAgICAg IHwgICAgICgtLS0tLSkNCj4+PiAgICAgICAgICAgICAgfCAgICAgICAgbyAgICAgLyAgICAgICAg ICAgICAgICAgfA0KPj4+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+Pj4gICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCj4+Pg0KPj4+DQo+Pj4gICAgICAgICAgICAgICAgICAgICAgR3JhcGggMSBJbmRvb3IgdXNh Z2Ugb2YgVFZXUw0KPj4+DQo+Pj4gIFRoZSBhY2Nlc3MgcG9pbnQgY291bGQgYmUgYSBXSS1GSSBy b3V0ZXIsIGFuZCB0aGUgbWljcm8gY2VsbCBpcyBhDQo+Pj4gIHNob3J0IHJhbmdlIHdpcmVsZXNz IGNvdmVyYWdlKGUuZy4gaW4gcmFuZ2Ugb2YgMC01MG0pIGJhc2Ugc3RhdGlvbiwNCj4+PiAgYm90 aCBvZiB0aGVtIGFjdCBhcyBtYXN0ZXIgZGV2aWNlcywgcXVlcnlpbmcgdGhlIGludGVybmV0IGNv bm5lY3RlZA0KPj4+ICBkYXRhYmFzZSBmb3IgYXZhaWxhYmxlIHdoaXRlIHNwYWNlIHNwZWN0cnVt IGJhc2VkIG9uIGl0cyBnZW8tDQo+Pj4gIGxvY2F0aW9uLCBhbmQgcHJvdmlkaW5nIFRWV1MgYWNj ZXNzIHRvIGluZG9vciB1c2VyLg0KPj4+DQo+Pj4gIFRoZSBUVldTIHNwZWN0cnVtIGhhcyBkaWZm ZXJlbnQgcHJvcGFnYXRpb24gY2hhcmFjdGVyaXN0aWNzIGNvbXBhcmVkDQo+Pj4gIHRvIGhpZ2hl ciBmcmVxdWVuY3kgYmFuZCwgZm9yIGV4YW1wbGUsIHRoZSB0cmFuc21pc3Npb24gZGlzdGFuY2UN Cj4+PiAgdXNpbmcgVFZXUyBjYW4gYmUgc2V2ZXJhbCB0aW1lcyBsb25nZXIgdGhhbiB0aG9zZSBp biB0aGUgaGlnaGVyIGJhbmQuDQo+Pj4gIEluIHRoaXMgY2FzZSwgZ29vZCBwZW5ldHJhdGlvbiBj aGFyYWN0ZXJpc3RpYyBvZiBUVldTIG1ha2VzIGl0DQo+Pj4gIGRpZmZpY3VsdCB0byBsb2NrIHRo ZSBzaWduYWxzIGluIHRoZSByb29tLCB0aGVuIGRpZmZpY3VsdCB0byBsb2NhbGl6ZQ0KPj4+ICBh bmQgZGlmZmVyZW50aWF0ZSBzaWduYWxzLCBhbmQgZmluYWxseSBjYXVzZSBpbnRlcmZlcmVzIGFt b25nDQo+Pj4gIG5laWdoYm9yaW5nIG5ldHdvcmtzLiAgUmVxdWlyZW1lbnRzIHRvIGluZG9vciBX UyBkYXRlYmFzZSB1c2FnZSB3b3VsZA0KPj4+ICBiZToNCj4+Pg0KPj4+DQo+Pj4gIDEuICBBIGZy ZXF1ZW5jeSBwcm90ZWN0aW9uIGdhcCBiZXR3ZWVuIG5laWdoYm9ycyhwYXJ0aWN1bGFyIHNwZWN0 cnVtDQo+Pj4gICAgICBhbGxvY2F0aW9uIGFsZ29yaXRobSBpcyBuZWVkZWQgaGVyZSkuDQo+Pj4N Cj4+PiAgMi4gIGxvd2VyIG91dHB1dCBwb3dlciBvZiBBUC9taWNybyBjZWxsLCBpdCBzZWVtcyB0 aGF0IG9ubHkgY2VydGFpbg0KPj4+ICAgICAgcGljbyBvciBmZW10byBjZWxscyBiZSBmZWFzaWJs ZSBoZXJlLg0KPj4+DQo+Pj4gIDMuICBQQVdTIG11c3Qgbm90IGJlIHRpZWQgdG8gYSBzcGVjaWZp YyBmcmVxdWVuY3kgYmFuZC4NCj4+Pg0KPj4+ICA0LiAgUEFXUyBtdXN0IHJlc3BvbnNlIHRoZSBw cm9wZXIgZnJlcXVlbmN5IGJhbmQgbGlzdCB0byBwYXJ0aWN1bGFyDQo+Pj4gICAgICBjb3ZlcmFn ZSB3aGl0ZSBzcGFjZSBkZXZpY2VzLg0KPj4+DQo+Pj4gIDUuICBNYXN0ZXIgZGV2aWNlcyBzaG91 bGQgc3VwcG9ydCBwb3dlciBjb250cm9sLg0KPj4+DQo+Pj4gIDYuICBTbGF2ZSBkZXZpY2VzIHNo b3VsZCBzdXBwb3J0IHBvd2VyIGNvbnRyb2wuDQo+Pj4NCj4+PiA9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+Pg0KPj4+IFpodSBMZWkNCj4+ Pg0KPj4+DQo+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+Pj4gt6K8/sjLOiBwYXdzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gR2VyYWxkDQo+Pj4g Q2hvdWluYXJkDQo+Pj4gt6LLzcqxvOQ6IDIwMTHE6jnUwjjI1SA4OjAxDQo+Pj4gytW8/sjLOiBH YWJvci5CYWprb0Bub2tpYS5jb20NCj4+PiCzrcvNOiBwYXdzQGlldGYub3JnDQo+Pj4g1vfM4jog UmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYgcmVxdWly ZW1lbnRzDQo+Pj4NCj4+PiBHYWJvciwNCj4+Pg0KPj4+IENhbiBJIGFzayB0aGF0IHRoZSB0ZXh0 IG1vZGlmaWNhdGlvbnMgdGhhdCBJIGhhdmUgc3VibWl0dGVkIHRvIHNjb3R0IGFuZA0KPj4+IGNv cGllZCB0byB0aGUgcGF3cyByZWZsZWN0b3IgaW4gbXkgZW1haWwgZGF0ZWQgOCBBdWd1c3QgYmUg aW5jbHVkZWQgYXMNCj4+PiB3ZWxsPw0KPj4+DQo+Pj4gVGhhbmsncywNCj4+Pg0KPj4+IEdlcmFs ZA0KPj4+DQo+Pj4NCj4+PiBBdCAyMDozMiAwNy0wOS0xMSArMDAwMCwgR2Fib3IuQmFqa29Abm9r aWEuY29tIHdyb3RlOg0KPj4+PiBPaywgbGV0J3MgdHJ5IHRoYXQgdGhlbi4NCj4+Pj4gU2NvdHQs IGNhbiB5b3UgcHV0IHVzZSBjYXNlcyBiZWZvcmUgUFMsIGFuZCBhZGQgdGhlIGFkLWhvYyB1c2Ug Y2FzZS4gSQ0KPj4+PiBqdXN0IHNjYW5uZWQgdGhyb3VnaCB0aGUgbGlzdCBhbmQgc3BvdHRlZCB0 aGF0IFRlY28gaW5kZWVkIHByb3ZpZGVkIGENCj4+Pj4gZGVzY3JpcHRpb24gZm9yIHRoYXQgdXNl IGNhc2Ugb24gQXVnIDNyZC4NCj4+Pj4gQW5kIHN1Ym1pdCB0aGUgZHJhZnQgYXMgYSB3ZyBpdGVt LCB1bmxlc3MgdGhlcmUgYXJlIHN0aWxsIG9iamVjdGlvbnMuDQo+Pj4+DQo+Pj4+IC1HYWJvcg0K Pj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBleHQgTmFu Y3kgQnJhdmluIFttYWlsdG86bmJyYXZpbkBlYXJ0aGxpbmsubmV0XQ0KPj4+PiBTZW50OiBTYXR1 cmRheSwgU2VwdGVtYmVyIDAzLCAyMDExIDM6NDEgUE0NCj4+Pj4gVG86IEJhamtvIEdhYm9yIChO b2tpYS1DSUMvU2lsaWNvblZhbGxleSkNCj4+Pj4gQ2M6IFRlY28gQm9vdDsgR2VyYWxkIENob3Vp bmFyZDsgcGF3c0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHBy b2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4+Pj4NCj4+Pj4gRGVh ciBHYWJvciBhbmQgQWxsLA0KPj4+Pg0KPj4+PiBJIHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRv IHB1dCB0aGUgdXNlIGNhc2VzIGJlZm9yZSB0aGUgUFMgZm9yIG9idmlvdXMNCj4+Pj4gcmVhc29u cywgYW5kIGluY2x1ZGluZyB0aGUgInByb3h5IiBuZWVkIGluIHRoZSBmaXJzdCBkcmFmdC4gSSBz dXBwb3J0DQo+Pj4+IGluY2x1ZGluZyBib3RoIEdlcmFsZCdzIHN1Z2dlc3Rpb25zIGFuZCBUZWNv J3MgcHJvcG9zYWwgaW4gdGhlIG9yaWdpbmFsDQo+Pj4+IGRyYWZ0IGFuZCBub3Qgd2FpdGluZyB1 bnRpbCBhIGxhdGVyIHRpbWUuIEl0IGlzIHRoZSBwcm9wZXIgb3JkZXIsDQo+Pj4+IGluY2x1c2l2 ZSBhbmQgbmVlZGVkIGluIHRoZSBpbml0aWFsIGRyYWZ0IGluIG15IG9waW5pb24uIEkgYmVsaWV2 ZSB3aXRoDQo+Pj4+IHRoZSB0YWxlbnQgaW4gdGhlIGdyb3VwIGl0IHdpbGwgbm90IHRha2UgbG9u ZyB0byBhY2NvbXBsaXNoIHRoaXMgYW5kIHlvdQ0KPj4+PiB3aWxsIGhhdmUgYSBtb3JlIGNvaGVz aXZlIGRyYWZ0Lg0KPj4+Pg0KPj4+PiBTSW5jZXJlbHksIE5hbmN5DQo+Pj4+DQo+Pj4+DQo+Pj4+ IE9uIFNlcCAyLCAyMDExLCBhdCAyOjE5IFBNLCA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj4+ PiA8R2Fib3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFRlY28sIEdlcmFs ZCwNCj4+Pj4+DQo+Pj4+PiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gSSdkIHN1Z2dlc3QgdGhh dCB3ZSBtYWtlIHRoaXMgZHJhZnQgYSBXRw0KPj4+PiBpdGVtLA0KPj4+PiB3aXRoIEdlcmFsZCdz IHByb3Bvc2VkIGNoYW5nZXMgaW4gaXQuIFJlZ2FyZGluZyB0aGUgb3JkZXIgb2YgdGhlDQo+Pj4+ IHByb2JsZW0NCj4+Pj4gc3RhdGVtZW50IHZzIHVzZSBjYXNlcywgbXkgcHJlZmVyZW5jZSB3b3Vs ZCBiZSB0byBsZWF2ZSBpdCBhcyBpdCBpcw0KPj4+PiAoYnV0DQo+Pj4+IHdlIGNhbiBhbHdheXMg Y2hhbmdlIGl0LCBpZiB0aGF0IGlzIHdoYXQgdGhlIFdHIHdhbnRzKS4NCj4+Pj4+DQo+Pj4+PiBT bywgSSdkIGFzayBTY290dCB0byBzdWJtaXQgYSBXRyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQsIHRo ZW4gaGF2ZQ0KPj4+PiBzb21lb25lIGNvbWUgdXAgd2l0aCB0ZXh0IGZvciB0aGlzIGFkLWhvYyBu ZXR3b3JrIHNjZW5hcmlvLCBoYXZlIHRoZSBXRw0KPj4+PiBhZ3JlZSB3aXRoIHRoZSB0ZXh0IGFu ZCBpbmNsdWRlIGl0IGluIG9uZSBvZiB0aGUgc3Vic2VxdWVudCB2ZXJzaW9ucy4NCj4+Pj4gVGVj bywgd291bGQgeW91IHdyaXRlIHVwIHNvbWUgdGV4dCBmb3IgdGhpcyBhZC1ob2MgdXNlIGNhc2Ug dGhlIFdHDQo+Pj4+IGNvdWxkDQo+Pj4+IGRpc2N1c3M/DQo+Pj4+Pg0KPj4+Pj4gV2UnbGwgYWxz byBzZW5kIGFuIGluaXRpYWwgdmVyc2lvbiBvZiBhIGxpc3Qgb2YgcmVxdWlyZW1lbnRzIHRvIHRo ZQ0KPj4+PiBsaXN0IG5leHQgd2Vlay4NCj4+Pj4+DQo+Pj4+PiAtIEdhYm9yDQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBleHQgVGVj byBCb290IFttYWlsdG86dGVjb0BpbmYtbmV0Lm5sXQ0KPj4+Pj4gU2VudDogVGh1cnNkYXksIFNl cHRlbWJlciAwMSwgMjAxMSAxMTowNiBQTQ0KPj4+Pj4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1D SUMvU2lsaWNvblZhbGxleSkNCj4+Pj4+IENjOiBwYXdzQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0 OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJg0KPj4+ Pj4gcmVxdWlyZW1lbnRzDQo+Pj4+Pg0KPj4+Pj4gSSB0aGluayB0aGUgZG9jIGlzIGEgZ29vZCBz dGFydGluZyBwb2ludC4gSSBzdXBwb3J0IGFkb3B0aW9uLg0KPj4+Pj4NCj4+Pj4+IEkgc3VnZ2Vz dCByZW9yZGVyaW5nOiBzcGVjaWZ5aW5nIHByb2JsZW0gc3RhdGVtZW50IGFmdGVyIGludHJvZHVj aW5nDQo+Pj4+IHRoZSB1c2UgY2FzZXMuDQo+Pj4+Pg0KPj4+Pj4gU29tZSBhc2tlZCBmb3IgdGhl IGFkIGhvYyBuZXR3b3JrIHNjZW5hcmlvLiBUaGlzIGluY2x1ZGVzIG1lIDotKS4NCj4+Pj4gVGhp cw0KPj4+PiBpcyBpbXBvcnRhbnQsIGJlY2F1c2UgaXQgZGVtb25zdHJhdGVzIHRoZSBuZWVkIGZv ciAicHJveHkiLg0KPj4+Pj4gQlRXLCBJIHdvbmRlciB3aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vz bid0IHBvcCB1cCBmcm9tIFdpRmkNCj4+Pj4gZGVwbG95bWVudHMuIFVzYWdlIG9mIGNvbnRyb2xs ZXJzIGluIGxhcmdlIHNpdGVzIGlzIG5vdCB1bmNvbW1vbi4gTm90DQo+Pj4+IHRvDQo+Pj4+IG1l bnRpb24gMTFzLg0KPj4+Pj4NCj4+Pj4+IFRoZSByZXF1aXJlbWVudHMgaXMgbGVmdCBvcGVuLiBJ J20gbG9va2luZyBmb3J3YXJkIHNlZSBzb21lIGRyYWZ0DQo+Pj4+IHRleHQuDQo+Pj4+Pg0KPj4+ Pj4gVGhhbmtzLCBUZWNvDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9wIDMwIGF1ZyAyMDExLCBvbSAx OTo0MiBoZWVmdCA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj4+PiA8R2Fib3IuQmFqa29Abm9r aWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoNCj4+Pj4+DQo+Pj4+Pj4gSSBzZW50IHRo aXMgZW1haWwgdG8gdGhlIGxpc3Qgb25lIHdlZWsgYWdvLCBhc2tpbmcgZm9yIGZlZWRiYWNrIG9u DQo+Pj4+Pj4NCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdz LXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10DQo+Pj4+Pj4gcyAtMDAudHh0IGJ1dCB0aGVyZSB3 YXMgbm90IG9uZSBmZWVkYmFjayByZWNlaXZlZC4gSSB0YWtlIHRoYXQgYXMNCj4+Pj4+PiBwZW9w bGUgaGF2ZSBubyBjb21tZW50cyB0byB0aGUgZHJhZnQgYXQgdGhpcyB0aW1lLg0KPj4+Pj4+DQo+ Pj4+Pj4gQW5kIEkgYW0gYXNraW5nIGFnYWluOiBpcyB0aGVyZSBhbnkgb2JqZWN0aW9uIGluIGFk b3B0aW5nIHRoZSBhYm92ZQ0KPj4+PiBkcmFmdCBhcyBhIHdnIGRvY3VtZW50Pw0KPj4+Pj4+DQo+ Pj4+Pj4gLUdhYm9yDQo+Pj4+Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+Pj4+IEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4+Pj4gT2YgZXh0IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0K Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDExIDI6NDMgUE0NCj4+Pj4+PiBUbzog cGF3c0BpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxl bSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+Pj4+Pj4gcmVxdWlyZW1lbnRzDQo+Pj4+Pj4NCj4+ Pj4+PiBEdXJpbmcgdGhlIFF1ZWJlYyBzZXNzaW9uLCB3ZSBoYWQgcHJlc2VudGF0aW9ucyBvZiB0 aGUgUFMgYW5kIHRoZQ0KPj4+PiB1c2UNCj4+Pj4gY2FzZXMgZHJhZnRzLiBUaGUgd2cgdGhlbiBk ZWNpZGVkIGl0IHdhbnRzIHRvIHNlZSB0aGVzZSBkcmFmdHMgbWVyZ2VkDQo+Pj4+IGludG8gb25l LiBTY290dCBqdXN0IGRpZCB0aGF0IGFuZCBwb3N0ZWQgdGhlIG1lcmdlZCBkcmFmdDoNCj4+Pj4+ Pg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtcHJvYmxl bS1zdG10LXVzZWNhc2VzLXJxbXQNCj4+Pj4+PiBzDQo+Pj4+Pj4gLTAwLnR4dA0KPj4+Pj4+DQo+ Pj4+Pj4gTm93IEkgd291bGQgbGlrZSB0byBhc2sgaWYgdGhlIHdnIGZlZWxzIGxpa2UgdGhpcyBk b2N1bWVudCBpcyByZWFkeQ0KPj4+PiB0bw0KPj4+PiBiZSBhZG9wdGVkIGFzIGEgd2cgZG9jdW1l bnQuIFBsZWFzZSBzZW5kIHlvdXIgZmVlZGJhY2sgYW5kIGh1bSB0byB0aGUNCj4+Pj4gbGlzdCBi eSB0aGlzIHRpbWUgbmV4dCB3ZWVrLg0KPj4+Pj4+DQo+Pj4+Pj4gLUdhYm9yDQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+PiAtDQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gRnJvbTogUHJvYmFzY28gU2NvdHQNCj4+Pj4+PiBT ZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSA5OjE4IEFNDQo+Pj4+Pj4gVG86IHBhd3NAaWV0 Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNh c2VzICYgcmVxdWlyZW1lbnRzDQo+Pj4+Pj4NCj4+Pj4+PiBIaSwNCj4+Pj4+Pg0KPj4+Pj4+IEFj Y29yZGluZyB0byB0aGUgcmVzdWx0cyBvZiB0aGUgZmFjZS10by1mYWNlIG1lZXRpbmcsIHdlIGhh dmUNCj4+Pj4gY29tYmluZWQNCj4+Pj4gdGhlIHByb2JsZW0gc3RhdGVtZW50IEktRCBhbmQgdXNl IGNhc2UgJiByZXF1aXJlbWVudCBJLUQgaW50byBhIHNpbmdsZQ0KPj4+PiBJLUQuICBZb3VyIGNv bW1lbnRzIGFyZSB3ZWxjb21lZC4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4gU2Nv dHQNCj4+Pj4+Pg0KPj4+Pj4+IFVSTDoNCj4+Pj4+Pg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXQNCj4+Pj4+ PiBzDQo+Pj4+Pj4gLTAwLnR4dA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBBYnN0cmFjdDoNCj4+ Pj4+PiBQb3J0aW9ucyBvZiB0aGUgcmFkaW8gc3BlY3RydW0gdGhhdCBhcmUgYWxsb2NhdGVkIHRv IGEgbGljZW5zZWQsDQo+Pj4+Pj4gcHJpbWFyeSB1c2VyIGJ1dCBhcmUgdW51c2VkIG9yIHVub2Nj dXBpZWQgYXQgc3BlY2lmaWMgbG9jYXRpb25zIGFuZA0KPj4+Pj4+IHRpbWVzIGFyZSBkZWZpbmVk IGFzICd3aGl0ZSBzcGFjZScuICBUaGUgY29uY2VwdCBvZiBhbGxvd2luZw0KPj4+Pj4+IHNlY29u ZGFyeSB0cmFuc21pc3Npb25zIChsaWNlbnNlZCBvciB1bmxpY2Vuc2VkKSBpbiB3aGl0ZSBzcGFj ZSBpcyBhDQo+Pj4+Pj4gdGVjaG5pcXVlIHRvICd1bmxvY2snIGV4aXN0aW5nIHNwZWN0cnVtIGZv ciBuZXcgdXNlLiAgQW4gb2J2aW91cw0KPj4+Pj4+IHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlc2Ug c2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgZG8gbm90IGludGVyZmVyZQ0KPj4+Pj4+IHdpdGggdGhl IHByaW1hcnkgdXNlIG9mIHRoZSBzcGVjdHJ1bS4gIE9uZSBhcHByb2FjaCB0byB1c2luZyB0aGUN Cj4+Pj4+PiB3aGl0ZSBzcGFjZSBzcGVjdHJ1bSBhdCBhIGdpdmVuIHRpbWUgYW5kIGxvY2F0aW9u IGlzIHRvIHZlcmlmeSB3aXRoDQo+Pj4+IGENCj4+Pj4+PiBkYXRhYmFzZSBhdmFpbGFibGUgY2hh bm5lbHMuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgY29uY2Vw dCBvZiBUViBXaGl0ZSBTcGFjZXMuICBJdCBhbHNvDQo+Pj4+Pj4gZGVzY3JpYmVzIHRoZSBwcm9i bGVtcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGZvciBlbmFibGluZyB0aGUNCj4+Pj4gdXNl DQo+Pj4+Pj4gb2YgdGhlIHByaW1hcnkgdXNlciBvd25lZCB3aGl0ZSBzcGFjZSBzcGVjdHJ1bSBm b3Igc2Vjb25kYXJ5IHVzZXJzLA0KPj4+Pj4+IHdpdGhvdXQgY2F1c2luZyBpbnRlcmZlcmVuY2Us IGJ5IHF1ZXJ5aW5nIGEgZGF0YWJhc2Ugd2hpY2gga25vd3MgdGhlDQo+Pj4+Pj4gY2hhbm5lbCBh dmFpbGFiaWxpdHkgYXQgYW55IGdpdmVuIGxvY2F0aW9uIGFuZCB0aW1lLiAgQSBudW1iZXIgb2YN Cj4+Pj4+PiBwb3NzaWJsZSB1c2UgY2FzZXMgb2YgdGhpcyBzcGVjdHJ1bSBhbmQgZGVyaXZlZCBy ZXF1aXJlbWVudHMgYXJlDQo+Pj4+IGFsc28NCj4+Pj4+PiBkZXNjcmliZWQuDQo+Pj4+Pj4NCj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gcGF3cyBtYWlsaW5n IGxpc3QNCj4+Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4+ PiBwYXdzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3MNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4gcGF3c0BpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4+PiBwYXdzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0K From Peter.McCann@huawei.com Tue Sep 13 19:34:17 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 CAD8621F8C37 for ; Tue, 13 Sep 2011 19:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 VRpqA1JIlC8O for ; Tue, 13 Sep 2011 19:34:17 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5081521F8C39 for ; Tue, 13 Sep 2011 19:34:17 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRH00G1DR8OFQ@usaga02-in.huawei.com> for paws@ietf.org; Tue, 13 Sep 2011 21:36:25 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRH00GIYMOEI8@usaga02-in.huawei.com> for paws@ietf.org; Tue, 13 Sep 2011 20:00:48 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 13 Sep 2011 17:35:26 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 10:37:35 -0700 Date: Tue, 13 Sep 2011 17:37:34 +0000 From: Peter McCann X-Originating-IP: [10.193.125.70] To: "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkA== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 02:34:17 -0000 Hi, I've been interacting with Zhu Lei off-list about his third use case, and I think it would be a possible candidate for inclusion in the document if it were properly explained. Generally (as opposed to specifically for the LTE MBMS case), the problem is to find a common bit of spectrum that is available over a wide area that can be used by multiple master BSs to simultaneously broadcast the same signal to a set of receivers. This is somewhat similar to the wide-area rural coverage scenario currently described in the working group document; however, there would be multiple Master BSs, each of which would independently query the WSDB for available spectrum. However, they need to coordinate the assignment so that they all get the same spectrum over the whole area. As an implementation example, this could be achieved by each BS reporting the same owner/operator and using a key or index value to indicate that they wanted to coordinate the assignment. Alternatively, you might be able to elect one BS as the leader and collect location information from all the other BSs and then coordinate the assignment similar to the use case in 4.2; the difference would be that the resulting assignment is for simultaneous (not TDD) use by all of the BSs covering the wider area. Does this sound like an interesting and novel use case? If so I can do a more detailed writeup and supply ASCII art for the draft. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA From jmh@joelhalpern.com Tue Sep 13 19:44: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 BF85711E8091 for ; Tue, 13 Sep 2011 19:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 IUquXMJBuY6T for ; Tue, 13 Sep 2011 19:44:45 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABEF11E8090 for ; Tue, 13 Sep 2011 19:44:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 44DF44300F1; Tue, 13 Sep 2011 19:46:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-71.clppva.btas.verizon.net [71.161.50.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9CBFF4300EC; Tue, 13 Sep 2011 19:46:52 -0700 (PDT) Message-ID: <4E701599.7010804@joelhalpern.com> Date: Tue, 13 Sep 2011 22:46:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Peter McCann References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 02:44:45 -0000 I may be missing something, but it seems to me taht what you are describing is not the job of the database query protocol. base station coordination is an interesting problem, but is it within scope for this WG? (I do not think just specifying the same owner to the database will resolve the problem, and it makes the database state MUCH more complex.) Yours, Joel On 9/13/2011 1:37 PM, Peter McCann wrote: > Hi, > > I've been interacting with Zhu Lei off-list about his third use case, > and I think it would be a possible candidate for inclusion in the document > if it were properly explained. > > Generally (as opposed to specifically for the LTE MBMS case), the > problem is to find a common bit of spectrum that is > available over a wide area that can be used by multiple master BSs > to simultaneously broadcast the same signal to a set of receivers. > This is somewhat similar to the wide-area rural coverage scenario > currently described in the working group document; however, there > would be multiple Master BSs, each of which would independently query > the WSDB for available spectrum. However, they need to coordinate > the assignment so that they all get the same spectrum over the whole > area. As an implementation example, this could be achieved by each > BS reporting the same owner/operator and using a key or index value > to indicate that they wanted to coordinate the assignment. Alternatively, > you might be able to elect one BS as the leader and collect location > information from all the other BSs and then coordinate the assignment > similar to the use case in 4.2; the difference would be that the > resulting assignment is for simultaneous (not TDD) use by all of the > BSs covering the wider area. > > Does this sound like an interesting and novel use case? If so I can > do a more detailed writeup and supply ASCII art for the draft. > > -- > Peter J. McCann > Huawei Technologies (USA) > Peter.McCann@Huawei.com > +1 908 541 3563 > Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From Basavaraj.Patil@nokia.com Tue Sep 13 19:53: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 E22E811E8090 for ; Tue, 13 Sep 2011 19:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 oKktjxx6dVYP for ; Tue, 13 Sep 2011 19:53:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1313D11E8083 for ; Tue, 13 Sep 2011 19:53:42 -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 p8E2tW4K007658; Wed, 14 Sep 2011 05:55:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 05:55:37 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 04:54:19 +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; Wed, 14 Sep 2011 04:54:18 +0200 From: To: , Thread-Topic: Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAATTVhQ Date: Wed, 14 Sep 2011 02:54:18 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719A97D3E@008-AM1MPN1-051.mgdnok.nokia.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.219.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 02:55:37.0602 (UTC) FILETIME=[C7DB3620:01CC7289] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 02:53:44 -0000 Pete, I dont believe co-ordination between BS' is needed.=20 Interference mitigation between BS' is an interesting problem no doubt. But= it is not in the scope of the current charter. Adjacent BS' (i.e Master WS devices) for example which query a database may= receive the same channel information. This could result in interference. However that is an issue which the PAWS = WG is not chartered to solve.=20 There is work on this happening in IEEE (802.19) but that aspect of cogniti= ve radio is not something we are aiming to solve currently. -Raj=20 ________________________________________ From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of ext Peter = McCann [Peter.McCann@huawei.com] Sent: Tuesday, September 13, 2011 12:37 PM To: paws@ietf.org Subject: [paws] Possible new use case: simulcasting Hi, I've been interacting with Zhu Lei off-list about his third use case, and I think it would be a possible candidate for inclusion in the document if it were properly explained. Generally (as opposed to specifically for the LTE MBMS case), the problem is to find a common bit of spectrum that is available over a wide area that can be used by multiple master BSs to simultaneously broadcast the same signal to a set of receivers. This is somewhat similar to the wide-area rural coverage scenario currently described in the working group document; however, there would be multiple Master BSs, each of which would independently query the WSDB for available spectrum. However, they need to coordinate the assignment so that they all get the same spectrum over the whole area. As an implementation example, this could be achieved by each BS reporting the same owner/operator and using a key or index value to indicate that they wanted to coordinate the assignment. Alternatively, you might be able to elect one BS as the leader and collect location information from all the other BSs and then coordinate the assignment similar to the use case in 4.2; the difference would be that the resulting assignment is for simultaneous (not TDD) use by all of the BSs covering the wider area. Does this sound like an interesting and novel use case? If so I can do a more detailed writeup and supply ASCII art for the draft. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From lei.zhu@huawei.com Wed Sep 14 02:06: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 B2B3621F8C2B for ; Wed, 14 Sep 2011 02:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 nxwtYUdAEnl7 for ; Wed, 14 Sep 2011 02:06:08 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFA421F8C2A for ; Wed, 14 Sep 2011 02:06:07 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI005009DL2Q@szxga03-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 17:08:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI007SL9DJXT@szxga03-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 17:08:09 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADY77559; Wed, 14 Sep 2011 17:08:04 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 17:08:00 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.189]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 17:08:03 +0800 Date: Wed, 14 Sep 2011 09:08:02 +0000 From: ZhuLei In-reply-to: <35D7EFC3-8EBD-428A-B579-8C4D783ED7BB@neustar.biz> X-Originating-IP: [10.108.64.160] To: "Rosen, Brian" , Peter Stanforth Message-id: <470F27D1263A1B4EB73491ED995DE62539C667@szxeml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [paws] combined problem statement, use cases & requirements Thread-index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3AgAB8ZQCAB4F8QIAAEMcAgAAQ2oCAAbYJkA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <35D7EFC3-8EBD-428A-B579-8C4D783ED7BB@neustar.biz> Cc: "paws@ietf.org" 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: Wed, 14 Sep 2011 09:06:09 -0000 SGksDQoNCk5vIGRvdWJ0IHRoYXQgUEFXUyBpcyBzcGVjdHJ1bSBpbmRlcGVuZGVudCwgYWlyIGlu dGVyZmFjZSB0ZWNobm9sb2dpZXMgaW5kZXBlbmRlbnQgYW5kIG5hdGlvbiBpbmRlcGVuZGVudCBw cm90b2NvbCB3aGljaCB3b3VsZCBoYXZlIHNvbWUgZXNzZW50aWFsIHBhcmFtZXRlcnMgaW4gcXVl cnkgcmVxdWVzdCBsaWtlICJsb2NhdGlvbiIsICJ0eXBlIiBhbmQgbWF4aW11bSBwb3dlciBsaW1p dHMuIEkgdXNlZCB0byB0aGluayB0aGF0IFBBV1MgaXMgZXZlbiBleHRlbmRhYmxlIGZvciBzb21l IGFkZGl0aW9uYWwgcnVsZSBpZiB0aGVyZSBpcy4gU3VjaCBzdXBwb3J0ZWQgb3IgZXh0ZW5kYWJs ZSBpbmZvcm1hdGlvbiBpbiBhIHF1ZXJ5IHJlcXVlc3Qgd291bGQgcHJvdmlkZSBpbmZvcm1hdGlv biB0byBmb3IgZGF0YWJhc2UgdG8gcmVwbHkgYXZhaWxhYmxlIGJhbmRzLiBUaGF0IGlzIG9yaWdp bmFsIGNvbmNlcHQgb2YgUEFXUyB3aGVuIEkgdXNlZCB0byBsaXN0ZW4uDQoNCkZvciBpbnRlcmZl cmVuY2UgaXNzdWUsIEkgdGhpbmsgdGhhdCBBUHMgaW5kb29yIGFyZSBtb3JlIGZsZXhpYmxlIHRv IGxpbWl0IHRoZSBvdXRwdXQgcG93ZXIsIGJ1dCBpdCBpcyBkaWZmaWN1bHQgdG8gbGltaXQgcG93 ZXIgb3V0cHV0IG9mIG91dGRvb3IgYWNjZXNzIHBvaW50cyB3aGljaCBjb3ZlciBvdmVyIGh1bmRy ZWRzIG1ldGVycy4gU28sIHRoZSBkYXRhYmFzZSBpcyBsaWtlbHkgdG8gcmVwbHkgb3RoZXIgc3Bl Y3RydW0gdG8gaW5kb29yIEFQcyBpZiB0aGUgc3BlY3RydW0gaXMgYWxyZWFkeSBjb3ZlcmVkIGJ5 IG90aGVyIG91dGRvb3IgQVAocykuIFRoZSBjb25jbHVzaW9uIG9mIHRoZSBpbmRvb3IgQVBzIGNv dWxkIGJlIGNvbXBsaWNhdGVkIG1vcmUgc2luY2Ugc29tZXRpbWVzIHBvd2VyIGNvbnRyb2wgd29y a3Mgd2hlbiBpbnRlcmZlcmVuY2UgaGFwcGVucywgYnV0IGludGVyZmVyZW5jZSBhdm9pZGFuY2Ug aXMgc3RpbGwgdmVyeSB1c2VmdWwgaW4gYSBudW1iZXIgb2YgY2FzZXMuIDgwMi4xMSBoYXMgImlu dGVyZmVyZW5jZSBhdm9pZGFuY2UiIGlzIGJhc2ljYWxseSB0byB1c2UgZGlmZmVyZW50ICJjaGFu bmVsIiBpbiBjYXNlIHRoYXQgbW9yZSB0aGFuIG9uZSBBUHMgd29yayBpbiBhbiBhcmVhLiBNeSBv cGluaW9uIGlzIHRoYXQgaXQgaXMgdmVyeSBoZWxwZnVsIGlmIGRhdGFiYXNlIHdvdWxkIHJlcGx5 IHNvbWUgaGlnaGVyIGJhbmRzIHRoYXQgcmFkaW8gd291bGQgbm90IGJlIGFibGUgdG8gcGVuZXRy YXRlIHNldmVyYWwgd2FsbHMgZm9yIHRoZSBzY2VuYXJpb3Mgc29tZSBBUHMgYXJlIGp1c3QgaW4g b25lIGJ1aWxkaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpaaHUgTGVpDQoNCg0KLS0tLS3Tyrz+1K28 /i0tLS0tDQq3orz+yMs6IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6XSANCreiy83KsbzkOiAyMDExxOo51MIxM8jVIDIxOjI3DQrK1bz+yMs6IFBldGVyIFN0YW5m b3J0aA0Ks63LzTogWmh1TGVpOyBzY290dC5wcm9iYXNjb0Bub2tpYS5jb207IHBhd3NAaWV0Zi5v cmcNCtb3zOI6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNl cyAmIHJlcXVpcmVtZW50cw0KDQpPdXIgY2hhcnRlciBzYXlzIHRoYXQgd2Ugd2lsbCBkZXZlbG9w IGEgcHJvdG9jb2wgd2hpY2ggaXMgc3BlY3RydW0gaW5kZXBlbmRlbnQgKGRpZmZlcmVudCBiYW5k cyksIHBoaSBpbmRlcGVuZGVudCAoZGlmZmVyZW50IHR5cGVzIG9mIGRldmljZXMgdXNpbmcgZGlm ZmVyZW50IG92ZXIgdGhlIGFpciBpbnRlcmZhY2VzKSBhbmQgbmF0aW9uIGluZGVwZW5kZW50Lg0K DQpUaGF0IG1lYW5zLCBhcyBQZXRlciBzYXlzLCBpbmRvb3IgYW5kIG91dGRvb3IgdXNlIHdvdWxk IGJlIGNvdmVyZWQuDQoNCkkgZG8gdGhpbmsgdGhlIHF1ZXJ5IHdpbGwgaGF2ZSBzb21lIGtpbmQg b2YgInR5cGUiIHdoaWNoIGlzIHRoZSBwaHkgaW5kZXBlbmRlbmNlLCBidXQgYWxzbyB0YWtlcyBp bnRvIGFjY291bnQgdGhlIHJlZ3VsYXRvcnMgcnVsZXMgb24gcG93ZXIsIGFudGVubmEgYW5kIG90 aGVyIHBhcmFtZXRlcnMuDQpUaGUgVVMgcnVsZXMgd29yayB0aGF0IHdheSwgYW5kIEkgZXhwZWN0 IG1hbnkgb3RoZXIgbmF0aW9ucyB3aWxsIGhhdmUgc2ltaWxhciBraW5kcyBvZiBydWxlcy4gIFlv dSBjYW4gaW1hZ2luZSBydWxlcyB3aGVyZSBtb3JlIGFudGVubmEgaW5mb3JtYXRpb24gaXMgbmVl ZGVkIGluIHRoZSBxdWVyeSB0byBkZXRlcm1pbmUgd2hhdCBzcGVjdHJ1bSBpcyBhdmFpbGFibGUs IGJ1dCBzbyBmYXIsIHRoZXJlIGFyZSBtZXJlbHkgbGltaXRzIGZvciBlYWNoIHR5cGUuDQoNCkJy aWFuDQoNCk9uIFNlcCAxMywgMjAxMSwgYXQgODoyNiBBTSwgUGV0ZXIgU3RhbmZvcnRoIHdyb3Rl Og0KDQo+IFJlZ3VsYXRpb24gb2YgVFZXUyBpcyBjdXJyZW50bHkgcHJvcG9zZWQgYnkgMyBSZWd1 bGF0b3JzLCBVUywgVUsgYW5kDQo+IENhbmFkYSwgd2l0aCB3b3JrIG9uZ29pbmcgaW4gU2luZ2Fw b3JlLCBGaW5sYW5kIGFuZCBzZXZlcmFsIG90aGVyDQo+IGNvdW50cmllcy4gVGhlcmUgYXJlIHN1 YnRsZSBkaWZmZXJlbmNlcyBpbiBhcHByb2FjaCBhbmQgcmVxdWlyZW1lbnRzIGJ1dA0KPiB0aGUg YmFzaWMgY29uY2VwdCBpcyB0aGUgc2FtZSBpbiBhbGwgY2FzZXMuIFBBV1Mgc2hvdWxkIGJlIGFi bGUgdG8gYWRkcmVzcw0KPiBhbGwgY2FzZXMuDQo+IEFsbCByZWd1bGF0b3JzIGFsbG93IGZvciBp bmRvb3IgdXNlIGFzIHdlbGwgYXMgb3V0ZG9vciB1c2UuIFBBV1Mgc2hvdWxkDQo+IGFkZHJlc3Mg YWxsIHRoZXNlIGNhc2VzLiBBbGwgcmVndWxhdG9ycyBwcm9wb3NlIHRoYXQgYSBjb21wb25lbnQg b2YgdGhlDQo+IGRlY2lzaW9uIGJlIGJhc2VkIG9uIHRoZSAiZGV2aWNlIHR5cGUiIGFsbG93aW5n IGZvciBkaWZmZXJlbnQgcmVzdWx0cw0KPiBiYXNlZCBvbiB0aGUgY2FwYWJpbGl0eSBhbmQsIGlu IHNvbWUgcmVndWxhdGlvbiwgdGhlIG1heGltdW0gcG93ZXIgb3V0cHV0DQo+IG9mIHRoZSBkZXZp Y2UuIFRoZXJlIGlzIG5vIHJlYXNvbiBQQVdTIGNhbm5vdCBhZGRyZXNzIHRoZSByZXF1aXJlbWVu dHMgZm9yDQo+IGluZG9vciB1c2UgYXMgd2VsbCBhcyBvdXRkb29yIHVzZS4gQXQgNDUwLTcwME1I eiB0aGUgaXNzdWUgb2YgY28tZXhpc3RlbmNlDQo+IGJldHdlZW4gMiBhcGFydG1lbnRzIGlzIHJl YWxseSBubyBkaWZmZXJlbnQgdGhhbiB0aGUgY28tZXhpc3RlbmNlIGJldHdlZW4NCj4gMiBvdXRk b29yIGFjY2VzcyBwb2ludHMgc2V2ZXJhbCBodW5kcmVkIG1ldGVycyBhcGFydC4gVGhhdCBzYWlk LCBpdCB3YXMgbXkNCj4gdW5kZXJzdGFuZGluZyB0aGF0IFBBV1Mgd2FzIGFsc28gZnJlcXVlbmN5 IGFuZCBtb2R1bGF0aW9uIGluZGVwZW5kZW50LA0KPiB3aGljaCBpdCBzaG91bGQgYmUuDQo+IFBl dGVyIFN0YW5mb3J0aA0KPiBTcGVjdHJ1bSBCcmlkZ2UgSW5jLg0KPg0KPiBPbiBUdWVTZXAvMTMv MTEgVHVlIFNlcCAxMywgMzowOSBBTSwgIlpodUxlaSIgPGxlaS56aHVAaHVhd2VpLmNvbT4gd3Jv dGU6DQo+DQo+PiBIaSBTY290dCBhbmQgYWxsLA0KPj4NCj4+IEZvciBzb21lIHJlYXNvbnMsIEkg dGhpbmsgdGhhdCBQQVdTIHByb3RvY29sIHdvdWxkIGJlIGRldmVsb3BlZCB3aXRoDQo+PiBxdWl0 ZSBzdGFibGUgc2NlbmFyaW8gZGVzY3JpcHRpb25zIG9mIGluZG9vciBjb3ZlcmFnZS4NCj4+DQo+ PiBBY2NvcmRpbmcgdG8gcHJldmlvdXMgZS1tYWlsIGRpc2N1c3Npb24gaW4gdGhlIGxpc3QsIGl0 IHNlZW1zIHRoYXQNCj4+IHdvcmtpbmcgZ3JvdXAgd291bGQgZGV2ZWxvcCBnZW5lcmljIGFuZCBn bG9iYWxseSBhcHBsaWNhYmxlIHNwZWN0cnVtDQo+PiBkYXRhYmFzZSBxdWVyeSBwcm90b2NvbCB3 aGljaCBob3BlbHkgaXMgYWNjZXB0ZWQgYnkgb3RoZXIgcmVndWxhdG9ycyBidXQNCj4+IG9ubHkg RkNDLiA3MDBNSHotODAwTUh6IGNhbiBiZSBzaGFyZWQgdG8gcGFydGljdWxhciB3aXJlbGVzcyBh Y2Nlc3MNCj4+IHRlY2hub2xvZ2llcyBsaWtlIDgwMi4xMSwgODAyLjIyIGFuZCBldmVuIExURS4g UGxlYXNlIGNvcnJlY3QgbWUgaWYNCj4+IHNvbWV0aGluZyB3cm9uZy4NCj4+DQo+PiBUaGUgZ2Vu ZXJpYyB1c2UgY2FzZXMgY291bGQgYmUgc2FmZSB3aGVuIGRlY2lkaW5nIHdvcmtpbmcgZ3JvdXAg ZHJhZnQuDQo+PiBCdXQgaG90c3BvdCBhbmQgdXJiYW4gaW50ZXJuZXQgY29ubmVjdGlvbiBkZXNj cmlwdGlvbiBpcyBzdGlsbCBub3QNCj4+IGNyZWRpdGFibGUgdG8gZGV2ZWxvcCBQQVdTIHByb3Rv Y29sIGZvciB0aGUgcmVhc29uIDcwME1IeiBoYXMgZmFyDQo+PiBkaWZmZXJlbnQgcHJvcGFnYXRp b24gY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIG5lZWRzIG9mIGluZG9vciBjb3ZlcmFnZQ0KPj4g YW5kIHVyYmFuIGhvdHNwb3QgdXNlIGNhc2UuIEluIGdlbmVyYWwsIGluZG9vciB1c2UgY2FzZSBz YXlzIHRoYXQNCj4+IGRhdGFiYXNlIHNob3VsZCB0byByZXNwb25zZSBwcm9wZXIgc3BlY3RydW0g aWYgQVBzIHJlcXVlc3QgY2hhbm5lbHMgZm9yDQo+PiBpbmRvb3IgSW50ZXJuZXQgY29ubmVjdGlv bi4gSWYgaXQgaXMgbm90IHBvc3NpYmxlLCByZWd1bGF0b3JzIG11c3QgdG8NCj4+IGZhY2UgcHJv YmxlbXMgb2YgaW50ZXJmZXJlbmNlIGFtb25nIEFQcyBhbmQgTWljcm8gY2VsbCBCU3MuIFRoZW4s IFBBV1MNCj4+IG5vdyBoYXMgdG8gcmVjb2duaXplIHNjZW5hcmlvIGRlc2NyaXB0aW9uIGFuZCBy ZXF1aXJlbWVudHMgYmVmb3JlIGRldmVsb3ANCj4+IHByb3RvY29sIHRoYXQgb3RoZXIgaGlnaGVy IGZyZXF1ZW50IGJhbmRzIChhdCBsZWFzdCBoaWdoZXIgdGhhbiAyLjFHSHopDQo+PiBzaG91bGQg YmUgY29uc2lkZXJlZCB0byBpbmRvb3IgY292ZXJhZ2UuIEkgd291bGQgbGlrZSB0byByZW1pbmQg dGhhdCBpcw0KPj4gZGlmZmVyZW50IG5lZWQgZm9yIGluZG9vciBjb3ZlcmFnZSBmcm9tIGdlbmVy aWMgaG90c3BvdCBhbmQgdXJiYW4NCj4+IGNvdmVyYWdlIHdoaWNoIGlzIHN0aWxsIHRvIGJlIGRp dmlkZWQuDQo+Pg0KPj4gRnJvbSBwcm90b2NvbCBwZXJzcGVjdGl2ZSwgaXQgd2lsbCBkZXBlbmQg b24gdGhlIGNvbmNsdXNpb24gb2Ygd29ya2luZw0KPj4gZ3JvdXAgd2hpY2ggSUVzIGFyZSByZXNl cnZlZCBmb3IgaW5kb29yIHF1ZXJ5IHVzYWdlcy4NCj4+DQo+PiBUaHJlZSB0aGluZ3MgYXJlIHBh cnRpY3VsYXIgZm9yIGluZG9vciBjb3ZlcmFnZSB1c2UgY2FzZSBpZiBkZXZlbG9wIFBBV1MNCj4+ IHByb3RvY29sLiBGaXJzdCBvbmUgaXMgdGhhdCB0aGUgbG9jYXRpb24gaW4gYSBidWlsZGluZyBp cyBkaWZmZXJlbnQgZnJvbQ0KPj4gR1BTIHBvc2l0aW9uaW5nLiBTZWNvbmQgb25lIGlzIHRoYXQg dGhlIGRhdGFiYXNlIHNob3VsZCBiZSBhYmxlIHRvDQo+PiBjYWxjdWxhdGUgdGhlIHByb3BlciBi YW5kIGZvciBpbmRvb3IgY292ZXJhZ2UuIFRoaXJkIG9uZSBpcyB0aGF0IGRhdGFiYXNlDQo+PiBz aG91bGQgYmUgYWJsZSB0byBjb25zaWRlciAob3IgY2FsY3VsYXRlKSBhbmQgYXZvaWQgdW5leHBl Y3RlZA0KPj4gaW50ZXJmZXJlbmNlIGFtb25nIGRpZmZlcmVudCBpbmRvb3IgQVBzIGFuZCBtaWNy byBjZWxsIEJTcy4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBaaHUgTGVpDQo+Pg0KPj4NCj4+ IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4gt6K8/sjLOiBzY290dC5wcm9iYXNjb0Bub2tpYS5jb20g W21haWx0bzpzY290dC5wcm9iYXNjb0Bub2tpYS5jb21dDQo+PiC3osvNyrG85DogMjAxMcTqOdTC OMjVIDIzOjQ5DQo+PiDK1bz+yMs6IFpodUxlaQ0KPj4gs63LzTogcGF3c0BpZXRmLm9yZw0KPj4g 1vfM4jogUmU6IFtwYXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYg cmVxdWlyZW1lbnRzDQo+Pg0KPj4gSGVsbG8gTGVpLA0KPj4NCj4+IEkgaGF2ZSBzdHVkaWVkIHRo ZSB0ZXh0IGJlbG93LCBidXQgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2UgeW91DQo+ PiBhcmUgcHJvcG9zaW5nLiBJdCBzZWVtcyB0byBtZSB0aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBh IGRlcGxveW1lbnQNCj4+IHNjZW5hcmlvICh3aGljaCBpcyBmaW5lKS4gSSBkbyBub3QgdW5kZXJz dGFuZCB3aGF0IGlzIHRoZSB1c2UgY2FzZSwgb3IgaG93DQo+PiB0aGlzIGNhc2UgaXMgZGlmZmVy ZW50IGZyb20gIkhvdHNwb3QiIHVzZSBjYXNlIChBUCBpcyBpbmRvb3IpIHdpdGggYQ0KPj4gIldp ZGUtYXJlYSBvciBydXJhbCIgdXNlIGNhc2UgZGVwbG95ZWQgaW4gdGhlIHNhbWUgZ2VuZXJhbCBh cmVhIChtaWNyb2NlbGwNCj4+IGlzIG91dGRvb3IpLg0KPj4NCj4+IEkgYW0gbm90IHNwZWFraW5n IGFnYWluc3QgdGhlIHVzZSBjYXNlLCBzaW1wbHkgc2F5aW5nIHRoYXQgSSBkb24ndA0KPj4gdW5k ZXJzdGFuZCBpdCB3ZWxsIGVub3VnaCB0byBjb21tZW50IG9uIGl0LiBJdCBtaWdodCBoZWxwIGZ1 cnRoZXINCj4+IGRpc2N1c3Npb24gaWYgeW91IGNhbiBkZXNjcmliZSBpbiBtb3JlIGRldGFpbCB0 aGUgdXNlIGNhc2UsIGFuZCBpbmNsdWRlDQo+PiBzcGVjaWZpYyBhY3Rpb25zIHRoYXQgZWFjaCBl bGVtZW50IChtaWNyb2NlbGwsIEFQLCBkZXZpY2UsIGRhdGFiYXNlLCBldGMpDQo+PiBtdXN0IGNv bXBsZXRlIGluIG9yZGVyIHRvIGRlcGxveSB0aGlzIHVzZSBjYXNlLg0KPj4NCj4+IFJlZ2FyZHMs DQo+PiBTY290dA0KPj4NCj4+DQo+PiBPbiA5LzcvMTEgODozNSBQTSwgImV4dCBaaHVMZWkiIDxs ZWkuemh1QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4NCj4+PiBIaSBhbGwsDQo+Pj4NCj4+PiBJIHRo aW5rIHRoYXQgd2UgZG8gc29tZSB3b3JrcyBvbiBpbXByb3Zpbmcgb3JpZ2luYWwgdXNlIGNhc2Ug ZHJhZnQgYnkNCj4+PiBhZGRpbmcgdGhyZWUgYWRkaXRpb25hbCB1c2UgY2FzZXMsIGluY2x1ZGlu ZyBpbmRvb3IgY292ZXJhZ2UsIGFkIGhvYw0KPj4+IG5ldHdvcmsgYW5kIGx0ZSBtYm1zIGlzc3Vl Lg0KPj4+DQo+Pj4gTm93LCBJIGFtIGFza2luZyB0byBhZGQgaW5kb29yIGNvdmVyYWdlIHNjZW5h cmlvIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3INCj4+PiBQQVdTIHByb3RvY29sIHRvIGNvbnNpZGVy IGluIG5leHQgc3RhZ2UuIFRoZSBwcm9wb3NlZCB1c2UgY2FzZSBpcyBzZWVuDQo+Pj4gYmVsb3cu IFRoZSB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBiZSBzdWJtaXR0ZWQgc29v biBieQ0KPj4+IGFkZGluZyBzb21lIHdvcmRpbmcgbW9kaWZpY2F0aW9ucy4gU28sIEkgZG9uJ3Qg dGhpbmsgd2UgYXJlIHRvIHNraXAgdGhlDQo+Pj4gYWRkaXRpb25hbCB1c2UgY2FzZXMgZXZlbiB0 aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudA0KPj4+IHByb3Bv c2FsIGhhdmUgYmVlbiBpbnRlZ3JhdGVkIG5vdy4NCj4+Pg0KPj4+ID09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+IHgueC4gIEluZG9vciB1 c2FnZSBvZiBUVldTDQo+Pj4NCj4+PiAgQXQgcHJlc2VudCwgdGhlIGluZG9vciB3aXJlbGVzcyBj b3ZlcmFnZSBlcXVpcG1lbnRzIGNvbnNpc3Qgb2YgV2ktRmktDQo+Pj4gIGxpa2UgYWNjZXNzIHBv aW50cyBhbmQgbWljcm8gY2VsbHMsIGFsbCBvZiB0aGVzZSB1dGlsaXplIHNlZ21lbnRzIG9mDQo+ Pj4gIGZyZXF1ZW5jeSwgZm9ybWVyIGF0IGFib3V0IDIuNEdIeiBvciA1R2h6IGFuZCB0aGUgbGF0 dGVyLCBmb3INCj4+PiAgZXhhbXBsZSwgODAyLjExbiBhdCBhYm91dCAyLjRHSHouICBBcyBhIHJl c3VsdCBvZiB0aGUgYmxvY2sgb2YNCj4+PiAgYnVpbGRpbmdzIGFuZCBvdGhlciBvYnN0cnVjdGlv biBhbmQgaW50ZXJmZXJlY2UsIGl0IG1heSBub3QgYmUgdGhhdA0KPj4+ICBvcHRpbWlzdGljIHdo ZW4gODAyLjExIGRldmljZXMgZXhhbWluZSB0aGUgc3RhdHVzIG9mIHdpcmVsZXNzDQo+Pj4NCj4+ Pg0KPj4+DQo+Pj4gWmh1ICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyLCAy MDEyICAgICAgICAgICAgICAgIFtQYWdlIDNdDQo+Pj4NCj4+Pg0KPj4+IEludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgUEFXUyB1c2UgY2FzZXMgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAx MQ0KPj4+DQo+Pj4NCj4+PiAgaW50ZXJmZXJlcy4gIFRoaXMgdXNlIGNhc2UgdGFrZXMgdGhlIGJl bmVmaXQgb2YgVFYgV2hpdGUgU3BhY2UgdG8NCj4+PiAgcHJvdmlkZSBhZGRpdGlvbmFsIGNhcGFj aXR5IHRvIGluZG9vciBjb3ZlcmFnZSBhbmQgcmVkdWNlIGNoYW5uZWwNCj4+PiAgaW50ZXJmZXJl Y2UuDQo+Pj4NCj4+PiAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlIGRlcGxveW1l bnQgb2YgdGhpcyBzY2VuYXJpby4NCj4+Pg0KPj4+ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4gICAgICAgICAgICAgIHwgICAgICAgICAgICBpbmRv b3IgICAgICAgICAgICAgIHwNCj4+PiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KPj4+ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQo+Pj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCj4+PiAgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgIHdoaXRlIHNwYWNlICAgICAg fCAgICstLS0tLS0tLS0tLS0tKw0KPj4+ICAgICAgICAgICAgICB8ICAgIHxEZXZpY2V8IC0gLSAt IC0gLSAtIC0gLSAtIC18LSAtfCBNaWNybyBjZWxsICB8DQo+Pj4gICAgICAgICAgICAgIHwgICAg Ky0tLS0tLSsgIFwgICAgICAgICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsNCj4+PiAgICAg ICAgICAgICAgfCAgICArLS0tLS0tKyAgIFx3aGl0ZSBzcGFjZSAgICAgfCAgICAgKC0tLS0tKQ0K Pj4+ICAgICAgICAgICAgICB8ICAgIHxEZXZpY2V8ICAgIFwgKy0tLS0tLS0tLS0tLSt8ICAgIC8g ICAgICAgXA0KPj4+ICAgICAgICAgICAgICB8ICAgICstLS0tLS0rICAgICAgfGFjY2VzcyBwb2lu dHx8PT09KCBJbnRlcm5ldCkNCj4+PiAgICAgICAgICAgICAgfCAgICAgICAgbyAgICAgICAvICst LS0tLS0tLS0tLS0rfCAgICBcICAgICAgIC8NCj4+PiAgICAgICAgICAgICAgfCAgICAgICAgbyAg ICAgIC8gICAgICAgICAgICAgICAgfCAgICAgKC0tLS0tKQ0KPj4+ICAgICAgICAgICAgICB8ICAg ICAgICBvICAgICAvICAgICAgICAgICAgICAgICB8DQo+Pj4gICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+PiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+DQo+Pj4NCj4+PiAgICAgICAgICAgICAgICAgICAg ICBHcmFwaCAxIEluZG9vciB1c2FnZSBvZiBUVldTDQo+Pj4NCj4+PiAgVGhlIGFjY2VzcyBwb2lu dCBjb3VsZCBiZSBhIFdJLUZJIHJvdXRlciwgYW5kIHRoZSBtaWNybyBjZWxsIGlzIGENCj4+PiAg c2hvcnQgcmFuZ2Ugd2lyZWxlc3MgY292ZXJhZ2UoZS5nLiBpbiByYW5nZSBvZiAwLTUwbSkgYmFz ZSBzdGF0aW9uLA0KPj4+ICBib3RoIG9mIHRoZW0gYWN0IGFzIG1hc3RlciBkZXZpY2VzLCBxdWVy eWluZyB0aGUgaW50ZXJuZXQgY29ubmVjdGVkDQo+Pj4gIGRhdGFiYXNlIGZvciBhdmFpbGFibGUg d2hpdGUgc3BhY2Ugc3BlY3RydW0gYmFzZWQgb24gaXRzIGdlby0NCj4+PiAgbG9jYXRpb24sIGFu ZCBwcm92aWRpbmcgVFZXUyBhY2Nlc3MgdG8gaW5kb29yIHVzZXIuDQo+Pj4NCj4+PiAgVGhlIFRW V1Mgc3BlY3RydW0gaGFzIGRpZmZlcmVudCBwcm9wYWdhdGlvbiBjaGFyYWN0ZXJpc3RpY3MgY29t cGFyZWQNCj4+PiAgdG8gaGlnaGVyIGZyZXF1ZW5jeSBiYW5kLCBmb3IgZXhhbXBsZSwgdGhlIHRy YW5zbWlzc2lvbiBkaXN0YW5jZQ0KPj4+ICB1c2luZyBUVldTIGNhbiBiZSBzZXZlcmFsIHRpbWVz IGxvbmdlciB0aGFuIHRob3NlIGluIHRoZSBoaWdoZXIgYmFuZC4NCj4+PiAgSW4gdGhpcyBjYXNl LCBnb29kIHBlbmV0cmF0aW9uIGNoYXJhY3RlcmlzdGljIG9mIFRWV1MgbWFrZXMgaXQNCj4+PiAg ZGlmZmljdWx0IHRvIGxvY2sgdGhlIHNpZ25hbHMgaW4gdGhlIHJvb20sIHRoZW4gZGlmZmljdWx0 IHRvIGxvY2FsaXplDQo+Pj4gIGFuZCBkaWZmZXJlbnRpYXRlIHNpZ25hbHMsIGFuZCBmaW5hbGx5 IGNhdXNlIGludGVyZmVyZXMgYW1vbmcNCj4+PiAgbmVpZ2hib3JpbmcgbmV0d29ya3MuICBSZXF1 aXJlbWVudHMgdG8gaW5kb29yIFdTIGRhdGViYXNlIHVzYWdlIHdvdWxkDQo+Pj4gIGJlOg0KPj4+ DQo+Pj4NCj4+PiAgMS4gIEEgZnJlcXVlbmN5IHByb3RlY3Rpb24gZ2FwIGJldHdlZW4gbmVpZ2hi b3JzKHBhcnRpY3VsYXIgc3BlY3RydW0NCj4+PiAgICAgIGFsbG9jYXRpb24gYWxnb3JpdGhtIGlz IG5lZWRlZCBoZXJlKS4NCj4+Pg0KPj4+ICAyLiAgbG93ZXIgb3V0cHV0IHBvd2VyIG9mIEFQL21p Y3JvIGNlbGwsIGl0IHNlZW1zIHRoYXQgb25seSBjZXJ0YWluDQo+Pj4gICAgICBwaWNvIG9yIGZl bXRvIGNlbGxzIGJlIGZlYXNpYmxlIGhlcmUuDQo+Pj4NCj4+PiAgMy4gIFBBV1MgbXVzdCBub3Qg YmUgdGllZCB0byBhIHNwZWNpZmljIGZyZXF1ZW5jeSBiYW5kLg0KPj4+DQo+Pj4gIDQuICBQQVdT IG11c3QgcmVzcG9uc2UgdGhlIHByb3BlciBmcmVxdWVuY3kgYmFuZCBsaXN0IHRvIHBhcnRpY3Vs YXINCj4+PiAgICAgIGNvdmVyYWdlIHdoaXRlIHNwYWNlIGRldmljZXMuDQo+Pj4NCj4+PiAgNS4g IE1hc3RlciBkZXZpY2VzIHNob3VsZCBzdXBwb3J0IHBvd2VyIGNvbnRyb2wuDQo+Pj4NCj4+PiAg Ni4gIFNsYXZlIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29udHJvbC4NCj4+Pg0KPj4+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K Pj4+DQo+Pj4gWmh1IExlaQ0KPj4+DQo+Pj4NCj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+PiC3 orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBHZXJhbGQNCj4+PiBDaG91aW5hcmQNCj4+PiC3osvNyrG85DogMjAxMcTqOdTCOMjV IDg6MDENCj4+PiDK1bz+yMs6IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj4+ILOty806IHBhd3NA aWV0Zi5vcmcNCj4+PiDW98ziOiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50 LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4+Pg0KPj4+IEdhYm9yLA0KPj4+DQo+Pj4gQ2Fu IEkgYXNrIHRoYXQgdGhlIHRleHQgbW9kaWZpY2F0aW9ucyB0aGF0IEkgaGF2ZSBzdWJtaXR0ZWQg dG8gc2NvdHQgYW5kDQo+Pj4gY29waWVkIHRvIHRoZSBwYXdzIHJlZmxlY3RvciBpbiBteSBlbWFp bCBkYXRlZCA4IEF1Z3VzdCBiZSBpbmNsdWRlZCBhcw0KPj4+IHdlbGw/DQo+Pj4NCj4+PiBUaGFu aydzLA0KPj4+DQo+Pj4gR2VyYWxkDQo+Pj4NCj4+Pg0KPj4+IEF0IDIwOjMyIDA3LTA5LTExICsw MDAwLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+Pj4+IE9rLCBsZXQncyB0cnkgdGhh dCB0aGVuLg0KPj4+PiBTY290dCwgY2FuIHlvdSBwdXQgdXNlIGNhc2VzIGJlZm9yZSBQUywgYW5k IGFkZCB0aGUgYWQtaG9jIHVzZSBjYXNlLiBJDQo+Pj4+IGp1c3Qgc2Nhbm5lZCB0aHJvdWdoIHRo ZSBsaXN0IGFuZCBzcG90dGVkIHRoYXQgVGVjbyBpbmRlZWQgcHJvdmlkZWQgYQ0KPj4+PiBkZXNj cmlwdGlvbiBmb3IgdGhhdCB1c2UgY2FzZSBvbiBBdWcgM3JkLg0KPj4+PiBBbmQgc3VibWl0IHRo ZSBkcmFmdCBhcyBhIHdnIGl0ZW0sIHVubGVzcyB0aGVyZSBhcmUgc3RpbGwgb2JqZWN0aW9ucy4N Cj4+Pj4NCj4+Pj4gLUdhYm9yDQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+IEZyb206IGV4dCBOYW5jeSBCcmF2aW4gW21haWx0bzpuYnJhdmluQGVhcnRobGluay5u ZXRdDQo+Pj4+IFNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTEgMzo0MSBQTQ0KPj4+ PiBUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KQ0KPj4+PiBDYzogVGVj byBCb290OyBHZXJhbGQgQ2hvdWluYXJkOyBwYXdzQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJl OiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVt ZW50cw0KPj4+Pg0KPj4+PiBEZWFyIEdhYm9yIGFuZCBBbGwsDQo+Pj4+DQo+Pj4+IEkgdGhpbmsg aXQgaXMgYXBwcm9wcmlhdGUgdG8gcHV0IHRoZSB1c2UgY2FzZXMgYmVmb3JlIHRoZSBQUyBmb3Ig b2J2aW91cw0KPj4+PiByZWFzb25zLCBhbmQgaW5jbHVkaW5nIHRoZSAicHJveHkiIG5lZWQgaW4g dGhlIGZpcnN0IGRyYWZ0LiBJIHN1cHBvcnQNCj4+Pj4gaW5jbHVkaW5nIGJvdGggR2VyYWxkJ3Mg c3VnZ2VzdGlvbnMgYW5kIFRlY28ncyBwcm9wb3NhbCBpbiB0aGUgb3JpZ2luYWwNCj4+Pj4gZHJh ZnQgYW5kIG5vdCB3YWl0aW5nIHVudGlsIGEgbGF0ZXIgdGltZS4gSXQgaXMgdGhlIHByb3BlciBv cmRlciwNCj4+Pj4gaW5jbHVzaXZlIGFuZCBuZWVkZWQgaW4gdGhlIGluaXRpYWwgZHJhZnQgaW4g bXkgb3Bpbmlvbi4gSSBiZWxpZXZlIHdpdGgNCj4+Pj4gdGhlIHRhbGVudCBpbiB0aGUgZ3JvdXAg aXQgd2lsbCBub3QgdGFrZSBsb25nIHRvIGFjY29tcGxpc2ggdGhpcyBhbmQgeW91DQo+Pj4+IHdp bGwgaGF2ZSBhIG1vcmUgY29oZXNpdmUgZHJhZnQuDQo+Pj4+DQo+Pj4+IFNJbmNlcmVseSwgTmFu Y3kNCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gU2VwIDIsIDIwMTEsIGF0IDI6MTkgUE0sIDxHYWJvci5C YWprb0Bub2tpYS5jb20+DQo+Pj4+IDxHYWJvci5CYWprb0Bub2tpYS5jb20+IHdyb3RlOg0KPj4+ Pg0KPj4+Pj4gVGVjbywgR2VyYWxkLA0KPj4+Pj4NCj4+Pj4+IFRoYW5rcyBmb3IgdGhlIGZlZWRi YWNrLiBJJ2Qgc3VnZ2VzdCB0aGF0IHdlIG1ha2UgdGhpcyBkcmFmdCBhIFdHDQo+Pj4+IGl0ZW0s DQo+Pj4+IHdpdGggR2VyYWxkJ3MgcHJvcG9zZWQgY2hhbmdlcyBpbiBpdC4gUmVnYXJkaW5nIHRo ZSBvcmRlciBvZiB0aGUNCj4+Pj4gcHJvYmxlbQ0KPj4+PiBzdGF0ZW1lbnQgdnMgdXNlIGNhc2Vz LCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGxlYXZlIGl0IGFzIGl0IGlzDQo+Pj4+IChidXQN Cj4+Pj4gd2UgY2FuIGFsd2F5cyBjaGFuZ2UgaXQsIGlmIHRoYXQgaXMgd2hhdCB0aGUgV0cgd2Fu dHMpLg0KPj4+Pj4NCj4+Pj4+IFNvLCBJJ2QgYXNrIFNjb3R0IHRvIHN1Ym1pdCBhIFdHIHZlcnNp b24gb2YgdGhpcyBkcmFmdCwgdGhlbiBoYXZlDQo+Pj4+IHNvbWVvbmUgY29tZSB1cCB3aXRoIHRl eHQgZm9yIHRoaXMgYWQtaG9jIG5ldHdvcmsgc2NlbmFyaW8sIGhhdmUgdGhlIFdHDQo+Pj4+IGFn cmVlIHdpdGggdGhlIHRleHQgYW5kIGluY2x1ZGUgaXQgaW4gb25lIG9mIHRoZSBzdWJzZXF1ZW50 IHZlcnNpb25zLg0KPj4+PiBUZWNvLCB3b3VsZCB5b3Ugd3JpdGUgdXAgc29tZSB0ZXh0IGZvciB0 aGlzIGFkLWhvYyB1c2UgY2FzZSB0aGUgV0cNCj4+Pj4gY291bGQNCj4+Pj4gZGlzY3Vzcz8NCj4+ Pj4+DQo+Pj4+PiBXZSdsbCBhbHNvIHNlbmQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgbGlzdCBv ZiByZXF1aXJlbWVudHMgdG8gdGhlDQo+Pj4+IGxpc3QgbmV4dCB3ZWVrLg0KPj4+Pj4NCj4+Pj4+ IC0gR2Fib3INCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4+IEZyb206IGV4dCBUZWNvIEJvb3QgW21haWx0bzp0ZWNvQGluZi1uZXQubmxdDQo+Pj4+ PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAxLCAyMDExIDExOjA2IFBNDQo+Pj4+PiBUbzog QmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KQ0KPj4+Pj4gQ2M6IHBhd3NAaWV0 Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1l bnQsIHVzZSBjYXNlcyAmDQo+Pj4+PiByZXF1aXJlbWVudHMNCj4+Pj4+DQo+Pj4+PiBJIHRoaW5r IHRoZSBkb2MgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50LiBJIHN1cHBvcnQgYWRvcHRpb24uDQo+ Pj4+Pg0KPj4+Pj4gSSBzdWdnZXN0IHJlb3JkZXJpbmc6IHNwZWNpZnlpbmcgcHJvYmxlbSBzdGF0 ZW1lbnQgYWZ0ZXIgaW50cm9kdWNpbmcNCj4+Pj4gdGhlIHVzZSBjYXNlcy4NCj4+Pj4+DQo+Pj4+ PiBTb21lIGFza2VkIGZvciB0aGUgYWQgaG9jIG5ldHdvcmsgc2NlbmFyaW8uIFRoaXMgaW5jbHVk ZXMgbWUgOi0pLg0KPj4+PiBUaGlzDQo+Pj4+IGlzIGltcG9ydGFudCwgYmVjYXVzZSBpdCBkZW1v bnN0cmF0ZXMgdGhlIG5lZWQgZm9yICJwcm94eSIuDQo+Pj4+PiBCVFcsIEkgd29uZGVyIHdoeSBz aW1pbGFyIHNjZW5hcmlvIGRvZXNuJ3QgcG9wIHVwIGZyb20gV2lGaQ0KPj4+PiBkZXBsb3ltZW50 cy4gVXNhZ2Ugb2YgY29udHJvbGxlcnMgaW4gbGFyZ2Ugc2l0ZXMgaXMgbm90IHVuY29tbW9uLiBO b3QNCj4+Pj4gdG8NCj4+Pj4gbWVudGlvbiAxMXMuDQo+Pj4+Pg0KPj4+Pj4gVGhlIHJlcXVpcmVt ZW50cyBpcyBsZWZ0IG9wZW4uIEknbSBsb29raW5nIGZvcndhcmQgc2VlIHNvbWUgZHJhZnQNCj4+ Pj4gdGV4dC4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsIFRlY28NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g T3AgMzAgYXVnIDIwMTEsIG9tIDE5OjQyIGhlZWZ0IDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+ Pj4+IDxHYWJvci5CYWprb0Bub2tpYS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPj4+ Pj4NCj4+Pj4+PiBJIHNlbnQgdGhpcyBlbWFpbCB0byB0aGUgbGlzdCBvbmUgd2VlayBhZ28sIGFz a2luZyBmb3IgZmVlZGJhY2sgb24NCj4+Pj4+Pg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LXByb2Jhc2NvLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXQNCj4+Pj4+PiBz IC0wMC50eHQgYnV0IHRoZXJlIHdhcyBub3Qgb25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJIHRha2Ug dGhhdCBhcw0KPj4+Pj4+IHBlb3BsZSBoYXZlIG5vIGNvbW1lbnRzIHRvIHRoZSBkcmFmdCBhdCB0 aGlzIHRpbWUuDQo+Pj4+Pj4NCj4+Pj4+PiBBbmQgSSBhbSBhc2tpbmcgYWdhaW46IGlzIHRoZXJl IGFueSBvYmplY3Rpb24gaW4gYWRvcHRpbmcgdGhlIGFib3ZlDQo+Pj4+IGRyYWZ0IGFzIGEgd2cg ZG9jdW1lbnQ/DQo+Pj4+Pj4NCj4+Pj4+PiAtR2Fib3INCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+Pj4+PiBPZiBleHQgR2Fi b3IuQmFqa29Abm9raWEuY29tDQo+Pj4+Pj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEg Mjo0MyBQTQ0KPj4+Pj4+IFRvOiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtw YXdzXSBjb21iaW5lZCBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYNCj4+Pj4+PiByZXF1 aXJlbWVudHMNCj4+Pj4+Pg0KPj4+Pj4+IER1cmluZyB0aGUgUXVlYmVjIHNlc3Npb24sIHdlIGhh ZCBwcmVzZW50YXRpb25zIG9mIHRoZSBQUyBhbmQgdGhlDQo+Pj4+IHVzZQ0KPj4+PiBjYXNlcyBk cmFmdHMuIFRoZSB3ZyB0aGVuIGRlY2lkZWQgaXQgd2FudHMgdG8gc2VlIHRoZXNlIGRyYWZ0cyBt ZXJnZWQNCj4+Pj4gaW50byBvbmUuIFNjb3R0IGp1c3QgZGlkIHRoYXQgYW5kIHBvc3RlZCB0aGUg bWVyZ2VkIGRyYWZ0Og0KPj4+Pj4+DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt cHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4+Pj4+IHMNCj4+Pj4+ PiAtMDAudHh0DQo+Pj4+Pj4NCj4+Pj4+PiBOb3cgSSB3b3VsZCBsaWtlIHRvIGFzayBpZiB0aGUg d2cgZmVlbHMgbGlrZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5DQo+Pj4+IHRvDQo+Pj4+IGJlIGFk b3B0ZWQgYXMgYSB3ZyBkb2N1bWVudC4gUGxlYXNlIHNlbmQgeW91ciBmZWVkYmFjayBhbmQgaHVt IHRvIHRoZQ0KPj4+PiBsaXN0IGJ5IHRoaXMgdGltZSBuZXh0IHdlZWsuDQo+Pj4+Pj4NCj4+Pj4+ PiAtR2Fib3INCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+IC0NCj4+ Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+PiBGcm9tOiBQcm9i YXNjbyBTY290dA0KPj4+Pj4+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDIyLCAyMDExIDk6MTggQU0N Cj4+Pj4+PiBUbzogcGF3c0BpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IGNvbWJpbmVkIHByb2Js ZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4+Pj4+Pg0KPj4+Pj4+IEhp LA0KPj4+Pj4+DQo+Pj4+Pj4gQWNjb3JkaW5nIHRvIHRoZSByZXN1bHRzIG9mIHRoZSBmYWNlLXRv LWZhY2UgbWVldGluZywgd2UgaGF2ZQ0KPj4+PiBjb21iaW5lZA0KPj4+PiB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQgSS1EIGFuZCB1c2UgY2FzZSAmIHJlcXVpcmVtZW50IEktRCBpbnRvIGEgc2luZ2xl DQo+Pj4+IEktRC4gIFlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWVkLg0KPj4+Pj4+DQo+Pj4+Pj4g UmVnYXJkcywNCj4+Pj4+PiBTY290dA0KPj4+Pj4+DQo+Pj4+Pj4gVVJMOg0KPj4+Pj4+DQo+Pj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJvYmFzY28tcGF3cy1wcm9ibGVtLXN0bXQt dXNlY2FzZXMtcnFtdA0KPj4+Pj4+IHMNCj4+Pj4+PiAtMDAudHh0DQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+IFBvcnRpb25zIG9mIHRoZSByYWRpbyBzcGVjdHJ1bSB0 aGF0IGFyZSBhbGxvY2F0ZWQgdG8gYSBsaWNlbnNlZCwNCj4+Pj4+PiBwcmltYXJ5IHVzZXIgYnV0 IGFyZSB1bnVzZWQgb3IgdW5vY2N1cGllZCBhdCBzcGVjaWZpYyBsb2NhdGlvbnMgYW5kDQo+Pj4+ Pj4gdGltZXMgYXJlIGRlZmluZWQgYXMgJ3doaXRlIHNwYWNlJy4gIFRoZSBjb25jZXB0IG9mIGFs bG93aW5nDQo+Pj4+Pj4gc2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgKGxpY2Vuc2VkIG9yIHVubGlj ZW5zZWQpIGluIHdoaXRlIHNwYWNlIGlzIGENCj4+Pj4+PiB0ZWNobmlxdWUgdG8gJ3VubG9jaycg ZXhpc3Rpbmcgc3BlY3RydW0gZm9yIG5ldyB1c2UuICBBbiBvYnZpb3VzDQo+Pj4+Pj4gcmVxdWly ZW1lbnQgaXMgdGhhdCB0aGVzZSBzZWNvbmRhcnkgdHJhbnNtaXNzaW9ucyBkbyBub3QgaW50ZXJm ZXJlDQo+Pj4+Pj4gd2l0aCB0aGUgcHJpbWFyeSB1c2Ugb2YgdGhlIHNwZWN0cnVtLiAgT25lIGFw cHJvYWNoIHRvIHVzaW5nIHRoZQ0KPj4+Pj4+IHdoaXRlIHNwYWNlIHNwZWN0cnVtIGF0IGEgZ2l2 ZW4gdGltZSBhbmQgbG9jYXRpb24gaXMgdG8gdmVyaWZ5IHdpdGgNCj4+Pj4gYQ0KPj4+Pj4+IGRh dGFiYXNlIGF2YWlsYWJsZSBjaGFubmVscy4NCj4+Pj4+Pg0KPj4+Pj4+IFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBjb25jZXB0IG9mIFRWIFdoaXRlIFNwYWNlcy4gIEl0IGFsc28NCj4+Pj4+ PiBkZXNjcmliZXMgdGhlIHByb2JsZW1zIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgZm9yIGVu YWJsaW5nIHRoZQ0KPj4+PiB1c2UNCj4+Pj4+PiBvZiB0aGUgcHJpbWFyeSB1c2VyIG93bmVkIHdo aXRlIHNwYWNlIHNwZWN0cnVtIGZvciBzZWNvbmRhcnkgdXNlcnMsDQo+Pj4+Pj4gd2l0aG91dCBj YXVzaW5nIGludGVyZmVyZW5jZSwgYnkgcXVlcnlpbmcgYSBkYXRhYmFzZSB3aGljaCBrbm93cyB0 aGUNCj4+Pj4+PiBjaGFubmVsIGF2YWlsYWJpbGl0eSBhdCBhbnkgZ2l2ZW4gbG9jYXRpb24gYW5k IHRpbWUuICBBIG51bWJlciBvZg0KPj4+Pj4+IHBvc3NpYmxlIHVzZSBjYXNlcyBvZiB0aGlzIHNw ZWN0cnVtIGFuZCBkZXJpdmVkIHJlcXVpcmVtZW50cyBhcmUNCj4+Pj4gYWxzbw0KPj4+Pj4+IGRl c2NyaWJlZC4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBwYXdzQGll dGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdz DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+DQo+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcGF3cyBtYWlsaW5n IGxpc3QNCj4+PiBwYXdzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NAaWV0Zi5vcmcNCj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcGF3cyBtYWls aW5nIGxpc3QNCj4+IHBhd3NAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBwYXdzIG1haWxpbmcgbGlzdA0KPiBwYXdzQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQo= From teco@inf-net.nl Wed Sep 14 03:05: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 AD9A921F8C08 for ; Wed, 14 Sep 2011 03:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 2Y8cFzX2-unH for ; Wed, 14 Sep 2011 03:05:42 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A55E621F8BFB for ; Wed, 14 Sep 2011 03:05:40 -0700 (PDT) Received: by eye4 with SMTP id 4so893123eye.31 for ; Wed, 14 Sep 2011 03:07:49 -0700 (PDT) Received: by 10.213.34.77 with SMTP id k13mr163091ebd.120.1315994868730; Wed, 14 Sep 2011 03:07:48 -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 b3sm7945655eec.7.2011.09.14.03.07.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 03:07:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Teco Boot In-Reply-To: <470F27D1263A1B4EB73491ED995DE62539C667@szxeml504-mbx.china.huawei.com> Date: Wed, 14 Sep 2011 12:07:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35D7EFC3-8EBD-428A-B579-8C4D783ED7BB@neustar.biz> <470F27D1263A1B4EB73491ED995DE62539C667@szxeml504-mbx.china.huawei.com> To: ZhuLei X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" 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: Wed, 14 Sep 2011 10:05:43 -0000 Hi, Aren't you describing an AP - WiFi Controller setup, and a protocol for = such? The controller can optimize spectrum usage for "slave" AP's, and = can perform a proxy for the AP's for getting spectrum. This can be done = in distributed way also, but I am not aware of such deployment. Teco Op 14 sep 2011, om 11:08 heeft ZhuLei het volgende geschreven: > Hi, >=20 > No doubt that PAWS is spectrum independent, air interface technologies = independent and nation independent protocol which would have some = essential parameters in query request like "location", "type" and = maximum power limits. I used to think that PAWS is even extendable for = some additional rule if there is. Such supported or extendable = information in a query request would provide information to for database = to reply available bands. That is original concept of PAWS when I used = to listen. >=20 > For interference issue, I think that APs indoor are more flexible to = limit the output power, but it is difficult to limit power output of = outdoor access points which cover over hundreds meters. So, the database = is likely to reply other spectrum to indoor APs if the spectrum is = already covered by other outdoor AP(s). The conclusion of the indoor APs = could be complicated more since sometimes power control works when = interference happens, but interference avoidance is still very useful in = a number of cases. 802.11 has "interference avoidance" is basically to = use different "channel" in case that more than one APs work in an area. = My opinion is that it is very helpful if database would reply some = higher bands that radio would not be able to penetrate several walls for = the scenarios some APs are just in one building. >=20 > Best regards, > Zhu Lei >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C213=C8=D5 21:27 > =CA=D5=BC=FE=C8=CB: Peter Stanforth > =B3=AD=CB=CD: ZhuLei; scott.probasco@nokia.com; paws@ietf.org > =D6=F7=CC=E2: Re: [paws] combined problem statement, use cases & = requirements >=20 > Our charter says that we will develop a protocol which is spectrum = independent (different bands), phi independent (different types of = devices using different over the air interfaces) and nation independent. >=20 > That means, as Peter says, indoor and outdoor use would be covered. >=20 > I do think the query will have some kind of "type" which is the phy = independence, but also takes into account the regulators rules on power, = antenna and other parameters. > The US rules work that way, and I expect many other nations will have = similar kinds of rules. You can imagine rules where more antenna = information is needed in the query to determine what spectrum is = available, but so far, there are merely limits for each type. >=20 > Brian >=20 > On Sep 13, 2011, at 8:26 AM, Peter Stanforth wrote: >=20 >> Regulation of TVWS is currently proposed by 3 Regulators, US, UK and >> Canada, with work ongoing in Singapore, Finland and several other >> countries. There are subtle differences in approach and requirements = but >> the basic concept is the same in all cases. PAWS should be able to = address >> all cases. >> All regulators allow for indoor use as well as outdoor use. PAWS = should >> address all these cases. All regulators propose that a component of = the >> decision be based on the "device type" allowing for different results >> based on the capability and, in some regulation, the maximum power = output >> of the device. There is no reason PAWS cannot address the = requirements for >> indoor use as well as outdoor use. At 450-700MHz the issue of = co-existence >> between 2 apartments is really no different than the co-existence = between >> 2 outdoor access points several hundred meters apart. That said, it = was my >> understanding that PAWS was also frequency and modulation = independent, >> which it should be. >> Peter Stanforth >> Spectrum Bridge Inc. >>=20 >> On TueSep/13/11 Tue Sep 13, 3:09 AM, "ZhuLei" = wrote: >>=20 >>> Hi Scott and all, >>>=20 >>> For some reasons, I think that PAWS protocol would be developed with >>> quite stable scenario descriptions of indoor coverage. >>>=20 >>> According to previous e-mail discussion in the list, it seems that >>> working group would develop generic and globally applicable spectrum >>> database query protocol which hopely is accepted by other regulators = but >>> only FCC. 700MHz-800MHz can be shared to particular wireless access >>> technologies like 802.11, 802.22 and even LTE. Please correct me if >>> something wrong. >>>=20 >>> The generic use cases could be safe when deciding working group = draft. >>> But hotspot and urban internet connection description is still not >>> creditable to develop PAWS protocol for the reason 700MHz has far >>> different propagation characteristics from the needs of indoor = coverage >>> and urban hotspot use case. In general, indoor use case says that >>> database should to response proper spectrum if APs request channels = for >>> indoor Internet connection. If it is not possible, regulators must = to >>> face problems of interference among APs and Micro cell BSs. Then, = PAWS >>> now has to recognize scenario description and requirements before = develop >>> protocol that other higher frequent bands (at least higher than = 2.1GHz) >>> should be considered to indoor coverage. I would like to remind that = is >>> different need for indoor coverage from generic hotspot and urban >>> coverage which is still to be divided. >>>=20 >>> =46rom protocol perspective, it will depend on the conclusion of = working >>> group which IEs are reserved for indoor query usages. >>>=20 >>> Three things are particular for indoor coverage use case if develop = PAWS >>> protocol. First one is that the location in a building is different = from >>> GPS positioning. Second one is that the database should be able to >>> calculate the proper band for indoor coverage. Third one is that = database >>> should be able to consider (or calculate) and avoid unexpected >>> interference among different indoor APs and micro cell BSs. >>>=20 >>> Best regards, >>> Zhu Lei >>>=20 >>>=20 >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: scott.probasco@nokia.com = [mailto:scott.probasco@nokia.com] >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C28=C8=D5 23:49 >>> =CA=D5=BC=FE=C8=CB: ZhuLei >>> =B3=AD=CB=CD: paws@ietf.org >>> =D6=F7=CC=E2: Re: [paws] combined problem statement, use cases & = requirements >>>=20 >>> Hello Lei, >>>=20 >>> I have studied the text below, but I do not understand the use case = you >>> are proposing. It seems to me that you are describing a deployment >>> scenario (which is fine). I do not understand what is the use case, = or how >>> this case is different from "Hotspot" use case (AP is indoor) with a >>> "Wide-area or rural" use case deployed in the same general area = (microcell >>> is outdoor). >>>=20 >>> I am not speaking against the use case, simply saying that I don't >>> understand it well enough to comment on it. It might help further >>> discussion if you can describe in more detail the use case, and = include >>> specific actions that each element (microcell, AP, device, database, = etc) >>> must complete in order to deploy this use case. >>>=20 >>> Regards, >>> Scott >>>=20 >>>=20 >>> On 9/7/11 8:35 PM, "ext ZhuLei" wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I think that we do some works on improving original use case draft = by >>>> adding three additional use cases, including indoor coverage, ad = hoc >>>> network and lte mbms issue. >>>>=20 >>>> Now, I am asking to add indoor coverage scenario which is necessary = for >>>> PAWS protocol to consider in next stage. The proposed use case is = seen >>>> below. The updated version of this draft is to be submitted soon by >>>> adding some wording modifications. So, I don't think we are to skip = the >>>> additional use cases even the problem statement, use case and = requirement >>>> proposal have been integrated now. >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>> x.x. Indoor usage of TVWS >>>>=20 >>>> At present, the indoor wireless coverage equipments consist of = Wi-Fi- >>>> like access points and micro cells, all of these utilize segments = of >>>> frequency, former at about 2.4GHz or 5Ghz and the latter, for >>>> example, 802.11n at about 2.4GHz. As a result of the block of >>>> buildings and other obstruction and interferece, it may not be that >>>> optimistic when 802.11 devices examine the status of wireless >>>>=20 >>>>=20 >>>>=20 >>>> Zhu Expires February 2, 2012 = [Page 3] >>>>=20 >>>>=20 >>>> Internet-Draft PAWS use cases August = 2011 >>>>=20 >>>>=20 >>>> interferes. This use case takes the benefit of TV White Space to >>>> provide additional capacity to indoor coverage and reduce channel >>>> interferece. >>>>=20 >>>> The figure below shows an example deployment of this scenario. >>>>=20 >>>> +--------------------------------+ >>>> | indoor | >>>> | | >>>> +--------------------------------+ >>>> | | >>>> | +------+ white space | +-------------+ >>>> | |Device| - - - - - - - - - -|- -| Micro cell | >>>> | +------+ \ | +-------------+ >>>> | +------+ \white space | (-----) >>>> | |Device| \ +------------+| / \ >>>> | +------+ |access point||=3D=3D=3D( Internet) >>>> | o / +------------+| \ / >>>> | o / | (-----) >>>> | o / | >>>> | | >>>> +--------------------------------+ >>>>=20 >>>>=20 >>>> Graph 1 Indoor usage of TVWS >>>>=20 >>>> The access point could be a WI-FI router, and the micro cell is a >>>> short range wireless coverage(e.g. in range of 0-50m) base station, >>>> both of them act as master devices, querying the internet connected >>>> database for available white space spectrum based on its geo- >>>> location, and providing TVWS access to indoor user. >>>>=20 >>>> The TVWS spectrum has different propagation characteristics = compared >>>> to higher frequency band, for example, the transmission distance >>>> using TVWS can be several times longer than those in the higher = band. >>>> In this case, good penetration characteristic of TVWS makes it >>>> difficult to lock the signals in the room, then difficult to = localize >>>> and differentiate signals, and finally cause interferes among >>>> neighboring networks. Requirements to indoor WS datebase usage = would >>>> be: >>>>=20 >>>>=20 >>>> 1. A frequency protection gap between neighbors(particular = spectrum >>>> allocation algorithm is needed here). >>>>=20 >>>> 2. lower output power of AP/micro cell, it seems that only certain >>>> pico or femto cells be feasible here. >>>>=20 >>>> 3. PAWS must not be tied to a specific frequency band. >>>>=20 >>>> 4. PAWS must response the proper frequency band list to particular >>>> coverage white space devices. >>>>=20 >>>> 5. Master devices should support power control. >>>>=20 >>>> 6. Slave devices should support power control. >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>=20 >>>> Zhu Lei >>>>=20 >>>>=20 >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>> =B7=A2=BC=FE=C8=CB: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] =B4=FA=B1=ED Gerald >>>> Chouinard >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C28=C8=D5 8:01 >>>> =CA=D5=BC=FE=C8=CB: Gabor.Bajko@nokia.com >>>> =B3=AD=CB=CD: paws@ietf.org >>>> =D6=F7=CC=E2: Re: [paws] combined problem statement, use cases & = requirements >>>>=20 >>>> Gabor, >>>>=20 >>>> Can I ask that the text modifications that I have submitted to = scott and >>>> copied to the paws reflector in my email dated 8 August be included = as >>>> well? >>>>=20 >>>> Thank's, >>>>=20 >>>> Gerald >>>>=20 >>>>=20 >>>> At 20:32 07-09-11 +0000, Gabor.Bajko@nokia.com wrote: >>>>> Ok, let's try that then. >>>>> Scott, can you put use cases before PS, and add the ad-hoc use = case. I >>>>> just scanned through the list and spotted that Teco indeed = provided a >>>>> description for that use case on Aug 3rd. >>>>> And submit the draft as a wg item, unless there are still = objections. >>>>>=20 >>>>> -Gabor >>>>>=20 >>>>> -----Original Message----- >>>>> From: ext Nancy Bravin [mailto:nbravin@earthlink.net] >>>>> Sent: Saturday, September 03, 2011 3:41 PM >>>>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>>>> Cc: Teco Boot; Gerald Chouinard; paws@ietf.org >>>>> Subject: Re: [paws] combined problem statement, use cases & = requirements >>>>>=20 >>>>> Dear Gabor and All, >>>>>=20 >>>>> I think it is appropriate to put the use cases before the PS for = obvious >>>>> reasons, and including the "proxy" need in the first draft. I = support >>>>> including both Gerald's suggestions and Teco's proposal in the = original >>>>> draft and not waiting until a later time. It is the proper order, >>>>> inclusive and needed in the initial draft in my opinion. I believe = with >>>>> the talent in the group it will not take long to accomplish this = and you >>>>> will have a more cohesive draft. >>>>>=20 >>>>> SIncerely, Nancy >>>>>=20 >>>>>=20 >>>>> On Sep 2, 2011, at 2:19 PM, >>>>> wrote: >>>>>=20 >>>>>> Teco, Gerald, >>>>>>=20 >>>>>> Thanks for the feedback. I'd suggest that we make this draft a WG >>>>> item, >>>>> with Gerald's proposed changes in it. Regarding the order of the >>>>> problem >>>>> statement vs use cases, my preference would be to leave it as it = is >>>>> (but >>>>> we can always change it, if that is what the WG wants). >>>>>>=20 >>>>>> So, I'd ask Scott to submit a WG version of this draft, then have >>>>> someone come up with text for this ad-hoc network scenario, have = the WG >>>>> agree with the text and include it in one of the subsequent = versions. >>>>> Teco, would you write up some text for this ad-hoc use case the WG >>>>> could >>>>> discuss? >>>>>>=20 >>>>>> We'll also send an initial version of a list of requirements to = the >>>>> list next week. >>>>>>=20 >>>>>> - Gabor >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ext Teco Boot [mailto:teco@inf-net.nl] >>>>>> Sent: Thursday, September 01, 2011 11:06 PM >>>>>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>>>>> Cc: paws@ietf.org >>>>>> Subject: Re: [paws] combined problem statement, use cases & >>>>>> requirements >>>>>>=20 >>>>>> I think the doc is a good starting point. I support adoption. >>>>>>=20 >>>>>> I suggest reordering: specifying problem statement after = introducing >>>>> the use cases. >>>>>>=20 >>>>>> Some asked for the ad hoc network scenario. This includes me :-). >>>>> This >>>>> is important, because it demonstrates the need for "proxy". >>>>>> BTW, I wonder why similar scenario doesn't pop up from WiFi >>>>> deployments. Usage of controllers in large sites is not uncommon. = Not >>>>> to >>>>> mention 11s. >>>>>>=20 >>>>>> The requirements is left open. I'm looking forward see some draft >>>>> text. >>>>>>=20 >>>>>> Thanks, Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 30 aug 2011, om 19:42 heeft >>>>> het volgende geschreven: >>>>>>=20 >>>>>>> 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-rqmt >>>>>>> s -00.txt but there was not one feedback received. I take that = as >>>>>>> people have no comments to the draft at this time. >>>>>>>=20 >>>>>>> And I am asking again: is there any objection in adopting the = above >>>>> draft as a wg document? >>>>>>>=20 >>>>>>> -Gabor >>>>>>>=20 >>>>>>> -----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 >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>> = http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmt >>>>>>> s >>>>>>> -00.txt >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> -Gabor >>>>>>>=20 >>>>>>>=20 >>>>> = --------------------------------------------------------------------- >>>>>>> - >>>>>>> --------------------------------- >>>>>>> From: Probasco Scott >>>>>>> Sent: Monday, August 22, 2011 9:18 AM >>>>>>> To: paws@ietf.org >>>>>>> Subject: combined problem statement, use cases & requirements >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Scott >>>>>>>=20 >>>>>>> URL: >>>>>>>=20 >>>>> = http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmt >>>>>>> s >>>>>>> -00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=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 >>>>=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 >> _______________________________________________ >> 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 peter@spectrumbridge.com Wed Sep 14 05:26: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 6575C21F8A55 for ; Wed, 14 Sep 2011 05:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=1.286, 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 ymtlYbMdLwln for ; Wed, 14 Sep 2011 05:26:23 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id AF36E21F8876 for ; Wed, 14 Sep 2011 05:26:23 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 14 Sep 2011 08:30:00 -0400 From: Peter Stanforth To: ZhuLei , "Rosen, Brian" Date: Wed, 14 Sep 2011 08:28:29 -0400 Thread-Topic: [paws] combined problem statement, use cases & requirements Thread-Index: Acxy2gTJCBHKDgvYTDurs6sylDLljQ== Message-ID: In-Reply-To: <470F27D1263A1B4EB73491ED995DE62539C667@szxeml504-mbx.china.huawei.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 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] 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: Wed, 14 Sep 2011 12:26:24 -0000 >From the regulator, and other spectrum holder perspective, the sole responsibility of the white space DB solution is to ensure that the secondary users do not, in any way, interfere with the primary user of the spectrum. This has to be the primary focus of PAWS. I would propose that any co-existence or other capability that assists in the management of the secondary users is handled by extensible capabilities above and beyond the basic requirement. While it would be beneficial to specify and standardize some of these capabilities they are of no interest to the spectrum "owner". Peter S. On WedSep/14/11 Wed Sep 14, 5:08 AM, "ZhuLei" wrote: >Hi, > >No doubt that PAWS is spectrum independent, air interface technologies >independent and nation independent protocol which would have some >essential parameters in query request like "location", "type" and maximum >power limits. I used to think that PAWS is even extendable for some >additional rule if there is. Such supported or extendable information in >a query request would provide information to for database to reply >available bands. That is original concept of PAWS when I used to listen. > >For interference issue, I think that APs indoor are more flexible to >limit the output power, but it is difficult to limit power output of >outdoor access points which cover over hundreds meters. So, the database >is likely to reply other spectrum to indoor APs if the spectrum is >already covered by other outdoor AP(s). The conclusion of the indoor APs >could be complicated more since sometimes power control works when >interference happens, but interference avoidance is still very useful in >a number of cases. 802.11 has "interference avoidance" is basically to >use different "channel" in case that more than one APs work in an area. >My opinion is that it is very helpful if database would reply some higher >bands that radio would not be able to penetrate several walls for the >scenarios some APs are just in one building. > >Best regards, >Zhu Lei > From lei.zhu@huawei.com Wed Sep 14 05:31:37 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 3050121F8B0D for ; Wed, 14 Sep 2011 05:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Vrvx4TqfXChD for ; Wed, 14 Sep 2011 05:31:35 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 25B7221F8634 for ; Wed, 14 Sep 2011 05:31:35 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00M6ZITKLP@szxga03-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 20:32:09 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI007BKITJKA@szxga03-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 20:32:08 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADY91619; Wed, 14 Sep 2011 20:32:06 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 20:31:58 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.189]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 20:32:05 +0800 Date: Wed, 14 Sep 2011 12:32:03 +0000 From: ZhuLei In-reply-to: X-Originating-IP: [10.108.64.160] To: Teco Boot Message-id: <470F27D1263A1B4EB73491ED995DE62539C71E@szxeml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [paws] combined problem statement, use cases & requirements Thread-index: AQHMbbpSvI202O9wxE+XVjq4c4dCVJVCsH3AgAB8ZQCAB4F8QIAAEMcAgAAQ2oCAAbYJkP//pLKAgACrIRA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <35D7EFC3-8EBD-428A-B579-8C4D783ED7BB@neustar.biz> <470F27D1263A1B4EB73491ED995DE62539C667@szxeml504-mbx.china.huawei.com> Cc: "paws@ietf.org" 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: Wed, 14 Sep 2011 12:31:37 -0000 SGksDQoNCkkgdGhpbmsgdGhhdCBBUChzKSBtYXkgZG8gdGhpcyBieSB0aGVtc2VsdmVzIHdoaWNo IGlzIHRvIHNlbnNlIGNvbmZsaWN0IGNoYW5uZWxzIGFuZCBhdm9pZCB0byB1c2UgdGhlbSwgb3Ig Y29udHJvbGxlciBvcHRpbWl6ZXMgaXQuIEl0IGlzIHN0aWxsIG9rIGZvciBQQVdTIGV2ZW4gaXQg aXMgbm90IGRpc2N1c3NlZC4NCg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQotLS0tLdPKvP7U rbz+LS0tLS0NCreivP7IyzogVGVjbyBCb290IFttYWlsdG86dGVjb0BpbmYtbmV0Lm5sXSANCrei y83KsbzkOiAyMDExxOo51MIxNMjVIDE4OjA4DQrK1bz+yMs6IFpodUxlaQ0Ks63LzTogUm9zZW4s IEJyaWFuOyBQZXRlciBTdGFuZm9ydGg7IHBhd3NAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbcGF3c10g Y29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cw0KDQpI aSwNCg0KQXJlbid0IHlvdSBkZXNjcmliaW5nIGFuIEFQIC0gV2lGaSBDb250cm9sbGVyIHNldHVw LCBhbmQgYSBwcm90b2NvbCBmb3Igc3VjaD8gVGhlIGNvbnRyb2xsZXIgY2FuIG9wdGltaXplIHNw ZWN0cnVtIHVzYWdlIGZvciAic2xhdmUiIEFQJ3MsIGFuZCBjYW4gcGVyZm9ybSBhIHByb3h5IGZv ciB0aGUgQVAncyBmb3IgZ2V0dGluZyBzcGVjdHJ1bS4gVGhpcyBjYW4gYmUgZG9uZSBpbiBkaXN0 cmlidXRlZCB3YXkgYWxzbywgYnV0IEkgYW0gbm90IGF3YXJlIG9mIHN1Y2ggZGVwbG95bWVudC4N Cg0KVGVjbw0KDQpPcCAxNCBzZXAgMjAxMSwgb20gMTE6MDggaGVlZnQgWmh1TGVpIGhldCB2b2xn ZW5kZSBnZXNjaHJldmVuOg0KDQo+IEhpLA0KPiANCj4gTm8gZG91YnQgdGhhdCBQQVdTIGlzIHNw ZWN0cnVtIGluZGVwZW5kZW50LCBhaXIgaW50ZXJmYWNlIHRlY2hub2xvZ2llcyBpbmRlcGVuZGVu dCBhbmQgbmF0aW9uIGluZGVwZW5kZW50IHByb3RvY29sIHdoaWNoIHdvdWxkIGhhdmUgc29tZSBl c3NlbnRpYWwgcGFyYW1ldGVycyBpbiBxdWVyeSByZXF1ZXN0IGxpa2UgImxvY2F0aW9uIiwgInR5 cGUiIGFuZCBtYXhpbXVtIHBvd2VyIGxpbWl0cy4gSSB1c2VkIHRvIHRoaW5rIHRoYXQgUEFXUyBp cyBldmVuIGV4dGVuZGFibGUgZm9yIHNvbWUgYWRkaXRpb25hbCBydWxlIGlmIHRoZXJlIGlzLiBT dWNoIHN1cHBvcnRlZCBvciBleHRlbmRhYmxlIGluZm9ybWF0aW9uIGluIGEgcXVlcnkgcmVxdWVz dCB3b3VsZCBwcm92aWRlIGluZm9ybWF0aW9uIHRvIGZvciBkYXRhYmFzZSB0byByZXBseSBhdmFp bGFibGUgYmFuZHMuIFRoYXQgaXMgb3JpZ2luYWwgY29uY2VwdCBvZiBQQVdTIHdoZW4gSSB1c2Vk IHRvIGxpc3Rlbi4NCj4gDQo+IEZvciBpbnRlcmZlcmVuY2UgaXNzdWUsIEkgdGhpbmsgdGhhdCBB UHMgaW5kb29yIGFyZSBtb3JlIGZsZXhpYmxlIHRvIGxpbWl0IHRoZSBvdXRwdXQgcG93ZXIsIGJ1 dCBpdCBpcyBkaWZmaWN1bHQgdG8gbGltaXQgcG93ZXIgb3V0cHV0IG9mIG91dGRvb3IgYWNjZXNz IHBvaW50cyB3aGljaCBjb3ZlciBvdmVyIGh1bmRyZWRzIG1ldGVycy4gU28sIHRoZSBkYXRhYmFz ZSBpcyBsaWtlbHkgdG8gcmVwbHkgb3RoZXIgc3BlY3RydW0gdG8gaW5kb29yIEFQcyBpZiB0aGUg c3BlY3RydW0gaXMgYWxyZWFkeSBjb3ZlcmVkIGJ5IG90aGVyIG91dGRvb3IgQVAocykuIFRoZSBj b25jbHVzaW9uIG9mIHRoZSBpbmRvb3IgQVBzIGNvdWxkIGJlIGNvbXBsaWNhdGVkIG1vcmUgc2lu Y2Ugc29tZXRpbWVzIHBvd2VyIGNvbnRyb2wgd29ya3Mgd2hlbiBpbnRlcmZlcmVuY2UgaGFwcGVu cywgYnV0IGludGVyZmVyZW5jZSBhdm9pZGFuY2UgaXMgc3RpbGwgdmVyeSB1c2VmdWwgaW4gYSBu dW1iZXIgb2YgY2FzZXMuIDgwMi4xMSBoYXMgImludGVyZmVyZW5jZSBhdm9pZGFuY2UiIGlzIGJh c2ljYWxseSB0byB1c2UgZGlmZmVyZW50ICJjaGFubmVsIiBpbiBjYXNlIHRoYXQgbW9yZSB0aGFu IG9uZSBBUHMgd29yayBpbiBhbiBhcmVhLiBNeSBvcGluaW9uIGlzIHRoYXQgaXQgaXMgdmVyeSBo ZWxwZnVsIGlmIGRhdGFiYXNlIHdvdWxkIHJlcGx5IHNvbWUgaGlnaGVyIGJhbmRzIHRoYXQgcmFk aW8gd291bGQgbm90IGJlIGFibGUgdG8gcGVuZXRyYXRlIHNldmVyYWwgd2FsbHMgZm9yIHRoZSBz Y2VuYXJpb3Mgc29tZSBBUHMgYXJlIGp1c3QgaW4gb25lIGJ1aWxkaW5nLg0KPiANCj4gQmVzdCBy ZWdhcmRzLA0KPiBaaHUgTGVpDQo+IA0KPiANCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7I yzogUm9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXpdIA0KPiC3osvN yrG85DogMjAxMcTqOdTCMTPI1SAyMToyNw0KPiDK1bz+yMs6IFBldGVyIFN0YW5mb3J0aA0KPiCz rcvNOiBaaHVMZWk7IHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KPiDW 98ziOiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiBy ZXF1aXJlbWVudHMNCj4gDQo+IE91ciBjaGFydGVyIHNheXMgdGhhdCB3ZSB3aWxsIGRldmVsb3Ag YSBwcm90b2NvbCB3aGljaCBpcyBzcGVjdHJ1bSBpbmRlcGVuZGVudCAoZGlmZmVyZW50IGJhbmRz KSwgcGhpIGluZGVwZW5kZW50IChkaWZmZXJlbnQgdHlwZXMgb2YgZGV2aWNlcyB1c2luZyBkaWZm ZXJlbnQgb3ZlciB0aGUgYWlyIGludGVyZmFjZXMpIGFuZCBuYXRpb24gaW5kZXBlbmRlbnQuDQo+ IA0KPiBUaGF0IG1lYW5zLCBhcyBQZXRlciBzYXlzLCBpbmRvb3IgYW5kIG91dGRvb3IgdXNlIHdv dWxkIGJlIGNvdmVyZWQuDQo+IA0KPiBJIGRvIHRoaW5rIHRoZSBxdWVyeSB3aWxsIGhhdmUgc29t ZSBraW5kIG9mICJ0eXBlIiB3aGljaCBpcyB0aGUgcGh5IGluZGVwZW5kZW5jZSwgYnV0IGFsc28g dGFrZXMgaW50byBhY2NvdW50IHRoZSByZWd1bGF0b3JzIHJ1bGVzIG9uIHBvd2VyLCBhbnRlbm5h IGFuZCBvdGhlciBwYXJhbWV0ZXJzLg0KPiBUaGUgVVMgcnVsZXMgd29yayB0aGF0IHdheSwgYW5k IEkgZXhwZWN0IG1hbnkgb3RoZXIgbmF0aW9ucyB3aWxsIGhhdmUgc2ltaWxhciBraW5kcyBvZiBy dWxlcy4gIFlvdSBjYW4gaW1hZ2luZSBydWxlcyB3aGVyZSBtb3JlIGFudGVubmEgaW5mb3JtYXRp b24gaXMgbmVlZGVkIGluIHRoZSBxdWVyeSB0byBkZXRlcm1pbmUgd2hhdCBzcGVjdHJ1bSBpcyBh dmFpbGFibGUsIGJ1dCBzbyBmYXIsIHRoZXJlIGFyZSBtZXJlbHkgbGltaXRzIGZvciBlYWNoIHR5 cGUuDQo+IA0KPiBCcmlhbg0KPiANCj4gT24gU2VwIDEzLCAyMDExLCBhdCA4OjI2IEFNLCBQZXRl ciBTdGFuZm9ydGggd3JvdGU6DQo+IA0KPj4gUmVndWxhdGlvbiBvZiBUVldTIGlzIGN1cnJlbnRs eSBwcm9wb3NlZCBieSAzIFJlZ3VsYXRvcnMsIFVTLCBVSyBhbmQNCj4+IENhbmFkYSwgd2l0aCB3 b3JrIG9uZ29pbmcgaW4gU2luZ2Fwb3JlLCBGaW5sYW5kIGFuZCBzZXZlcmFsIG90aGVyDQo+PiBj b3VudHJpZXMuIFRoZXJlIGFyZSBzdWJ0bGUgZGlmZmVyZW5jZXMgaW4gYXBwcm9hY2ggYW5kIHJl cXVpcmVtZW50cyBidXQNCj4+IHRoZSBiYXNpYyBjb25jZXB0IGlzIHRoZSBzYW1lIGluIGFsbCBj YXNlcy4gUEFXUyBzaG91bGQgYmUgYWJsZSB0byBhZGRyZXNzDQo+PiBhbGwgY2FzZXMuDQo+PiBB bGwgcmVndWxhdG9ycyBhbGxvdyBmb3IgaW5kb29yIHVzZSBhcyB3ZWxsIGFzIG91dGRvb3IgdXNl LiBQQVdTIHNob3VsZA0KPj4gYWRkcmVzcyBhbGwgdGhlc2UgY2FzZXMuIEFsbCByZWd1bGF0b3Jz IHByb3Bvc2UgdGhhdCBhIGNvbXBvbmVudCBvZiB0aGUNCj4+IGRlY2lzaW9uIGJlIGJhc2VkIG9u IHRoZSAiZGV2aWNlIHR5cGUiIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcmVzdWx0cw0KPj4gYmFz ZWQgb24gdGhlIGNhcGFiaWxpdHkgYW5kLCBpbiBzb21lIHJlZ3VsYXRpb24sIHRoZSBtYXhpbXVt IHBvd2VyIG91dHB1dA0KPj4gb2YgdGhlIGRldmljZS4gVGhlcmUgaXMgbm8gcmVhc29uIFBBV1Mg Y2Fubm90IGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyBmb3INCj4+IGluZG9vciB1c2UgYXMgd2Vs bCBhcyBvdXRkb29yIHVzZS4gQXQgNDUwLTcwME1IeiB0aGUgaXNzdWUgb2YgY28tZXhpc3RlbmNl DQo+PiBiZXR3ZWVuIDIgYXBhcnRtZW50cyBpcyByZWFsbHkgbm8gZGlmZmVyZW50IHRoYW4gdGhl IGNvLWV4aXN0ZW5jZSBiZXR3ZWVuDQo+PiAyIG91dGRvb3IgYWNjZXNzIHBvaW50cyBzZXZlcmFs IGh1bmRyZWQgbWV0ZXJzIGFwYXJ0LiBUaGF0IHNhaWQsIGl0IHdhcyBteQ0KPj4gdW5kZXJzdGFu ZGluZyB0aGF0IFBBV1Mgd2FzIGFsc28gZnJlcXVlbmN5IGFuZCBtb2R1bGF0aW9uIGluZGVwZW5k ZW50LA0KPj4gd2hpY2ggaXQgc2hvdWxkIGJlLg0KPj4gUGV0ZXIgU3RhbmZvcnRoDQo+PiBTcGVj dHJ1bSBCcmlkZ2UgSW5jLg0KPj4gDQo+PiBPbiBUdWVTZXAvMTMvMTEgVHVlIFNlcCAxMywgMzow OSBBTSwgIlpodUxlaSIgPGxlaS56aHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+PiBIaSBT Y290dCBhbmQgYWxsLA0KPj4+IA0KPj4+IEZvciBzb21lIHJlYXNvbnMsIEkgdGhpbmsgdGhhdCBQ QVdTIHByb3RvY29sIHdvdWxkIGJlIGRldmVsb3BlZCB3aXRoDQo+Pj4gcXVpdGUgc3RhYmxlIHNj ZW5hcmlvIGRlc2NyaXB0aW9ucyBvZiBpbmRvb3IgY292ZXJhZ2UuDQo+Pj4gDQo+Pj4gQWNjb3Jk aW5nIHRvIHByZXZpb3VzIGUtbWFpbCBkaXNjdXNzaW9uIGluIHRoZSBsaXN0LCBpdCBzZWVtcyB0 aGF0DQo+Pj4gd29ya2luZyBncm91cCB3b3VsZCBkZXZlbG9wIGdlbmVyaWMgYW5kIGdsb2JhbGx5 IGFwcGxpY2FibGUgc3BlY3RydW0NCj4+PiBkYXRhYmFzZSBxdWVyeSBwcm90b2NvbCB3aGljaCBo b3BlbHkgaXMgYWNjZXB0ZWQgYnkgb3RoZXIgcmVndWxhdG9ycyBidXQNCj4+PiBvbmx5IEZDQy4g NzAwTUh6LTgwME1IeiBjYW4gYmUgc2hhcmVkIHRvIHBhcnRpY3VsYXIgd2lyZWxlc3MgYWNjZXNz DQo+Pj4gdGVjaG5vbG9naWVzIGxpa2UgODAyLjExLCA4MDIuMjIgYW5kIGV2ZW4gTFRFLiBQbGVh c2UgY29ycmVjdCBtZSBpZg0KPj4+IHNvbWV0aGluZyB3cm9uZy4NCj4+PiANCj4+PiBUaGUgZ2Vu ZXJpYyB1c2UgY2FzZXMgY291bGQgYmUgc2FmZSB3aGVuIGRlY2lkaW5nIHdvcmtpbmcgZ3JvdXAg ZHJhZnQuDQo+Pj4gQnV0IGhvdHNwb3QgYW5kIHVyYmFuIGludGVybmV0IGNvbm5lY3Rpb24gZGVz Y3JpcHRpb24gaXMgc3RpbGwgbm90DQo+Pj4gY3JlZGl0YWJsZSB0byBkZXZlbG9wIFBBV1MgcHJv dG9jb2wgZm9yIHRoZSByZWFzb24gNzAwTUh6IGhhcyBmYXINCj4+PiBkaWZmZXJlbnQgcHJvcGFn YXRpb24gY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIG5lZWRzIG9mIGluZG9vciBjb3ZlcmFnZQ0K Pj4+IGFuZCB1cmJhbiBob3RzcG90IHVzZSBjYXNlLiBJbiBnZW5lcmFsLCBpbmRvb3IgdXNlIGNh c2Ugc2F5cyB0aGF0DQo+Pj4gZGF0YWJhc2Ugc2hvdWxkIHRvIHJlc3BvbnNlIHByb3BlciBzcGVj dHJ1bSBpZiBBUHMgcmVxdWVzdCBjaGFubmVscyBmb3INCj4+PiBpbmRvb3IgSW50ZXJuZXQgY29u bmVjdGlvbi4gSWYgaXQgaXMgbm90IHBvc3NpYmxlLCByZWd1bGF0b3JzIG11c3QgdG8NCj4+PiBm YWNlIHByb2JsZW1zIG9mIGludGVyZmVyZW5jZSBhbW9uZyBBUHMgYW5kIE1pY3JvIGNlbGwgQlNz LiBUaGVuLCBQQVdTDQo+Pj4gbm93IGhhcyB0byByZWNvZ25pemUgc2NlbmFyaW8gZGVzY3JpcHRp b24gYW5kIHJlcXVpcmVtZW50cyBiZWZvcmUgZGV2ZWxvcA0KPj4+IHByb3RvY29sIHRoYXQgb3Ro ZXIgaGlnaGVyIGZyZXF1ZW50IGJhbmRzIChhdCBsZWFzdCBoaWdoZXIgdGhhbiAyLjFHSHopDQo+ Pj4gc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gaW5kb29yIGNvdmVyYWdlLiBJIHdvdWxkIGxpa2Ug dG8gcmVtaW5kIHRoYXQgaXMNCj4+PiBkaWZmZXJlbnQgbmVlZCBmb3IgaW5kb29yIGNvdmVyYWdl IGZyb20gZ2VuZXJpYyBob3RzcG90IGFuZCB1cmJhbg0KPj4+IGNvdmVyYWdlIHdoaWNoIGlzIHN0 aWxsIHRvIGJlIGRpdmlkZWQuDQo+Pj4gDQo+Pj4gRnJvbSBwcm90b2NvbCBwZXJzcGVjdGl2ZSwg aXQgd2lsbCBkZXBlbmQgb24gdGhlIGNvbmNsdXNpb24gb2Ygd29ya2luZw0KPj4+IGdyb3VwIHdo aWNoIElFcyBhcmUgcmVzZXJ2ZWQgZm9yIGluZG9vciBxdWVyeSB1c2FnZXMuDQo+Pj4gDQo+Pj4g VGhyZWUgdGhpbmdzIGFyZSBwYXJ0aWN1bGFyIGZvciBpbmRvb3IgY292ZXJhZ2UgdXNlIGNhc2Ug aWYgZGV2ZWxvcCBQQVdTDQo+Pj4gcHJvdG9jb2wuIEZpcnN0IG9uZSBpcyB0aGF0IHRoZSBsb2Nh dGlvbiBpbiBhIGJ1aWxkaW5nIGlzIGRpZmZlcmVudCBmcm9tDQo+Pj4gR1BTIHBvc2l0aW9uaW5n LiBTZWNvbmQgb25lIGlzIHRoYXQgdGhlIGRhdGFiYXNlIHNob3VsZCBiZSBhYmxlIHRvDQo+Pj4g Y2FsY3VsYXRlIHRoZSBwcm9wZXIgYmFuZCBmb3IgaW5kb29yIGNvdmVyYWdlLiBUaGlyZCBvbmUg aXMgdGhhdCBkYXRhYmFzZQ0KPj4+IHNob3VsZCBiZSBhYmxlIHRvIGNvbnNpZGVyIChvciBjYWxj dWxhdGUpIGFuZCBhdm9pZCB1bmV4cGVjdGVkDQo+Pj4gaW50ZXJmZXJlbmNlIGFtb25nIGRpZmZl cmVudCBpbmRvb3IgQVBzIGFuZCBtaWNybyBjZWxsIEJTcy4NCj4+PiANCj4+PiBCZXN0IHJlZ2Fy ZHMsDQo+Pj4gWmh1IExlaQ0KPj4+IA0KPj4+IA0KPj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+ ILeivP7Iyzogc2NvdHQucHJvYmFzY29Abm9raWEuY29tIFttYWlsdG86c2NvdHQucHJvYmFzY29A bm9raWEuY29tXQ0KPj4+ILeiy83KsbzkOiAyMDExxOo51MI4yNUgMjM6NDkNCj4+PiDK1bz+yMs6 IFpodUxlaQ0KPj4+ILOty806IHBhd3NAaWV0Zi5vcmcNCj4+PiDW98ziOiBSZTogW3Bhd3NdIGNv bWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMgJiByZXF1aXJlbWVudHMNCj4+PiAN Cj4+PiBIZWxsbyBMZWksDQo+Pj4gDQo+Pj4gSSBoYXZlIHN0dWRpZWQgdGhlIHRleHQgYmVsb3cs IGJ1dCBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3UNCj4+PiBhcmUgcHJvcG9z aW5nLiBJdCBzZWVtcyB0byBtZSB0aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBhIGRlcGxveW1lbnQN Cj4+PiBzY2VuYXJpbyAod2hpY2ggaXMgZmluZSkuIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCBp cyB0aGUgdXNlIGNhc2UsIG9yIGhvdw0KPj4+IHRoaXMgY2FzZSBpcyBkaWZmZXJlbnQgZnJvbSAi SG90c3BvdCIgdXNlIGNhc2UgKEFQIGlzIGluZG9vcikgd2l0aCBhDQo+Pj4gIldpZGUtYXJlYSBv ciBydXJhbCIgdXNlIGNhc2UgZGVwbG95ZWQgaW4gdGhlIHNhbWUgZ2VuZXJhbCBhcmVhIChtaWNy b2NlbGwNCj4+PiBpcyBvdXRkb29yKS4NCj4+PiANCj4+PiBJIGFtIG5vdCBzcGVha2luZyBhZ2Fp bnN0IHRoZSB1c2UgY2FzZSwgc2ltcGx5IHNheWluZyB0aGF0IEkgZG9uJ3QNCj4+PiB1bmRlcnN0 YW5kIGl0IHdlbGwgZW5vdWdoIHRvIGNvbW1lbnQgb24gaXQuIEl0IG1pZ2h0IGhlbHAgZnVydGhl cg0KPj4+IGRpc2N1c3Npb24gaWYgeW91IGNhbiBkZXNjcmliZSBpbiBtb3JlIGRldGFpbCB0aGUg dXNlIGNhc2UsIGFuZCBpbmNsdWRlDQo+Pj4gc3BlY2lmaWMgYWN0aW9ucyB0aGF0IGVhY2ggZWxl bWVudCAobWljcm9jZWxsLCBBUCwgZGV2aWNlLCBkYXRhYmFzZSwgZXRjKQ0KPj4+IG11c3QgY29t cGxldGUgaW4gb3JkZXIgdG8gZGVwbG95IHRoaXMgdXNlIGNhc2UuDQo+Pj4gDQo+Pj4gUmVnYXJk cywNCj4+PiBTY290dA0KPj4+IA0KPj4+IA0KPj4+IE9uIDkvNy8xMSA4OjM1IFBNLCAiZXh0IFpo dUxlaSIgPGxlaS56aHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+ Pj4gDQo+Pj4+IEkgdGhpbmsgdGhhdCB3ZSBkbyBzb21lIHdvcmtzIG9uIGltcHJvdmluZyBvcmln aW5hbCB1c2UgY2FzZSBkcmFmdCBieQ0KPj4+PiBhZGRpbmcgdGhyZWUgYWRkaXRpb25hbCB1c2Ug Y2FzZXMsIGluY2x1ZGluZyBpbmRvb3IgY292ZXJhZ2UsIGFkIGhvYw0KPj4+PiBuZXR3b3JrIGFu ZCBsdGUgbWJtcyBpc3N1ZS4NCj4+Pj4gDQo+Pj4+IE5vdywgSSBhbSBhc2tpbmcgdG8gYWRkIGlu ZG9vciBjb3ZlcmFnZSBzY2VuYXJpbyB3aGljaCBpcyBuZWNlc3NhcnkgZm9yDQo+Pj4+IFBBV1Mg cHJvdG9jb2wgdG8gY29uc2lkZXIgaW4gbmV4dCBzdGFnZS4gVGhlIHByb3Bvc2VkIHVzZSBjYXNl IGlzIHNlZW4NCj4+Pj4gYmVsb3cuIFRoZSB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBp cyB0byBiZSBzdWJtaXR0ZWQgc29vbiBieQ0KPj4+PiBhZGRpbmcgc29tZSB3b3JkaW5nIG1vZGlm aWNhdGlvbnMuIFNvLCBJIGRvbid0IHRoaW5rIHdlIGFyZSB0byBza2lwIHRoZQ0KPj4+PiBhZGRp dGlvbmFsIHVzZSBjYXNlcyBldmVuIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2UgYW5k IHJlcXVpcmVtZW50DQo+Pj4+IHByb3Bvc2FsIGhhdmUgYmVlbiBpbnRlZ3JhdGVkIG5vdy4NCj4+ Pj4gDQo+Pj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPj4+PiB4LnguICBJbmRvb3IgdXNhZ2Ugb2YgVFZXUw0KPj4+PiANCj4+Pj4gQXQg cHJlc2VudCwgdGhlIGluZG9vciB3aXJlbGVzcyBjb3ZlcmFnZSBlcXVpcG1lbnRzIGNvbnNpc3Qg b2YgV2ktRmktDQo+Pj4+IGxpa2UgYWNjZXNzIHBvaW50cyBhbmQgbWljcm8gY2VsbHMsIGFsbCBv ZiB0aGVzZSB1dGlsaXplIHNlZ21lbnRzIG9mDQo+Pj4+IGZyZXF1ZW5jeSwgZm9ybWVyIGF0IGFi b3V0IDIuNEdIeiBvciA1R2h6IGFuZCB0aGUgbGF0dGVyLCBmb3INCj4+Pj4gZXhhbXBsZSwgODAy LjExbiBhdCBhYm91dCAyLjRHSHouICBBcyBhIHJlc3VsdCBvZiB0aGUgYmxvY2sgb2YNCj4+Pj4g YnVpbGRpbmdzIGFuZCBvdGhlciBvYnN0cnVjdGlvbiBhbmQgaW50ZXJmZXJlY2UsIGl0IG1heSBu b3QgYmUgdGhhdA0KPj4+PiBvcHRpbWlzdGljIHdoZW4gODAyLjExIGRldmljZXMgZXhhbWluZSB0 aGUgc3RhdHVzIG9mIHdpcmVsZXNzDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IFpodSAgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMiAgICAgICAgICAgICAgICBb UGFnZSAzXQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg UEFXUyB1c2UgY2FzZXMgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMQ0KPj4+PiANCj4+Pj4g DQo+Pj4+IGludGVyZmVyZXMuICBUaGlzIHVzZSBjYXNlIHRha2VzIHRoZSBiZW5lZml0IG9mIFRW IFdoaXRlIFNwYWNlIHRvDQo+Pj4+IHByb3ZpZGUgYWRkaXRpb25hbCBjYXBhY2l0eSB0byBpbmRv b3IgY292ZXJhZ2UgYW5kIHJlZHVjZSBjaGFubmVsDQo+Pj4+IGludGVyZmVyZWNlLg0KPj4+PiAN Cj4+Pj4gVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlIGRlcGxveW1lbnQgb2YgdGhp cyBzY2VuYXJpby4NCj4+Pj4gDQo+Pj4+ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCj4+Pj4gICAgICAgICAgICAgfCAgICAgICAgICAgIGluZG9vciAgICAg ICAgICAgICAgfA0KPj4+PiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+Pj4+ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCj4+Pj4gICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K Pj4+PiAgICAgICAgICAgICB8ICAgICstLS0tLS0rICAgd2hpdGUgc3BhY2UgICAgICB8ICAgKy0t LS0tLS0tLS0tLS0rDQo+Pj4+ICAgICAgICAgICAgIHwgICAgfERldmljZXwgLSAtIC0gLSAtIC0g LSAtIC0gLXwtIC18IE1pY3JvIGNlbGwgIHwNCj4+Pj4gICAgICAgICAgICAgfCAgICArLS0tLS0t KyAgXCAgICAgICAgICAgICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KPj4+PiAgICAgICAgICAg ICB8ICAgICstLS0tLS0rICAgXHdoaXRlIHNwYWNlICAgICB8ICAgICAoLS0tLS0pDQo+Pj4+ICAg ICAgICAgICAgIHwgICAgfERldmljZXwgICAgXCArLS0tLS0tLS0tLS0tK3wgICAgLyAgICAgICBc DQo+Pj4+ICAgICAgICAgICAgIHwgICAgKy0tLS0tLSsgICAgICB8YWNjZXNzIHBvaW50fHw9PT0o IEludGVybmV0KQ0KPj4+PiAgICAgICAgICAgICB8ICAgICAgICBvICAgICAgIC8gKy0tLS0tLS0t LS0tLSt8ICAgIFwgICAgICAgLw0KPj4+PiAgICAgICAgICAgICB8ICAgICAgICBvICAgICAgLyAg ICAgICAgICAgICAgICB8ICAgICAoLS0tLS0pDQo+Pj4+ICAgICAgICAgICAgIHwgICAgICAgIG8g ICAgIC8gICAgICAgICAgICAgICAgIHwNCj4+Pj4gICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KPj4+PiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQo+Pj4+IA0KPj4+PiANCj4+Pj4gICAgICAgICAgICAgICAgICAgICBH cmFwaCAxIEluZG9vciB1c2FnZSBvZiBUVldTDQo+Pj4+IA0KPj4+PiBUaGUgYWNjZXNzIHBvaW50 IGNvdWxkIGJlIGEgV0ktRkkgcm91dGVyLCBhbmQgdGhlIG1pY3JvIGNlbGwgaXMgYQ0KPj4+PiBz aG9ydCByYW5nZSB3aXJlbGVzcyBjb3ZlcmFnZShlLmcuIGluIHJhbmdlIG9mIDAtNTBtKSBiYXNl IHN0YXRpb24sDQo+Pj4+IGJvdGggb2YgdGhlbSBhY3QgYXMgbWFzdGVyIGRldmljZXMsIHF1ZXJ5 aW5nIHRoZSBpbnRlcm5ldCBjb25uZWN0ZWQNCj4+Pj4gZGF0YWJhc2UgZm9yIGF2YWlsYWJsZSB3 aGl0ZSBzcGFjZSBzcGVjdHJ1bSBiYXNlZCBvbiBpdHMgZ2VvLQ0KPj4+PiBsb2NhdGlvbiwgYW5k IHByb3ZpZGluZyBUVldTIGFjY2VzcyB0byBpbmRvb3IgdXNlci4NCj4+Pj4gDQo+Pj4+IFRoZSBU VldTIHNwZWN0cnVtIGhhcyBkaWZmZXJlbnQgcHJvcGFnYXRpb24gY2hhcmFjdGVyaXN0aWNzIGNv bXBhcmVkDQo+Pj4+IHRvIGhpZ2hlciBmcmVxdWVuY3kgYmFuZCwgZm9yIGV4YW1wbGUsIHRoZSB0 cmFuc21pc3Npb24gZGlzdGFuY2UNCj4+Pj4gdXNpbmcgVFZXUyBjYW4gYmUgc2V2ZXJhbCB0aW1l cyBsb25nZXIgdGhhbiB0aG9zZSBpbiB0aGUgaGlnaGVyIGJhbmQuDQo+Pj4+IEluIHRoaXMgY2Fz ZSwgZ29vZCBwZW5ldHJhdGlvbiBjaGFyYWN0ZXJpc3RpYyBvZiBUVldTIG1ha2VzIGl0DQo+Pj4+ IGRpZmZpY3VsdCB0byBsb2NrIHRoZSBzaWduYWxzIGluIHRoZSByb29tLCB0aGVuIGRpZmZpY3Vs dCB0byBsb2NhbGl6ZQ0KPj4+PiBhbmQgZGlmZmVyZW50aWF0ZSBzaWduYWxzLCBhbmQgZmluYWxs eSBjYXVzZSBpbnRlcmZlcmVzIGFtb25nDQo+Pj4+IG5laWdoYm9yaW5nIG5ldHdvcmtzLiAgUmVx dWlyZW1lbnRzIHRvIGluZG9vciBXUyBkYXRlYmFzZSB1c2FnZSB3b3VsZA0KPj4+PiBiZToNCj4+ Pj4gDQo+Pj4+IA0KPj4+PiAxLiAgQSBmcmVxdWVuY3kgcHJvdGVjdGlvbiBnYXAgYmV0d2VlbiBu ZWlnaGJvcnMocGFydGljdWxhciBzcGVjdHJ1bQ0KPj4+PiAgICAgYWxsb2NhdGlvbiBhbGdvcml0 aG0gaXMgbmVlZGVkIGhlcmUpLg0KPj4+PiANCj4+Pj4gMi4gIGxvd2VyIG91dHB1dCBwb3dlciBv ZiBBUC9taWNybyBjZWxsLCBpdCBzZWVtcyB0aGF0IG9ubHkgY2VydGFpbg0KPj4+PiAgICAgcGlj byBvciBmZW10byBjZWxscyBiZSBmZWFzaWJsZSBoZXJlLg0KPj4+PiANCj4+Pj4gMy4gIFBBV1Mg bXVzdCBub3QgYmUgdGllZCB0byBhIHNwZWNpZmljIGZyZXF1ZW5jeSBiYW5kLg0KPj4+PiANCj4+ Pj4gNC4gIFBBV1MgbXVzdCByZXNwb25zZSB0aGUgcHJvcGVyIGZyZXF1ZW5jeSBiYW5kIGxpc3Qg dG8gcGFydGljdWxhcg0KPj4+PiAgICAgY292ZXJhZ2Ugd2hpdGUgc3BhY2UgZGV2aWNlcy4NCj4+ Pj4gDQo+Pj4+IDUuICBNYXN0ZXIgZGV2aWNlcyBzaG91bGQgc3VwcG9ydCBwb3dlciBjb250cm9s Lg0KPj4+PiANCj4+Pj4gNi4gIFNsYXZlIGRldmljZXMgc2hvdWxkIHN1cHBvcnQgcG93ZXIgY29u dHJvbC4NCj4+Pj4gDQo+Pj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPj4+PiANCj4+Pj4gWmh1IExlaQ0KPj4+PiANCj4+Pj4gDQo+Pj4+ IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+PiC3orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBHZXJhbGQNCj4+Pj4gQ2hvdWluYXJk DQo+Pj4+ILeiy83KsbzkOiAyMDExxOo51MI4yNUgODowMQ0KPj4+PiDK1bz+yMs6IEdhYm9yLkJh amtvQG5va2lhLmNvbQ0KPj4+PiCzrcvNOiBwYXdzQGlldGYub3JnDQo+Pj4+INb3zOI6IFJlOiBb cGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50 cw0KPj4+PiANCj4+Pj4gR2Fib3IsDQo+Pj4+IA0KPj4+PiBDYW4gSSBhc2sgdGhhdCB0aGUgdGV4 dCBtb2RpZmljYXRpb25zIHRoYXQgSSBoYXZlIHN1Ym1pdHRlZCB0byBzY290dCBhbmQNCj4+Pj4g Y29waWVkIHRvIHRoZSBwYXdzIHJlZmxlY3RvciBpbiBteSBlbWFpbCBkYXRlZCA4IEF1Z3VzdCBi ZSBpbmNsdWRlZCBhcw0KPj4+PiB3ZWxsPw0KPj4+PiANCj4+Pj4gVGhhbmsncywNCj4+Pj4gDQo+ Pj4+IEdlcmFsZA0KPj4+PiANCj4+Pj4gDQo+Pj4+IEF0IDIwOjMyIDA3LTA5LTExICswMDAwLCBH YWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+Pj4+PiBPaywgbGV0J3MgdHJ5IHRoYXQgdGhl bi4NCj4+Pj4+IFNjb3R0LCBjYW4geW91IHB1dCB1c2UgY2FzZXMgYmVmb3JlIFBTLCBhbmQgYWRk IHRoZSBhZC1ob2MgdXNlIGNhc2UuIEkNCj4+Pj4+IGp1c3Qgc2Nhbm5lZCB0aHJvdWdoIHRoZSBs aXN0IGFuZCBzcG90dGVkIHRoYXQgVGVjbyBpbmRlZWQgcHJvdmlkZWQgYQ0KPj4+Pj4gZGVzY3Jp cHRpb24gZm9yIHRoYXQgdXNlIGNhc2Ugb24gQXVnIDNyZC4NCj4+Pj4+IEFuZCBzdWJtaXQgdGhl IGRyYWZ0IGFzIGEgd2cgaXRlbSwgdW5sZXNzIHRoZXJlIGFyZSBzdGlsbCBvYmplY3Rpb25zLg0K Pj4+Pj4gDQo+Pj4+PiAtR2Fib3INCj4+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+IEZyb206IGV4dCBOYW5jeSBCcmF2aW4gW21haWx0bzpuYnJhdmluQGVhcnRo bGluay5uZXRdDQo+Pj4+PiBTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDAzLCAyMDExIDM6NDEg UE0NCj4+Pj4+IFRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+Pj4+ PiBDYzogVGVjbyBCb290OyBHZXJhbGQgQ2hvdWluYXJkOyBwYXdzQGlldGYub3JnDQo+Pj4+PiBT dWJqZWN0OiBSZTogW3Bhd3NdIGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2UgY2FzZXMg JiByZXF1aXJlbWVudHMNCj4+Pj4+IA0KPj4+Pj4gRGVhciBHYWJvciBhbmQgQWxsLA0KPj4+Pj4g DQo+Pj4+PiBJIHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRvIHB1dCB0aGUgdXNlIGNhc2VzIGJl Zm9yZSB0aGUgUFMgZm9yIG9idmlvdXMNCj4+Pj4+IHJlYXNvbnMsIGFuZCBpbmNsdWRpbmcgdGhl ICJwcm94eSIgbmVlZCBpbiB0aGUgZmlyc3QgZHJhZnQuIEkgc3VwcG9ydA0KPj4+Pj4gaW5jbHVk aW5nIGJvdGggR2VyYWxkJ3Mgc3VnZ2VzdGlvbnMgYW5kIFRlY28ncyBwcm9wb3NhbCBpbiB0aGUg b3JpZ2luYWwNCj4+Pj4+IGRyYWZ0IGFuZCBub3Qgd2FpdGluZyB1bnRpbCBhIGxhdGVyIHRpbWUu IEl0IGlzIHRoZSBwcm9wZXIgb3JkZXIsDQo+Pj4+PiBpbmNsdXNpdmUgYW5kIG5lZWRlZCBpbiB0 aGUgaW5pdGlhbCBkcmFmdCBpbiBteSBvcGluaW9uLiBJIGJlbGlldmUgd2l0aA0KPj4+Pj4gdGhl IHRhbGVudCBpbiB0aGUgZ3JvdXAgaXQgd2lsbCBub3QgdGFrZSBsb25nIHRvIGFjY29tcGxpc2gg dGhpcyBhbmQgeW91DQo+Pj4+PiB3aWxsIGhhdmUgYSBtb3JlIGNvaGVzaXZlIGRyYWZ0Lg0KPj4+ Pj4gDQo+Pj4+PiBTSW5jZXJlbHksIE5hbmN5DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT24gU2Vw IDIsIDIwMTEsIGF0IDI6MTkgUE0sIDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQo+Pj4+PiA8R2Fi b3IuQmFqa29Abm9raWEuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IFRlY28sIEdlcmFsZCwN Cj4+Pj4+PiANCj4+Pj4+PiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gSSdkIHN1Z2dlc3QgdGhh dCB3ZSBtYWtlIHRoaXMgZHJhZnQgYSBXRw0KPj4+Pj4gaXRlbSwNCj4+Pj4+IHdpdGggR2VyYWxk J3MgcHJvcG9zZWQgY2hhbmdlcyBpbiBpdC4gUmVnYXJkaW5nIHRoZSBvcmRlciBvZiB0aGUNCj4+ Pj4+IHByb2JsZW0NCj4+Pj4+IHN0YXRlbWVudCB2cyB1c2UgY2FzZXMsIG15IHByZWZlcmVuY2Ug d291bGQgYmUgdG8gbGVhdmUgaXQgYXMgaXQgaXMNCj4+Pj4+IChidXQNCj4+Pj4+IHdlIGNhbiBh bHdheXMgY2hhbmdlIGl0LCBpZiB0aGF0IGlzIHdoYXQgdGhlIFdHIHdhbnRzKS4NCj4+Pj4+PiAN Cj4+Pj4+PiBTbywgSSdkIGFzayBTY290dCB0byBzdWJtaXQgYSBXRyB2ZXJzaW9uIG9mIHRoaXMg ZHJhZnQsIHRoZW4gaGF2ZQ0KPj4+Pj4gc29tZW9uZSBjb21lIHVwIHdpdGggdGV4dCBmb3IgdGhp cyBhZC1ob2MgbmV0d29yayBzY2VuYXJpbywgaGF2ZSB0aGUgV0cNCj4+Pj4+IGFncmVlIHdpdGgg dGhlIHRleHQgYW5kIGluY2x1ZGUgaXQgaW4gb25lIG9mIHRoZSBzdWJzZXF1ZW50IHZlcnNpb25z Lg0KPj4+Pj4gVGVjbywgd291bGQgeW91IHdyaXRlIHVwIHNvbWUgdGV4dCBmb3IgdGhpcyBhZC1o b2MgdXNlIGNhc2UgdGhlIFdHDQo+Pj4+PiBjb3VsZA0KPj4+Pj4gZGlzY3Vzcz8NCj4+Pj4+PiAN Cj4+Pj4+PiBXZSdsbCBhbHNvIHNlbmQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgbGlzdCBvZiBy ZXF1aXJlbWVudHMgdG8gdGhlDQo+Pj4+PiBsaXN0IG5leHQgd2Vlay4NCj4+Pj4+PiANCj4+Pj4+ PiAtIEdhYm9yDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+PiBGcm9tOiBleHQgVGVjbyBCb290IFttYWlsdG86dGVjb0BpbmYtbmV0Lm5s XQ0KPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTEgMTE6MDYgUE0NCj4+ Pj4+PiBUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KQ0KPj4+Pj4+IENj OiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtwYXdzXSBjb21iaW5lZCBwcm9i bGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzICYNCj4+Pj4+PiByZXF1aXJlbWVudHMNCj4+Pj4+PiAN Cj4+Pj4+PiBJIHRoaW5rIHRoZSBkb2MgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50LiBJIHN1cHBv cnQgYWRvcHRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBzdWdnZXN0IHJlb3JkZXJpbmc6IHNwZWNp ZnlpbmcgcHJvYmxlbSBzdGF0ZW1lbnQgYWZ0ZXIgaW50cm9kdWNpbmcNCj4+Pj4+IHRoZSB1c2Ug Y2FzZXMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gU29tZSBhc2tlZCBmb3IgdGhlIGFkIGhvYyBuZXR3b3Jr IHNjZW5hcmlvLiBUaGlzIGluY2x1ZGVzIG1lIDotKS4NCj4+Pj4+IFRoaXMNCj4+Pj4+IGlzIGlt cG9ydGFudCwgYmVjYXVzZSBpdCBkZW1vbnN0cmF0ZXMgdGhlIG5lZWQgZm9yICJwcm94eSIuDQo+ Pj4+Pj4gQlRXLCBJIHdvbmRlciB3aHkgc2ltaWxhciBzY2VuYXJpbyBkb2Vzbid0IHBvcCB1cCBm cm9tIFdpRmkNCj4+Pj4+IGRlcGxveW1lbnRzLiBVc2FnZSBvZiBjb250cm9sbGVycyBpbiBsYXJn ZSBzaXRlcyBpcyBub3QgdW5jb21tb24uIE5vdA0KPj4+Pj4gdG8NCj4+Pj4+IG1lbnRpb24gMTFz Lg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSByZXF1aXJlbWVudHMgaXMgbGVmdCBvcGVuLiBJJ20gbG9v a2luZyBmb3J3YXJkIHNlZSBzb21lIGRyYWZ0DQo+Pj4+PiB0ZXh0Lg0KPj4+Pj4+IA0KPj4+Pj4+ IFRoYW5rcywgVGVjbw0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IE9wIDMwIGF1ZyAyMDExLCBv bSAxOTo0MiBoZWVmdCA8R2Fib3IuQmFqa29Abm9raWEuY29tPg0KPj4+Pj4gPEdhYm9yLkJhamtv QG5va2lhLmNvbT4gaGV0IHZvbGdlbmRlIGdlc2NocmV2ZW46DQo+Pj4+Pj4gDQo+Pj4+Pj4+IEkg c2VudCB0aGlzIGVtYWlsIHRvIHRoZSBsaXN0IG9uZSB3ZWVrIGFnbywgYXNraW5nIGZvciBmZWVk YmFjayBvbg0KPj4+Pj4+PiANCj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJv YmFzY28tcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdA0KPj4+Pj4+PiBzIC0wMC50eHQg YnV0IHRoZXJlIHdhcyBub3Qgb25lIGZlZWRiYWNrIHJlY2VpdmVkLiBJIHRha2UgdGhhdCBhcw0K Pj4+Pj4+PiBwZW9wbGUgaGF2ZSBubyBjb21tZW50cyB0byB0aGUgZHJhZnQgYXQgdGhpcyB0aW1l Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gQW5kIEkgYW0gYXNraW5nIGFnYWluOiBpcyB0aGVyZSBhbnkg b2JqZWN0aW9uIGluIGFkb3B0aW5nIHRoZSBhYm92ZQ0KPj4+Pj4gZHJhZnQgYXMgYSB3ZyBkb2N1 bWVudD8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IC1HYWJvcg0KPj4+Pj4+PiANCj4+Pj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+Pj4+Pj4gT2YgZXh0 IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj4+Pj4+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAyMiwg MjAxMSAyOjQzIFBNDQo+Pj4+Pj4+IFRvOiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4+IFN1YmplY3Q6 IFJlOiBbcGF3c10gY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQsIHVzZSBjYXNlcyAmDQo+Pj4+ Pj4+IHJlcXVpcmVtZW50cw0KPj4+Pj4+PiANCj4+Pj4+Pj4gRHVyaW5nIHRoZSBRdWViZWMgc2Vz c2lvbiwgd2UgaGFkIHByZXNlbnRhdGlvbnMgb2YgdGhlIFBTIGFuZCB0aGUNCj4+Pj4+IHVzZQ0K Pj4+Pj4gY2FzZXMgZHJhZnRzLiBUaGUgd2cgdGhlbiBkZWNpZGVkIGl0IHdhbnRzIHRvIHNlZSB0 aGVzZSBkcmFmdHMgbWVyZ2VkDQo+Pj4+PiBpbnRvIG9uZS4gU2NvdHQganVzdCBkaWQgdGhhdCBh bmQgcG9zdGVkIHRoZSBtZXJnZWQgZHJhZnQ6DQo+Pj4+Pj4+IA0KPj4+Pj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1wcm9iYXNjby1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10 DQo+Pj4+Pj4+IHMNCj4+Pj4+Pj4gLTAwLnR4dA0KPj4+Pj4+PiANCj4+Pj4+Pj4gTm93IEkgd291 bGQgbGlrZSB0byBhc2sgaWYgdGhlIHdnIGZlZWxzIGxpa2UgdGhpcyBkb2N1bWVudCBpcyByZWFk eQ0KPj4+Pj4gdG8NCj4+Pj4+IGJlIGFkb3B0ZWQgYXMgYSB3ZyBkb2N1bWVudC4gUGxlYXNlIHNl bmQgeW91ciBmZWVkYmFjayBhbmQgaHVtIHRvIHRoZQ0KPj4+Pj4gbGlzdCBieSB0aGlzIHRpbWUg bmV4dCB3ZWVrLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gLUdhYm9yDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAN Cj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+PiAtDQo+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+PiBGcm9tOiBQcm9iYXNjbyBTY290dA0KPj4+Pj4+PiBT ZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSA5OjE4IEFNDQo+Pj4+Pj4+IFRvOiBwYXdzQGll dGYub3JnDQo+Pj4+Pj4+IFN1YmplY3Q6IGNvbWJpbmVkIHByb2JsZW0gc3RhdGVtZW50LCB1c2Ug Y2FzZXMgJiByZXF1aXJlbWVudHMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEhpLA0KPj4+Pj4+PiANCj4+ Pj4+Pj4gQWNjb3JkaW5nIHRvIHRoZSByZXN1bHRzIG9mIHRoZSBmYWNlLXRvLWZhY2UgbWVldGlu Zywgd2UgaGF2ZQ0KPj4+Pj4gY29tYmluZWQNCj4+Pj4+IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBJ LUQgYW5kIHVzZSBjYXNlICYgcmVxdWlyZW1lbnQgSS1EIGludG8gYSBzaW5nbGUNCj4+Pj4+IEkt RC4gIFlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWVkLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gUmVnYXJk cywNCj4+Pj4+Pj4gU2NvdHQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFVSTDoNCj4+Pj4+Pj4gDQo+Pj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXByb2Jhc2NvLXBhd3MtcHJvYmxlbS1zdG10 LXVzZWNhc2VzLXJxbXQNCj4+Pj4+Pj4gcw0KPj4+Pj4+PiAtMDAudHh0DQo+Pj4+Pj4+IA0KPj4+ Pj4+PiANCj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+IFBvcnRpb25zIG9mIHRoZSByYWRpbyBz cGVjdHJ1bSB0aGF0IGFyZSBhbGxvY2F0ZWQgdG8gYSBsaWNlbnNlZCwNCj4+Pj4+Pj4gcHJpbWFy eSB1c2VyIGJ1dCBhcmUgdW51c2VkIG9yIHVub2NjdXBpZWQgYXQgc3BlY2lmaWMgbG9jYXRpb25z IGFuZA0KPj4+Pj4+PiB0aW1lcyBhcmUgZGVmaW5lZCBhcyAnd2hpdGUgc3BhY2UnLiAgVGhlIGNv bmNlcHQgb2YgYWxsb3dpbmcNCj4+Pj4+Pj4gc2Vjb25kYXJ5IHRyYW5zbWlzc2lvbnMgKGxpY2Vu c2VkIG9yIHVubGljZW5zZWQpIGluIHdoaXRlIHNwYWNlIGlzIGENCj4+Pj4+Pj4gdGVjaG5pcXVl IHRvICd1bmxvY2snIGV4aXN0aW5nIHNwZWN0cnVtIGZvciBuZXcgdXNlLiAgQW4gb2J2aW91cw0K Pj4+Pj4+PiByZXF1aXJlbWVudCBpcyB0aGF0IHRoZXNlIHNlY29uZGFyeSB0cmFuc21pc3Npb25z IGRvIG5vdCBpbnRlcmZlcmUNCj4+Pj4+Pj4gd2l0aCB0aGUgcHJpbWFyeSB1c2Ugb2YgdGhlIHNw ZWN0cnVtLiAgT25lIGFwcHJvYWNoIHRvIHVzaW5nIHRoZQ0KPj4+Pj4+PiB3aGl0ZSBzcGFjZSBz cGVjdHJ1bSBhdCBhIGdpdmVuIHRpbWUgYW5kIGxvY2F0aW9uIGlzIHRvIHZlcmlmeSB3aXRoDQo+ Pj4+PiBhDQo+Pj4+Pj4+IGRhdGFiYXNlIGF2YWlsYWJsZSBjaGFubmVscy4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBjb25jZXB0IG9mIFRWIFdoaXRlIFNw YWNlcy4gIEl0IGFsc28NCj4+Pj4+Pj4gZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyB0aGF0IG5lZWQg dG8gYmUgYWRkcmVzc2VkIGZvciBlbmFibGluZyB0aGUNCj4+Pj4+IHVzZQ0KPj4+Pj4+PiBvZiB0 aGUgcHJpbWFyeSB1c2VyIG93bmVkIHdoaXRlIHNwYWNlIHNwZWN0cnVtIGZvciBzZWNvbmRhcnkg dXNlcnMsDQo+Pj4+Pj4+IHdpdGhvdXQgY2F1c2luZyBpbnRlcmZlcmVuY2UsIGJ5IHF1ZXJ5aW5n IGEgZGF0YWJhc2Ugd2hpY2gga25vd3MgdGhlDQo+Pj4+Pj4+IGNoYW5uZWwgYXZhaWxhYmlsaXR5 IGF0IGFueSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZS4gIEEgbnVtYmVyIG9mDQo+Pj4+Pj4+IHBv c3NpYmxlIHVzZSBjYXNlcyBvZiB0aGlzIHNwZWN0cnVtIGFuZCBkZXJpdmVkIHJlcXVpcmVtZW50 cyBhcmUNCj4+Pj4+IGFsc28NCj4+Pj4+Pj4gZGVzY3JpYmVkLg0KPj4+Pj4+PiANCj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4g cGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gcGF3cyBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHBhd3MgbWFpbGluZyBsaXN0 DQo+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBwYXdzIG1haWxpbmcgbGlz dA0KPj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+PiBwYXdzQGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+IA0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4+PiBwYXdzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4gcGF3c0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBw YXdzIG1haWxpbmcgbGlzdA0KPiBwYXdzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQo= From brian.rosen@neustar.biz Wed Sep 14 05:53: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 B479521F8BCD for ; Wed, 14 Sep 2011 05:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 3lodCzb7QPMg for ; Wed, 14 Sep 2011 05:53:48 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A26BC21F8BCB for ; Wed, 14 Sep 2011 05:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1316004943; x=1631198311; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Uy4t1mjXPx/9r0CFGUnlk XynYH5yICd3Im1BBozjALg=; b=LSvu0h9XQMCZJWXPyqidfxE7OixIXK0wTbbEw qd3qauJcYb95Ep9nUTY3cJjS9wIi2uBwo1Q3nBeu3QRgORHEQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49586782; Wed, 14 Sep 2011 08:55:41 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 14 Sep 2011 08:55:41 -0400 From: "Rosen, Brian" To: Basavaraj Patil Date: Wed, 14 Sep 2011 08:55:40 -0400 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: Acxy3Ztm6hIlgxS1QmSFU7MZwONjyw== Message-ID: <70C17ADA-D805-4E32-A691-1976521FFEC2@neustar.biz> References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <21E7D9BD69CC7241AAE00F4EA183B719A97D3E@008-AM1MPN1-051.mgdnok.nokia.com> In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719A97D3E@008-AM1MPN1-051.mgdnok.nokia.com> 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: hSoO7hXQESVcVzugIBgnLg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 12:53:52 -0000 Correct. Our charter very specifically DOES NOT include mechanisms for multiple seco= ndary users to equitably share the available spectrum. It only is scoped f= or mechanisms for the secondary users to avoid interference with primary us= ers. When we solve the current problem, if there is enough interest, we mi= ght be able to recharter to work on sharing among secondary users. A narrowly scoped charter is a good thing in the IETF, but it means not all= the interests of the participants may be covered. Let's solve the current= problem, and if we have enough interest, we can expand later. Brian On Sep 13, 2011, at 10:54 PM, wrote: >=20 > Pete, >=20 > I dont believe co-ordination between BS' is needed.=20 > Interference mitigation between BS' is an interesting problem no doubt. B= ut it is not in the scope of the current charter. > Adjacent BS' (i.e Master WS devices) for example which query a database m= ay receive the same channel information. > This could result in interference. However that is an issue which the PAW= S WG is not chartered to solve.=20 > There is work on this happening in IEEE (802.19) but that aspect of cogni= tive radio is not something we are aiming to solve currently. >=20 > -Raj=20 > ________________________________________ > From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of ext Pete= r McCann [Peter.McCann@huawei.com] > Sent: Tuesday, September 13, 2011 12:37 PM > To: paws@ietf.org > Subject: [paws] Possible new use case: simulcasting >=20 > Hi, >=20 > I've been interacting with Zhu Lei off-list about his third use case, > and I think it would be a possible candidate for inclusion in the documen= t > if it were properly explained. >=20 > Generally (as opposed to specifically for the LTE MBMS case), the > problem is to find a common bit of spectrum that is > available over a wide area that can be used by multiple master BSs > to simultaneously broadcast the same signal to a set of receivers. > This is somewhat similar to the wide-area rural coverage scenario > currently described in the working group document; however, there > would be multiple Master BSs, each of which would independently query > the WSDB for available spectrum. However, they need to coordinate > the assignment so that they all get the same spectrum over the whole > area. As an implementation example, this could be achieved by each > BS reporting the same owner/operator and using a key or index value > to indicate that they wanted to coordinate the assignment. Alternatively= , > you might be able to elect one BS as the leader and collect location > information from all the other BSs and then coordinate the assignment > similar to the use case in 4.2; the difference would be that the > resulting assignment is for simultaneous (not TDD) use by all of the > BSs covering the wider area. >=20 > Does this sound like an interesting and novel use case? If so I can > do a more detailed writeup and supply ASCII art for the draft. >=20 > -- > Peter J. McCann > Huawei Technologies (USA) > Peter.McCann@Huawei.com > +1 908 541 3563 > Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 = USA >=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 Peter.McCann@huawei.com Wed Sep 14 05:56: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 A6C8221F8B00 for ; Wed, 14 Sep 2011 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 dKjbSBYZRedH for ; Wed, 14 Sep 2011 05:56:40 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2661021F8497 for ; Wed, 14 Sep 2011 05:56:25 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00DC6K1KPS@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 07:58:33 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI007KWK1JNC@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 07:58:32 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 05:58:32 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 05:58:29 -0700 Date: Wed, 14 Sep 2011 12:58:28 +0000 From: Peter McCann In-reply-to: <4E701599.7010804@joelhalpern.com> X-Originating-IP: [10.193.125.70] To: "Joel M. Halpern" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 12:56:44 -0000 Based on some of the existing use cases, it looks like the database is keeping state even for the secondary users. That is, it is acting as a de-facto registry for users of the secondary spectrum and will refuse to allocate the same spectrum to different users in overlapping geographic regions. Am I mistaken in this assumption? -Pete Joel M. Halpern wrote: > I may be missing something, but it seems to me taht what you are > describing is not the job of the database query protocol. base > station coordination is an interesting problem, but is it within scope > for this WG? (I do not think just specifying the same owner to the > database will resolve the problem, and it makes the database state > MUCH more > complex.) > > Yours, > Joel > > On 9/13/2011 1:37 PM, Peter McCann wrote: >> Hi, >> >> I've been interacting with Zhu Lei off-list about his third use >> case, and I think it would be a possible candidate for inclusion in >> the document if it were properly explained. >> >> Generally (as opposed to specifically for the LTE MBMS case), the >> problem is to find a common bit of spectrum that is available over a >> wide area that can be used by multiple master BSs to simultaneously >> broadcast the same signal to a set of receivers. This is somewhat >> similar to the wide-area rural coverage scenario currently described in >> the working group document; however, there would be multiple Master >> BSs, each of which would independently query the WSDB for available >> spectrum. However, they need to coordinate the assignment so that they >> all get the same spectrum over the whole area. As an implementation >> example, this could be achieved by each BS reporting the same >> owner/operator and using a key or index value to indicate that they >> wanted to coordinate the assignment. Alternatively, you might be able >> to elect one BS as the leader and collect location information from all >> the other BSs and then coordinate the assignment similar to the use >> case in 4.2; the difference would be that the resulting assignment is >> for simultaneous (not TDD) use by all of the BSs covering the wider >> area. >> >> Does this sound like an interesting and novel use case? If so I can >> do a more detailed writeup and supply ASCII art for the draft. >> >> -- >> Peter J. McCann >> Huawei Technologies (USA) >> Peter.McCann@Huawei.com >> +1 908 541 3563 >> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >> 08807-2863 USA >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From scott.probasco@nokia.com Wed Sep 14 06:02: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 6DC4C21F8C65 for ; Wed, 14 Sep 2011 06:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.670, 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 C1WJpLANG5aH for ; Wed, 14 Sep 2011 06:02:20 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4A73921F8C57 for ; Wed, 14 Sep 2011 06:02:20 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8ED45W4003993; Wed, 14 Sep 2011 16:04:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 16:04:18 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 15:04:17 +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; Wed, 14 Sep 2011 15:04:17 +0200 From: To: , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSA Date: Wed, 14 Sep 2011 13:04:16 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.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.241.50.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 13:04:18.0138 (UTC) FILETIME=[CFCAC3A0:01CC72DE] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:02:24 -0000 Hi, Thank you Peter & Lei for the more detailed description of the use case. When I look at this case, the question is: can PAWS be used to allow multiple Master devices to knowingly select the same channel for operation. (The discussion of "why" and "is it a good idea" not undertaken here as this likely wanders outside the scope of PAWS). One of the proposed solutions is coordination among BSs (external to PAWS). This is already described in section 4.3 Wide-Area or Rural internet broadband access: >Some of the masters/BSs may be deployed and operated by a single >entity, i.e. there can be centralized coordination between these >masters/BSs,... Further, you note the difference is in TDD: >The BS in this scenario use a TDD radio >Technology Would it be appropriate and acceptable to WG members to add "typically" such as: >The BS in this scenario typically uses a >TDD radio Technology... Does this enable the use case you are describing? Regards, Scott On 9/13/11 12:37 PM, "ext Peter McCann" wrote: >Hi, > >I've been interacting with Zhu Lei off-list about his third use case, >and I think it would be a possible candidate for inclusion in the document >if it were properly explained. > >Generally (as opposed to specifically for the LTE MBMS case), the >problem is to find a common bit of spectrum that is >available over a wide area that can be used by multiple master BSs >to simultaneously broadcast the same signal to a set of receivers. >This is somewhat similar to the wide-area rural coverage scenario >currently described in the working group document; however, there >would be multiple Master BSs, each of which would independently query >the WSDB for available spectrum. However, they need to coordinate >the assignment so that they all get the same spectrum over the whole >area. As an implementation example, this could be achieved by each >BS reporting the same owner/operator and using a key or index value >to indicate that they wanted to coordinate the assignment. Alternatively, >you might be able to elect one BS as the leader and collect location >information from all the other BSs and then coordinate the assignment >similar to the use case in 4.2; the difference would be that the >resulting assignment is for simultaneous (not TDD) use by all of the >BSs covering the wider area. > >Does this sound like an interesting and novel use case? If so I can >do a more detailed writeup and supply ASCII art for the draft. > >-- >Peter J. McCann >Huawei Technologies (USA) >Peter.McCann@Huawei.com >+1 908 541 3563 >Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 >USA > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Wed Sep 14 06:02: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 782D521F8CB6 for ; Wed, 14 Sep 2011 06:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.619, 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 yVaAYr2mi8En for ; Wed, 14 Sep 2011 06:02:34 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7146221F8CB8 for ; Wed, 14 Sep 2011 06:02:34 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8ED45W9003993; Wed, 14 Sep 2011 16:04:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 16:04:19 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 15:04:18 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 15:04:18 +0200 From: To: , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAATTVhQAAbGNIA= Date: Wed, 14 Sep 2011 13:04:18 +0000 Message-ID: In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719A97D3E@008-AM1MPN1-051.mgdnok.nokia.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.241.50.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E9E5D05B320E841B50621ABB433A2D3@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 13:04:19.0138 (UTC) FILETIME=[D0635A20:01CC72DE] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:02:38 -0000 Hi, Coexistence is a very interesting topic which I hope we can consider after the first version of PAWS is complete. Regards, Scott On 9/13/11 9:54 PM, "ext Basavaraj.Patil@nokia.com" wrote: > >Pete, > >I dont believe co-ordination between BS' is needed. >Interference mitigation between BS' is an interesting problem no doubt. >But it is not in the scope of the current charter. >Adjacent BS' (i.e Master WS devices) for example which query a database >may receive the same channel information. >This could result in interference. However that is an issue which the >PAWS WG is not chartered to solve. >There is work on this happening in IEEE (802.19) but that aspect of >cognitive radio is not something we are aiming to solve currently. > >-Raj=20 >________________________________________ >From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of ext >Peter McCann [Peter.McCann@huawei.com] >Sent: Tuesday, September 13, 2011 12:37 PM >To: paws@ietf.org >Subject: [paws] Possible new use case: simulcasting > >Hi, > >I've been interacting with Zhu Lei off-list about his third use case, >and I think it would be a possible candidate for inclusion in the document >if it were properly explained. > >Generally (as opposed to specifically for the LTE MBMS case), the >problem is to find a common bit of spectrum that is >available over a wide area that can be used by multiple master BSs >to simultaneously broadcast the same signal to a set of receivers. >This is somewhat similar to the wide-area rural coverage scenario >currently described in the working group document; however, there >would be multiple Master BSs, each of which would independently query >the WSDB for available spectrum. However, they need to coordinate >the assignment so that they all get the same spectrum over the whole >area. As an implementation example, this could be achieved by each >BS reporting the same owner/operator and using a key or index value >to indicate that they wanted to coordinate the assignment. Alternatively, >you might be able to elect one BS as the leader and collect location >information from all the other BSs and then coordinate the assignment >similar to the use case in 4.2; the difference would be that the >resulting assignment is for simultaneous (not TDD) use by all of the >BSs covering the wider area. > >Does this sound like an interesting and novel use case? If so I can >do a more detailed writeup and supply ASCII art for the draft. > >-- >Peter J. McCann >Huawei Technologies (USA) >Peter.McCann@Huawei.com >+1 908 541 3563 >Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 >USA > > >_______________________________________________ >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 Sep 14 06:10: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 4853A21F8CEB for ; Wed, 14 Sep 2011 06:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 pIm2Rn1ierIX for ; Wed, 14 Sep 2011 06:09:52 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B9CAF21F8CE3 for ; Wed, 14 Sep 2011 06:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1316005866; x=1631198311; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=7WjESIiZv6ZqcM9uw9h+N YWBmaCyA4WybGLJv42vJvY=; b=Td++b0nkI3e+MWf92cCAawxAQI+zM8RV8crcN 58IInWcOwaWDUSHUJVZNJ55HV83lCHHd4anoxszku2s631YDg== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49587831; Wed, 14 Sep 2011 09:11:05 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 14 Sep 2011 09:11:05 -0400 From: "Rosen, Brian" To: Peter McCann Date: Wed, 14 Sep 2011 09:11:02 -0400 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: Acxy38J9OPxDzj32TE6U3iLdUWnfJQ== Message-ID: <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> 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: flIQVSeLoMHpe+0se1q36w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:10:23 -0000 Yes, you are mistaken. If two queriers with the same location and input parameters query the datab= ase, they will get the same response. Suppose two U.S. Mode I devices at = essentially the same location (within 25 meters) query the database, and th= e first is told he may use TV channels 1-5, 9-11 and 25-33. The second one= will be told the same thing. The database knows query patterns, but does not track use. Specifically, i= t doesn't know what part of the spectrum the device actually chooses to use= , when it starts using it, and when it ceases to use it. =20 Brian On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: > Based on some of the existing use cases, it looks like the database > is keeping state even for the secondary users. That is, it is acting > as a de-facto registry for users of the secondary spectrum and will > refuse to allocate the same spectrum to different users in overlapping > geographic regions. Am I mistaken in this assumption? >=20 > -Pete >=20 >=20 > Joel M. Halpern wrote: >> I may be missing something, but it seems to me taht what you are >> describing is not the job of the database query protocol. base >> station coordination is an interesting problem, but is it within scope >> for this WG? (I do not think just specifying the same owner to the >> database will resolve the problem, and it makes the database state >> MUCH more >> complex.) >>=20 >> Yours, >> Joel >>=20 >> On 9/13/2011 1:37 PM, Peter McCann wrote: >>> Hi, >>>=20 >>> I've been interacting with Zhu Lei off-list about his third use >>> case, and I think it would be a possible candidate for inclusion in >>> the document if it were properly explained. >>>=20 >>> Generally (as opposed to specifically for the LTE MBMS case), the >>> problem is to find a common bit of spectrum that is available over a >>> wide area that can be used by multiple master BSs to simultaneously >>> broadcast the same signal to a set of receivers. This is somewhat >>> similar to the wide-area rural coverage scenario currently described in >>> the working group document; however, there would be multiple Master >>> BSs, each of which would independently query the WSDB for available >>> spectrum. However, they need to coordinate the assignment so that they >>> all get the same spectrum over the whole area. As an implementation >>> example, this could be achieved by each BS reporting the same >>> owner/operator and using a key or index value to indicate that they >>> wanted to coordinate the assignment. Alternatively, you might be able >>> to elect one BS as the leader and collect location information from all >>> the other BSs and then coordinate the assignment similar to the use >>> case in 4.2; the difference would be that the resulting assignment is >>> for simultaneous (not TDD) use by all of the BSs covering the wider >>> area. >>>=20 >>> Does this sound like an interesting and novel use case? If so I can >>> do a more detailed writeup and supply ASCII art for the draft. >>>=20 >>> -- >>> Peter J. McCann >>> Huawei Technologies (USA) >>> Peter.McCann@Huawei.com >>> +1 908 541 3563 >>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>> 08807-2863 USA >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Sep 14 06:16: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 6B57F21F8B50 for ; Wed, 14 Sep 2011 06:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 gcM5jnzFvLiw for ; Wed, 14 Sep 2011 06:16:46 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id C55F521F8AFF for ; Wed, 14 Sep 2011 06:16:46 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00DXWKZJPS@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 08:18:55 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI007D4KZINC@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 08:18:55 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 06:18:55 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 06:18:51 -0700 Date: Wed, 14 Sep 2011 13:18:51 +0000 From: Peter McCann In-reply-to: <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> X-Originating-IP: [10.193.125.70] To: "Rosen, Brian" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:16:47 -0000 However, the location-based services use case clearly has the white space database keeping state on the secondary user, at least his location. Step 7 of the Hotspot use case has the BS registering the spectrum that it selected for its use. If the database is keeping state in this manner, it could easily calculate the exclusion zones for the secondary users as well. Or did these use cases as described exceed the mandate of the charter? -Pete Rosen, Brian wrote: > Yes, you are mistaken. > > If two queriers with the same location and input parameters query the > database, they will get the same response. Suppose two U.S. Mode I > devices at essentially the same location (within 25 meters) query the > database, and the first is told he may use TV channels 1-5, 9-11 and > 25-33. The second one will be told the same thing. > > The database knows query patterns, but does not track use. > Specifically, it doesn't know what part of the spectrum the device > actually chooses to use, when it starts using it, and when it ceases > to use it. > > Brian > > > On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: > >> Based on some of the existing use cases, it looks like the database is >> keeping state even for the secondary users. That is, it is acting as a >> de-facto registry for users of the secondary spectrum and will refuse >> to allocate the same spectrum to different users in overlapping >> geographic regions. Am I mistaken in this assumption? >> >> -Pete >> >> >> Joel M. Halpern wrote: >>> I may be missing something, but it seems to me taht what you are >>> describing is not the job of the database query protocol. base >>> station coordination is an interesting problem, but is it within scope >>> for this WG? (I do not think just specifying the same owner to the >>> database will resolve the problem, and it makes the database state >>> MUCH more complex.) >>> >>> Yours, >>> Joel >>> >>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>> Hi, >>>> >>>> I've been interacting with Zhu Lei off-list about his third use >>>> case, and I think it would be a possible candidate for inclusion >>>> in the document if it were properly explained. >>>> >>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>> problem is to find a common bit of spectrum that is available over a >>>> wide area that can be used by multiple master BSs to simultaneously >>>> broadcast the same signal to a set of receivers. This is somewhat >>>> similar to the wide-area rural coverage scenario currently described >>>> in the working group document; however, there would be multiple >>>> Master BSs, each of which would independently query the WSDB for >>>> available spectrum. However, they need to coordinate the assignment >>>> so that they all get the same spectrum over the whole area. As an >>>> implementation example, this could be achieved by each BS reporting >>>> the same owner/operator and using a key or index value to indicate >>>> that they wanted to coordinate the assignment. Alternatively, you >>>> might be able to elect one BS as the leader and collect location >>>> information from all the other BSs and then coordinate the assignment >>>> similar to the use case in 4.2; the difference would be that the >>>> resulting assignment is for simultaneous (not TDD) use by all of the >>>> BSs covering the wider area. >>>> >>>> Does this sound like an interesting and novel use case? If so I can >>>> do a more detailed writeup and supply ASCII art for the draft. >>>> >>>> -- >>>> Peter J. McCann >>>> Huawei Technologies (USA) >>>> Peter.McCann@Huawei.com >>>> +1 908 541 3563 >>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>> 08807-2863 USA From Peter.McCann@huawei.com Wed Sep 14 06:18: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 1DBD321F8BF9 for ; Wed, 14 Sep 2011 06:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 vp6vrjxEVWVj for ; Wed, 14 Sep 2011 06:18:27 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0283921F8B58 for ; Wed, 14 Sep 2011 06:18:27 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00DA7L2BPS@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 08:20:35 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI007MEL2BNC@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 08:20:35 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 06:20:36 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 06:20:31 -0700 Date: Wed, 14 Sep 2011 13:20:31 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:18:31 -0000 Hi, Scott, scott.probasco@nokia.com wrote: > Hi, > > Thank you Peter & Lei for the more detailed description of the use case. > When I look at this case, the question is: can PAWS be used to allow > multiple Master devices to knowingly select the same channel for > operation. (The discussion of "why" and "is it a good idea" not > undertaken here as this likely wanders outside the scope of PAWS). > > One of the proposed solutions is coordination among BSs (external to > PAWS). This is already described in section 4.3 Wide-Area or Rural > internet broadband access: > >> Some of the masters/BSs may be deployed and operated by a single >> entity, i.e. there can be centralized coordination between these >> masters/BSs,... > > Further, you note the difference is in TDD: > >> The BS in this scenario use a TDD radio >> Technology > > Would it be appropriate and acceptable to WG members to add "typically" > such as: > >> The BS in this scenario typically uses a >> TDD radio Technology... > > Does this enable the use case you are describing? Maybe we could say: The BS in this scenario typically use a TDD radio technology or other means to coordinate use of the selected spectrum. -Pete > > > > Regards, > Scott > > > On 9/13/11 12:37 PM, "ext Peter McCann" wrote: > >> Hi, >> >> I've been interacting with Zhu Lei off-list about his third use case, >> and I think it would be a possible candidate for inclusion in the >> document if it were properly explained. >> >> Generally (as opposed to specifically for the LTE MBMS case), the >> problem is to find a common bit of spectrum that is available over a >> wide area that can be used by multiple master BSs to simultaneously >> broadcast the same signal to a set of receivers. This is somewhat >> similar to the wide-area rural coverage scenario currently described in >> the working group document; however, there would be multiple Master >> BSs, each of which would independently query the WSDB for available >> spectrum. However, they need to coordinate the assignment so that they >> all get the same spectrum over the whole area. As an implementation >> example, this could be achieved by each BS reporting the same >> owner/operator and using a key or index value to indicate that they >> wanted to coordinate the assignment. Alternatively, you might be able >> to elect one BS as the leader and collect location information from all >> the other BSs and then coordinate the assignment similar to the use >> case in 4.2; the difference would be that the resulting assignment is >> for simultaneous (not TDD) use by all of the BSs covering the wider >> area. >> >> Does this sound like an interesting and novel use case? If so I can do >> a more detailed writeup and supply ASCII art for the draft. >> >> -- >> Peter J. McCann >> Huawei Technologies (USA) >> Peter.McCann@Huawei.com >> +1 908 541 3563 >> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >> 08807-2863 USA >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Sep 14 06:23: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 2359421F8C99 for ; Wed, 14 Sep 2011 06:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 jQc+06nu04hQ for ; Wed, 14 Sep 2011 06:23:43 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B8DF421F8C00 for ; Wed, 14 Sep 2011 06:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1316006742; x=1631198311; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=0hFHRlxBktuVwV40BhOwE Fx0vTX9XcM5JuDr5aKDyg4=; b=mrH+hB50w0z0vbHx2dnAk5VzO1nW6BtRYnxpY DZQCdbkVaFkM0qgsMOZ+MOq2Brtu8f1DgZ3OBTIWHPabnvhEQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49588571; Wed, 14 Sep 2011 09:25:41 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 14 Sep 2011 09:25:41 -0400 From: "Rosen, Brian" To: Peter McCann Date: Wed, 14 Sep 2011 09:25:40 -0400 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: Acxy4cxnMKNKvFfXQxarU3Yd1e+Rag== Message-ID: References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> 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: oC8pBab6WqJzt9TyB6pe+g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:23:47 -0000 It's beyond the charter. This was discussed when we created the charter, a= nd explicitly excluded it for this initial work. Brian On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: > However, the location-based services use case clearly has the > white space database keeping state on the secondary user, at > least his location. Step 7 of the Hotspot use case has the=20 > BS registering the spectrum that it selected for its use. > If the database is keeping state in this manner, it could easily > calculate the exclusion zones for the secondary users as well. >=20 > Or did these use cases as described exceed the mandate of the > charter? >=20 > -Pete >=20 > Rosen, Brian wrote: >> Yes, you are mistaken. >>=20 >> If two queriers with the same location and input parameters query the >> database, they will get the same response. Suppose two U.S. Mode I >> devices at essentially the same location (within 25 meters) query the >> database, and the first is told he may use TV channels 1-5, 9-11 and >> 25-33. The second one will be told the same thing. >>=20 >> The database knows query patterns, but does not track use. >> Specifically, it doesn't know what part of the spectrum the device >> actually chooses to use, when it starts using it, and when it ceases >> to use it. >>=20 >> Brian >>=20 >>=20 >> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>=20 >>> Based on some of the existing use cases, it looks like the database is >>> keeping state even for the secondary users. That is, it is acting as a >>> de-facto registry for users of the secondary spectrum and will refuse >>> to allocate the same spectrum to different users in overlapping >>> geographic regions. Am I mistaken in this assumption? >>>=20 >>> -Pete >>>=20 >>>=20 >>> Joel M. Halpern wrote: >>>> I may be missing something, but it seems to me taht what you are >>>> describing is not the job of the database query protocol. base >>>> station coordination is an interesting problem, but is it within scope >>>> for this WG? (I do not think just specifying the same owner to the >>>> database will resolve the problem, and it makes the database state >>>> MUCH more complex.) >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>> Hi, >>>>>=20 >>>>> I've been interacting with Zhu Lei off-list about his third use >>>>> case, and I think it would be a possible candidate for inclusion >>>>> in the document if it were properly explained. >>>>>=20 >>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>> problem is to find a common bit of spectrum that is available over a >>>>> wide area that can be used by multiple master BSs to simultaneously >>>>> broadcast the same signal to a set of receivers. This is somewhat >>>>> similar to the wide-area rural coverage scenario currently described >>>>> in the working group document; however, there would be multiple >>>>> Master BSs, each of which would independently query the WSDB for >>>>> available spectrum. However, they need to coordinate the assignment >>>>> so that they all get the same spectrum over the whole area. As an >>>>> implementation example, this could be achieved by each BS reporting >>>>> the same owner/operator and using a key or index value to indicate >>>>> that they wanted to coordinate the assignment. Alternatively, you >>>>> might be able to elect one BS as the leader and collect location >>>>> information from all the other BSs and then coordinate the assignment >>>>> similar to the use case in 4.2; the difference would be that the >>>>> resulting assignment is for simultaneous (not TDD) use by all of the >>>>> BSs covering the wider area. >>>>>=20 >>>>> Does this sound like an interesting and novel use case? If so I can >>>>> do a more detailed writeup and supply ASCII art for the draft. >>>>>=20 >>>>> -- >>>>> Peter J. McCann >>>>> Huawei Technologies (USA) >>>>> Peter.McCann@Huawei.com >>>>> +1 908 541 3563 >>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>> 08807-2863 USA >=20 >=20 >=20 From Peter.McCann@huawei.com Wed Sep 14 06:47: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 91A1A21F8B5A for ; Wed, 14 Sep 2011 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ZxmIaoyBEe5C for ; Wed, 14 Sep 2011 06:47:56 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id D983221F84D4 for ; Wed, 14 Sep 2011 06:47:55 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00GF6LM9FQ@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 08:32:34 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRI005HILCCSG@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 08:26:36 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 06:26:32 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 06:26:32 -0700 Date: Wed, 14 Sep 2011 13:26:32 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "Rosen, Brian" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A061@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQCAAHU0wA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 13:47:56 -0000 So do these use cases in the accepted working group document need to be modified, then? -Pete Rosen, Brian wrote: > It's beyond the charter. This was discussed when we created the > charter, and explicitly excluded it for this initial work. > > Brian > > On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: > >> However, the location-based services use case clearly has the white >> space database keeping state on the secondary user, at least his >> location. Step 7 of the Hotspot use case has the BS registering the >> spectrum that it selected for its use. >> If the database is keeping state in this manner, it could easily >> calculate the exclusion zones for the secondary users as well. >> >> Or did these use cases as described exceed the mandate of the charter? >> >> -Pete >> >> Rosen, Brian wrote: >>> Yes, you are mistaken. >>> >>> If two queriers with the same location and input parameters query the >>> database, they will get the same response. Suppose two U.S. Mode I >>> devices at essentially the same location (within 25 meters) query the >>> database, and the first is told he may use TV channels 1-5, 9-11 and >>> 25-33. The second one will be told the same thing. >>> >>> The database knows query patterns, but does not track use. >>> Specifically, it doesn't know what part of the spectrum the device >>> actually chooses to use, when it starts using it, and when it >>> ceases to use it. >>> >>> Brian >>> >>> >>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>> >>>> Based on some of the existing use cases, it looks like the >>>> database is keeping state even for the secondary users. That is, >>>> it is acting as a de-facto registry for users of the secondary >>>> spectrum and will refuse to allocate the same spectrum to >>>> different users in overlapping geographic regions. Am I mistaken in this assumption? >>>> >>>> -Pete >>>> >>>> >>>> Joel M. Halpern wrote: >>>>> I may be missing something, but it seems to me taht what you are >>>>> describing is not the job of the database query protocol. base >>>>> station coordination is an interesting problem, but is it within >>>>> scope for this WG? (I do not think just specifying the same owner >>>>> to the database will resolve the problem, and it makes the database >>>>> state MUCH more complex.) >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>> Hi, >>>>>> >>>>>> I've been interacting with Zhu Lei off-list about his third use >>>>>> case, and I think it would be a possible candidate for inclusion >>>>>> in the document if it were properly explained. >>>>>> >>>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>>> problem is to find a common bit of spectrum that is available over >>>>>> a wide area that can be used by multiple master BSs to >>>>>> simultaneously broadcast the same signal to a set of receivers. >>>>>> This is somewhat similar to the wide-area rural coverage scenario >>>>>> currently described in the working group document; however, there >>>>>> would be multiple Master BSs, each of which would independently >>>>>> query the WSDB for available spectrum. However, they need to >>>>>> coordinate the assignment so that they all get the same spectrum >>>>>> over the whole area. As an implementation example, this could be >>>>>> achieved by each BS reporting the same owner/operator and using a >>>>>> key or index value to indicate that they wanted to coordinate the >>>>>> assignment. Alternatively, you might be able to elect one BS as the >>>>>> leader and collect location information from all the other BSs and >>>>>> then coordinate the assignment similar to the use case in 4.2; the >>>>>> difference would be that the resulting assignment is for >>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >>>>>> area. >>>>>> >>>>>> Does this sound like an interesting and novel use case? If so I >>>>>> can do a more detailed writeup and supply ASCII art for the draft. >>>>>> >>>>>> -- >>>>>> Peter J. McCann >>>>>> Huawei Technologies (USA) >>>>>> Peter.McCann@Huawei.com >>>>>> +1 908 541 3563 >>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>> 08807-2863 USA >> >> >> From gerald.chouinard@crc.ca Wed Sep 14 07:36:39 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 C035E21F8B9F for ; Wed, 14 Sep 2011 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, 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 EOyXDjWQxu3r for ; Wed, 14 Sep 2011 07:36:35 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 8DCB721F8B88 for ; Wed, 14 Sep 2011 07:36:35 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 9E6856B04CC; Wed, 14 Sep 2011 10:38:39 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 82C4C6B03B7; Wed, 14 Sep 2011 10:38:39 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 74A5E6B03D2; Wed, 14 Sep 2011 10:38:39 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 4D6106B03B7; Wed, 14 Sep 2011 10:38:34 -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 E570D6B1561; Wed, 14 Sep 2011 10:38:33 -0400 (EDT) Message-Id: <5.1.0.14.2.20110914103336.02b6f128@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Sep 2011 10:38:36 -0400 To: Peter McCann , "Rosen, Brian" From: Gerald Chouinard In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A061@dfweml503-mbx.chi na.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 14:36:39 -0000 Peter, Brian, My suggestion would be to leave this feature in. It will not cost much to make room in the protocol for the TVBD to indicate to the database which channel it decided to operate on and it would provide easy extensibility to the protocol for an eventual consideration of the coexistence amongst the license-exempt devices. I would agree, however, that the current step of the protocol development should be limited to protecting of the broadcast incumbents as stated in the scope. Gerald At 13:26 14-09-11 +0000, Peter McCann wrote: >So do these use cases in the accepted working group document >need to be modified, then? > >-Pete > >Rosen, Brian wrote: > > It's beyond the charter. This was discussed when we created the > > charter, and explicitly excluded it for this initial work. > > > > Brian > > > > On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: > > > >> However, the location-based services use case clearly has the white > >> space database keeping state on the secondary user, at least his > >> location. Step 7 of the Hotspot use case has the BS registering the > >> spectrum that it selected for its use. > >> If the database is keeping state in this manner, it could easily > >> calculate the exclusion zones for the secondary users as well. > >> > >> Or did these use cases as described exceed the mandate of the charter? > >> > >> -Pete > >> > >> Rosen, Brian wrote: > >>> Yes, you are mistaken. > >>> > >>> If two queriers with the same location and input parameters query the > >>> database, they will get the same response. Suppose two U.S. Mode I > >>> devices at essentially the same location (within 25 meters) query the > >>> database, and the first is told he may use TV channels 1-5, 9-11 and > >>> 25-33. The second one will be told the same thing. > >>> > >>> The database knows query patterns, but does not track use. > >>> Specifically, it doesn't know what part of the spectrum the device > >>> actually chooses to use, when it starts using it, and when it > >>> ceases to use it. > >>> > >>> Brian > >>> > >>> > >>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: > >>> > >>>> Based on some of the existing use cases, it looks like the > >>>> database is keeping state even for the secondary users. That is, > >>>> it is acting as a de-facto registry for users of the secondary > >>>> spectrum and will refuse to allocate the same spectrum to > >>>> different users in overlapping geographic regions. Am I mistaken in > this assumption? > >>>> > >>>> -Pete > >>>> > >>>> > >>>> Joel M. Halpern wrote: > >>>>> I may be missing something, but it seems to me taht what you are > >>>>> describing is not the job of the database query protocol. base > >>>>> station coordination is an interesting problem, but is it within > >>>>> scope for this WG? (I do not think just specifying the same owner > >>>>> to the database will resolve the problem, and it makes the database > >>>>> state MUCH more complex.) > >>>>> > >>>>> Yours, > >>>>> Joel > >>>>> > >>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I've been interacting with Zhu Lei off-list about his third use > >>>>>> case, and I think it would be a possible candidate for inclusion > >>>>>> in the document if it were properly explained. > >>>>>> > >>>>>> Generally (as opposed to specifically for the LTE MBMS case), the > >>>>>> problem is to find a common bit of spectrum that is available over > >>>>>> a wide area that can be used by multiple master BSs to > >>>>>> simultaneously broadcast the same signal to a set of receivers. > >>>>>> This is somewhat similar to the wide-area rural coverage scenario > >>>>>> currently described in the working group document; however, there > >>>>>> would be multiple Master BSs, each of which would independently > >>>>>> query the WSDB for available spectrum. However, they need to > >>>>>> coordinate the assignment so that they all get the same spectrum > >>>>>> over the whole area. As an implementation example, this could be > >>>>>> achieved by each BS reporting the same owner/operator and using a > >>>>>> key or index value to indicate that they wanted to coordinate the > >>>>>> assignment. Alternatively, you might be able to elect one BS as the > >>>>>> leader and collect location information from all the other BSs and > >>>>>> then coordinate the assignment similar to the use case in 4.2; the > >>>>>> difference would be that the resulting assignment is for > >>>>>> simultaneous (not TDD) use by all of the BSs covering the wider > >>>>>> area. > >>>>>> > >>>>>> Does this sound like an interesting and novel use case? If so I > >>>>>> can do a more detailed writeup and supply ASCII art for the draft. > >>>>>> > >>>>>> -- > >>>>>> Peter J. McCann > >>>>>> Huawei Technologies (USA) > >>>>>> Peter.McCann@Huawei.com > >>>>>> +1 908 541 3563 > >>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ > >>>>>> 08807-2863 USA > >> > >> > >> > > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Sep 14 07:53:53 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 7D90921F888A for ; Wed, 14 Sep 2011 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 hz9-q5k1bOj3 for ; Wed, 14 Sep 2011 07:53:49 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4C21F8B42 for ; Wed, 14 Sep 2011 07:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1316012150; x=1631198311; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ZDCaXMET1MNpcSINWg6x1 QaWqx98D0Thkhc1BW8EBo4=; b=jmG6/O49UT+bdkagKStetVzJ1hM/TtG63oaWT 1J64/oqKN4vXrhO7YDx6s4UW6VWjjgygCd7cUJscBiC39QUpQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49593889; Wed, 14 Sep 2011 10:55:49 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 14 Sep 2011 10:55:49 -0400 From: "Rosen, Brian" To: Gerald Chouinard Date: Wed, 14 Sep 2011 10:55:48 -0400 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: Acxy7mO/gYvq83npSGCdhffWpONeTA== Message-ID: <88B20E31-8FFC-47F6-8272-C8D4000EB942@neustar.biz> References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914103336.02b6f128@imap.crc.ca> In-Reply-To: <5.1.0.14.2.20110914103336.02b6f128@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: 5gf8SRlXERi8vZ8y5fRtaQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 14:53:53 -0000 The problem is that this turns the transaction into multiple steps. As it = is now, you send a query and get a response. =20 If the device needs to update with what it used, that's another step. Also= , what happens if it changes its mind? Brian On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: > Peter, Brian, >=20 > My suggestion would be to leave this feature in. It will not cost much t= o=20 > make room in the protocol for the TVBD to indicate to the database which= =20 > channel it decided to operate on and it would provide easy extensibility = to=20 > the protocol for an eventual consideration of the coexistence amongst the= =20 > license-exempt devices. >=20 > I would agree, however, that the current step of the protocol development= =20 > should be limited to protecting of the broadcast incumbents as stated in= =20 > the scope. >=20 > Gerald >=20 >=20 > At 13:26 14-09-11 +0000, Peter McCann wrote: >> So do these use cases in the accepted working group document >> need to be modified, then? >>=20 >> -Pete >>=20 >> Rosen, Brian wrote: >>> It's beyond the charter. This was discussed when we created the >>> charter, and explicitly excluded it for this initial work. >>>=20 >>> Brian >>>=20 >>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>=20 >>>> However, the location-based services use case clearly has the white >>>> space database keeping state on the secondary user, at least his >>>> location. Step 7 of the Hotspot use case has the BS registering the >>>> spectrum that it selected for its use. >>>> If the database is keeping state in this manner, it could easily >>>> calculate the exclusion zones for the secondary users as well. >>>>=20 >>>> Or did these use cases as described exceed the mandate of the charter? >>>>=20 >>>> -Pete >>>>=20 >>>> Rosen, Brian wrote: >>>>> Yes, you are mistaken. >>>>>=20 >>>>> If two queriers with the same location and input parameters query the >>>>> database, they will get the same response. Suppose two U.S. Mode I >>>>> devices at essentially the same location (within 25 meters) query the >>>>> database, and the first is told he may use TV channels 1-5, 9-11 and >>>>> 25-33. The second one will be told the same thing. >>>>>=20 >>>>> The database knows query patterns, but does not track use. >>>>> Specifically, it doesn't know what part of the spectrum the device >>>>> actually chooses to use, when it starts using it, and when it >>>>> ceases to use it. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>=20 >>>>>> Based on some of the existing use cases, it looks like the >>>>>> database is keeping state even for the secondary users. That is, >>>>>> it is acting as a de-facto registry for users of the secondary >>>>>> spectrum and will refuse to allocate the same spectrum to >>>>>> different users in overlapping geographic regions. Am I mistaken in= =20 >> this assumption? >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>>=20 >>>>>> Joel M. Halpern wrote: >>>>>>> I may be missing something, but it seems to me taht what you are >>>>>>> describing is not the job of the database query protocol. base >>>>>>> station coordination is an interesting problem, but is it within >>>>>>> scope for this WG? (I do not think just specifying the same owner >>>>>>> to the database will resolve the problem, and it makes the database >>>>>>> state MUCH more complex.) >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I've been interacting with Zhu Lei off-list about his third use >>>>>>>> case, and I think it would be a possible candidate for inclusion >>>>>>>> in the document if it were properly explained. >>>>>>>>=20 >>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>>>>> problem is to find a common bit of spectrum that is available over >>>>>>>> a wide area that can be used by multiple master BSs to >>>>>>>> simultaneously broadcast the same signal to a set of receivers. >>>>>>>> This is somewhat similar to the wide-area rural coverage scenario >>>>>>>> currently described in the working group document; however, there >>>>>>>> would be multiple Master BSs, each of which would independently >>>>>>>> query the WSDB for available spectrum. However, they need to >>>>>>>> coordinate the assignment so that they all get the same spectrum >>>>>>>> over the whole area. As an implementation example, this could be >>>>>>>> achieved by each BS reporting the same owner/operator and using a >>>>>>>> key or index value to indicate that they wanted to coordinate the >>>>>>>> assignment. Alternatively, you might be able to elect one BS as th= e >>>>>>>> leader and collect location information from all the other BSs and >>>>>>>> then coordinate the assignment similar to the use case in 4.2; the >>>>>>>> difference would be that the resulting assignment is for >>>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >>>>>>>> area. >>>>>>>>=20 >>>>>>>> Does this sound like an interesting and novel use case? If so I >>>>>>>> can do a more detailed writeup and supply ASCII art for the draft. >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Peter J. McCann >>>>>>>> Huawei Technologies (USA) >>>>>>>> Peter.McCann@Huawei.com >>>>>>>> +1 908 541 3563 >>>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>>>> 08807-2863 USA >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 From jmh@joelhalpern.com Wed Sep 14 08:05:17 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 70D1621F8B13 for ; Wed, 14 Sep 2011 08:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 bb+BPFpk8zNH for ; Wed, 14 Sep 2011 08:05:13 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id E22EF21F8B3A for ; Wed, 14 Sep 2011 08:05:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3F8EE4300CB; Wed, 14 Sep 2011 08:07:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-71.clppva.btas.verizon.net [71.161.50.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id C0B834300CC; Wed, 14 Sep 2011 08:07:20 -0700 (PDT) Message-ID: <4E70C324.5060909@joelhalpern.com> Date: Wed, 14 Sep 2011 11:07:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Rosen, Brian" References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914103336.02b6f128@imap.crc.ca> <88B20E31-8FFC-47F6-8272-C8D4000EB942@neustar.biz> In-Reply-To: <88B20E31-8FFC-47F6-8272-C8D4000EB942@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 15:05:17 -0000 I can see many other problems in trying to extend the protocol in thsi regard. Among other things, it changes the security model of the database, since it is now accepting update information as well as queries from the Internet. And that is the tip of the iceberg. The charter says we don't go there (my thanks to the chairs and ADs). Lets not. Yours, Joel PS: If we want to keep "interesting ideas" in the use case document, it seems to me they at least need to be clearly labelled as being out of scope. Personally, I would just remove them as distraction. On 9/14/2011 10:55 AM, Rosen, Brian wrote: > The problem is that this turns the transaction into multiple steps. As it is now, you send a query and get a response. > > If the device needs to update with what it used, that's another step. Also, what happens if it changes its mind? > > Brian > > On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: > >> Peter, Brian, >> >> My suggestion would be to leave this feature in. It will not cost much to >> make room in the protocol for the TVBD to indicate to the database which >> channel it decided to operate on and it would provide easy extensibility to >> the protocol for an eventual consideration of the coexistence amongst the >> license-exempt devices. >> >> I would agree, however, that the current step of the protocol development >> should be limited to protecting of the broadcast incumbents as stated in >> the scope. >> >> Gerald >> >> >> At 13:26 14-09-11 +0000, Peter McCann wrote: >>> So do these use cases in the accepted working group document >>> need to be modified, then? >>> >>> -Pete >>> >>> Rosen, Brian wrote: >>>> It's beyond the charter. This was discussed when we created the >>>> charter, and explicitly excluded it for this initial work. >>>> >>>> Brian >>>> >>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>> >>>>> However, the location-based services use case clearly has the white >>>>> space database keeping state on the secondary user, at least his >>>>> location. Step 7 of the Hotspot use case has the BS registering the >>>>> spectrum that it selected for its use. >>>>> If the database is keeping state in this manner, it could easily >>>>> calculate the exclusion zones for the secondary users as well. >>>>> >>>>> Or did these use cases as described exceed the mandate of the charter? >>>>> >>>>> -Pete >>>>> >>>>> Rosen, Brian wrote: >>>>>> Yes, you are mistaken. >>>>>> >>>>>> If two queriers with the same location and input parameters query the >>>>>> database, they will get the same response. Suppose two U.S. Mode I >>>>>> devices at essentially the same location (within 25 meters) query the >>>>>> database, and the first is told he may use TV channels 1-5, 9-11 and >>>>>> 25-33. The second one will be told the same thing. >>>>>> >>>>>> The database knows query patterns, but does not track use. >>>>>> Specifically, it doesn't know what part of the spectrum the device >>>>>> actually chooses to use, when it starts using it, and when it >>>>>> ceases to use it. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>> >>>>>>> Based on some of the existing use cases, it looks like the >>>>>>> database is keeping state even for the secondary users. That is, >>>>>>> it is acting as a de-facto registry for users of the secondary >>>>>>> spectrum and will refuse to allocate the same spectrum to >>>>>>> different users in overlapping geographic regions. Am I mistaken in >>> this assumption? >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> >>>>>>> Joel M. Halpern wrote: >>>>>>>> I may be missing something, but it seems to me taht what you are >>>>>>>> describing is not the job of the database query protocol. base >>>>>>>> station coordination is an interesting problem, but is it within >>>>>>>> scope for this WG? (I do not think just specifying the same owner >>>>>>>> to the database will resolve the problem, and it makes the database >>>>>>>> state MUCH more complex.) >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've been interacting with Zhu Lei off-list about his third use >>>>>>>>> case, and I think it would be a possible candidate for inclusion >>>>>>>>> in the document if it were properly explained. >>>>>>>>> >>>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>>>>>> problem is to find a common bit of spectrum that is available over >>>>>>>>> a wide area that can be used by multiple master BSs to >>>>>>>>> simultaneously broadcast the same signal to a set of receivers. >>>>>>>>> This is somewhat similar to the wide-area rural coverage scenario >>>>>>>>> currently described in the working group document; however, there >>>>>>>>> would be multiple Master BSs, each of which would independently >>>>>>>>> query the WSDB for available spectrum. However, they need to >>>>>>>>> coordinate the assignment so that they all get the same spectrum >>>>>>>>> over the whole area. As an implementation example, this could be >>>>>>>>> achieved by each BS reporting the same owner/operator and using a >>>>>>>>> key or index value to indicate that they wanted to coordinate the >>>>>>>>> assignment. Alternatively, you might be able to elect one BS as the >>>>>>>>> leader and collect location information from all the other BSs and >>>>>>>>> then coordinate the assignment similar to the use case in 4.2; the >>>>>>>>> difference would be that the resulting assignment is for >>>>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >>>>>>>>> area. >>>>>>>>> >>>>>>>>> Does this sound like an interesting and novel use case? If so I >>>>>>>>> can do a more detailed writeup and supply ASCII art for the draft. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Peter J. McCann >>>>>>>>> Huawei Technologies (USA) >>>>>>>>> Peter.McCann@Huawei.com >>>>>>>>> +1 908 541 3563 >>>>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>>>>> 08807-2863 USA >>>>> >>>>> >>>>> >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Sep 14 08:15: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 2AA3521F8CDD for ; Wed, 14 Sep 2011 08:15:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCTR8PuEeGwI for ; Wed, 14 Sep 2011 08:15:06 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 1829621F8BA2 for ; Wed, 14 Sep 2011 08:15:06 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 86B9D6B04C7; Wed, 14 Sep 2011 11:17:08 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 6142A6B03C1; Wed, 14 Sep 2011 11:17:08 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 52A346B03D6; Wed, 14 Sep 2011 11:17:08 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 189E16B03C1; Wed, 14 Sep 2011 11:17:04 -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 A53FF6B15B4; Wed, 14 Sep 2011 11:17:03 -0400 (EDT) Message-Id: <5.1.0.14.2.20110914111211.02bb7c98@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Sep 2011 11:16:31 -0400 To: "Rosen, Brian" From: Gerald Chouinard In-Reply-To: <88B20E31-8FFC-47F6-8272-C8D4000EB942@neustar.biz> References: <5.1.0.14.2.20110914103336.02b6f128@imap.crc.ca> <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914103336.02b6f128@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" , Peter McCann Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 15:15:07 -0000 Brian, Agreed. A single transaction, to the DB and back to the TVBD, would be sufficient if the protocol is to be kept simple. Coexistence amongst the license-exempt devices would then be left to other processes such as the one being developed by the IEEE 802.19.1. Gerald At 10:55 14-09-11 -0400, Rosen, Brian wrote: >The problem is that this turns the transaction into multiple steps. As it >is now, you send a query and get a response. > >If the device needs to update with what it used, that's another >step. Also, what happens if it changes its mind? > >Brian > >On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: > > > Peter, Brian, > > > > My suggestion would be to leave this feature in. It will not cost much to > > make room in the protocol for the TVBD to indicate to the database which > > channel it decided to operate on and it would provide easy > extensibility to > > the protocol for an eventual consideration of the coexistence amongst the > > license-exempt devices. > > > > I would agree, however, that the current step of the protocol development > > should be limited to protecting of the broadcast incumbents as stated in > > the scope. > > > > Gerald > > > > > > At 13:26 14-09-11 +0000, Peter McCann wrote: > >> So do these use cases in the accepted working group document > >> need to be modified, then? > >> > >> -Pete > >> > >> Rosen, Brian wrote: > >>> It's beyond the charter. This was discussed when we created the > >>> charter, and explicitly excluded it for this initial work. > >>> > >>> Brian > >>> > >>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: > >>> > >>>> However, the location-based services use case clearly has the white > >>>> space database keeping state on the secondary user, at least his > >>>> location. Step 7 of the Hotspot use case has the BS registering the > >>>> spectrum that it selected for its use. > >>>> If the database is keeping state in this manner, it could easily > >>>> calculate the exclusion zones for the secondary users as well. > >>>> > >>>> Or did these use cases as described exceed the mandate of the charter? > >>>> > >>>> -Pete > >>>> > >>>> Rosen, Brian wrote: > >>>>> Yes, you are mistaken. > >>>>> > >>>>> If two queriers with the same location and input parameters query the > >>>>> database, they will get the same response. Suppose two U.S. Mode I > >>>>> devices at essentially the same location (within 25 meters) query the > >>>>> database, and the first is told he may use TV channels 1-5, 9-11 and > >>>>> 25-33. The second one will be told the same thing. > >>>>> > >>>>> The database knows query patterns, but does not track use. > >>>>> Specifically, it doesn't know what part of the spectrum the device > >>>>> actually chooses to use, when it starts using it, and when it > >>>>> ceases to use it. > >>>>> > >>>>> Brian > >>>>> > >>>>> > >>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: > >>>>> > >>>>>> Based on some of the existing use cases, it looks like the > >>>>>> database is keeping state even for the secondary users. That is, > >>>>>> it is acting as a de-facto registry for users of the secondary > >>>>>> spectrum and will refuse to allocate the same spectrum to > >>>>>> different users in overlapping geographic regions. Am I mistaken in > >> this assumption? > >>>>>> > >>>>>> -Pete > >>>>>> > >>>>>> > >>>>>> Joel M. Halpern wrote: > >>>>>>> I may be missing something, but it seems to me taht what you are > >>>>>>> describing is not the job of the database query protocol. base > >>>>>>> station coordination is an interesting problem, but is it within > >>>>>>> scope for this WG? (I do not think just specifying the same owner > >>>>>>> to the database will resolve the problem, and it makes the database > >>>>>>> state MUCH more complex.) > >>>>>>> > >>>>>>> Yours, > >>>>>>> Joel > >>>>>>> > >>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I've been interacting with Zhu Lei off-list about his third use > >>>>>>>> case, and I think it would be a possible candidate for inclusion > >>>>>>>> in the document if it were properly explained. > >>>>>>>> > >>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), the > >>>>>>>> problem is to find a common bit of spectrum that is available over > >>>>>>>> a wide area that can be used by multiple master BSs to > >>>>>>>> simultaneously broadcast the same signal to a set of receivers. > >>>>>>>> This is somewhat similar to the wide-area rural coverage scenario > >>>>>>>> currently described in the working group document; however, there > >>>>>>>> would be multiple Master BSs, each of which would independently > >>>>>>>> query the WSDB for available spectrum. However, they need to > >>>>>>>> coordinate the assignment so that they all get the same spectrum > >>>>>>>> over the whole area. As an implementation example, this could be > >>>>>>>> achieved by each BS reporting the same owner/operator and using a > >>>>>>>> key or index value to indicate that they wanted to coordinate the > >>>>>>>> assignment. Alternatively, you might be able to elect one BS as the > >>>>>>>> leader and collect location information from all the other BSs and > >>>>>>>> then coordinate the assignment similar to the use case in 4.2; the > >>>>>>>> difference would be that the resulting assignment is for > >>>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider > >>>>>>>> area. > >>>>>>>> > >>>>>>>> Does this sound like an interesting and novel use case? If so I > >>>>>>>> can do a more detailed writeup and supply ASCII art for the draft. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Peter J. McCann > >>>>>>>> Huawei Technologies (USA) > >>>>>>>> Peter.McCann@Huawei.com > >>>>>>>> +1 908 541 3563 > >>>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ > >>>>>>>> 08807-2863 USA > >>>> > >>>> > >>>> > >> > >> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > > > > > From scott.probasco@nokia.com Wed Sep 14 08:38:35 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 9355121F85D1 for ; Wed, 14 Sep 2011 08:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 YEQjhzPIsmXF for ; Wed, 14 Sep 2011 08:38:34 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA321F85AA for ; Wed, 14 Sep 2011 08:38:34 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EFegow021707 for ; Wed, 14 Sep 2011 18:40:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 18:40:20 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 17:40:19 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 17:40:18 +0200 From: To: Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAA== Date: Wed, 14 Sep 2011 15:40:18 +0000 Message-ID: In-Reply-To: <5.1.0.14.2.20110914111211.02bb7c98@imap.crc.ca> 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.241.50.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <3534E67B64C91A4E82F7BF8EC463D1A3@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 15:40:20.0127 (UTC) FILETIME=[9BF8EAF0:01CC72F4] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 15:38:35 -0000 Hi, One of the key aspects of this protocol between device and database is extensibility. The charter does recognize that the contents of the database is defined external to PAWS. Thus hard to say that any single specific value or information element is beyond the scope. Also the charter allows for queries and responses, there is no restriction that single transactions are mandated. So IMHO the use cases already approved are still valid, no reasons to exclude pieces. Regards, Scott On 9/14/11 10:16 AM, "ext Gerald Chouinard" wrote: >Brian, > >Agreed. A single transaction, to the DB and back to the TVBD, would be >sufficient if the protocol is to be kept simple. Coexistence amongst the >license-exempt devices would then be left to other processes such as the >one being developed by the IEEE 802.19.1. > >Gerald > > >At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>The problem is that this turns the transaction into multiple steps. As >>it=20 >>is now, you send a query and get a response. >> >>If the device needs to update with what it used, that's another >>step. Also, what happens if it changes its mind? >> >>Brian >> >>On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >> >> > Peter, Brian, >> > >> > My suggestion would be to leave this feature in. It will not cost >>much to >> > make room in the protocol for the TVBD to indicate to the database >>which >> > channel it decided to operate on and it would provide easy >> extensibility to >> > the protocol for an eventual consideration of the coexistence amongst >>the >> > license-exempt devices. >> > >> > I would agree, however, that the current step of the protocol >>development >> > should be limited to protecting of the broadcast incumbents as stated >>in >> > the scope. >> > >> > Gerald >> > >> > >> > At 13:26 14-09-11 +0000, Peter McCann wrote: >> >> So do these use cases in the accepted working group document >> >> need to be modified, then? >> >> >> >> -Pete >> >> >> >> Rosen, Brian wrote: >> >>> It's beyond the charter. This was discussed when we created the >> >>> charter, and explicitly excluded it for this initial work. >> >>> >> >>> Brian >> >>> >> >>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >> >>> >> >>>> However, the location-based services use case clearly has the white >> >>>> space database keeping state on the secondary user, at least his >> >>>> location. Step 7 of the Hotspot use case has the BS registering >>the >> >>>> spectrum that it selected for its use. >> >>>> If the database is keeping state in this manner, it could easily >> >>>> calculate the exclusion zones for the secondary users as well. >> >>>> >> >>>> Or did these use cases as described exceed the mandate of the >>charter? >> >>>> >> >>>> -Pete >> >>>> >> >>>> Rosen, Brian wrote: >> >>>>> Yes, you are mistaken. >> >>>>> >> >>>>> If two queriers with the same location and input parameters query >>the >> >>>>> database, they will get the same response. Suppose two U.S. >>Mode I >> >>>>> devices at essentially the same location (within 25 meters) query >>the >> >>>>> database, and the first is told he may use TV channels 1-5, 9-11 >>and >> >>>>> 25-33. The second one will be told the same thing. >> >>>>> >> >>>>> The database knows query patterns, but does not track use. >> >>>>> Specifically, it doesn't know what part of the spectrum the device >> >>>>> actually chooses to use, when it starts using it, and when it >> >>>>> ceases to use it. >> >>>>> >> >>>>> Brian >> >>>>> >> >>>>> >> >>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >> >>>>> >> >>>>>> Based on some of the existing use cases, it looks like the >> >>>>>> database is keeping state even for the secondary users. That is, >> >>>>>> it is acting as a de-facto registry for users of the secondary >> >>>>>> spectrum and will refuse to allocate the same spectrum to >> >>>>>> different users in overlapping geographic regions. Am I >>mistaken in >> >> this assumption? >> >>>>>> >> >>>>>> -Pete >> >>>>>> >> >>>>>> >> >>>>>> Joel M. Halpern wrote: >> >>>>>>> I may be missing something, but it seems to me taht what you are >> >>>>>>> describing is not the job of the database query protocol. base >> >>>>>>> station coordination is an interesting problem, but is it within >> >>>>>>> scope for this WG? (I do not think just specifying the same >>owner >> >>>>>>> to the database will resolve the problem, and it makes the >>database >> >>>>>>> state MUCH more complex.) >> >>>>>>> >> >>>>>>> Yours, >> >>>>>>> Joel >> >>>>>>> >> >>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> I've been interacting with Zhu Lei off-list about his third use >> >>>>>>>> case, and I think it would be a possible candidate for >>inclusion >> >>>>>>>> in the document if it were properly explained. >> >>>>>>>> >> >>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), >>the >> >>>>>>>> problem is to find a common bit of spectrum that is available >>over >> >>>>>>>> a wide area that can be used by multiple master BSs to >> >>>>>>>> simultaneously broadcast the same signal to a set of receivers. >> >>>>>>>> This is somewhat similar to the wide-area rural coverage >>scenario >> >>>>>>>> currently described in the working group document; however, >>there >> >>>>>>>> would be multiple Master BSs, each of which would independently >> >>>>>>>> query the WSDB for available spectrum. However, they need to >> >>>>>>>> coordinate the assignment so that they all get the same >>spectrum >> >>>>>>>> over the whole area. As an implementation example, this could >>be >> >>>>>>>> achieved by each BS reporting the same owner/operator and >>using a >> >>>>>>>> key or index value to indicate that they wanted to coordinate >>the >> >>>>>>>> assignment. Alternatively, you might be able to elect one BS >>as the >> >>>>>>>> leader and collect location information from all the other BSs >>and >> >>>>>>>> then coordinate the assignment similar to the use case in 4.2; >>the >> >>>>>>>> difference would be that the resulting assignment is for >> >>>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >> >>>>>>>> area. >> >>>>>>>> >> >>>>>>>> Does this sound like an interesting and novel use case? If so >>I >> >>>>>>>> can do a more detailed writeup and supply ASCII art for the >>draft. >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Peter J. McCann >> >>>>>>>> Huawei Technologies (USA) >> >>>>>>>> Peter.McCann@Huawei.com >> >>>>>>>> +1 908 541 3563 >> >>>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >> >>>>>>>> 08807-2863 USA >> >>>> >> >>>> >> >>>> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 Wed Sep 14 08:38: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 6FF1021F8B6E for ; Wed, 14 Sep 2011 08:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 f2GQrmd1aJmA for ; Wed, 14 Sep 2011 08:38:46 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DF21F8B66 for ; Wed, 14 Sep 2011 08:38:46 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EFdtTN007249; Wed, 14 Sep 2011 18:40:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 18:40:17 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 17:40:17 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 17:40:16 +0200 From: To: , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AA== Date: Wed, 14 Sep 2011 15:40:16 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.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.241.50.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <64C1A0711C19294182B10C23658A7B27@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 15:40:17.0955 (UTC) FILETIME=[9AAD7F30:01CC72F4] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 15:38:47 -0000 Hi Pete, There is no coordination aspect to TDD is there? I added TDD initially to indicate that a single channel is used for operation, contrasted to the 2 channel requirement for FDD. I believe the use case under discussion is using the channel for full DL broadcast. It's not so much as coordination, just 100% DL. Right? Would help me if you could clarify what spectrum coordination is happening in this case. Regards, Scott On 9/14/11 8:20 AM, "ext Peter McCann" wrote: >Hi, Scott, > >scott.probasco@nokia.com wrote: >> Hi, >>=20 >> Thank you Peter & Lei for the more detailed description of the use case. >> When I look at this case, the question is: can PAWS be used to allow >> multiple Master devices to knowingly select the same channel for >> operation. (The discussion of "why" and "is it a good idea" not >> undertaken here as this likely wanders outside the scope of PAWS). >>=20 >> One of the proposed solutions is coordination among BSs (external to >> PAWS). This is already described in section 4.3 Wide-Area or Rural >> internet broadband access: >>=20 >>> Some of the masters/BSs may be deployed and operated by a single >>> entity, i.e. there can be centralized coordination between these >>> masters/BSs,... >>=20 >> Further, you note the difference is in TDD: >>=20 >>> The BS in this scenario use a TDD radio >>> Technology >>=20 >> Would it be appropriate and acceptable to WG members to add "typically" >> such as: >>=20 >>> The BS in this scenario typically uses a >>> TDD radio Technology... >>=20 >> Does this enable the use case you are describing? > >Maybe we could say: > >The BS in this scenario typically use a TDD radio technology >or other means to coordinate use of the selected spectrum. > >-Pete > >>=20 >>=20 >>=20 >> Regards, >> Scott >>=20 >>=20 >> On 9/13/11 12:37 PM, "ext Peter McCann" wrote: >>=20 >>> Hi, >>>=20 >>> I've been interacting with Zhu Lei off-list about his third use case, >>> and I think it would be a possible candidate for inclusion in the >>> document if it were properly explained. >>>=20 >>> Generally (as opposed to specifically for the LTE MBMS case), the >>> problem is to find a common bit of spectrum that is available over a >>> wide area that can be used by multiple master BSs to simultaneously >>> broadcast the same signal to a set of receivers. This is somewhat >>> similar to the wide-area rural coverage scenario currently described in >>> the working group document; however, there would be multiple Master >>> BSs, each of which would independently query the WSDB for available >>> spectrum. However, they need to coordinate the assignment so that they >>> all get the same spectrum over the whole area. As an implementation >>> example, this could be achieved by each BS reporting the same >>> owner/operator and using a key or index value to indicate that they >>> wanted to coordinate the assignment. Alternatively, you might be able >>> to elect one BS as the leader and collect location information from all >>> the other BSs and then coordinate the assignment similar to the use >>> case in 4.2; the difference would be that the resulting assignment is >>> for simultaneous (not TDD) use by all of the BSs covering the wider >>> area. >>>=20 >>> Does this sound like an interesting and novel use case? If so I can do >>> a more detailed writeup and supply ASCII art for the draft. >>>=20 >>> -- >>> Peter J. McCann >>> Huawei Technologies (USA) >>> Peter.McCann@Huawei.com >>> +1 908 541 3563 >>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>> 08807-2863 USA >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > > > From Peter.McCann@huawei.com Wed Sep 14 09:39:55 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 89F7A21F8B19 for ; Wed, 14 Sep 2011 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 K4x0+3Rfash9 for ; Wed, 14 Sep 2011 09:39:54 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8E21F8B10 for ; Wed, 14 Sep 2011 09:39:54 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00BFBTIQB9@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 11:23:15 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRI00BLIT30B0@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 11:13:48 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 09:13:44 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 09:13:46 -0700 Date: Wed, 14 Sep 2011 16:13:45 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A326@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AP//gblg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 16:39:55 -0000 TDD is a turn-taking mechanism for sharing the spectrum. I would call that a form of coordination between the various transmitters. Someone needs to publish a schedule of who is allowed to transmit when. In the broadcast case, the coordination required is for all BS to transmit exactly the same physical layer signal at the same time so that receivers see constructive interference. -Pete scott.probasco@nokia.com wrote: > Hi Pete, > > There is no coordination aspect to TDD is there? I added TDD initially > to indicate that a single channel is used for operation, contrasted to > the 2 channel requirement for FDD. > > I believe the use case under discussion is using the channel for full > DL broadcast. It's not so much as coordination, just 100% DL. Right? > > Would help me if you could clarify what spectrum coordination is > happening in this case. > > Regards, > Scott > > > On 9/14/11 8:20 AM, "ext Peter McCann" wrote: > >> Hi, Scott, >> >> scott.probasco@nokia.com wrote: >>> Hi, >>> >>> Thank you Peter & Lei for the more detailed description of the use >>> case. When I look at this case, the question is: can PAWS be used to >>> allow multiple Master devices to knowingly select the same channel for >>> operation. (The discussion of "why" and "is it a good idea" not >>> undertaken here as this likely wanders outside the scope of PAWS). >>> >>> One of the proposed solutions is coordination among BSs (external >>> to PAWS). This is already described in section 4.3 Wide-Area or >>> Rural internet broadband access: >>> >>>> Some of the masters/BSs may be deployed and operated by a single >>>> entity, i.e. there can be centralized coordination between these >>>> masters/BSs,... >>> >>> Further, you note the difference is in TDD: >>> >>>> The BS in this scenario use a TDD radio Technology >>> >>> Would it be appropriate and acceptable to WG members to add >>> "typically" such as: >>> >>>> The BS in this scenario typically uses a TDD radio Technology... >>> >>> Does this enable the use case you are describing? >> >> Maybe we could say: >> >> The BS in this scenario typically use a TDD radio technology or other >> means to coordinate use of the selected spectrum. >> >> -Pete >> >>> >>> >>> >>> Regards, >>> Scott >>> >>> >>> On 9/13/11 12:37 PM, "ext Peter McCann" >>> wrote: >>> >>>> Hi, >>>> >>>> I've been interacting with Zhu Lei off-list about his third use >>>> case, and I think it would be a possible candidate for inclusion >>>> in the document if it were properly explained. >>>> >>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>> problem is to find a common bit of spectrum that is available over a >>>> wide area that can be used by multiple master BSs to simultaneously >>>> broadcast the same signal to a set of receivers. This is somewhat >>>> similar to the wide-area rural coverage scenario currently described >>>> in the working group document; however, there would be multiple >>>> Master BSs, each of which would independently query the WSDB for >>>> available spectrum. However, they need to coordinate the assignment >>>> so that they all get the same spectrum over the whole area. As an >>>> implementation example, this could be achieved by each BS reporting >>>> the same owner/operator and using a key or index value to indicate >>>> that they wanted to coordinate the assignment. Alternatively, you >>>> might be able to elect one BS as the leader and collect location >>>> information from all the other BSs and then coordinate the assignment >>>> similar to the use case in 4.2; the difference would be that the >>>> resulting assignment is for simultaneous (not TDD) use by all of the >>>> BSs covering the wider area. >>>> >>>> Does this sound like an interesting and novel use case? If so I can >>>> do a more detailed writeup and supply ASCII art for the draft. >>>> >>>> -- >>>> Peter J. McCann >>>> Huawei Technologies (USA) >>>> Peter.McCann@Huawei.com >>>> +1 908 541 3563 >>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>> 08807-2863 USA >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >> >> >> From Peter.McCann@huawei.com Wed Sep 14 09:39:55 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 A55A421F8B10 for ; Wed, 14 Sep 2011 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 tGqBm2K+DFBd for ; Wed, 14 Sep 2011 09:39:54 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFD21F8B14 for ; Wed, 14 Sep 2011 09:39:54 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00BFBTIQB9@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 11:23:15 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRI00AGBTG5BE@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 11:22:25 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 09:22:01 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 09:22:01 -0700 Date: Wed, 14 Sep 2011 16:22:00 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A342@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQD//59BXoAAee4AgAAFyYCAAAalAIAAavvg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5.1.0.14.2.20110914111211.02bb7c98@imap.crc.ca> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 16:39:55 -0000 Hi, Scott, The problem is when I see text like this in section 4.2 and 4.3: 7. The master/AP acknowledges to the database which of the available WS channels it has selected for its operation. The database is updated with the information provided by the master/AP. it makes me think that the database is tracking the use of spectrum by the whitespace master devices. When it says "database is updated" that makes me think that the database of exclusion zones is updated in a way that will impact the results of future queries. There is also the location-based service use case where the database is keeping state about the whitespace master device, namely its location: 3. The server queries the trusted white space database with the master identity provided by the application in the user's smartphone. 4. The trusted white space database replies to the server with the location of the master device. If the database is to be truly stateless and passive with respect to queries by whitespace devices, these kinds of statements should be removed from the use cases. -Pete scott.probasco@nokia.com wrote: > Hi, > > One of the key aspects of this protocol between device and database is > extensibility. The charter does recognize that the contents of the > database is defined external to PAWS. Thus hard to say that any single > specific value or information element is beyond the scope. > > Also the charter allows for queries and responses, there is no > restriction that single transactions are mandated. > > So IMHO the use cases already approved are still valid, no reasons to > exclude pieces. > > Regards, > Scott > > > > On 9/14/11 10:16 AM, "ext Gerald Chouinard" > wrote: > >> Brian, >> >> Agreed. A single transaction, to the DB and back to the TVBD, would be >> sufficient if the protocol is to be kept simple. Coexistence amongst >> the license-exempt devices would then be left to other processes such >> as the one being developed by the IEEE 802.19.1. >> >> Gerald >> >> >> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>> The problem is that this turns the transaction into multiple steps. >>> As it is now, you send a query and get a response. >>> >>> If the device needs to update with what it used, that's another step. >>> Also, what happens if it changes its mind? >>> >>> Brian >>> >>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>> >>>> Peter, Brian, >>>> >>>> My suggestion would be to leave this feature in. It will not cost >>>> much to make room in the protocol for the TVBD to indicate to the >>>> database which channel it decided to operate on and it would provide >>>> easy extensibility to the protocol for an eventual consideration of >>>> the coexistence amongst the license-exempt devices. >>>> >>>> I would agree, however, that the current step of the protocol >>>> development should be limited to protecting of the broadcast >>>> incumbents as stated in the scope. >>>> >>>> Gerald >>>> >>>> >>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>> So do these use cases in the accepted working group document >>>>> need to be modified, then? >>>>> >>>>> -Pete >>>>> >>>>> Rosen, Brian wrote: >>>>>> It's beyond the charter. This was discussed when we created >>>>>> the charter, and explicitly excluded it for this initial work. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>> >>>>>>> However, the location-based services use case clearly has the >>>>>>> white space database keeping state on the secondary user, at least >>>>>>> his location. Step 7 of the Hotspot use case has the BS >>>>>>> registering the spectrum that it selected for its use. If the >>>>>>> database is keeping state in this manner, it could easily >>>>>>> calculate the exclusion zones for the secondary users as well. >>>>>>> >>>>>>> Or did these use cases as described exceed the mandate of the >>>>>>> charter? >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> Rosen, Brian wrote: >>>>>>>> Yes, you are mistaken. >>>>>>>> >>>>>>>> If two queriers with the same location and input parameters query >>>>>>>> the database, they will get the same response. Suppose two U.S. >>>>>>>> Mode I devices at essentially the same location (within 25 >>>>>>>> meters) query the database, and the first is told he may use TV >>>>>>>> channels 1-5, 9-11 and 25-33. The second one will be told the >>>>>>>> same thing. >>>>>>>> >>>>>>>> The database knows query patterns, but does not track use. >>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>> device actually chooses to use, when it starts using it, and >>>>>>>> when it ceases to use it. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>> >>>>>>>>> Based on some of the existing use cases, it looks like the >>>>>>>>> database is keeping state even for the secondary users. That is, >>>>>>>>> it is acting as a de-facto registry for users of the secondary >>>>>>>>> spectrum and will refuse to allocate the same spectrum to >>>>>>>>> different users in overlapping geographic regions. Am I >>> mistaken in >>>>> this assumption? >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>> >>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>> I may be missing something, but it seems to me taht what you >>>>>>>>>> are describing is not the job of the database query protocol. >>>>>>>>>> base station coordination is an interesting problem, but is it >>>>>>>>>> within scope for this WG? (I do not think just specifying the >>>>>>>>>> same owner to the database will resolve the problem, and it >>>>>>>>>> makes the database state MUCH more complex.) >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I've been interacting with Zhu Lei off-list about his third >>>>>>>>>>> use case, and I think it would be a possible candidate for >>>>>>>>>>> inclusion in the document if it were properly explained. >>>>>>>>>>> >>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), >>>>>>>>>>> the problem is to find a common bit of spectrum that is >>>>>>>>>>> available over a wide area that can be used by multiple master >>>>>>>>>>> BSs to simultaneously broadcast the same signal to a set of >>>>>>>>>>> receivers. This is somewhat similar to the wide-area rural >>>>>>>>>>> coverage scenario currently described in the working group >>>>>>>>>>> document; however, there would be multiple Master BSs, each of >>>>>>>>>>> which would independently query the WSDB for available >>>>>>>>>>> spectrum. However, they need to coordinate the assignment so >>>>>>>>>>> that they all get the same spectrum over the whole area. As an >>>>>>>>>>> implementation example, this could be achieved by each BS >>>>>>>>>>> reporting the same owner/operator and using a key or index >>>>>>>>>>> value to indicate that they wanted to coordinate the >>>>>>>>>>> assignment. Alternatively, you might be able to elect one > BS >>> as the >>>>>>>>>>> leader and collect location information from all the other BSs >>>>>>>>>>> and then coordinate the assignment similar to the use case in >>>>>>>>>>> 4.2; the difference would be that the resulting assignment is >>>>>>>>>>> for simultaneous (not TDD) use by all of the BSs covering the >>>>>>>>>>> wider area. >>>>>>>>>>> >>>>>>>>>>> Does this sound like an interesting and novel use case? If so >>>>>>>>>>> I can do a more detailed writeup and supply ASCII art for the >>>>>>>>>>> draft. From gerald.chouinard@crc.ca Wed Sep 14 10:04: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 6AA8421F8BE9 for ; Wed, 14 Sep 2011 10:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 c+YXsHViBND8 for ; Wed, 14 Sep 2011 10:04:31 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 5307E21F8BBB for ; Wed, 14 Sep 2011 10:04:31 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id A2BCD6B0433; Wed, 14 Sep 2011 13:06:40 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 81E2B6B03B7; Wed, 14 Sep 2011 13:06:40 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 7164B6B03D6; Wed, 14 Sep 2011 13:06:40 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 6A3FF6B03B7; Wed, 14 Sep 2011 13:06:36 -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 0817A6B15B4; Wed, 14 Sep 2011 13:06:35 -0400 (EDT) Message-Id: <5.1.0.14.2.20110914125759.02bb7dd8@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Sep 2011 13:06:35 -0400 To: , From: Gerald Chouinard In-Reply-To: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Cc: paws@ietf.org Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 17:04:32 -0000 Scott, Peter, One way to provide such a coordination would be to nominate one BS in an area as the master BS that would query the DB for itself and on behalf of the other 'slave' BSs. Coordination could then be done locally by the master BS by sending a filtered version of the available channels list as received from the DB to the appropriate slave BS. Unfortunately,it is still not clear whether the regulations in the various countries will allow such 'proxying' of TVBD's by other TVBD's and that this will not pose security problems. If it is allowed everywhere and appropriate security can be achieved, then such coordination could be transparent to the DB since it would take place at the master BS without the DB having to know about it. It would only know that a BS is asking for the channels availability on behalf of other BSs. Gerald At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: >Hi Pete, > >There is no coordination aspect to TDD is there? I added TDD initially to >indicate that a single channel is used for operation, contrasted to the 2 >channel requirement for FDD. > >I believe the use case under discussion is using the channel for full DL >broadcast. It's not so much as coordination, just 100% DL. Right? > >Would help me if you could clarify what spectrum coordination is happening >in this case. > >Regards, >Scott > > >On 9/14/11 8:20 AM, "ext Peter McCann" wrote: > > >Hi, Scott, > > > >scott.probasco@nokia.com wrote: > >> Hi, > >> > >> Thank you Peter & Lei for the more detailed description of the use case. > >> When I look at this case, the question is: can PAWS be used to allow > >> multiple Master devices to knowingly select the same channel for > >> operation. (The discussion of "why" and "is it a good idea" not > >> undertaken here as this likely wanders outside the scope of PAWS). > >> > >> One of the proposed solutions is coordination among BSs (external to > >> PAWS). This is already described in section 4.3 Wide-Area or Rural > >> internet broadband access: > >> > >>> Some of the masters/BSs may be deployed and operated by a single > >>> entity, i.e. there can be centralized coordination between these > >>> masters/BSs,... > >> > >> Further, you note the difference is in TDD: > >> > >>> The BS in this scenario use a TDD radio > >>> Technology > >> > >> Would it be appropriate and acceptable to WG members to add "typically" > >> such as: > >> > >>> The BS in this scenario typically uses a > >>> TDD radio Technology... > >> > >> Does this enable the use case you are describing? > > > >Maybe we could say: > > > >The BS in this scenario typically use a TDD radio technology > >or other means to coordinate use of the selected spectrum. > > > >-Pete > > > >> > >> > >> > >> Regards, > >> Scott > >> > >> > >> On 9/13/11 12:37 PM, "ext Peter McCann" wrote: > >> > >>> Hi, > >>> > >>> I've been interacting with Zhu Lei off-list about his third use case, > >>> and I think it would be a possible candidate for inclusion in the > >>> document if it were properly explained. > >>> > >>> Generally (as opposed to specifically for the LTE MBMS case), the > >>> problem is to find a common bit of spectrum that is available over a > >>> wide area that can be used by multiple master BSs to simultaneously > >>> broadcast the same signal to a set of receivers. This is somewhat > >>> similar to the wide-area rural coverage scenario currently described in > >>> the working group document; however, there would be multiple Master > >>> BSs, each of which would independently query the WSDB for available > >>> spectrum. However, they need to coordinate the assignment so that they > >>> all get the same spectrum over the whole area. As an implementation > >>> example, this could be achieved by each BS reporting the same > >>> owner/operator and using a key or index value to indicate that they > >>> wanted to coordinate the assignment. Alternatively, you might be able > >>> to elect one BS as the leader and collect location information from all > >>> the other BSs and then coordinate the assignment similar to the use > >>> case in 4.2; the difference would be that the resulting assignment is > >>> for simultaneous (not TDD) use by all of the BSs covering the wider > >>> area. > >>> > >>> Does this sound like an interesting and novel use case? If so I can do > >>> a more detailed writeup and supply ASCII art for the draft. > >>> > >>> -- > >>> Peter J. McCann > >>> Huawei Technologies (USA) > >>> Peter.McCann@Huawei.com > >>> +1 908 541 3563 > >>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ > >>> 08807-2863 USA > >>> > >>> > >>> _______________________________________________ > >>> 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 Peter.McCann@huawei.com Wed Sep 14 10:11: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 4F96521F8B0D for ; Wed, 14 Sep 2011 10:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 d2QgkgzXIyL6 for ; Wed, 14 Sep 2011 10:11:26 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 46BCF21F8B00 for ; Wed, 14 Sep 2011 10:11:24 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI005FBVUKI4@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 12:13:32 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI004K0VUJ7D@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 12:13:32 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 10:13:32 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 10:13:31 -0700 Date: Wed, 14 Sep 2011 17:13:30 +0000 From: Peter McCann In-reply-to: <5.1.0.14.2.20110914125759.02bb7dd8@imap.crc.ca> X-Originating-IP: [10.193.125.70] To: Gerald Chouinard , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIABAtKAgAB1DzA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914125759.02bb7dd8@imap.crc.ca> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 17:11:27 -0000 Hi, Gerald, I think what Scott is asking about is coordination in access to the channel after it has been cleared for use by the WSDB. It seems like you are asking about how to coordinate the assignment of the channel among all the different BS. I agree that one BS could act as the "master", collecting information from the peer BSs and presenting it all to the WSDB in a query for a vacant channel. Isn't this the same as the existing WRAN use case in Section 4.3? Or is there some difference due to the fact that all the BSs are "Master" devices? -Pete Gerald Chouinard wrote: > Scott, Peter, > > One way to provide such a coordination would be to nominate one BS in > an area as the master BS that would query the DB for itself and on > behalf of the other 'slave' BSs. Coordination could then be done > locally by the master BS by sending a filtered version of the > available channels list as received from the DB to the appropriate slave BS. > > Unfortunately,it is still not clear whether the regulations in the > various countries will allow such 'proxying' of TVBD's by other TVBD's > and that this will not pose security problems. If it is allowed > everywhere and appropriate security can be achieved, then such > coordination could be transparent to the DB since it would take place > at the master BS without the DB having to know about it. It would > only know that a BS is asking for the channels availability on behalf > of other BSs. > > Gerald > > > At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: >> Hi Pete, >> >> There is no coordination aspect to TDD is there? I added TDD >> initially to indicate that a single channel is used for operation, >> contrasted to the 2 channel requirement for FDD. >> >> I believe the use case under discussion is using the channel for full >> DL broadcast. It's not so much as coordination, just 100% DL. Right? >> >> Would help me if you could clarify what spectrum coordination is >> happening in this case. >> >> Regards, >> Scott >> >> >> On 9/14/11 8:20 AM, "ext Peter McCann" wrote: >> >>> Hi, Scott, >>> >>> scott.probasco@nokia.com wrote: >>>> Hi, >>>> >>>> Thank you Peter & Lei for the more detailed description of the use >>>> case. When I look at this case, the question is: can PAWS be used to >>>> allow multiple Master devices to knowingly select the same channel >>>> for operation. (The discussion of "why" and "is it a good idea" not >>>> undertaken here as this likely wanders outside the scope of PAWS). >>>> >>>> One of the proposed solutions is coordination among BSs (external >>>> to PAWS). This is already described in section 4.3 Wide-Area or >>>> Rural internet broadband access: >>>> >>>>> Some of the masters/BSs may be deployed and operated by a single >>>>> entity, i.e. there can be centralized coordination between these >>>>> masters/BSs,... >>>> >>>> Further, you note the difference is in TDD: >>>> >>>>> The BS in this scenario use a TDD radio Technology >>>> >>>> Would it be appropriate and acceptable to WG members to add >>>> "typically" such as: >>>> >>>>> The BS in this scenario typically uses a TDD radio Technology... >>>> >>>> Does this enable the use case you are describing? >>> >>> Maybe we could say: >>> >>> The BS in this scenario typically use a TDD radio technology or other >>> means to coordinate use of the selected spectrum. >>> >>> -Pete >>> >>>> >>>> >>>> >>>> Regards, >>>> Scott >>>> >>>> >>>> On 9/13/11 12:37 PM, "ext Peter McCann" >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I've been interacting with Zhu Lei off-list about his third use >>>>> case, and I think it would be a possible candidate for inclusion >>>>> in the document if it were properly explained. >>>>> >>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>> problem is to find a common bit of spectrum that is available over a >>>>> wide area that can be used by multiple master BSs to simultaneously >>>>> broadcast the same signal to a set of receivers. This is somewhat >>>>> similar to the wide-area rural coverage scenario currently described >>>>> in the working group document; however, there would be multiple >>>>> Master BSs, each of which would independently query the WSDB for >>>>> available spectrum. However, they need to coordinate the assignment >>>>> so that they all get the same spectrum over the whole area. As an >>>>> implementation example, this could be achieved by each BS reporting >>>>> the same owner/operator and using a key or index value to indicate >>>>> that they wanted to coordinate the assignment. Alternatively, you >>>>> might be able to elect one BS as the leader and collect location >>>>> information from all the other BSs and then coordinate the >>>>> assignment similar to the use case in 4.2; the difference would be >>>>> that the resulting assignment is for simultaneous (not TDD) use by >>>>> all of the BSs covering the wider area. >>>>> >>>>> Does this sound like an interesting and novel use case? If so I can >>>>> do a more detailed writeup and supply ASCII art for the draft. >>>>> >>>>> -- >>>>> Peter J. McCann >>>>> Huawei Technologies (USA) >>>>> Peter.McCann@Huawei.com >>>>> +1 908 541 3563 >>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>> 08807-2863 USA From gerald.chouinard@crc.ca Wed Sep 14 10:17: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 E46A921F86A5 for ; Wed, 14 Sep 2011 10:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-1.184, 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 OFRxocf0xs8q for ; Wed, 14 Sep 2011 10:17:43 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id E350B21F869E for ; Wed, 14 Sep 2011 10:17:42 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id C8E376B04C8; Wed, 14 Sep 2011 13:19:46 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id B0BB46B03B7; Wed, 14 Sep 2011 13:19:46 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id A292B6B03CA; Wed, 14 Sep 2011 13:19:46 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 161126B03B7; Wed, 14 Sep 2011 13:19:43 -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 A69F46B15B4; Wed, 14 Sep 2011 13:19:42 -0400 (EDT) Message-Id: <5.1.0.14.2.20110914130859.0287b618@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Sep 2011 13:19:44 -0400 To: Peter McCann From: Gerald Chouinard In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A326@dfweml503-mbx.chi na.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> 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 Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 17:17:44 -0000 Peter,

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

Gerald


At 16:13 14-09-11 +0000, Peter McCann wrote:
TDD is a turn-taking mechanism for sharing the spectrum.  I would
call that a form of coordination between the various transmitters.
Someone needs to publish a schedule of who is allowed to transmit
when.

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

-Pete

scott.probasco@nokia.com wrote:
> Hi Pete,
>
> There is no coordination aspect to TDD is there? I added TDD initially
> to indicate that a single channel is used for operation, contrasted to
> the 2 channel requirement for FDD.
>
> I believe the use case under discussion is using the channel for full
> DL broadcast. It's not so much as coordination, just 100% DL. Right?
>
> Would help me if you could clarify what spectrum coordination is
> happening in this case.
>
> Regards,
> Scott
>
>
> On 9/14/11 8:20 AM, "ext Peter McCann" <Peter.McCann@huawei.com> wrote:
>
>> Hi, Scott,
>>
>> scott.probasco@nokia.com wrote:
>>> Hi,
>>>
>>> Thank you Peter & Lei for the more detailed description of the use
>>> case. When I look at this case, the question is: can PAWS be used to
>>> allow multiple Master devices to knowingly select the same channel for
>>> operation. (The discussion of "why" and "is it a good idea" not
>>> undertaken here as this likely wanders outside the scope of PAWS).
>>>
>>> One of the proposed solutions is coordination among BSs (external
>>> to PAWS). This is already described in section 4.3 Wide-Area or
>>> Rural internet broadband access:
>>>
>>>> Some of the masters/BSs may be deployed and operated by a single
>>>> entity, i.e. there can be centralized coordination between these
>>>> masters/BSs,...
>>>
>>> Further, you note the difference is in TDD:
>>>
>>>> The BS in this scenario use a TDD radio Technology
>>>
>>> Would it be appropriate and acceptable to WG members to add
>>> "typically" such as:
>>>
>>>> The BS in this scenario typically uses a TDD radio Technology...
>>>
>>> Does this enable the use case you are describing?
>>
>> Maybe we could say:
>>
>> The BS in this scenario typically use a TDD radio technology or other
>> means to coordinate use of the selected spectrum.
>>
>> -Pete
>>
>>>
>>>
>>>
>>> Regards,
>>> Scott
>>>
>>>
>>> On 9/13/11 12:37 PM, "ext Peter McCann" <Peter.McCann@huawei.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've been interacting with Zhu Lei off-list about his third use
>>>> case, and I think it would be a possible candidate for inclusion
>>>> in the document if it were properly explained.
>>>>
>>>> Generally (as opposed to specifically for the LTE MBMS case), the
>>>> problem is to find a common bit of spectrum that is available over a
>>>> wide area that can be used by multiple master BSs to simultaneously
>>>> broadcast the same signal to a set of receivers. This is somewhat
>>>> similar to the wide-area rural coverage scenario currently described
>>>> in the working group document; however, there would be multiple
>>>> Master BSs, each of which would independently query the WSDB for
>>>> available spectrum.  However, they need to coordinate the assignment
>>>> so that they all get the same spectrum over the whole area. As an
>>>> implementation example, this could be achieved by each BS reporting
>>>> the same owner/operator and using a key or index value to indicate
>>>> that they wanted to coordinate the assignment. Alternatively, you
>>>> might be able to elect one BS as the leader and collect location
>>>> information from all the other BSs and then coordinate the assignment
>>>> similar to the use case in 4.2; the difference would be that the
>>>> resulting assignment is for simultaneous (not TDD) use by all of the
>>>> BSs covering the wider area.
>>>>
>>>> Does this sound like an interesting and novel use case?  If so I can
>>>> do a more detailed writeup and supply ASCII art for the draft.
>>>>
>>>> --
>>>> Peter J. McCann
>>>> Huawei Technologies (USA)
>>>> Peter.McCann@Huawei.com
>>>> +1 908 541 3563
>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ
>>>> 08807-2863 USA
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Basavaraj.Patil@nokia.com Wed Sep 14 10:20:33 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 B42BE21F8B50 for ; Wed, 14 Sep 2011 10:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 iTDeXoVMpqWH for ; Wed, 14 Sep 2011 10:20:32 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 13FFA21F8B9D for ; Wed, 14 Sep 2011 10:20:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EHMYtm025934; Wed, 14 Sep 2011 20:22:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 20:22:34 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 19:22:33 +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; Wed, 14 Sep 2011 19:22:33 +0200 From: To: , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAa/KAgAAB7wD//67PgA== Date: Wed, 14 Sep 2011 17:22:33 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.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: [172.19.59.28] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6EADD50F679D524CB968A4372707348B@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 17:22:34.0438 (UTC) FILETIME=[E44E7E60:01CC7302] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 17:20:33 -0000 Pete, If multiple BS' co-ordinate among themselves (master-slave relationship) and only the master BS sends the query, then that use-case is beyond the scope of the PAWS charter. The protocol that is being specified is the one between this master-BS (or master WS device) and the database. If a network has multiple BS' and there exists co-ordination between them, with only one of the BS' having the authority to query the database that=B9= s fine. Because it is invisible to the protocol that we are defining in PAWS.=20 -Raj On 9/14/11 12:13 PM, "ext Peter McCann" wrote: >Hi, Gerald, > >I think what Scott is asking about is coordination in access to >the channel after it has been cleared for use by the WSDB. > >It seems like you are asking about how to coordinate the assignment >of the channel among all the different BS. I agree that one BS >could act as the "master", collecting information from the peer >BSs and presenting it all to the WSDB in a query for a vacant >channel. Isn't this the same as the existing WRAN use case in >Section 4.3? Or is there some difference due to the fact that >all the BSs are "Master" devices? > >-Pete > >Gerald Chouinard wrote: >> Scott, Peter, >>=20 >> One way to provide such a coordination would be to nominate one BS in >> an area as the master BS that would query the DB for itself and on >> behalf of the other 'slave' BSs. Coordination could then be done >> locally by the master BS by sending a filtered version of the >> available channels list as received from the DB to the appropriate >>slave BS. >>=20 >> Unfortunately,it is still not clear whether the regulations in the >> various countries will allow such 'proxying' of TVBD's by other TVBD's >> and that this will not pose security problems. If it is allowed >> everywhere and appropriate security can be achieved, then such >> coordination could be transparent to the DB since it would take place >> at the master BS without the DB having to know about it. It would >> only know that a BS is asking for the channels availability on behalf >> of other BSs. >>=20 >> Gerald >>=20 >>=20 >> At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: >>> Hi Pete, >>>=20 >>> There is no coordination aspect to TDD is there? I added TDD >>> initially to indicate that a single channel is used for operation, >>> contrasted to the 2 channel requirement for FDD. >>>=20 >>> I believe the use case under discussion is using the channel for full >>> DL broadcast. It's not so much as coordination, just 100% DL. Right? >>>=20 >>> Would help me if you could clarify what spectrum coordination is >>> happening in this case. >>>=20 >>> Regards, >>> Scott >>>=20 >>>=20 >>> On 9/14/11 8:20 AM, "ext Peter McCann" wrote: >>>=20 >>>> Hi, Scott, >>>>=20 >>>> scott.probasco@nokia.com wrote: >>>>> Hi, >>>>>=20 >>>>> Thank you Peter & Lei for the more detailed description of the use >>>>> case. When I look at this case, the question is: can PAWS be used to >>>>> allow multiple Master devices to knowingly select the same channel >>>>> for operation. (The discussion of "why" and "is it a good idea" not >>>>> undertaken here as this likely wanders outside the scope of PAWS). >>>>>=20 >>>>> One of the proposed solutions is coordination among BSs (external >>>>> to PAWS). This is already described in section 4.3 Wide-Area or >>>>> Rural internet broadband access: >>>>>=20 >>>>>> Some of the masters/BSs may be deployed and operated by a single >>>>>> entity, i.e. there can be centralized coordination between these >>>>>> masters/BSs,... >>>>>=20 >>>>> Further, you note the difference is in TDD: >>>>>=20 >>>>>> The BS in this scenario use a TDD radio Technology >>>>>=20 >>>>> Would it be appropriate and acceptable to WG members to add >>>>> "typically" such as: >>>>>=20 >>>>>> The BS in this scenario typically uses a TDD radio Technology... >>>>>=20 >>>>> Does this enable the use case you are describing? >>>>=20 >>>> Maybe we could say: >>>>=20 >>>> The BS in this scenario typically use a TDD radio technology or other >>>> means to coordinate use of the selected spectrum. >>>>=20 >>>> -Pete >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, >>>>> Scott >>>>>=20 >>>>>=20 >>>>> On 9/13/11 12:37 PM, "ext Peter McCann" >>>>> wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I've been interacting with Zhu Lei off-list about his third use >>>>>> case, and I think it would be a possible candidate for inclusion >>>>>> in the document if it were properly explained. >>>>>>=20 >>>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>>> problem is to find a common bit of spectrum that is available over a >>>>>> wide area that can be used by multiple master BSs to simultaneously >>>>>> broadcast the same signal to a set of receivers. This is somewhat >>>>>> similar to the wide-area rural coverage scenario currently described >>>>>> in the working group document; however, there would be multiple >>>>>> Master BSs, each of which would independently query the WSDB for >>>>>> available spectrum. However, they need to coordinate the assignment >>>>>> so that they all get the same spectrum over the whole area. As an >>>>>> implementation example, this could be achieved by each BS reporting >>>>>> the same owner/operator and using a key or index value to indicate >>>>>> that they wanted to coordinate the assignment. Alternatively, you >>>>>> might be able to elect one BS as the leader and collect location >>>>>> information from all the other BSs and then coordinate the >>>>>> assignment similar to the use case in 4.2; the difference would be >>>>>> that the resulting assignment is for simultaneous (not TDD) use by >>>>>> all of the BSs covering the wider area. >>>>>>=20 >>>>>> Does this sound like an interesting and novel use case? If so I can >>>>>> do a more detailed writeup and supply ASCII art for the draft. >>>>>>=20 >>>>>> -- >>>>>> Peter J. McCann >>>>>> Huawei Technologies (USA) >>>>>> Peter.McCann@Huawei.com >>>>>> +1 908 541 3563 >>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>> 08807-2863 USA > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@crc.ca Wed Sep 14 10:28:10 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 C5C7121F8C10 for ; Wed, 14 Sep 2011 10:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 IzX0zKa6WqDW for ; Wed, 14 Sep 2011 10:28:10 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 9358E21F8C14 for ; Wed, 14 Sep 2011 10:28:09 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id EBF756B04CF; Wed, 14 Sep 2011 13:30:18 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id CB9A86B03CA; Wed, 14 Sep 2011 13:30:18 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id BB4006B03D9; Wed, 14 Sep 2011 13:30:18 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id B20576B03C1; Wed, 14 Sep 2011 13:30:17 -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 5E6416B15B4; Wed, 14 Sep 2011 13:30:17 -0400 (EDT) Message-Id: <5.1.0.14.2.20110914132100.0287b758@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Sep 2011 13:30:20 -0400 To: Peter McCann From: Gerald Chouinard References: <5.1.0.14.2.20110914125759.02bb7dd8@imap.crc.ca> <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914125759.02bb7dd8@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" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 17:28:10 -0000 Peter, Yes, it is very similar to what we are trying to do in the WRAN use case where the BS would collect the geolocation information from all its CPEs and query the DB on their behalf. The list of available channels for each CPE would then be collated by the BS and the decision as to what channel would be used by the WRAN cell would be made at the BS and transmitted to its CPEs. No need to forward the list of available channels to the CPEs since they are slave to the BS and are bound to operate on the same channel to be part of the network. The unknown is still whether this 'proxying' of DB request on behalf of the CPEs is acceptable to the regulators. I still have not been able to satisfy myself with the wording that exists in the FCC Part 15.700. This will need to be clarified for this application as well as what I was proposing for the multiple BS case that need to coordinate the channel usage. In this latter case, the master BS may need to forward the list of available channels to the appropriate BS in case they want to move to a different channel which is not the case for a WRAN cell. Gerald At 17:13 14-09-11 +0000, Peter McCann wrote: >Hi, Gerald, > >I think what Scott is asking about is coordination in access to >the channel after it has been cleared for use by the WSDB. > >It seems like you are asking about how to coordinate the assignment >of the channel among all the different BS. I agree that one BS >could act as the "master", collecting information from the peer >BSs and presenting it all to the WSDB in a query for a vacant >channel. Isn't this the same as the existing WRAN use case in >Section 4.3? Or is there some difference due to the fact that >all the BSs are "Master" devices? > >-Pete > >Gerald Chouinard wrote: > > Scott, Peter, > > > > One way to provide such a coordination would be to nominate one BS in > > an area as the master BS that would query the DB for itself and on > > behalf of the other 'slave' BSs. Coordination could then be done > > locally by the master BS by sending a filtered version of the > > available channels list as received from the DB to the appropriate > slave BS. > > > > Unfortunately,it is still not clear whether the regulations in the > > various countries will allow such 'proxying' of TVBD's by other TVBD's > > and that this will not pose security problems. If it is allowed > > everywhere and appropriate security can be achieved, then such > > coordination could be transparent to the DB since it would take place > > at the master BS without the DB having to know about it. It would > > only know that a BS is asking for the channels availability on behalf > > of other BSs. > > > > Gerald > > > > > > At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: > >> Hi Pete, > >> > >> There is no coordination aspect to TDD is there? I added TDD > >> initially to indicate that a single channel is used for operation, > >> contrasted to the 2 channel requirement for FDD. > >> > >> I believe the use case under discussion is using the channel for full > >> DL broadcast. It's not so much as coordination, just 100% DL. Right? > >> > >> Would help me if you could clarify what spectrum coordination is > >> happening in this case. > >> > >> Regards, > >> Scott > >> > >> > >> On 9/14/11 8:20 AM, "ext Peter McCann" wrote: > >> > >>> Hi, Scott, > >>> > >>> scott.probasco@nokia.com wrote: > >>>> Hi, > >>>> > >>>> Thank you Peter & Lei for the more detailed description of the use > >>>> case. When I look at this case, the question is: can PAWS be used to > >>>> allow multiple Master devices to knowingly select the same channel > >>>> for operation. (The discussion of "why" and "is it a good idea" not > >>>> undertaken here as this likely wanders outside the scope of PAWS). > >>>> > >>>> One of the proposed solutions is coordination among BSs (external > >>>> to PAWS). This is already described in section 4.3 Wide-Area or > >>>> Rural internet broadband access: > >>>> > >>>>> Some of the masters/BSs may be deployed and operated by a single > >>>>> entity, i.e. there can be centralized coordination between these > >>>>> masters/BSs,... > >>>> > >>>> Further, you note the difference is in TDD: > >>>> > >>>>> The BS in this scenario use a TDD radio Technology > >>>> > >>>> Would it be appropriate and acceptable to WG members to add > >>>> "typically" such as: > >>>> > >>>>> The BS in this scenario typically uses a TDD radio Technology... > >>>> > >>>> Does this enable the use case you are describing? > >>> > >>> Maybe we could say: > >>> > >>> The BS in this scenario typically use a TDD radio technology or other > >>> means to coordinate use of the selected spectrum. > >>> > >>> -Pete > >>> > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Scott > >>>> > >>>> > >>>> On 9/13/11 12:37 PM, "ext Peter McCann" > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I've been interacting with Zhu Lei off-list about his third use > >>>>> case, and I think it would be a possible candidate for inclusion > >>>>> in the document if it were properly explained. > >>>>> > >>>>> Generally (as opposed to specifically for the LTE MBMS case), the > >>>>> problem is to find a common bit of spectrum that is available over a > >>>>> wide area that can be used by multiple master BSs to simultaneously > >>>>> broadcast the same signal to a set of receivers. This is somewhat > >>>>> similar to the wide-area rural coverage scenario currently described > >>>>> in the working group document; however, there would be multiple > >>>>> Master BSs, each of which would independently query the WSDB for > >>>>> available spectrum. However, they need to coordinate the assignment > >>>>> so that they all get the same spectrum over the whole area. As an > >>>>> implementation example, this could be achieved by each BS reporting > >>>>> the same owner/operator and using a key or index value to indicate > >>>>> that they wanted to coordinate the assignment. Alternatively, you > >>>>> might be able to elect one BS as the leader and collect location > >>>>> information from all the other BSs and then coordinate the > >>>>> assignment similar to the use case in 4.2; the difference would be > >>>>> that the resulting assignment is for simultaneous (not TDD) use by > >>>>> all of the BSs covering the wider area. > >>>>> > >>>>> Does this sound like an interesting and novel use case? If so I can > >>>>> do a more detailed writeup and supply ASCII art for the draft. > >>>>> > >>>>> -- > >>>>> Peter J. McCann > >>>>> Huawei Technologies (USA) > >>>>> Peter.McCann@Huawei.com > >>>>> +1 908 541 3563 > >>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ > >>>>> 08807-2863 USA From gerald.chouinard@crc.ca Wed Sep 14 10:30:42 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 3711621F8C57 for ; Wed, 14 Sep 2011 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, 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 bmdeLRZiMSxL for ; Wed, 14 Sep 2011 10:30:41 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 2862221F8C10 for ; Wed, 14 Sep 2011 10:30:41 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 8308F6B04CF for ; Wed, 14 Sep 2011 13:32:50 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 6C3536B03B7 for ; Wed, 14 Sep 2011 13:32:50 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 5C2076B03CA; Wed, 14 Sep 2011 13:32:50 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id D456A6B03B7 for ; Wed, 14 Sep 2011 13:32:47 -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 928EF6B15B4 for ; Wed, 14 Sep 2011 13:32:47 -0400 (EDT) Message-Id: <5.1.0.14.2.20110914133219.0287b898@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Sep 2011 13:32:50 -0400 To: From: Gerald Chouinard In-Reply-To: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 17:30:42 -0000 I agree with Raj. Gerald At 17:22 14-09-11 +0000, Basavaraj.Patil@nokia.com wrote: >Pete, > >If multiple BS' co-ordinate among themselves (master-slave relationship) >and only the master BS sends the query, then that use-case is beyond the >scope of the PAWS charter. >The protocol that is being specified is the one between this master-BS (or >master WS device) and the database. >If a network has multiple BS' and there exists co-ordination between them, >with only one of the BS' having the authority to query the database that=B9= s >fine. Because it is invisible to the protocol that we are defining in >PAWS. > >-Raj > >On 9/14/11 12:13 PM, "ext Peter McCann" wrote: > > >Hi, Gerald, > > > >I think what Scott is asking about is coordination in access to > >the channel after it has been cleared for use by the WSDB. > > > >It seems like you are asking about how to coordinate the assignment > >of the channel among all the different BS. I agree that one BS > >could act as the "master", collecting information from the peer > >BSs and presenting it all to the WSDB in a query for a vacant > >channel. Isn't this the same as the existing WRAN use case in > >Section 4.3? Or is there some difference due to the fact that > >all the BSs are "Master" devices? > > > >-Pete > > > >Gerald Chouinard wrote: > >> Scott, Peter, > >> > >> One way to provide such a coordination would be to nominate one BS in > >> an area as the master BS that would query the DB for itself and on > >> behalf of the other 'slave' BSs. Coordination could then be done > >> locally by the master BS by sending a filtered version of the > >> available channels list as received from the DB to the appropriate > >>slave BS. > >> > >> Unfortunately,it is still not clear whether the regulations in the > >> various countries will allow such 'proxying' of TVBD's by other TVBD's > >> and that this will not pose security problems. If it is allowed > >> everywhere and appropriate security can be achieved, then such > >> coordination could be transparent to the DB since it would take place > >> at the master BS without the DB having to know about it. It would > >> only know that a BS is asking for the channels availability on behalf > >> of other BSs. > >> > >> Gerald > >> > >> > >> At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: > >>> Hi Pete, > >>> > >>> There is no coordination aspect to TDD is there? I added TDD > >>> initially to indicate that a single channel is used for operation, > >>> contrasted to the 2 channel requirement for FDD. > >>> > >>> I believe the use case under discussion is using the channel for full > >>> DL broadcast. It's not so much as coordination, just 100% DL. Right? > >>> > >>> Would help me if you could clarify what spectrum coordination is > >>> happening in this case. > >>> > >>> Regards, > >>> Scott > >>> > >>> > >>> On 9/14/11 8:20 AM, "ext Peter McCann" = wrote: > >>> > >>>> Hi, Scott, > >>>> > >>>> scott.probasco@nokia.com wrote: > >>>>> Hi, > >>>>> > >>>>> Thank you Peter & Lei for the more detailed description of the use > >>>>> case. When I look at this case, the question is: can PAWS be used to > >>>>> allow multiple Master devices to knowingly select the same channel > >>>>> for operation. (The discussion of "why" and "is it a good idea" not > >>>>> undertaken here as this likely wanders outside the scope of PAWS). > >>>>> > >>>>> One of the proposed solutions is coordination among BSs (external > >>>>> to PAWS). This is already described in section 4.3 Wide-Area or > >>>>> Rural internet broadband access: > >>>>> > >>>>>> Some of the masters/BSs may be deployed and operated by a single > >>>>>> entity, i.e. there can be centralized coordination between these > >>>>>> masters/BSs,... > >>>>> > >>>>> Further, you note the difference is in TDD: > >>>>> > >>>>>> The BS in this scenario use a TDD radio Technology > >>>>> > >>>>> Would it be appropriate and acceptable to WG members to add > >>>>> "typically" such as: > >>>>> > >>>>>> The BS in this scenario typically uses a TDD radio Technology... > >>>>> > >>>>> Does this enable the use case you are describing? > >>>> > >>>> Maybe we could say: > >>>> > >>>> The BS in this scenario typically use a TDD radio technology or other > >>>> means to coordinate use of the selected spectrum. > >>>> > >>>> -Pete > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> Scott > >>>>> > >>>>> > >>>>> On 9/13/11 12:37 PM, "ext Peter McCann" > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I've been interacting with Zhu Lei off-list about his third use > >>>>>> case, and I think it would be a possible candidate for inclusion > >>>>>> in the document if it were properly explained. > >>>>>> > >>>>>> Generally (as opposed to specifically for the LTE MBMS case), the > >>>>>> problem is to find a common bit of spectrum that is available over= a > >>>>>> wide area that can be used by multiple master BSs to simultaneously > >>>>>> broadcast the same signal to a set of receivers. This is somewhat > >>>>>> similar to the wide-area rural coverage scenario currently= described > >>>>>> in the working group document; however, there would be multiple > >>>>>> Master BSs, each of which would independently query the WSDB for > >>>>>> available spectrum. However, they need to coordinate the= assignment > >>>>>> so that they all get the same spectrum over the whole area. As an > >>>>>> implementation example, this could be achieved by each BS reporting > >>>>>> the same owner/operator and using a key or index value to indicate > >>>>>> that they wanted to coordinate the assignment. Alternatively, you > >>>>>> might be able to elect one BS as the leader and collect location > >>>>>> information from all the other BSs and then coordinate the > >>>>>> assignment similar to the use case in 4.2; the difference would be > >>>>>> that the resulting assignment is for simultaneous (not TDD) use by > >>>>>> all of the BSs covering the wider area. > >>>>>> > >>>>>> Does this sound like an interesting and novel use case? If so I= can > >>>>>> do a more detailed writeup and supply ASCII art for the draft. > >>>>>> > >>>>>> -- > >>>>>> Peter J. McCann > >>>>>> Huawei Technologies (USA) > >>>>>> Peter.McCann@Huawei.com > >>>>>> +1 908 541 3563 > >>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ > >>>>>> 08807-2863 USA > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Sep 14 11:01:54 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 027F521F8B48 for ; Wed, 14 Sep 2011 11:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 WLTRGl8cKKqX for ; Wed, 14 Sep 2011 11:01:53 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 769B121F8B3A for ; Wed, 14 Sep 2011 11:01:53 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00BMKXB0B9@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 12:45:02 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRI00ADKX52BE@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 12:41:27 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 10:41:21 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 10:41:25 -0700 Date: Wed, 14 Sep 2011 17:41:24 +0000 From: Peter McCann In-reply-to: <5.1.0.14.2.20110914130859.0287b618@imap.crc.ca> X-Originating-IP: [10.193.125.70] To: Gerald Chouinard Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A3C5@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAkTtF///6+JA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A034@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914130859.0287b618@imap.crc.ca> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 18:01:54 -0000 Hi, Gerald, Even in TDD there must at least be an agreement on which side is allowed to transmit during which half of the frame interval. That's the coordination to which I was referring. And in a point-to-multipoint system like TDD-LTE, you need to schedule the uplink users in the time and frequency domain (resource blocks). So I think the phrase "TDD radio technology or other means to coordinate use of the selected spectrum" would be appropriate wording. -Pete Gerald Chouinard wrote: > Peter, > > I guess you are referring to TDM (time-division multiplex) in your > email and not TDD (time-division duplex). TDD refers to bidirectional > communications using the same channel in both directions. A > unidirectional communication such as a broadcast application is, by > definition, not TDD. However, if there are multiple BSs that use the > same channel, they can be using TDM to share the channel or, if the > information content is the same, they can even use the same channel > simultaneously under certain conditions to take advantage of the > redundancy in transmission signals. The conditions are that these > transmissions need to be tightly synchronized in frequency and > relatively closely synchronized in time so that, for single-carrier > modulation, the receivers can recover the signal after proper echo > equalization, and for multi-carrier modulation such as OFDM, all the > echoes created by these similar transmissions fall within the guard > interval (i.e., cyclic prefix) to avoid inter-symbol interference. > > Gerald > > > At 16:13 14-09-11 +0000, Peter McCann wrote: > > > TDD is a turn-taking mechanism for sharing the spectrum. I would call > that a form of coordination between the various transmitters. Someone > needs to publish a schedule of who is allowed to transmit when. > > In the broadcast case, the coordination required is for all BS to > transmit exactly the same physical layer signal at the same time > so that receivers see constructive interference. > > -Pete > From Peter.McCann@huawei.com Wed Sep 14 11:01:54 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 3CE3121F8B4A for ; Wed, 14 Sep 2011 11:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 0hcKHJQc1so9 for ; Wed, 14 Sep 2011 11:01:53 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 508C521F8B38 for ; Wed, 14 Sep 2011 11:01:53 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00BMKXB0B9@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 12:45:01 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRI00AZLWO0BE@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 12:31:16 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 10:30:08 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 10:30:09 -0700 Date: Wed, 14 Sep 2011 17:30:08 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "Basavaraj.Patil@nokia.com" , "gerald.chouinard@crc.ca" , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIABAtKAgAB1DzD//49ngIAAdSKA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 18:01:54 -0000 Hi, Raj, I think my use case is covered by Section 4.3 with a small change along the lines that Scott suggested. Note there is this text in step 8: 8. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS. The slave/user device provides its geolocation to the BS which, in turn, queries the database for a list of channels available at the slaves' geolocation. What I am suggesting is no different except for the fact that each of the devices could have independent Internet access and be capable of querying the database itself. There could be one BS that handles all the queries or the individual BSs could query themselves (each for their own location) and they could compare notes to find a common free channel. As for the protocol between the BS and the WSDB, we may want to have a requirement that the protocol carry multiple location elements (instead of just one) so that we save the cost of multiple queries across the Internet. The WSDB, after doing the polygon intersection test at each location, could additionally do a set intersection test on the remaining free channels and return the results. That's one concrete way that this use case may impact the protocol specification. -Pete Basavaraj.Patil@nokia.com wrote: >=20 > Pete, >=20 > If multiple BS' co-ordinate among themselves (master-slave > relationship) and only the master BS sends the query, then that use- > case is beyond the scope of the PAWS charter. > The protocol that is being specified is the one between this master-BS > (or master WS device) and the database. > If a network has multiple BS' and there exists co-ordination between > them, with only one of the BS' having the authority to query the > database that=B9s fine. Because it is invisible to the protocol that we > are defining in PAWS. >=20 > -Raj >=20 > On 9/14/11 12:13 PM, "ext Peter McCann" wrote: >=20 >> Hi, Gerald, >>=20 >> I think what Scott is asking about is coordination in access to the >> channel after it has been cleared for use by the WSDB. >>=20 >> It seems like you are asking about how to coordinate the assignment >> of the channel among all the different BS. I agree that one BS could >> act as the "master", collecting information from the peer BSs and >> presenting it all to the WSDB in a query for a vacant channel. Isn't >> this the same as the existing WRAN use case in Section 4.3? Or is >> there some difference due to the fact that all the BSs are "Master" >> devices? >>=20 >> -Pete >>=20 >> Gerald Chouinard wrote: >>> Scott, Peter, >>>=20 >>> One way to provide such a coordination would be to nominate one BS in >>> an area as the master BS that would query the DB for itself and on >>> behalf of the other 'slave' BSs. Coordination could then be done >>> locally by the master BS by sending a filtered version of the >>> available channels list as received from the DB to the appropriate >>> slave BS. >>>=20 >>> Unfortunately,it is still not clear whether the regulations in the >>> various countries will allow such 'proxying' of TVBD's by other >>> TVBD's and that this will not pose security problems. If it is >>> allowed everywhere and appropriate security can be achieved, then >>> such coordination could be transparent to the DB since it would >>> take place at the master BS without the DB having to know about it. >>> It would only know that a BS is asking for the channels >>> availability on behalf of other BSs. >>>=20 >>> Gerald >>>=20 >>>=20 >>> At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: >>>> Hi Pete, >>>>=20 >>>> There is no coordination aspect to TDD is there? I added TDD >>>> initially to indicate that a single channel is used for operation, >>>> contrasted to the 2 channel requirement for FDD. >>>>=20 >>>> I believe the use case under discussion is using the channel for full >>>> DL broadcast. It's not so much as coordination, just 100% DL. Right? >>>>=20 >>>> Would help me if you could clarify what spectrum coordination is >>>> happening in this case. >>>>=20 >>>> Regards, >>>> Scott >>>>=20 >>>>=20 >>>> On 9/14/11 8:20 AM, "ext Peter McCann" >>>> wrote: >>>>=20 >>>>> Hi, Scott, >>>>>=20 >>>>> scott.probasco@nokia.com wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Thank you Peter & Lei for the more detailed description of the use >>>>>> case. When I look at this case, the question is: can PAWS be used >>>>>> to allow multiple Master devices to knowingly select the same >>>>>> channel for operation. (The discussion of "why" and "is it a good >>>>>> idea" not undertaken here as this likely wanders outside the scope >>>>>> of PAWS). >>>>>>=20 >>>>>> One of the proposed solutions is coordination among BSs >>>>>> (external to PAWS). This is already described in section 4.3 >>>>>> Wide-Area or Rural internet broadband access: >>>>>>=20 >>>>>>> Some of the masters/BSs may be deployed and operated by a >>>>>>> single entity, i.e. there can be centralized coordination >>>>>>> between these masters/BSs,... >>>>>>=20 >>>>>> Further, you note the difference is in TDD: >>>>>>=20 >>>>>>> The BS in this scenario use a TDD radio Technology >>>>>>=20 >>>>>> Would it be appropriate and acceptable to WG members to add >>>>>> "typically" such as: >>>>>>=20 >>>>>>> The BS in this scenario typically uses a TDD radio Technology... >>>>>>=20 >>>>>> Does this enable the use case you are describing? >>>>>=20 >>>>> Maybe we could say: >>>>>=20 >>>>> The BS in this scenario typically use a TDD radio technology or >>>>> other means to coordinate use of the selected spectrum. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Scott >>>>>>=20 >>>>>>=20 >>>>>> On 9/13/11 12:37 PM, "ext Peter McCann" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I've been interacting with Zhu Lei off-list about his third use >>>>>>> case, and I think it would be a possible candidate for >>>>>>> inclusion in the document if it were properly explained. >>>>>>>=20 >>>>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>>>> problem is to find a common bit of spectrum that is available over >>>>>>> a wide area that can be used by multiple master BSs to >>>>>>> simultaneously broadcast the same signal to a set of receivers. >>>>>>> This is somewhat similar to the wide-area rural coverage scenario >>>>>>> currently described in the working group document; however, there >>>>>>> would be multiple Master BSs, each of which would independently >>>>>>> query the WSDB for available spectrum. However, they need to >>>>>>> coordinate the assignment so that they all get the same spectrum >>>>>>> over the whole area. As an implementation example, this could be >>>>>>> achieved by each BS reporting the same owner/operator and using a >>>>>>> key or index value to indicate that they wanted to coordinate the >>>>>>> assignment. Alternatively, you might be able to elect one BS as >>>>>>> the leader and collect location information from all the other BSs >>>>>>> and then coordinate the assignment similar to the use case in 4.2; >>>>>>> the difference would be that the resulting assignment is for >>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >>>>>>> area. >>>>>>>=20 >>>>>>> Does this sound like an interesting and novel use case? If so I >>>>>>> can do a more detailed writeup and supply ASCII art for the draft. >>>>>>>=20 >>>>>>> -- >>>>>>> Peter J. McCann >>>>>>> Huawei Technologies (USA) >>>>>>> Peter.McCann@Huawei.com >>>>>>> +1 908 541 3563 >>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>>> 08807-2863 USA From scott.probasco@nokia.com Wed Sep 14 11:19:51 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 80BCB21F8CA0 for ; Wed, 14 Sep 2011 11:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 jKF7ehP2docB for ; Wed, 14 Sep 2011 11:19:50 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8085221F8C58 for ; Wed, 14 Sep 2011 11:19:50 -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 p8EIJeDX026213 for ; Wed, 14 Sep 2011 21:21:38 +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, 14 Sep 2011 21:21:18 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 20:21:18 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 20:21:17 +0200 From: To: Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAa/KAgAAB7wD//67PgIAAVpcA//+5s4A= Date: Wed, 14 Sep 2011 18:21:16 +0000 Message-ID: In-Reply-To: <5.1.0.14.2.20110914133219.0287b898@imap.crc.ca> 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.241.50.179] Content-Type: text/plain; charset="euc-kr" Content-ID: <1AA1B8DC7FE6CC418D372BB018CBB4B6@nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 18:21:18.0300 (UTC) FILETIME=[18B129C0:01CC730B] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 18:19:51 -0000 SGkgQWxsLA0KDQpNeSBjb21tZW50IHdhcyBhYm91dCB0aGUgd29yZGluZyBvZiB0aGUgV2lkZS1B cmVhIG9yIFJ1cmFsIGludGVybmV0DQpicm9hZGJhbmQgYWNjZXNzIHVzZSBjYXNlOg0KDQo+RnVy dGhlciwgeW91IG5vdGUgdGhlIGRpZmZlcmVuY2UgaXMgaW4gVEREOg0KPj5UaGUgQlMgaW4gdGhp cyBzY2VuYXJpbyB1c2UgYSBUREQgcmFkaW8gVGVjaG5vbG9neQ0KPldvdWxkIGl0IGJlIGFwcHJv cHJpYXRlIGFuZCBhY2NlcHRhYmxlIHRvIFdHIG1lbWJlcnMgdG8gYWRkDQo+InR5cGljYWxseSIg c3VjaCBhczoNCj4+VGhlIEJTIGluIHRoaXMgc2NlbmFyaW8gdHlwaWNhbGx5IHVzZXMgYSBUREQg cmFkaW8gVGVjaG5vbG9neS4uLg0KPkRvZXMgdGhpcyBlbmFibGUgdGhlIHVzZSBjYXNlIHlvdSBh cmUgZGVzY3JpYmluZz8NCk1heWJlIHdlIGNvdWxkIHNheToNClRoZSBCUyBpbiB0aGlzIHNjZW5h cmlvIHR5cGljYWxseSB1c2UgYSBUREQgcmFkaW8gdGVjaG5vbG9neSBvciBvdGhlcg0KbWVhbnMg dG8gY29vcmRpbmF0ZSB1c2Ugb2YgdGhlIHNlbGVjdGVkIHNwZWN0cnVtLg0KDQoNClNwZWNpZmlj YWxseSBJIGRvbid0IHNlZSBob3cgVEREIGNvb3JkaW5hdGVzIHVzZSBvZiB0aGUgc3BlY3RydW07 IGl0DQpzaW1wbHkgaXMgb25lIG1ldGhvZCBvZiBkdXBsZXhpbmcgd2hpY2ggYWxsb3dzIHVzZSBv ZiBzaW5nbGUgcmFkaW8NCmZyZXF1ZW5jeSBmb3IgYmktZGlyZWN0aW9uYWwgY29tbXVuaWNhdGlv bi4gVGhlIHdoaXRlIHNwYWNlIHBhcmFkaWdtIG9ubHkNCmFmZm9yZHMgcHJvdGVjdGlvbiB0byB0 aGUgbGljZW5zZWQgcHJpbWFyeSB1c2VyLCBubyBwcm90ZWN0aW9uIHRvIGFueQ0KbGljZW5zZWQt ZXhlbXB0IHNlY29uZGFyeSB1c2VyLCBpLmUuIHVzZSBvZiB0aGUgc3BlY3RydW0gaXMgbm90DQpj b29yZGluYXRlZCAob3RoZXIgdGhhbiB0aGUgZGF0YWJhc2UgaW5kaWNhdGluZyB3aGljaCBjaGFu bmVscyBhcmUNCmF2YWlsYWJsZSBmb3Igc2Vjb25kYXJ5IHVzZSkuIFRodXMgSSBzdWdnZXN0IHRv IHN0cmlrZSAib3Igb3RoZXIgbWVhbnMgdG8NCmNvb3JkaW5hdGUgdXNlIG9mIHRoZSBzZWxlY3Rl ZCBzcGVjdHJ1bSIgZnJvbSBQZXRlJ3MgcHJvcG9zYWwuDQoNClJlZ2FyZGluZyB0aGUgc2NlbmFy aW9zIG9mIGNvb3JkaW5hdGlvbiwgUEFXUyBpcyBhIHByb3RvY29sIHRvIHRyYW5zcG9ydA0KaW5m b3JtYXRpb24uIEl0IHNob3VsZCBzdXBwb3J0IFJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIGdsb2Jh bGx5LCBpbmNsdWRpbmcNCnRob3NlIGZyb20gdGhlIEZDQyBidXQgbm90IGxpbWl0ZWQgdG8gdGhl IEZDQyByZXF1aXJlbWVudHMuIEkgYmVsaWV2ZSB0aGlzDQphbHNvIG1lYW5zIHdlICBuZWVkIHRv IGJlIG9wZW4tbWluZGVkIGFuZCBmb3J3YXJkLXRoaW5raW5nIHNpbmNlIG90aGVyDQpSZWd1bGF0 b3J5IGdyb3VwcyBhcmUgYWN0aXZlbHkgcmV2aWV3aW5nIHdoaXRlIHNwYWNlIHBhcmFkaWdtcywg YW5kIHRoZWlyDQpyZXF1aXJlbWVudHMgYXJlIHlldCB0byBiZSBzZWVuLg0KDQpSZWdhcmRzLA0K U2NvdHQNCg0KDQoNCk9uIDkvMTQvMTEgMTI6MzIgUE0sICJleHQgR2VyYWxkIENob3VpbmFyZCIg PGdlcmFsZC5jaG91aW5hcmRAY3JjLmNhPg0Kd3JvdGU6DQoNCj4NCj5JIGFncmVlIHdpdGggUmFq Lg0KPg0KPkdlcmFsZA0KPg0KPkF0IDE3OjIyIDE0LTA5LTExICswMDAwLCBCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tIHdyb3RlOg0KPg0KPj5QZXRlLA0KPj4NCj4+SWYgbXVsdGlwbGUgQlMnIGNv LW9yZGluYXRlIGFtb25nIHRoZW1zZWx2ZXMgKG1hc3Rlci1zbGF2ZSByZWxhdGlvbnNoaXApDQo+ PmFuZCBvbmx5IHRoZSBtYXN0ZXIgQlMgc2VuZHMgdGhlIHF1ZXJ5LCB0aGVuIHRoYXQgdXNlLWNh c2UgaXMgYmV5b25kIHRoZQ0KPj5zY29wZSBvZiB0aGUgUEFXUyBjaGFydGVyLg0KPj5UaGUgcHJv dG9jb2wgdGhhdCBpcyBiZWluZyBzcGVjaWZpZWQgaXMgdGhlIG9uZSBiZXR3ZWVuIHRoaXMgbWFz dGVyLUJTDQo+Pihvcg0KPj5tYXN0ZXIgV1MgZGV2aWNlKSBhbmQgdGhlIGRhdGFiYXNlLg0KPj5J ZiBhIG5ldHdvcmsgaGFzIG11bHRpcGxlIEJTJyBhbmQgdGhlcmUgZXhpc3RzIGNvLW9yZGluYXRp b24gYmV0d2Vlbg0KPj50aGVtLA0KPj53aXRoIG9ubHkgb25lIG9mIHRoZSBCUycgaGF2aW5nIHRo ZSBhdXRob3JpdHkgdG8gcXVlcnkgdGhlIGRhdGFiYXNlDQo+PnRoYXSp9nMNCj4+ZmluZS4gQmVj YXVzZSBpdCBpcyBpbnZpc2libGUgdG8gdGhlIHByb3RvY29sIHRoYXQgd2UgYXJlIGRlZmluaW5n IGluDQo+PlBBV1MuDQo+Pg0KPj4tUmFqDQo+Pg0KPj5PbiA5LzE0LzExIDEyOjEzIFBNLCAiZXh0 IFBldGVyIE1jQ2FubiIgPFBldGVyLk1jQ2FubkBodWF3ZWkuY29tPiB3cm90ZToNCj4+DQo+PiA+ SGksIEdlcmFsZCwNCj4+ID4NCj4+ID5JIHRoaW5rIHdoYXQgU2NvdHQgaXMgYXNraW5nIGFib3V0 IGlzIGNvb3JkaW5hdGlvbiBpbiBhY2Nlc3MgdG8NCj4+ID50aGUgY2hhbm5lbCBhZnRlciBpdCBo YXMgYmVlbiBjbGVhcmVkIGZvciB1c2UgYnkgdGhlIFdTREIuDQo+PiA+DQo+PiA+SXQgc2VlbXMg bGlrZSB5b3UgYXJlIGFza2luZyBhYm91dCBob3cgdG8gY29vcmRpbmF0ZSB0aGUgYXNzaWdubWVu dA0KPj4gPm9mIHRoZSBjaGFubmVsIGFtb25nIGFsbCB0aGUgZGlmZmVyZW50IEJTLiAgSSBhZ3Jl ZSB0aGF0IG9uZSBCUw0KPj4gPmNvdWxkIGFjdCBhcyB0aGUgIm1hc3RlciIsIGNvbGxlY3Rpbmcg aW5mb3JtYXRpb24gZnJvbSB0aGUgcGVlcg0KPj4gPkJTcyBhbmQgcHJlc2VudGluZyBpdCBhbGwg dG8gdGhlIFdTREIgaW4gYSBxdWVyeSBmb3IgYSB2YWNhbnQNCj4+ID5jaGFubmVsLiAgSXNuJ3Qg dGhpcyB0aGUgc2FtZSBhcyB0aGUgZXhpc3RpbmcgV1JBTiB1c2UgY2FzZSBpbg0KPj4gPlNlY3Rp b24gNC4zPyAgT3IgaXMgdGhlcmUgc29tZSBkaWZmZXJlbmNlIGR1ZSB0byB0aGUgZmFjdCB0aGF0 DQo+PiA+YWxsIHRoZSBCU3MgYXJlICJNYXN0ZXIiIGRldmljZXM/DQo+PiA+DQo+PiA+LVBldGUN Cj4+ID4NCj4+ID5HZXJhbGQgQ2hvdWluYXJkIHdyb3RlOg0KPj4gPj4gU2NvdHQsIFBldGVyLA0K Pj4gPj4NCj4+ID4+IE9uZSB3YXkgdG8gcHJvdmlkZSBzdWNoIGEgY29vcmRpbmF0aW9uIHdvdWxk IGJlIHRvIG5vbWluYXRlIG9uZSBCUyBpbg0KPj4gPj4gYW4gYXJlYSBhcyB0aGUgbWFzdGVyIEJT IHRoYXQgd291bGQgcXVlcnkgdGhlIERCIGZvciBpdHNlbGYgYW5kIG9uDQo+PiA+PiBiZWhhbGYg b2YgdGhlIG90aGVyICdzbGF2ZScgQlNzLiAgQ29vcmRpbmF0aW9uIGNvdWxkIHRoZW4gYmUgZG9u ZQ0KPj4gPj4gbG9jYWxseSBieSB0aGUgbWFzdGVyIEJTIGJ5IHNlbmRpbmcgYSBmaWx0ZXJlZCB2 ZXJzaW9uIG9mIHRoZQ0KPj4gPj4gYXZhaWxhYmxlIGNoYW5uZWxzIGxpc3QgYXMgcmVjZWl2ZWQg ZnJvbSB0aGUgREIgdG8gdGhlIGFwcHJvcHJpYXRlDQo+PiA+PnNsYXZlIEJTLg0KPj4gPj4NCj4+ ID4+IFVuZm9ydHVuYXRlbHksaXQgaXMgc3RpbGwgbm90IGNsZWFyIHdoZXRoZXIgdGhlIHJlZ3Vs YXRpb25zIGluIHRoZQ0KPj4gPj4gdmFyaW91cyBjb3VudHJpZXMgd2lsbCBhbGxvdyBzdWNoICdw cm94eWluZycgb2YgVFZCRCdzIGJ5IG90aGVyDQo+PlRWQkQncw0KPj4gPj4gYW5kIHRoYXQgdGhp cyB3aWxsIG5vdCBwb3NlIHNlY3VyaXR5IHByb2JsZW1zLiAgSWYgaXQgaXMgYWxsb3dlZA0KPj4g Pj4gZXZlcnl3aGVyZSBhbmQgYXBwcm9wcmlhdGUgc2VjdXJpdHkgY2FuIGJlIGFjaGlldmVkLCB0 aGVuIHN1Y2gNCj4+ID4+IGNvb3JkaW5hdGlvbiBjb3VsZCBiZSB0cmFuc3BhcmVudCB0byB0aGUg REIgc2luY2UgaXQgd291bGQgdGFrZSBwbGFjZQ0KPj4gPj4gYXQgdGhlIG1hc3RlciBCUyB3aXRo b3V0IHRoZSBEQiBoYXZpbmcgdG8ga25vdyBhYm91dCBpdC4gIEl0IHdvdWxkDQo+PiA+PiBvbmx5 IGtub3cgdGhhdCBhIEJTIGlzIGFza2luZyBmb3IgdGhlIGNoYW5uZWxzIGF2YWlsYWJpbGl0eSBv biBiZWhhbGYNCj4+ID4+IG9mIG90aGVyIEJTcy4NCj4+ID4+DQo+PiA+PiBHZXJhbGQNCj4+ID4+ DQo+PiA+Pg0KPj4gPj4gQXQgMTU6NDAgMTQtMDktMTEgKzAwMDAsIHNjb3R0LnByb2Jhc2NvQG5v a2lhLmNvbSB3cm90ZToNCj4+ID4+PiBIaSBQZXRlLA0KPj4gPj4+DQo+PiA+Pj4gVGhlcmUgaXMg bm8gY29vcmRpbmF0aW9uIGFzcGVjdCB0byBUREQgaXMgdGhlcmU/IEkgYWRkZWQgVEREDQo+PiA+ Pj4gaW5pdGlhbGx5IHRvIGluZGljYXRlIHRoYXQgYSBzaW5nbGUgY2hhbm5lbCBpcyB1c2VkIGZv ciBvcGVyYXRpb24sDQo+PiA+Pj4gY29udHJhc3RlZCB0byB0aGUgMiBjaGFubmVsIHJlcXVpcmVt ZW50IGZvciBGREQuDQo+PiA+Pj4NCj4+ID4+PiBJIGJlbGlldmUgdGhlIHVzZSBjYXNlIHVuZGVy IGRpc2N1c3Npb24gaXMgdXNpbmcgdGhlIGNoYW5uZWwgZm9yDQo+PmZ1bGwNCj4+ID4+PiBETCBi cm9hZGNhc3QuIEl0J3Mgbm90IHNvIG11Y2ggYXMgY29vcmRpbmF0aW9uLCBqdXN0IDEwMCUgREwu IFJpZ2h0Pw0KPj4gPj4+DQo+PiA+Pj4gV291bGQgaGVscCBtZSBpZiB5b3UgY291bGQgY2xhcmlm eSB3aGF0IHNwZWN0cnVtIGNvb3JkaW5hdGlvbiBpcw0KPj4gPj4+IGhhcHBlbmluZyBpbiB0aGlz IGNhc2UuDQo+PiA+Pj4NCj4+ID4+PiBSZWdhcmRzLA0KPj4gPj4+IFNjb3R0DQo+PiA+Pj4NCj4+ ID4+Pg0KPj4gPj4+IE9uIDkvMTQvMTEgODoyMCBBTSwgImV4dCBQZXRlciBNY0Nhbm4iIDxQZXRl ci5NY0Nhbm5AaHVhd2VpLmNvbT4NCj4+d3JvdGU6DQo+PiA+Pj4NCj4+ID4+Pj4gSGksIFNjb3R0 LA0KPj4gPj4+Pg0KPj4gPj4+PiBzY290dC5wcm9iYXNjb0Bub2tpYS5jb20gd3JvdGU6DQo+PiA+ Pj4+PiBIaSwNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBUaGFuayB5b3UgUGV0ZXIgJiBMZWkgZm9yIHRo ZSBtb3JlIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSB1c2UNCj4+ID4+Pj4+IGNhc2UuIFdo ZW4gSSBsb29rIGF0IHRoaXMgY2FzZSwgdGhlIHF1ZXN0aW9uIGlzOiBjYW4gUEFXUyBiZSB1c2Vk DQo+PnRvDQo+PiA+Pj4+PiBhbGxvdyBtdWx0aXBsZSBNYXN0ZXIgZGV2aWNlcyB0byBrbm93aW5n bHkgc2VsZWN0IHRoZSBzYW1lIGNoYW5uZWwNCj4+ID4+Pj4+IGZvciBvcGVyYXRpb24uIChUaGUg ZGlzY3Vzc2lvbiBvZiAid2h5IiBhbmQgImlzIGl0IGEgZ29vZCBpZGVhIg0KPj5ub3QNCj4+ID4+ Pj4+IHVuZGVydGFrZW4gaGVyZSBhcyB0aGlzIGxpa2VseSB3YW5kZXJzIG91dHNpZGUgdGhlIHNj b3BlIG9mIFBBV1MpLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IE9uZSBvZiB0aGUgcHJvcG9zZWQgc29s dXRpb25zIGlzIGNvb3JkaW5hdGlvbiBhbW9uZyBCU3MgKGV4dGVybmFsDQo+PiA+Pj4+PiB0byBQ QVdTKS4gVGhpcyBpcyBhbHJlYWR5IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDQuMyBXaWRlLUFyZWEg b3INCj4+ID4+Pj4+IFJ1cmFsIGludGVybmV0IGJyb2FkYmFuZCBhY2Nlc3M6DQo+PiA+Pj4+Pg0K Pj4gPj4+Pj4+IFNvbWUgb2YgdGhlIG1hc3RlcnMvQlNzIG1heSBiZSBkZXBsb3llZCBhbmQgb3Bl cmF0ZWQgYnkgYSBzaW5nbGUNCj4+ID4+Pj4+PiBlbnRpdHksIGkuZS4gdGhlcmUgY2FuIGJlIGNl bnRyYWxpemVkIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIHRoZXNlDQo+PiA+Pj4+Pj4gbWFzdGVycy9C U3MsLi4uDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gRnVydGhlciwgeW91IG5vdGUgdGhlIGRpZmZlcmVu Y2UgaXMgaW4gVEREOg0KPj4gPj4+Pj4NCj4+ID4+Pj4+PiBUaGUgQlMgaW4gdGhpcyBzY2VuYXJp byB1c2UgYSBUREQgcmFkaW8gVGVjaG5vbG9neQ0KPj4gPj4+Pj4NCj4+ID4+Pj4+IFdvdWxkIGl0 IGJlIGFwcHJvcHJpYXRlIGFuZCBhY2NlcHRhYmxlIHRvIFdHIG1lbWJlcnMgdG8gYWRkDQo+PiA+ Pj4+PiAidHlwaWNhbGx5IiBzdWNoIGFzOg0KPj4gPj4+Pj4NCj4+ID4+Pj4+PiBUaGUgQlMgaW4g dGhpcyBzY2VuYXJpbyB0eXBpY2FsbHkgdXNlcyBhIFRERCByYWRpbyBUZWNobm9sb2d5Li4uDQo+ PiA+Pj4+Pg0KPj4gPj4+Pj4gRG9lcyB0aGlzIGVuYWJsZSB0aGUgdXNlIGNhc2UgeW91IGFyZSBk ZXNjcmliaW5nPw0KPj4gPj4+Pg0KPj4gPj4+PiBNYXliZSB3ZSBjb3VsZCBzYXk6DQo+PiA+Pj4+ DQo+PiA+Pj4+IFRoZSBCUyBpbiB0aGlzIHNjZW5hcmlvIHR5cGljYWxseSB1c2UgYSBUREQgcmFk aW8gdGVjaG5vbG9neSBvcg0KPj5vdGhlcg0KPj4gPj4+PiBtZWFucyB0byBjb29yZGluYXRlIHVz ZSBvZiB0aGUgc2VsZWN0ZWQgc3BlY3RydW0uDQo+PiA+Pj4+DQo+PiA+Pj4+IC1QZXRlDQo+PiA+ Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBSZWdhcmRzLA0KPj4g Pj4+Pj4gU2NvdHQNCj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gT24gOS8xMy8xMSAxMjoz NyBQTSwgImV4dCBQZXRlciBNY0Nhbm4iIDxQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4NCj4+ID4+ Pj4+IHdyb3RlOg0KPj4gPj4+Pj4NCj4+ID4+Pj4+PiBIaSwNCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+ IEkndmUgYmVlbiBpbnRlcmFjdGluZyB3aXRoIFpodSBMZWkgb2ZmLWxpc3QgYWJvdXQgaGlzIHRo aXJkIHVzZQ0KPj4gPj4+Pj4+IGNhc2UsIGFuZCBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgcG9zc2li bGUgY2FuZGlkYXRlIGZvciBpbmNsdXNpb24NCj4+ID4+Pj4+PiBpbiB0aGUgZG9jdW1lbnQgaWYg aXQgd2VyZSBwcm9wZXJseSBleHBsYWluZWQuDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBHZW5lcmFs bHkgKGFzIG9wcG9zZWQgdG8gc3BlY2lmaWNhbGx5IGZvciB0aGUgTFRFIE1CTVMgY2FzZSksIHRo ZQ0KPj4gPj4+Pj4+IHByb2JsZW0gaXMgdG8gZmluZCBhIGNvbW1vbiBiaXQgb2Ygc3BlY3RydW0g dGhhdCBpcyBhdmFpbGFibGUNCj4+b3ZlciBhDQo+PiA+Pj4+Pj4gd2lkZSBhcmVhIHRoYXQgY2Fu IGJlIHVzZWQgYnkgbXVsdGlwbGUgbWFzdGVyIEJTcyB0bw0KPj5zaW11bHRhbmVvdXNseQ0KPj4g Pj4+Pj4+IGJyb2FkY2FzdCB0aGUgc2FtZSBzaWduYWwgdG8gYSBzZXQgb2YgcmVjZWl2ZXJzLiBU aGlzIGlzIHNvbWV3aGF0DQo+PiA+Pj4+Pj4gc2ltaWxhciB0byB0aGUgd2lkZS1hcmVhIHJ1cmFs IGNvdmVyYWdlIHNjZW5hcmlvIGN1cnJlbnRseQ0KPj5kZXNjcmliZWQNCj4+ID4+Pj4+PiBpbiB0 aGUgd29ya2luZyBncm91cCBkb2N1bWVudDsgaG93ZXZlciwgdGhlcmUgd291bGQgYmUgbXVsdGlw bGUNCj4+ID4+Pj4+PiBNYXN0ZXIgQlNzLCBlYWNoIG9mIHdoaWNoIHdvdWxkIGluZGVwZW5kZW50 bHkgcXVlcnkgdGhlIFdTREIgZm9yDQo+PiA+Pj4+Pj4gYXZhaWxhYmxlIHNwZWN0cnVtLiAgSG93 ZXZlciwgdGhleSBuZWVkIHRvIGNvb3JkaW5hdGUgdGhlDQo+PmFzc2lnbm1lbnQNCj4+ID4+Pj4+ PiBzbyB0aGF0IHRoZXkgYWxsIGdldCB0aGUgc2FtZSBzcGVjdHJ1bSBvdmVyIHRoZSB3aG9sZSBh cmVhLiBBcyBhbg0KPj4gPj4+Pj4+IGltcGxlbWVudGF0aW9uIGV4YW1wbGUsIHRoaXMgY291bGQg YmUgYWNoaWV2ZWQgYnkgZWFjaCBCUw0KPj5yZXBvcnRpbmcNCj4+ID4+Pj4+PiB0aGUgc2FtZSBv d25lci9vcGVyYXRvciBhbmQgdXNpbmcgYSBrZXkgb3IgaW5kZXggdmFsdWUgdG8NCj4+aW5kaWNh dGUNCj4+ID4+Pj4+PiB0aGF0IHRoZXkgd2FudGVkIHRvIGNvb3JkaW5hdGUgdGhlIGFzc2lnbm1l bnQuIEFsdGVybmF0aXZlbHksIHlvdQ0KPj4gPj4+Pj4+IG1pZ2h0IGJlIGFibGUgdG8gZWxlY3Qg b25lIEJTIGFzIHRoZSBsZWFkZXIgYW5kIGNvbGxlY3QgbG9jYXRpb24NCj4+ID4+Pj4+PiBpbmZv cm1hdGlvbiBmcm9tIGFsbCB0aGUgb3RoZXIgQlNzIGFuZCB0aGVuIGNvb3JkaW5hdGUgdGhlDQo+ PiA+Pj4+Pj4gYXNzaWdubWVudCBzaW1pbGFyIHRvIHRoZSB1c2UgY2FzZSBpbiA0LjI7IHRoZSBk aWZmZXJlbmNlIHdvdWxkDQo+PmJlDQo+PiA+Pj4+Pj4gdGhhdCB0aGUgcmVzdWx0aW5nIGFzc2ln bm1lbnQgaXMgZm9yIHNpbXVsdGFuZW91cyAobm90IFRERCkgdXNlDQo+PmJ5DQo+PiA+Pj4+Pj4g YWxsIG9mIHRoZSBCU3MgY292ZXJpbmcgdGhlIHdpZGVyIGFyZWEuDQo+PiA+Pj4+Pj4NCj4+ID4+ Pj4+PiBEb2VzIHRoaXMgc291bmQgbGlrZSBhbiBpbnRlcmVzdGluZyBhbmQgbm92ZWwgdXNlIGNh c2U/ICBJZiBzbyBJDQo+PmNhbg0KPj4gPj4+Pj4+IGRvIGEgbW9yZSBkZXRhaWxlZCB3cml0ZXVw IGFuZCBzdXBwbHkgQVNDSUkgYXJ0IGZvciB0aGUgZHJhZnQuDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+ PiAtLQ0KPj4gPj4+Pj4+IFBldGVyIEouIE1jQ2Fubg0KPj4gPj4+Pj4+IEh1YXdlaSBUZWNobm9s b2dpZXMgKFVTQSkNCj4+ID4+Pj4+PiBQZXRlci5NY0Nhbm5ASHVhd2VpLmNvbQ0KPj4gPj4+Pj4+ ICsxIDkwOCA1NDEgMzU2Mw0KPj4gPj4+Pj4+IFJtLiBDLTAxMDUsIDQwMCBDcm9zc2luZ3MgQmx2 ZC4gKDJuZCBmbG9vciksIEJyaWRnZXdhdGVyLCBOSg0KPj4gPj4+Pj4+IDA4ODA3LTI4NjMgVVNB DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID5wYXdzIG1haWxpbmcgbGlzdA0KPj4gPnBhd3NAaWV0Zi5vcmcNCj4+ID5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4NCj4NCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0 DQo+cGF3c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KDQo= From scott.probasco@nokia.com Wed Sep 14 11:21:16 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 05EEE21F8CB3 for ; Wed, 14 Sep 2011 11:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 jBa80SMUrzl0 for ; Wed, 14 Sep 2011 11:21:15 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BE5BA21F8CCD for ; Wed, 14 Sep 2011 11:21:14 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EINJ3T016785; Wed, 14 Sep 2011 21:23:20 +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); Wed, 14 Sep 2011 21:23:19 +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; Wed, 14 Sep 2011 20:23:19 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 20:23:19 +0200 From: To: , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAIAAX3oA///OEAA= Date: Wed, 14 Sep 2011 18:23:18 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A342@dfweml503-mbx.china.huawei.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.241.50.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <806E9FBCE18E434791A6EAEF34C34BCE@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 18:23:19.0592 (UTC) FILETIME=[60FCDA80:01CC730B] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 18:21:16 -0000 Hi Pete, Allowing PAWS to carry information back to the database as in 4.2 & 4.3 is just a transport. We don't have to think about what the database does with that. While FCC may not have regulations today which require this type of transport, IMHO it is premature to assume that no regulator in the world will have such need. Similarly for location-based service use case, the only issue from PAWS perspective is some message which allows a query of the database, based on master identity. In addition to the location based service use case already included in the I-D, another example is identification of a Master who is causing interference. FCC does envision something very similar, though not precisely same, to this scenario for determination of interference. Thus I believe these use cases are useful and reasonable. Regards, Scott On 9/14/11 11:22 AM, "ext Peter McCann" wrote: >Hi, Scott, > >The problem is when I see text like this in section 4.2 and 4.3: > > 7. The master/AP acknowledges to the database which of the available > WS channels it has selected for its operation. The database is > updated with the information provided by the master/AP. > >it makes me think that the database is tracking the use of spectrum >by the whitespace master devices. When it says "database is updated" >that makes me think that the database of exclusion zones is updated >in a way that will impact the results of future queries. > >There is also the location-based service use case where the database >is keeping state about the whitespace master device, namely its location: > > 3. The server queries the trusted white space database with the > master identity provided by the application in the user's > smartphone. > > 4. The trusted white space database replies to the server with the > location of the master device. > >If the database is to be truly stateless and passive with respect to >queries by whitespace devices, these kinds of statements should be >removed from the use cases. > >-Pete > > >scott.probasco@nokia.com wrote: >> Hi, >>=20 >> One of the key aspects of this protocol between device and database is >> extensibility. The charter does recognize that the contents of the >> database is defined external to PAWS. Thus hard to say that any single >> specific value or information element is beyond the scope. >>=20 >> Also the charter allows for queries and responses, there is no >> restriction that single transactions are mandated. >>=20 >> So IMHO the use cases already approved are still valid, no reasons to >> exclude pieces. >>=20 >> Regards, >> Scott >>=20 >>=20 >>=20 >> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >> wrote: >>=20 >>> Brian, >>>=20 >>> Agreed. A single transaction, to the DB and back to the TVBD, would be >>> sufficient if the protocol is to be kept simple. Coexistence amongst >>> the license-exempt devices would then be left to other processes such >>> as the one being developed by the IEEE 802.19.1. >>>=20 >>> Gerald >>>=20 >>>=20 >>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>> The problem is that this turns the transaction into multiple steps. >>>> As it is now, you send a query and get a response. >>>>=20 >>>> If the device needs to update with what it used, that's another step. >>>> Also, what happens if it changes its mind? >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>=20 >>>>> Peter, Brian, >>>>>=20 >>>>> My suggestion would be to leave this feature in. It will not cost >>>>> much to make room in the protocol for the TVBD to indicate to the >>>>> database which channel it decided to operate on and it would provide >>>>> easy extensibility to the protocol for an eventual consideration of >>>>> the coexistence amongst the license-exempt devices. >>>>>=20 >>>>> I would agree, however, that the current step of the protocol >>>>> development should be limited to protecting of the broadcast >>>>> incumbents as stated in the scope. >>>>>=20 >>>>> Gerald >>>>>=20 >>>>>=20 >>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>> So do these use cases in the accepted working group document >>>>>> need to be modified, then? >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Rosen, Brian wrote: >>>>>>> It's beyond the charter. This was discussed when we created >>>>>>> the charter, and explicitly excluded it for this initial work. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>=20 >>>>>>>> However, the location-based services use case clearly has the >>>>>>>> white space database keeping state on the secondary user, at least >>>>>>>> his location. Step 7 of the Hotspot use case has the BS >>>>>>>> registering the spectrum that it selected for its use. If the >>>>>>>> database is keeping state in this manner, it could easily >>>>>>>> calculate the exclusion zones for the secondary users as well. >>>>>>>>=20 >>>>>>>> Or did these use cases as described exceed the mandate of the >>>>>>>> charter? >>>>>>>>=20 >>>>>>>> -Pete >>>>>>>>=20 >>>>>>>> Rosen, Brian wrote: >>>>>>>>> Yes, you are mistaken. >>>>>>>>>=20 >>>>>>>>> If two queriers with the same location and input parameters query >>>>>>>>> the database, they will get the same response. Suppose two U.S. >>>>>>>>> Mode I devices at essentially the same location (within 25 >>>>>>>>> meters) query the database, and the first is told he may use TV >>>>>>>>> channels 1-5, 9-11 and 25-33. The second one will be told the >>>>>>>>> same thing. >>>>>>>>>=20 >>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>> device actually chooses to use, when it starts using it, and >>>>>>>>> when it ceases to use it. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>=20 >>>>>>>>>> Based on some of the existing use cases, it looks like the >>>>>>>>>> database is keeping state even for the secondary users. That is, >>>>>>>>>> it is acting as a de-facto registry for users of the secondary >>>>>>>>>> spectrum and will refuse to allocate the same spectrum to >>>>>>>>>> different users in overlapping geographic regions. Am I >>>> mistaken in >>>>>> this assumption? >>>>>>>>>>=20 >>>>>>>>>> -Pete >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>> I may be missing something, but it seems to me taht what you >>>>>>>>>>> are describing is not the job of the database query protocol. >>>>>>>>>>> base station coordination is an interesting problem, but is it >>>>>>>>>>> within scope for this WG? (I do not think just specifying the >>>>>>>>>>> same owner to the database will resolve the problem, and it >>>>>>>>>>> makes the database state MUCH more complex.) >>>>>>>>>>>=20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>>=20 >>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his third >>>>>>>>>>>> use case, and I think it would be a possible candidate for >>>>>>>>>>>> inclusion in the document if it were properly explained. >>>>>>>>>>>>=20 >>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), >>>>>>>>>>>> the problem is to find a common bit of spectrum that is >>>>>>>>>>>> available over a wide area that can be used by multiple master >>>>>>>>>>>> BSs to simultaneously broadcast the same signal to a set of >>>>>>>>>>>> receivers. This is somewhat similar to the wide-area rural >>>>>>>>>>>> coverage scenario currently described in the working group >>>>>>>>>>>> document; however, there would be multiple Master BSs, each of >>>>>>>>>>>> which would independently query the WSDB for available >>>>>>>>>>>> spectrum. However, they need to coordinate the assignment so >>>>>>>>>>>> that they all get the same spectrum over the whole area. As an >>>>>>>>>>>> implementation example, this could be achieved by each BS >>>>>>>>>>>> reporting the same owner/operator and using a key or index >>>>>>>>>>>> value to indicate that they wanted to coordinate the >>>>>>>>>>>> assignment. Alternatively, you might be able to elect one >> BS >>>> as the >>>>>>>>>>>> leader and collect location information from all the other BSs >>>>>>>>>>>> and then coordinate the assignment similar to the use case in >>>>>>>>>>>> 4.2; the difference would be that the resulting assignment is >>>>>>>>>>>> for simultaneous (not TDD) use by all of the BSs covering the >>>>>>>>>>>> wider area. >>>>>>>>>>>>=20 >>>>>>>>>>>> Does this sound like an interesting and novel use case? If so >>>>>>>>>>>> I can do a more detailed writeup and supply ASCII art for the >>>>>>>>>>>> draft. > From Peter.McCann@huawei.com Wed Sep 14 12:09:46 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 5EB4A21F8D22 for ; Wed, 14 Sep 2011 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3MvUhR9MVCBV for ; Wed, 14 Sep 2011 12:09:42 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id C35CF21F8D03 for ; Wed, 14 Sep 2011 12:09:41 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00KFG1BQVB@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 14:11:51 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ004BJ1BO7D@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 14:11:50 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 12:11:50 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 12:11:46 -0700 Date: Wed, 14 Sep 2011 19:11:45 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A430@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAa/KAgAAB7wD//67PgIAAVpcA//+5s4D//33c0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5.1.0.14.2.20110914133219.0287b898@imap.crc.ca> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 19:09:46 -0000 Hi, Scott, I'm not proposing that the database provide the coordination or protection for the secondary users. I am just saying that there could be some protocol, completely outside the scope of PAWS, by which the multiple devices schedule their use of the selected=20 spectrum. This seems like an obvious requirement for a master device that serves a collection of slave devices. Similarly, when all the BSs want to simulcast, there needs to be a protocol that provides synchronization. The text right now uses TDD as an example spectrum access protocol. I am just saying we should generalize and allow for other means of deciding who transmits what when. -Pete scott.probasco@nokia.com wrote: > Hi All, >=20 > My comment was about the wording of the Wide-Area or Rural internet > broadband access use case: >=20 >> Further, you note the difference is in TDD: >>> The BS in this scenario use a TDD radio Technology >> Would it be appropriate and acceptable to WG members to add "typically" >> such as: >>> The BS in this scenario typically uses a TDD radio Technology... >> Does this enable the use case you are describing? > Maybe we could say: > The BS in this scenario typically use a TDD radio technology or other > means to coordinate use of the selected spectrum. >=20 >=20 > Specifically I don't see how TDD coordinates use of the spectrum; it > simply is one method of duplexing which allows use of single radio > frequency for bi-directional communication. The white space paradigm > only affords protection to the licensed primary user, no protection to > any licensed-exempt secondary user, i.e. use of the spectrum is not > coordinated (other than the database indicating which channels are > available for secondary use). Thus I suggest to strike "or other means > to coordinate use of the selected spectrum" from Pete's proposal. >=20 > Regarding the scenarios of coordination, PAWS is a protocol to > transport information. It should support Regulatory requirements > globally, including those from the FCC but not limited to the FCC > requirements. I believe this also means we need to be open-minded and > forward-thinking since other Regulatory groups are actively reviewing > white space paradigms, and their requirements are yet to be seen. >=20 > Regards, > Scott >=20 >=20 >=20 > On 9/14/11 12:32 PM, "ext Gerald Chouinard" > wrote: >=20 >>=20 >> I agree with Raj. >>=20 >> Gerald >>=20 >> At 17:22 14-09-11 +0000, Basavaraj.Patil@nokia.com wrote: >>=20 >>> Pete, >>>=20 >>> If multiple BS' co-ordinate among themselves (master-slave >>> relationship) and only the master BS sends the query, then that >>> use-case is beyond the scope of the PAWS charter. The protocol that is >>> being specified is the one between this master- BS (or master WS >>> device) and the database. If a network has multiple BS' and there >>> exists co-ordination between them, with only one of the BS' having the >>> authority to query the database that=B9s fine. Because it is invisible >>> to the protocol that we are defining in PAWS. >>>=20 >>> -Raj >>>=20 >>> On 9/14/11 12:13 PM, "ext Peter McCann" >>> wrote: >>>=20 >>>> Hi, Gerald, >>>>=20 >>>> I think what Scott is asking about is coordination in access to >>>> the channel after it has been cleared for use by the WSDB. >>>>=20 >>>> It seems like you are asking about how to coordinate the >>>> assignment of the channel among all the different BS. I agree >>>> that one BS could act as the "master", collecting information from >>>> the peer BSs and presenting it all to the WSDB in a query for a vacant= channel. >>>> Isn't this the same as the existing WRAN use case in Section 4.3? >>>> Or is there some difference due to the fact that all the BSs are >>>> "Master" devices? >>>>=20 >>>> -Pete >>>>=20 >>>> Gerald Chouinard wrote: >>>>> Scott, Peter, >>>>>=20 >>>>> One way to provide such a coordination would be to nominate one BS >>>>> in an area as the master BS that would query the DB for itself and >>>>> on behalf of the other 'slave' BSs. Coordination could then be >>>>> done locally by the master BS by sending a filtered version of the >>>>> available channels list as received from the DB to the appropriate >>>>> slave BS. >>>>>=20 >>>>> Unfortunately,it is still not clear whether the regulations in the >>>>> various countries will allow such 'proxying' of TVBD's by other >>>>> TVBD's and that this will not pose security problems. If it is >>>>> allowed everywhere and appropriate security can be achieved, then >>>>> such coordination could be transparent to the DB since it would take >>>>> place at the master BS without the DB having to know about it. It >>>>> would only know that a BS is asking for the channels availability on >>>>> behalf of other BSs. >>>>>=20 >>>>> Gerald >>>>>=20 >>>>>=20 >>>>> At 15:40 14-09-11 +0000, scott.probasco@nokia.com wrote: >>>>>> Hi Pete, >>>>>>=20 >>>>>> There is no coordination aspect to TDD is there? I added TDD >>>>>> initially to indicate that a single channel is used for >>>>>> operation, contrasted to the 2 channel requirement for FDD. >>>>>>=20 >>>>>> I believe the use case under discussion is using the channel for >>>>>> full DL broadcast. It's not so much as coordination, just 100% DL. >>>>>> Right? >>>>>>=20 >>>>>> Would help me if you could clarify what spectrum coordination >>>>>> is happening in this case. >>>>>>=20 >>>>>> Regards, >>>>>> Scott >>>>>>=20 >>>>>>=20 >>>>>> On 9/14/11 8:20 AM, "ext Peter McCann" >>>>>> wrote: >>>>>>=20 >>>>>>> Hi, Scott, >>>>>>>=20 >>>>>>> scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Thank you Peter & Lei for the more detailed description of the >>>>>>>> use case. When I look at this case, the question is: can PAWS be >>>>>>>> used to allow multiple Master devices to knowingly select the >>>>>>>> same channel for operation. (The discussion of "why" and "is it a > good idea" >>> not >>>>>>>> undertaken here as this likely wanders outside the scope of PAWS). >>>>>>>>=20 >>>>>>>> One of the proposed solutions is coordination among BSs >>>>>>>> (external to PAWS). This is already described in section 4.3 >>>>>>>> Wide-Area or Rural internet broadband access: >>>>>>>>=20 >>>>>>>>> Some of the masters/BSs may be deployed and operated by a >>>>>>>>> single entity, i.e. there can be centralized coordination >>>>>>>>> between these masters/BSs,... >>>>>>>>=20 >>>>>>>> Further, you note the difference is in TDD: >>>>>>>>=20 >>>>>>>>> The BS in this scenario use a TDD radio Technology >>>>>>>>=20 >>>>>>>> Would it be appropriate and acceptable to WG members to add >>>>>>>> "typically" such as: >>>>>>>>=20 >>>>>>>>> The BS in this scenario typically uses a TDD radio > Technology... >>>>>>>>=20 >>>>>>>> Does this enable the use case you are describing? >>>>>>>=20 >>>>>>> Maybe we could say: >>>>>>>=20 >>>>>>> The BS in this scenario typically use a TDD radio technology or >>>>>>> other means to coordinate use of the selected spectrum. >>>>>>>=20 >>>>>>> -Pete >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Scott >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 9/13/11 12:37 PM, "ext Peter McCann" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> I've been interacting with Zhu Lei off-list about his third >>>>>>>>> use case, and I think it would be a possible candidate for >>>>>>>>> inclusion in the document if it were properly explained. >>>>>>>>>=20 >>>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), >>>>>>>>> the problem is to find a common bit of spectrum that is >>>>>>>>> available over a wide area that can be used by multiple master >>>>>>>>> BSs to simultaneously broadcast the same signal to a set of >>>>>>>>> receivers. This is somewhat similar to the wide-area rural >>>>>>>>> coverage scenario currently described in the working group >>>>>>>>> document; however, there would be multiple Master BSs, each of >>>>>>>>> which would independently query the WSDB for available spectrum. >>>>>>>>> However, they need to coordinate the assignment so that they >>>>>>>>> all get the same spectrum over the whole area. As an >>>>>>>>> implementation example, this could be achieved by each BS >>>>>>>>> reporting the same owner/operator and using a key or index value >>>>>>>>> to indicate that they wanted to coordinate the assignment. >>>>>>>>> Alternatively, you might be able to elect one BS as the leader >>>>>>>>> and collect location information from all the other BSs and then >>>>>>>>> coordinate the assignment similar to the use case in 4.2; the >>>>>>>>> difference would be that the resulting assignment is for >>>>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >>>>>>>>> area. >>>>>>>>>=20 >>>>>>>>> Does this sound like an interesting and novel use case? If so I >>>>>>>>> can do a more detailed writeup and supply ASCII art for the >>>>>>>>> draft. >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Peter J. McCann >>>>>>>>> Huawei Technologies (USA) >>>>>>>>> Peter.McCann@Huawei.com >>>>>>>>> +1 908 541 3563 >>>>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>>>>> 08807-2863 USA From paul@marvell.com Wed Sep 14 12:12:49 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 762C621F8CA2 for ; Wed, 14 Sep 2011 12:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 WRi56hLVXHCn for ; Wed, 14 Sep 2011 12:12:48 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id E718D21F8D6E for ; Wed, 14 Sep 2011 12:12:44 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTnD9ILo6uI0Pjt46P2LUnZccZyPeL9ep@postini.com; Wed, 14 Sep 2011 12:14:58 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 14 Sep 2011 12:11:16 -0700 From: Paul Lambert To: "Rosen, Brian" , Gerald Chouinard Date: Wed, 14 Sep 2011 12:11:20 -0700 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: Acxy7mO/gYvq83npSGCdhffWpONeTAAI0ryQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141C15B711@SC-VEXCH2.marvell.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE715969CF9@dfweml503-mbx.china.huawei.com> <4E701599.7010804@joelhalpern.com> <5963DDF1F751474D8DEEFDCDBEE43AE715969FF8@dfweml503-mbx.china.huawei.com> <46D3FA12-C69D-4E7E-868D-FBCC386AF38E@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71596A028@dfweml503-mbx.china.huawei.com> <5.1.0.14.2.20110914103336.02b6f128@imap.crc.ca> <88B20E31-8FFC-47F6-8272-C8D4000EB942@neustar.biz> In-Reply-To: <88B20E31-8FFC-47F6-8272-C8D4000EB942@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" , Peter McCann Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 19:12:49 -0000 Tracking changes in a devices usage of spectrum is a very different require= ment than giving authority to use specific spectrum. The devices will change bands and there is no requirement to have the datab= ase know every aspect of a device operation (current band, modulation, powe= r etc.). Coordination is a very different function that 'authorization' They happen = to use similar data items - but we should not overload the protocol. This = coexistence would be an intereting task group of it's own. Paul -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, September 14, 2011 7:56 AM To: Gerald Chouinard Cc: paws@ietf.org; Peter McCann Subject: Re: [paws] Possible new use case: simulcasting The problem is that this turns the transaction into multiple steps. As it = is now, you send a query and get a response. =20 If the device needs to update with what it used, that's another step. Also= , what happens if it changes its mind? Brian On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: > Peter, Brian, >=20 > My suggestion would be to leave this feature in. It will not cost much t= o=20 > make room in the protocol for the TVBD to indicate to the database which= =20 > channel it decided to operate on and it would provide easy extensibility = to=20 > the protocol for an eventual consideration of the coexistence amongst the= =20 > license-exempt devices. >=20 > I would agree, however, that the current step of the protocol development= =20 > should be limited to protecting of the broadcast incumbents as stated in= =20 > the scope. >=20 > Gerald >=20 >=20 > At 13:26 14-09-11 +0000, Peter McCann wrote: >> So do these use cases in the accepted working group document >> need to be modified, then? >>=20 >> -Pete >>=20 >> Rosen, Brian wrote: >>> It's beyond the charter. This was discussed when we created the >>> charter, and explicitly excluded it for this initial work. >>>=20 >>> Brian >>>=20 >>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>=20 >>>> However, the location-based services use case clearly has the white >>>> space database keeping state on the secondary user, at least his >>>> location. Step 7 of the Hotspot use case has the BS registering the >>>> spectrum that it selected for its use. >>>> If the database is keeping state in this manner, it could easily >>>> calculate the exclusion zones for the secondary users as well. >>>>=20 >>>> Or did these use cases as described exceed the mandate of the charter? >>>>=20 >>>> -Pete >>>>=20 >>>> Rosen, Brian wrote: >>>>> Yes, you are mistaken. >>>>>=20 >>>>> If two queriers with the same location and input parameters query the >>>>> database, they will get the same response. Suppose two U.S. Mode I >>>>> devices at essentially the same location (within 25 meters) query the >>>>> database, and the first is told he may use TV channels 1-5, 9-11 and >>>>> 25-33. The second one will be told the same thing. >>>>>=20 >>>>> The database knows query patterns, but does not track use. >>>>> Specifically, it doesn't know what part of the spectrum the device >>>>> actually chooses to use, when it starts using it, and when it >>>>> ceases to use it. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>=20 >>>>>> Based on some of the existing use cases, it looks like the >>>>>> database is keeping state even for the secondary users. That is, >>>>>> it is acting as a de-facto registry for users of the secondary >>>>>> spectrum and will refuse to allocate the same spectrum to >>>>>> different users in overlapping geographic regions. Am I mistaken in= =20 >> this assumption? >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>>=20 >>>>>> Joel M. Halpern wrote: >>>>>>> I may be missing something, but it seems to me taht what you are >>>>>>> describing is not the job of the database query protocol. base >>>>>>> station coordination is an interesting problem, but is it within >>>>>>> scope for this WG? (I do not think just specifying the same owner >>>>>>> to the database will resolve the problem, and it makes the database >>>>>>> state MUCH more complex.) >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I've been interacting with Zhu Lei off-list about his third use >>>>>>>> case, and I think it would be a possible candidate for inclusion >>>>>>>> in the document if it were properly explained. >>>>>>>>=20 >>>>>>>> Generally (as opposed to specifically for the LTE MBMS case), the >>>>>>>> problem is to find a common bit of spectrum that is available over >>>>>>>> a wide area that can be used by multiple master BSs to >>>>>>>> simultaneously broadcast the same signal to a set of receivers. >>>>>>>> This is somewhat similar to the wide-area rural coverage scenario >>>>>>>> currently described in the working group document; however, there >>>>>>>> would be multiple Master BSs, each of which would independently >>>>>>>> query the WSDB for available spectrum. However, they need to >>>>>>>> coordinate the assignment so that they all get the same spectrum >>>>>>>> over the whole area. As an implementation example, this could be >>>>>>>> achieved by each BS reporting the same owner/operator and using a >>>>>>>> key or index value to indicate that they wanted to coordinate the >>>>>>>> assignment. Alternatively, you might be able to elect one BS as th= e >>>>>>>> leader and collect location information from all the other BSs and >>>>>>>> then coordinate the assignment similar to the use case in 4.2; the >>>>>>>> difference would be that the resulting assignment is for >>>>>>>> simultaneous (not TDD) use by all of the BSs covering the wider >>>>>>>> area. >>>>>>>>=20 >>>>>>>> Does this sound like an interesting and novel use case? If so I >>>>>>>> can do a more detailed writeup and supply ASCII art for the draft. >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Peter J. McCann >>>>>>>> Huawei Technologies (USA) >>>>>>>> Peter.McCann@Huawei.com >>>>>>>> +1 908 541 3563 >>>>>>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ >>>>>>>> 08807-2863 USA >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Sep 14 12:22:33 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 7941621F8B78 for ; Wed, 14 Sep 2011 12:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3kykIxbaP1uv for ; Wed, 14 Sep 2011 12:22:30 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id EF48221F8CFB for ; Wed, 14 Sep 2011 12:22:29 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ0077H1H7XE@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 14:15:07 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRJ00ADR11KBE@usaga02-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 14:05:44 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 12:05:39 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 12:05:42 -0700 Date: Wed, 14 Sep 2011 19:05:41 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A423@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQD//59BXoAAee4AgAAFyYCAAAalAIAAavvg///CkACAAGoRMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A342@dfweml503-mbx.china.huawei.com> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 19:22:34 -0000 Hi, Scott, The text says "the database is updated." That wording is at least confusing. It also says "the database replies with the location of the master device". Both of these imply that some state on a per-master basis is being kept in the database. We need to get clarity within the working group whether the database can keep state about the devices that query it or whether it is designed to be a completely passive repository of information. -Pete scott.probasco@nokia.com wrote: > Hi Pete, > > Allowing PAWS to carry information back to the database as in 4.2 & > 4.3 is just a transport. We don't have to think about what the > database does with that. While FCC may not have regulations today > which require this type of transport, IMHO it is premature to assume > that no regulator in the world will have such need. > > Similarly for location-based service use case, the only issue from > PAWS perspective is some message which allows a query of the database, > based on master identity. In addition to the location based service > use case already included in the I-D, another example is > identification of a Master who is causing interference. FCC does > envision something very similar, though not precisely same, to this > scenario for determination of interference. > > Thus I believe these use cases are useful and reasonable. > > Regards, > Scott > > > > On 9/14/11 11:22 AM, "ext Peter McCann" wrote: > >> Hi, Scott, >> >> The problem is when I see text like this in section 4.2 and 4.3: >> >> 7. The master/AP acknowledges to the database which of the > available >> WS channels it has selected for its operation. The database is >> updated with the information provided by the master/AP. >> it makes me think that the database is tracking the use of spectrum >> by the whitespace master devices. When it says "database is updated" >> that makes me think that the database of exclusion zones is updated >> in a way that will impact the results of future queries. >> >> There is also the location-based service use case where the database is >> keeping state about the whitespace master device, namely its location: >> >> 3. The server queries the trusted white space database with the >> master identity provided by the application in the user's >> smartphone. >> 4. The trusted white space database replies to the server with the >> location of the master device. >> If the database is to be truly stateless and passive with respect to >> queries by whitespace devices, these kinds of statements should be >> removed from the use cases. >> >> -Pete >> >> >> scott.probasco@nokia.com wrote: >>> Hi, >>> >>> One of the key aspects of this protocol between device and database is >>> extensibility. The charter does recognize that the contents of the >>> database is defined external to PAWS. Thus hard to say that any single >>> specific value or information element is beyond the scope. >>> >>> Also the charter allows for queries and responses, there is no >>> restriction that single transactions are mandated. >>> >>> So IMHO the use cases already approved are still valid, no reasons to >>> exclude pieces. >>> >>> Regards, >>> Scott >>> >>> >>> >>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>> wrote: >>> >>>> Brian, >>>> >>>> Agreed. A single transaction, to the DB and back to the TVBD, would >>>> be sufficient if the protocol is to be kept simple. Coexistence >>>> amongst the license-exempt devices would then be left to other >>>> processes such as the one being developed by the IEEE 802.19.1. >>>> >>>> Gerald >>>> >>>> >>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>> The problem is that this turns the transaction into multiple steps. >>>>> As it is now, you send a query and get a response. >>>>> >>>>> If the device needs to update with what it used, that's another >>>>> step. Also, what happens if it changes its mind? >>>>> >>>>> Brian >>>>> >>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>> >>>>>> Peter, Brian, >>>>>> >>>>>> My suggestion would be to leave this feature in. It will not cost >>>>>> much to make room in the protocol for the TVBD to indicate to the >>>>>> database which channel it decided to operate on and it would >>>>>> provide easy extensibility to the protocol for an eventual >>>>>> consideration of the coexistence amongst the license-exempt devices. >>>>>> >>>>>> I would agree, however, that the current step of the protocol >>>>>> development should be limited to protecting of the broadcast >>>>>> incumbents as stated in the scope. >>>>>> >>>>>> Gerald >>>>>> >>>>>> >>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>> So do these use cases in the accepted working group document need >>>>>>> to be modified, then? >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> Rosen, Brian wrote: >>>>>>>> It's beyond the charter. This was discussed when we created the >>>>>>>> charter, and explicitly excluded it for this initial work. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>> >>>>>>>>> However, the location-based services use case clearly has the >>>>>>>>> white space database keeping state on the secondary user, at >>>>>>>>> least his location. Step 7 of the Hotspot use case has the >>>>>>>>> BS registering the spectrum that it selected for its use. If >>>>>>>>> the database is keeping state in this manner, it could easily >>>>>>>>> calculate the exclusion zones for the secondary users as well. >>>>>>>>> >>>>>>>>> Or did these use cases as described exceed the mandate of the >>>>>>>>> charter? >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>> Rosen, Brian wrote: >>>>>>>>>> Yes, you are mistaken. >>>>>>>>>> >>>>>>>>>> If two queriers with the same location and input parameters >>>>>>>>>> query the database, they will get the same response. Suppose >>>>>>>>>> two U.S. Mode I devices at essentially the same location >>>>>>>>>> (within 25 meters) query the database, and the first is told he >>>>>>>>>> may use TV channels 1-5, 9-11 and 25-33. The second one will >>>>>>>>>> be told the same thing. >>>>>>>>>> >>>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>>> device actually chooses to use, when it starts using it, and >>>>>>>>>> when it ceases to use it. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>> >>>>>>>>>>> Based on some of the existing use cases, it looks like the >>>>>>>>>>> database is keeping state even for the secondary users. >>>>>>>>>>> That is, it is acting as a de-facto registry for users of >>>>>>>>>>> the secondary spectrum and will refuse to allocate the same >>>>>>>>>>> spectrum to different users in overlapping geographic >>>>>>>>>>> regions. Am I >>>>> mistaken in >>>>>>> this assumption? >>>>>>>>>>> >>>>>>>>>>> -Pete >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>> I may be missing something, but it seems to me taht what you >>>>>>>>>>>> are describing is not the job of the database query protocol. >>>>>>>>>>>> base station coordination is an interesting problem, but is >>>>>>>>>>>> it within scope for this WG? (I do not think just specifying >>>>>>>>>>>> the same owner to the database will resolve the problem, and >>>>>>>>>>>> it makes the database state MUCH more complex.) >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his third >>>>>>>>>>>>> use case, and I think it would be a possible candidate for >>>>>>>>>>>>> inclusion in the document if it were properly explained. >>>>>>>>>>>>> >>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>> case), the problem is to find a common bit of spectrum that >>>>>>>>>>>>> is available over a wide area that can be used by multiple >>>>>>>>>>>>> master BSs to simultaneously broadcast the same signal to a >>>>>>>>>>>>> set of receivers. This is somewhat similar to the wide- area >>>>>>>>>>>>> rural coverage scenario currently described in the working >>>>>>>>>>>>> group document; however, there would be multiple Master BSs, >>>>>>>>>>>>> each of which would independently query the WSDB for >>>>>>>>>>>>> available spectrum. However, they need to coordinate the >>>>>>>>>>>>> assignment so that they all get the same spectrum over the >>>>>>>>>>>>> whole area. As an implementation example, this could be >>>>>>>>>>>>> achieved by each BS reporting the same owner/operator and >>>>>>>>>>>>> using a key or index value to indicate that they wanted to >>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be able >>>>>>>>>>>>> to elect one >>> BS >>>>> as the >>>>>>>>>>>>> leader and collect location information from all the >>>>>>>>>>>>> other BSs and then coordinate the assignment similar to >>>>>>>>>>>>> the use case in 4.2; the difference would be that the >>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use by >>>>>>>>>>>>> all of the BSs covering the wider area. >>>>>>>>>>>>> >>>>>>>>>>>>> Does this sound like an interesting and novel use case? >>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >>>>>>>>>>>>> art for the draft. From Basavaraj.Patil@nokia.com Wed Sep 14 12:50: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 90B1B21F86DD for ; Wed, 14 Sep 2011 12:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 ligEIcnca3GM for ; Wed, 14 Sep 2011 12:50:03 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2AD21F86F6 for ; Wed, 14 Sep 2011 12:50:03 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EJpQSo008176; Wed, 14 Sep 2011 22:52:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 22:51:48 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 21:51:48 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 21:51:47 +0200 From: To: , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAIAAX3oA///OEACAAF+sgP//uSyA Date: Wed, 14 Sep 2011 19:51:46 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A423@dfweml503-mbx.china.huawei.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: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D09A91EFA380F45A97E353DAE17F09E@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 19:51:48.0673 (UTC) FILETIME=[BD725310:01CC7317] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 19:50:04 -0000 Pete, IMO we don't need to be concerned about whether the database is keeping state. Its upto the database. I agree that the text should not say anything about what the database does if the Master WS device informs the database which of the available channels were selected for use/operation. There is no reason for the WS device to not send an acknowledgement back to the database indicating which channels (from the list) are being used. What the database does with this information is outside the scope of the protocol itself. -Raj=20 On 9/14/11 2:05 PM, "ext Peter McCann" wrote: >Hi, Scott, > >The text says "the database is updated." That wording is at least >confusing. It also says "the database replies with the location of >the master device". Both of these imply that some state on a per-master >basis is being kept in the database. > >We need to get clarity within the working group whether the database >can keep state about the devices that query it or whether it is designed >to be a completely passive repository of information. > >-Pete > > >scott.probasco@nokia.com wrote: >> Hi Pete, >>=20 >> Allowing PAWS to carry information back to the database as in 4.2 & >> 4.3 is just a transport. We don't have to think about what the >> database does with that. While FCC may not have regulations today >> which require this type of transport, IMHO it is premature to assume >> that no regulator in the world will have such need. >>=20 >> Similarly for location-based service use case, the only issue from >> PAWS perspective is some message which allows a query of the database, >> based on master identity. In addition to the location based service >> use case already included in the I-D, another example is >> identification of a Master who is causing interference. FCC does >> envision something very similar, though not precisely same, to this >> scenario for determination of interference. >>=20 >> Thus I believe these use cases are useful and reasonable. >>=20 >> Regards, >> Scott >>=20 >>=20 >>=20 >> On 9/14/11 11:22 AM, "ext Peter McCann" wrote: >>=20 >>> Hi, Scott, >>>=20 >>> The problem is when I see text like this in section 4.2 and 4.3: >>>=20 >>> 7. The master/AP acknowledges to the database which of the >> available >>> WS channels it has selected for its operation. The database is >>> updated with the information provided by the master/AP. >>> it makes me think that the database is tracking the use of spectrum >>> by the whitespace master devices. When it says "database is updated" >>> that makes me think that the database of exclusion zones is updated >>> in a way that will impact the results of future queries. >>>=20 >>> There is also the location-based service use case where the database is >>> keeping state about the whitespace master device, namely its location: >>>=20 >>> 3. The server queries the trusted white space database with the >>> master identity provided by the application in the user's >>> smartphone. >>> 4. The trusted white space database replies to the server with the >>> location of the master device. >>> If the database is to be truly stateless and passive with respect to >>> queries by whitespace devices, these kinds of statements should be >>> removed from the use cases. >>>=20 >>> -Pete >>>=20 >>>=20 >>> scott.probasco@nokia.com wrote: >>>> Hi, >>>>=20 >>>> One of the key aspects of this protocol between device and database is >>>> extensibility. The charter does recognize that the contents of the >>>> database is defined external to PAWS. Thus hard to say that any single >>>> specific value or information element is beyond the scope. >>>>=20 >>>> Also the charter allows for queries and responses, there is no >>>> restriction that single transactions are mandated. >>>>=20 >>>> So IMHO the use cases already approved are still valid, no reasons to >>>> exclude pieces. >>>>=20 >>>> Regards, >>>> Scott >>>>=20 >>>>=20 >>>>=20 >>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>>> wrote: >>>>=20 >>>>> Brian, >>>>>=20 >>>>> Agreed. A single transaction, to the DB and back to the TVBD, would >>>>> be sufficient if the protocol is to be kept simple. Coexistence >>>>> amongst the license-exempt devices would then be left to other >>>>> processes such as the one being developed by the IEEE 802.19.1. >>>>>=20 >>>>> Gerald >>>>>=20 >>>>>=20 >>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>>> The problem is that this turns the transaction into multiple steps. >>>>>> As it is now, you send a query and get a response. >>>>>>=20 >>>>>> If the device needs to update with what it used, that's another >>>>>> step. Also, what happens if it changes its mind? >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>>>=20 >>>>>>> Peter, Brian, >>>>>>>=20 >>>>>>> My suggestion would be to leave this feature in. It will not cost >>>>>>> much to make room in the protocol for the TVBD to indicate to the >>>>>>> database which channel it decided to operate on and it would >>>>>>> provide easy extensibility to the protocol for an eventual >>>>>>> consideration of the coexistence amongst the license-exempt >>>>>>>devices. >>>>>>>=20 >>>>>>> I would agree, however, that the current step of the protocol >>>>>>> development should be limited to protecting of the broadcast >>>>>>> incumbents as stated in the scope. >>>>>>>=20 >>>>>>> Gerald >>>>>>>=20 >>>>>>>=20 >>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>>> So do these use cases in the accepted working group document need >>>>>>>> to be modified, then? >>>>>>>>=20 >>>>>>>> -Pete >>>>>>>>=20 >>>>>>>> Rosen, Brian wrote: >>>>>>>>> It's beyond the charter. This was discussed when we created the >>>>>>>>> charter, and explicitly excluded it for this initial work. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>>>=20 >>>>>>>>>> However, the location-based services use case clearly has the >>>>>>>>>> white space database keeping state on the secondary user, at >>>>>>>>>> least his location. Step 7 of the Hotspot use case has the >>>>>>>>>> BS registering the spectrum that it selected for its use. If >>>>>>>>>> the database is keeping state in this manner, it could easily >>>>>>>>>> calculate the exclusion zones for the secondary users as well. >>>>>>>>>>=20 >>>>>>>>>> Or did these use cases as described exceed the mandate of the >>>>>>>>>> charter? >>>>>>>>>>=20 >>>>>>>>>> -Pete >>>>>>>>>>=20 >>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>> Yes, you are mistaken. >>>>>>>>>>>=20 >>>>>>>>>>> If two queriers with the same location and input parameters >>>>>>>>>>> query the database, they will get the same response. Suppose >>>>>>>>>>> two U.S. Mode I devices at essentially the same location >>>>>>>>>>> (within 25 meters) query the database, and the first is told he >>>>>>>>>>> may use TV channels 1-5, 9-11 and 25-33. The second one will >>>>>>>>>>> be told the same thing. >>>>>>>>>>>=20 >>>>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>>>> device actually chooses to use, when it starts using it, and >>>>>>>>>>> when it ceases to use it. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Based on some of the existing use cases, it looks like the >>>>>>>>>>>> database is keeping state even for the secondary users. >>>>>>>>>>>> That is, it is acting as a de-facto registry for users of >>>>>>>>>>>> the secondary spectrum and will refuse to allocate the same >>>>>>>>>>>> spectrum to different users in overlapping geographic >>>>>>>>>>>> regions. Am I >>>>>> mistaken in >>>>>>>> this assumption? >>>>>>>>>>>>=20 >>>>>>>>>>>> -Pete >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>>> I may be missing something, but it seems to me taht what you >>>>>>>>>>>>> are describing is not the job of the database query protocol. >>>>>>>>>>>>> base station coordination is an interesting problem, but is >>>>>>>>>>>>> it within scope for this WG? (I do not think just specifying >>>>>>>>>>>>> the same owner to the database will resolve the problem, and >>>>>>>>>>>>> it makes the database state MUCH more complex.) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his third >>>>>>>>>>>>>> use case, and I think it would be a possible candidate for >>>>>>>>>>>>>> inclusion in the document if it were properly explained. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum that >>>>>>>>>>>>>> is available over a wide area that can be used by multiple >>>>>>>>>>>>>> master BSs to simultaneously broadcast the same signal to a >>>>>>>>>>>>>> set of receivers. This is somewhat similar to the wide- area >>>>>>>>>>>>>> rural coverage scenario currently described in the working >>>>>>>>>>>>>> group document; however, there would be multiple Master BSs, >>>>>>>>>>>>>> each of which would independently query the WSDB for >>>>>>>>>>>>>> available spectrum. However, they need to coordinate the >>>>>>>>>>>>>> assignment so that they all get the same spectrum over the >>>>>>>>>>>>>> whole area. As an implementation example, this could be >>>>>>>>>>>>>> achieved by each BS reporting the same owner/operator and >>>>>>>>>>>>>> using a key or index value to indicate that they wanted to >>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be able >>>>>>>>>>>>>> to elect one >>>> BS >>>>>> as the >>>>>>>>>>>>>> leader and collect location information from all the >>>>>>>>>>>>>> other BSs and then coordinate the assignment similar to >>>>>>>>>>>>>> the use case in 4.2; the difference would be that the >>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use by >>>>>>>>>>>>>> all of the BSs covering the wider area. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Does this sound like an interesting and novel use case? >>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >>>>>>>>>>>>>> art for the draft. > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Sep 14 13:01:39 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 3565521F8C17 for ; Wed, 14 Sep 2011 13:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 zDgO7b4124nM for ; Wed, 14 Sep 2011 13:01:38 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 255C821F8C0C for ; Wed, 14 Sep 2011 13:01:37 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00K883QAVB@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:03:46 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00CIW3Q93X@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:03:46 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 13:03:46 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 13:03:33 -0700 Date: Wed, 14 Sep 2011 20:03:31 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A45C@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQD//59BXoAAee4AgAAFyYCAAAalAIAAavvg///CkACAAGoRMP//rqcAAA5bRRA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A423@dfweml503-mbx.china.huawei.com> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:01:39 -0000 "no reason to not send" does not equal "reason to send." -Pete Basavaraj.Patil@nokia.com wrote: > > Pete, > > IMO we don't need to be concerned about whether the database is keeping > state. Its upto the database. I agree that the text should not say > anything about what the database does if the Master WS device informs > the database which of the available channels were selected for > use/operation. > > There is no reason for the WS device to not send an acknowledgement > back to the database indicating which channels (from the list) are > being used. > > What the database does with this information is outside the scope of > the protocol itself. > > -Raj > > On 9/14/11 2:05 PM, "ext Peter McCann" wrote: > >> Hi, Scott, >> >> The text says "the database is updated." That wording is at least >> confusing. It also says "the database replies with the location of the >> master device". Both of these imply that some state on a per-master >> basis is being kept in the database. >> >> We need to get clarity within the working group whether the database >> can keep state about the devices that query it or whether it is >> designed to be a completely passive repository of information. >> >> -Pete >> >> >> scott.probasco@nokia.com wrote: >>> Hi Pete, >>> >>> Allowing PAWS to carry information back to the database as in 4.2 & >>> 4.3 is just a transport. We don't have to think about what the >>> database does with that. While FCC may not have regulations today >>> which require this type of transport, IMHO it is premature to >>> assume that no regulator in the world will have such need. >>> >>> Similarly for location-based service use case, the only issue from >>> PAWS perspective is some message which allows a query of the database, >>> based on master identity. In addition to the location based service >>> use case already included in the I-D, another example is >>> identification of a Master who is causing interference. FCC does >>> envision something very similar, though not precisely same, to this >>> scenario for determination of interference. >>> >>> Thus I believe these use cases are useful and reasonable. >>> >>> Regards, >>> Scott >>> >>> >>> >>> On 9/14/11 11:22 AM, "ext Peter McCann" >>> wrote: >>> >>>> Hi, Scott, >>>> >>>> The problem is when I see text like this in section 4.2 and 4.3: >>>> >>>> 7. The master/AP acknowledges to the database which of the >>> available >>>> WS channels it has selected for its operation. The database is >>>> updated with the information provided by the master/AP. >>>> it makes me think that the database is tracking the use of spectrum >>>> by the whitespace master devices. When it says "database is updated" >>>> that makes me think that the database of exclusion zones is updated >>>> in a way that will impact the results of future queries. >>>> >>>> There is also the location-based service use case where the database >>>> is keeping state about the whitespace master device, namely its >>>> location: >>>> >>>> 3. The server queries the trusted white space database with the >>>> master identity provided by the application in the user's >>>> smartphone. >>>> 4. The trusted white space database replies to the server with > the >>>> location of the master device. >>>> If the database is to be truly stateless and passive with respect to >>>> queries by whitespace devices, these kinds of statements should be >>>> removed from the use cases. >>>> >>>> -Pete >>>> >>>> >>>> scott.probasco@nokia.com wrote: >>>>> Hi, >>>>> >>>>> One of the key aspects of this protocol between device and database >>>>> is extensibility. The charter does recognize that the contents of >>>>> the database is defined external to PAWS. Thus hard to say that any >>>>> single specific value or information element is beyond the scope. >>>>> >>>>> Also the charter allows for queries and responses, there is no >>>>> restriction that single transactions are mandated. >>>>> >>>>> So IMHO the use cases already approved are still valid, no >>>>> reasons to exclude pieces. >>>>> >>>>> Regards, >>>>> Scott >>>>> >>>>> >>>>> >>>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>>>> >>>>> wrote: >>>>> >>>>>> Brian, >>>>>> >>>>>> Agreed. A single transaction, to the DB and back to the TVBD, >>>>>> would be sufficient if the protocol is to be kept simple. >>>>>> Coexistence amongst the license-exempt devices would then be left >>>>>> to other processes such as the one being developed by the IEEE >>>>>> 802.19.1. >>>>>> >>>>>> Gerald >>>>>> >>>>>> >>>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>>>> The problem is that this turns the transaction into multiple >>>>>>> steps. As it is now, you send a query and get a response. >>>>>>> >>>>>>> If the device needs to update with what it used, that's another >>>>>>> step. Also, what happens if it changes its mind? >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>>>> >>>>>>>> Peter, Brian, >>>>>>>> >>>>>>>> My suggestion would be to leave this feature in. It will not >>>>>>>> cost much to make room in the protocol for the TVBD to indicate >>>>>>>> to the database which channel it decided to operate on and it >>>>>>>> would provide easy extensibility to the protocol for an eventual >>>>>>>> consideration of the coexistence amongst the license-exempt >>>>>>>> devices. >>>>>>>> >>>>>>>> I would agree, however, that the current step of the protocol >>>>>>>> development should be limited to protecting of the broadcast >>>>>>>> incumbents as stated in the scope. >>>>>>>> >>>>>>>> Gerald >>>>>>>> >>>>>>>> >>>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>>>> So do these use cases in the accepted working group document >>>>>>>>> need to be modified, then? >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>> Rosen, Brian wrote: >>>>>>>>>> It's beyond the charter. This was discussed when we created >>>>>>>>>> the charter, and explicitly excluded it for this initial work. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>>>> >>>>>>>>>>> However, the location-based services use case clearly has the >>>>>>>>>>> white space database keeping state on the secondary user, at >>>>>>>>>>> least his location. Step 7 of the Hotspot use case has the BS >>>>>>>>>>> registering the spectrum that it selected for its use. If the >>>>>>>>>>> database is keeping state in this manner, it could easily >>>>>>>>>>> calculate the exclusion zones for the secondary users as well. >>>>>>>>>>> >>>>>>>>>>> Or did these use cases as described exceed the mandate of the >>>>>>>>>>> charter? >>>>>>>>>>> >>>>>>>>>>> -Pete >>>>>>>>>>> >>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>> Yes, you are mistaken. >>>>>>>>>>>> >>>>>>>>>>>> If two queriers with the same location and input parameters >>>>>>>>>>>> query the database, they will get the same response. Suppose >>>>>>>>>>>> two U.S. Mode I devices at essentially the same location >>>>>>>>>>>> (within 25 meters) query the database, and the first is told >>>>>>>>>>>> he may use TV channels 1-5, 9-11 and 25-33. The second one >>>>>>>>>>>> will be told the same thing. >>>>>>>>>>>> >>>>>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>>>>> device actually chooses to use, when it starts using it, and >>>>>>>>>>>> when it ceases to use it. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Based on some of the existing use cases, it looks like the >>>>>>>>>>>>> database is keeping state even for the secondary users. That >>>>>>>>>>>>> is, it is acting as a de-facto registry for users of the >>>>>>>>>>>>> secondary spectrum and will refuse to allocate the same >>>>>>>>>>>>> spectrum to different users in overlapping geographic >>>>>>>>>>>>> regions. Am I >>>>>>> mistaken in >>>>>>>>> this assumption? >>>>>>>>>>>>> >>>>>>>>>>>>> -Pete >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>>>> I may be missing something, but it seems to me taht what >>>>>>>>>>>>>> you are describing is not the job of the database query >>>>>>>>>>>>>> protocol. base station coordination is an interesting >>>>>>>>>>>>>> problem, but is it within scope for this WG? (I do not >>>>>>>>>>>>>> think just specifying the same owner to the database will >>>>>>>>>>>>>> resolve the problem, and it makes the database state MUCH >>>>>>>>>>>>>> more complex.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his >>>>>>>>>>>>>>> third use case, and I think it would be a possible >>>>>>>>>>>>>>> candidate for inclusion in the document if it were >>>>>>>>>>>>>>> properly explained. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum >>>>>>>>>>>>>>> that is available over a wide area that can be used by >>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the same >>>>>>>>>>>>>>> signal to a set of receivers. This is somewhat similar to >>>>>>>>>>>>>>> the wide- area rural coverage scenario currently described >>>>>>>>>>>>>>> in the working group document; however, there would be >>>>>>>>>>>>>>> multiple Master BSs, each of which would independently >>>>>>>>>>>>>>> query the WSDB for available spectrum. However, they need >>>>>>>>>>>>>>> to coordinate the assignment so that they all get the same >>>>>>>>>>>>>>> spectrum over the whole area. As an implementation >>>>>>>>>>>>>>> example, this could be achieved by each BS reporting the >>>>>>>>>>>>>>> same owner/operator and using a key or index value to >>>>>>>>>>>>>>> indicate that they wanted to coordinate the assignment. >>>>>>>>>>>>>>> Alternatively, you might be able to elect one >>>>> BS >>>>>>> as the >>>>>>>>>>>>>>> leader and collect location information from all the other >>>>>>>>>>>>>>> BSs and then coordinate the assignment similar to the use >>>>>>>>>>>>>>> case in 4.2; the difference would be that the resulting >>>>>>>>>>>>>>> assignment is for simultaneous (not TDD) use by all of the >>>>>>>>>>>>>>> BSs covering the wider area. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does this sound like an interesting and novel use case? >>>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >>>>>>>>>>>>>>> art for the draft. From Basavaraj.Patil@nokia.com Wed Sep 14 13:06: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 7635A21F8C17 for ; Wed, 14 Sep 2011 13:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 yOIQ0dsAAVIW for ; Wed, 14 Sep 2011 13:06:26 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3D85E21F8B9C for ; Wed, 14 Sep 2011 13:06:25 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EK7sOl024493; Wed, 14 Sep 2011 23:08:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 23:07:54 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 22:07:53 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 22:07:53 +0200 From: To: , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAIAAX3oA///OEACAAF+sgP//uSyAAArfo4D//62DgA== Date: Wed, 14 Sep 2011 20:07:52 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A45C@dfweml503-mbx.china.huawei.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: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <579947FF8B88F54AB82341E97D246545@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 20:07:54.0645 (UTC) FILETIME=[FD35F450:01CC7319] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:06:27 -0000 Agree.=20 Reason to send is from the perspective that such information may help in future extensions or enhancements that would enable interference mitigation (as an example) or other purposes. On 9/14/11 3:03 PM, "ext Peter McCann" wrote: >"no reason to not send" does not equal "reason to send." > >-Pete > >Basavaraj.Patil@nokia.com wrote: >>=20 >> Pete, >>=20 >> IMO we don't need to be concerned about whether the database is keeping >> state. Its upto the database. I agree that the text should not say >> anything about what the database does if the Master WS device informs >> the database which of the available channels were selected for >> use/operation. >>=20 >> There is no reason for the WS device to not send an acknowledgement >> back to the database indicating which channels (from the list) are >> being used. >>=20 >> What the database does with this information is outside the scope of >> the protocol itself. >>=20 >> -Raj >>=20 >> On 9/14/11 2:05 PM, "ext Peter McCann" wrote: >>=20 >>> Hi, Scott, >>>=20 >>> The text says "the database is updated." That wording is at least >>> confusing. It also says "the database replies with the location of the >>> master device". Both of these imply that some state on a per-master >>> basis is being kept in the database. >>>=20 >>> We need to get clarity within the working group whether the database >>> can keep state about the devices that query it or whether it is >>> designed to be a completely passive repository of information. >>>=20 >>> -Pete >>>=20 >>>=20 >>> scott.probasco@nokia.com wrote: >>>> Hi Pete, >>>>=20 >>>> Allowing PAWS to carry information back to the database as in 4.2 & >>>> 4.3 is just a transport. We don't have to think about what the >>>> database does with that. While FCC may not have regulations today >>>> which require this type of transport, IMHO it is premature to >>>> assume that no regulator in the world will have such need. >>>>=20 >>>> Similarly for location-based service use case, the only issue from >>>> PAWS perspective is some message which allows a query of the database, >>>> based on master identity. In addition to the location based service >>>> use case already included in the I-D, another example is >>>> identification of a Master who is causing interference. FCC does >>>> envision something very similar, though not precisely same, to this >>>> scenario for determination of interference. >>>>=20 >>>> Thus I believe these use cases are useful and reasonable. >>>>=20 >>>> Regards, >>>> Scott >>>>=20 >>>>=20 >>>>=20 >>>> On 9/14/11 11:22 AM, "ext Peter McCann" >>>> wrote: >>>>=20 >>>>> Hi, Scott, >>>>>=20 >>>>> The problem is when I see text like this in section 4.2 and 4.3: >>>>>=20 >>>>> 7. The master/AP acknowledges to the database which of the >>>> available >>>>> WS channels it has selected for its operation. The database is >>>>> updated with the information provided by the master/AP. >>>>> it makes me think that the database is tracking the use of spectrum >>>>> by the whitespace master devices. When it says "database is updated" >>>>> that makes me think that the database of exclusion zones is updated >>>>> in a way that will impact the results of future queries. >>>>>=20 >>>>> There is also the location-based service use case where the database >>>>> is keeping state about the whitespace master device, namely its >>>>> location: >>>>>=20 >>>>> 3. The server queries the trusted white space database with the >>>>> master identity provided by the application in the user's >>>>> smartphone. >>>>> 4. The trusted white space database replies to the server with >> the >>>>> location of the master device. >>>>> If the database is to be truly stateless and passive with respect to >>>>> queries by whitespace devices, these kinds of statements should be >>>>> removed from the use cases. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>>=20 >>>>> scott.probasco@nokia.com wrote: >>>>>> Hi, >>>>>>=20 >>>>>> One of the key aspects of this protocol between device and database >>>>>> is extensibility. The charter does recognize that the contents of >>>>>> the database is defined external to PAWS. Thus hard to say that any >>>>>> single specific value or information element is beyond the scope. >>>>>>=20 >>>>>> Also the charter allows for queries and responses, there is no >>>>>> restriction that single transactions are mandated. >>>>>>=20 >>>>>> So IMHO the use cases already approved are still valid, no >>>>>> reasons to exclude pieces. >>>>>>=20 >>>>>> Regards, >>>>>> Scott >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> Brian, >>>>>>>=20 >>>>>>> Agreed. A single transaction, to the DB and back to the TVBD, >>>>>>> would be sufficient if the protocol is to be kept simple. >>>>>>> Coexistence amongst the license-exempt devices would then be left >>>>>>> to other processes such as the one being developed by the IEEE >>>>>>> 802.19.1. >>>>>>>=20 >>>>>>> Gerald >>>>>>>=20 >>>>>>>=20 >>>>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>>>>> The problem is that this turns the transaction into multiple >>>>>>>> steps. As it is now, you send a query and get a response. >>>>>>>>=20 >>>>>>>> If the device needs to update with what it used, that's another >>>>>>>> step. Also, what happens if it changes its mind? >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>>>>>=20 >>>>>>>>> Peter, Brian, >>>>>>>>>=20 >>>>>>>>> My suggestion would be to leave this feature in. It will not >>>>>>>>> cost much to make room in the protocol for the TVBD to indicate >>>>>>>>> to the database which channel it decided to operate on and it >>>>>>>>> would provide easy extensibility to the protocol for an eventual >>>>>>>>> consideration of the coexistence amongst the license-exempt >>>>>>>>> devices. >>>>>>>>>=20 >>>>>>>>> I would agree, however, that the current step of the protocol >>>>>>>>> development should be limited to protecting of the broadcast >>>>>>>>> incumbents as stated in the scope. >>>>>>>>>=20 >>>>>>>>> Gerald >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>>>>> So do these use cases in the accepted working group document >>>>>>>>>> need to be modified, then? >>>>>>>>>>=20 >>>>>>>>>> -Pete >>>>>>>>>>=20 >>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>> It's beyond the charter. This was discussed when we created >>>>>>>>>>> the charter, and explicitly excluded it for this initial work. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> However, the location-based services use case clearly has the >>>>>>>>>>>> white space database keeping state on the secondary user, at >>>>>>>>>>>> least his location. Step 7 of the Hotspot use case has the BS >>>>>>>>>>>> registering the spectrum that it selected for its use. If the >>>>>>>>>>>> database is keeping state in this manner, it could easily >>>>>>>>>>>> calculate the exclusion zones for the secondary users as well. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or did these use cases as described exceed the mandate of the >>>>>>>>>>>> charter? >>>>>>>>>>>>=20 >>>>>>>>>>>> -Pete >>>>>>>>>>>>=20 >>>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>>> Yes, you are mistaken. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If two queriers with the same location and input parameters >>>>>>>>>>>>> query the database, they will get the same response. Suppose >>>>>>>>>>>>> two U.S. Mode I devices at essentially the same location >>>>>>>>>>>>> (within 25 meters) query the database, and the first is told >>>>>>>>>>>>> he may use TV channels 1-5, 9-11 and 25-33. The second one >>>>>>>>>>>>> will be told the same thing. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>>>>>> device actually chooses to use, when it starts using it, and >>>>>>>>>>>>> when it ceases to use it. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Brian >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Based on some of the existing use cases, it looks like the >>>>>>>>>>>>>> database is keeping state even for the secondary users. That >>>>>>>>>>>>>> is, it is acting as a de-facto registry for users of the >>>>>>>>>>>>>> secondary spectrum and will refuse to allocate the same >>>>>>>>>>>>>> spectrum to different users in overlapping geographic >>>>>>>>>>>>>> regions. Am I >>>>>>>> mistaken in >>>>>>>>>> this assumption? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -Pete >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>>>>> I may be missing something, but it seems to me taht what >>>>>>>>>>>>>>> you are describing is not the job of the database query >>>>>>>>>>>>>>> protocol. base station coordination is an interesting >>>>>>>>>>>>>>> problem, but is it within scope for this WG? (I do not >>>>>>>>>>>>>>> think just specifying the same owner to the database will >>>>>>>>>>>>>>> resolve the problem, and it makes the database state MUCH >>>>>>>>>>>>>>> more complex.) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his >>>>>>>>>>>>>>>> third use case, and I think it would be a possible >>>>>>>>>>>>>>>> candidate for inclusion in the document if it were >>>>>>>>>>>>>>>> properly explained. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum >>>>>>>>>>>>>>>> that is available over a wide area that can be used by >>>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the same >>>>>>>>>>>>>>>> signal to a set of receivers. This is somewhat similar to >>>>>>>>>>>>>>>> the wide- area rural coverage scenario currently described >>>>>>>>>>>>>>>> in the working group document; however, there would be >>>>>>>>>>>>>>>> multiple Master BSs, each of which would independently >>>>>>>>>>>>>>>> query the WSDB for available spectrum. However, they need >>>>>>>>>>>>>>>> to coordinate the assignment so that they all get the same >>>>>>>>>>>>>>>> spectrum over the whole area. As an implementation >>>>>>>>>>>>>>>> example, this could be achieved by each BS reporting the >>>>>>>>>>>>>>>> same owner/operator and using a key or index value to >>>>>>>>>>>>>>>> indicate that they wanted to coordinate the assignment. >>>>>>>>>>>>>>>> Alternatively, you might be able to elect one >>>>>> BS >>>>>>>> as the >>>>>>>>>>>>>>>> leader and collect location information from all the other >>>>>>>>>>>>>>>> BSs and then coordinate the assignment similar to the use >>>>>>>>>>>>>>>> case in 4.2; the difference would be that the resulting >>>>>>>>>>>>>>>> assignment is for simultaneous (not TDD) use by all of the >>>>>>>>>>>>>>>> BSs covering the wider area. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Does this sound like an interesting and novel use case? >>>>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >>>>>>>>>>>>>>>> art for the draft. > > > From Peter.McCann@huawei.com Wed Sep 14 13:08:39 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 AC45721F8C90 for ; Wed, 14 Sep 2011 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3DElU+eVkVqM for ; Wed, 14 Sep 2011 13:08:38 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9577F21F8C87 for ; Wed, 14 Sep 2011 13:08:38 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00KHJ420VB@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:10:48 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00CIA41Y3X@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:10:48 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 13:10:48 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 13:10:46 -0700 Date: Wed, 14 Sep 2011 20:10:45 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQD//59BXoAAee4AgAAFyYCAAAalAIAAavvg///CkACAAGoRMP//rqcAAA5bRRAADctJAAAqLx5g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A45C@dfweml503-mbx.china.huawei.com> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:08:39 -0000 Any such requirement has been ruled out of scope by the chair. -Pete Basavaraj.Patil@nokia.com wrote: > > Agree. > Reason to send is from the perspective that such information may help > in future extensions or enhancements that would enable interference > mitigation (as an example) or other purposes. > > On 9/14/11 3:03 PM, "ext Peter McCann" wrote: > >> "no reason to not send" does not equal "reason to send." >> >> -Pete >> >> Basavaraj.Patil@nokia.com wrote: >>> >>> Pete, >>> >>> IMO we don't need to be concerned about whether the database is >>> keeping state. Its upto the database. I agree that the text should not >>> say anything about what the database does if the Master WS device >>> informs the database which of the available channels were selected for >>> use/operation. >>> >>> There is no reason for the WS device to not send an acknowledgement >>> back to the database indicating which channels (from the list) are >>> being used. >>> >>> What the database does with this information is outside the scope >>> of the protocol itself. >>> >>> -Raj >>> >>> On 9/14/11 2:05 PM, "ext Peter McCann" wrote: >>> >>>> Hi, Scott, >>>> >>>> The text says "the database is updated." That wording is at least >>>> confusing. It also says "the database replies with the location >>>> of the master device". Both of these imply that some state on a >>>> per-master basis is being kept in the database. >>>> >>>> We need to get clarity within the working group whether the database >>>> can keep state about the devices that query it or whether it is >>>> designed to be a completely passive repository of information. >>>> >>>> -Pete >>>> >>>> >>>> scott.probasco@nokia.com wrote: >>>>> Hi Pete, >>>>> >>>>> Allowing PAWS to carry information back to the database as in 4.2 & >>>>> 4.3 is just a transport. We don't have to think about what the >>>>> database does with that. While FCC may not have regulations today >>>>> which require this type of transport, IMHO it is premature to assume >>>>> that no regulator in the world will have such need. >>>>> >>>>> Similarly for location-based service use case, the only issue from >>>>> PAWS perspective is some message which allows a query of the >>>>> database, based on master identity. In addition to the location >>>>> based service use case already included in the I-D, another example >>>>> is identification of a Master who is causing interference. FCC does >>>>> envision something very similar, though not precisely same, to this >>>>> scenario for determination of interference. >>>>> >>>>> Thus I believe these use cases are useful and reasonable. >>>>> >>>>> Regards, >>>>> Scott >>>>> >>>>> >>>>> >>>>> On 9/14/11 11:22 AM, "ext Peter McCann" >>>>> wrote: >>>>> >>>>>> Hi, Scott, >>>>>> >>>>>> The problem is when I see text like this in section 4.2 and 4.3: >>>>>> >>>>>> 7. The master/AP acknowledges to the database which of the >>>>> available >>>>>> WS channels it has selected for its operation. The database >>>>>> is updated with the information provided by the master/AP. >>>>>> it makes me think that the database is tracking the use of spectrum >>>>>> by the whitespace master devices. When it says "database is >>>>>> updated" that makes me think that the database of exclusion zones >>>>>> is updated in a way that will impact the results of future queries. >>>>>> >>>>>> There is also the location-based service use case where the >>>>>> database is keeping state about the whitespace master device, >>>>>> namely its >>>>>> location: >>>>>> >>>>>> 3. The server queries the trusted white space database with > the >>>>>> master identity provided by the application in the user's >>>>>> smartphone. >>>>>> 4. The trusted white space database replies to the server >>>>>> with >>> the >>>>>> location of the master device. >>>>>> If the database is to be truly stateless and passive with respect >>>>>> to queries by whitespace devices, these kinds of statements should >>>>>> be removed from the use cases. >>>>>> >>>>>> -Pete >>>>>> >>>>>> >>>>>> scott.probasco@nokia.com wrote: >>>>>>> Hi, >>>>>>> >>>>>>> One of the key aspects of this protocol between device and >>>>>>> database is extensibility. The charter does recognize that the >>>>>>> contents of the database is defined external to PAWS. Thus hard to >>>>>>> say that any single specific value or information element is >>>>>>> beyond the scope. >>>>>>> >>>>>>> Also the charter allows for queries and responses, there is no >>>>>>> restriction that single transactions are mandated. >>>>>>> >>>>>>> So IMHO the use cases already approved are still valid, no >>>>>>> reasons to exclude pieces. >>>>>>> >>>>>>> Regards, >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> Agreed. A single transaction, to the DB and back to the TVBD, >>>>>>>> would be sufficient if the protocol is to be kept simple. >>>>>>>> Coexistence amongst the license-exempt devices would then be >>>>>>>> left to other processes such as the one being developed by the >>>>>>>> IEEE 802.19.1. >>>>>>>> >>>>>>>> Gerald >>>>>>>> >>>>>>>> >>>>>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>>>>>> The problem is that this turns the transaction into multiple >>>>>>>>> steps. As it is now, you send a query and get a response. >>>>>>>>> >>>>>>>>> If the device needs to update with what it used, that's another >>>>>>>>> step. Also, what happens if it changes its mind? >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>>>>>> >>>>>>>>>> Peter, Brian, >>>>>>>>>> >>>>>>>>>> My suggestion would be to leave this feature in. It will >>>>>>>>>> not cost much to make room in the protocol for the TVBD to >>>>>>>>>> indicate to the database which channel it decided to >>>>>>>>>> operate on and it would provide easy extensibility to the >>>>>>>>>> protocol for an eventual consideration of the coexistence >>>>>>>>>> amongst the license-exempt devices. >>>>>>>>>> >>>>>>>>>> I would agree, however, that the current step of the >>>>>>>>>> protocol development should be limited to protecting of the >>>>>>>>>> broadcast incumbents as stated in the scope. >>>>>>>>>> >>>>>>>>>> Gerald >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>>>>>> So do these use cases in the accepted working group >>>>>>>>>>> document need to be modified, then? >>>>>>>>>>> >>>>>>>>>>> -Pete >>>>>>>>>>> >>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>> It's beyond the charter. This was discussed when we created >>>>>>>>>>>> the charter, and explicitly excluded it for this initial work. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>>>>>> >>>>>>>>>>>>> However, the location-based services use case clearly has >>>>>>>>>>>>> the white space database keeping state on the secondary >>>>>>>>>>>>> user, at least his location. Step 7 of the Hotspot use case >>>>>>>>>>>>> has the BS registering the spectrum that it selected for its >>>>>>>>>>>>> use. If the database is keeping state in this manner, it >>>>>>>>>>>>> could easily calculate the exclusion zones for the secondary >>>>>>>>>>>>> users as well. >>>>>>>>>>>>> >>>>>>>>>>>>> Or did these use cases as described exceed the mandate of >>>>>>>>>>>>> the charter? >>>>>>>>>>>>> >>>>>>>>>>>>> -Pete >>>>>>>>>>>>> >>>>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>>>> Yes, you are mistaken. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If two queriers with the same location and input parameters >>>>>>>>>>>>>> query the database, they will get the same response. >>>>>>>>>>>>>> Suppose two U.S. Mode I devices at essentially the same >>>>>>>>>>>>>> location (within 25 meters) query the database, and the >>>>>>>>>>>>>> first is told he may use TV channels 1-5, 9-11 and 25-33. >>>>>>>>>>>>>> The second one will be told the same thing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>>>>>>> device actually chooses to use, when it starts using it, >>>>>>>>>>>>>> and when it ceases to use it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Based on some of the existing use cases, it looks like >>>>>>>>>>>>>>> the database is keeping state even for the secondary >>>>>>>>>>>>>>> users. That is, it is acting as a de-facto registry for >>>>>>>>>>>>>>> users of the secondary spectrum and will refuse to >>>>>>>>>>>>>>> allocate the same spectrum to different users in >>>>>>>>>>>>>>> overlapping geographic regions. Am I >>>>>>>>> mistaken in >>>>>>>>>>> this assumption? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Pete >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>>>>>> I may be missing something, but it seems to me taht what >>>>>>>>>>>>>>>> you are describing is not the job of the database query >>>>>>>>>>>>>>>> protocol. base station coordination is an interesting >>>>>>>>>>>>>>>> problem, but is it within scope for this WG? (I do not >>>>>>>>>>>>>>>> think just specifying the same owner to the database will >>>>>>>>>>>>>>>> resolve the problem, and it makes the database state MUCH >>>>>>>>>>>>>>>> more complex.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his >>>>>>>>>>>>>>>>> third use case, and I think it would be a possible >>>>>>>>>>>>>>>>> candidate for inclusion in the document if it were >>>>>>>>>>>>>>>>> properly explained. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum >>>>>>>>>>>>>>>>> that is available over a wide area that can be used by >>>>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the same >>>>>>>>>>>>>>>>> signal to a set of receivers. This is somewhat similar >>>>>>>>>>>>>>>>> to the wide- area rural coverage scenario currently >>>>>>>>>>>>>>>>> described in the working group document; however, there >>>>>>>>>>>>>>>>> would be multiple Master BSs, each of which would >>>>>>>>>>>>>>>>> independently query the WSDB for available spectrum. >>>>>>>>>>>>>>>>> However, they need to coordinate the assignment so that >>>>>>>>>>>>>>>>> they all get the same spectrum over the whole area. As >>>>>>>>>>>>>>>>> an implementation example, this could be achieved by >>>>>>>>>>>>>>>>> each BS reporting the same owner/operator and using a >>>>>>>>>>>>>>>>> key or index value to indicate that they wanted to >>>>>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be >>>>>>>>>>>>>>>>> able to elect one >>>>>>> BS >>>>>>>>> as the >>>>>>>>>>>>>>>>> leader and collect location information from all the >>>>>>>>>>>>>>>>> other BSs and then coordinate the assignment similar to >>>>>>>>>>>>>>>>> the use case in 4.2; the difference would be that the >>>>>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use >>>>>>>>>>>>>>>>> by all of the BSs covering the wider area. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does this sound like an interesting and novel use case? >>>>>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >>>>>>>>>>>>>>>>> art for the draft. >> >> >> From Basavaraj.Patil@nokia.com Wed Sep 14 13:15: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 3938721F8CF8 for ; Wed, 14 Sep 2011 13:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 txC9Y+mFrrVj for ; Wed, 14 Sep 2011 13:15:44 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E9E9721F8CF5 for ; Wed, 14 Sep 2011 13:15:43 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EKHgm0013164; Wed, 14 Sep 2011 23:17:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 23:17:43 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 22:17:43 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 22:17:42 +0200 From: To: , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAIAAX3oA///OEACAAF+sgP//uSyAAArfo4D//62DgIAAVIKA//+uPAA= Date: Wed, 14 Sep 2011 20:17:41 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.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: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <49704A73AAC84E4FA0AB7B515A68E4F1@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 20:17:43.0760 (UTC) FILETIME=[5C59C500:01CC731B] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:15:45 -0000 True. And I am in sync with that. However during the formation of this WG there has been discussion that the WG could consider expanding the scope once the initial objective has been met.=20 Consequently we could simply focus on the request/response protocol for now and extend it at a later date if the charter were to be revised and the scope expanded. However can we foresee a requirement by some regulatory entity that would mandate the database being informed about the channels being used by a WS device? Do we want such flexibility to be incorporated into the protocol knowing that the regulatory domain w.r.t this technology is still in its infancy? -Raj On 9/14/11 3:10 PM, "ext Peter McCann" wrote: >Any such requirement has been ruled out of scope by the chair. > >-Pete > >Basavaraj.Patil@nokia.com wrote: >>=20 >> Agree. >> Reason to send is from the perspective that such information may help >> in future extensions or enhancements that would enable interference >> mitigation (as an example) or other purposes. >>=20 >> On 9/14/11 3:03 PM, "ext Peter McCann" wrote: >>=20 >>> "no reason to not send" does not equal "reason to send." >>>=20 >>> -Pete >>>=20 >>> Basavaraj.Patil@nokia.com wrote: >>>>=20 >>>> Pete, >>>>=20 >>>> IMO we don't need to be concerned about whether the database is >>>> keeping state. Its upto the database. I agree that the text should not >>>> say anything about what the database does if the Master WS device >>>> informs the database which of the available channels were selected for >>>> use/operation. >>>>=20 >>>> There is no reason for the WS device to not send an acknowledgement >>>> back to the database indicating which channels (from the list) are >>>> being used. >>>>=20 >>>> What the database does with this information is outside the scope >>>> of the protocol itself. >>>>=20 >>>> -Raj >>>>=20 >>>> On 9/14/11 2:05 PM, "ext Peter McCann" >>>>wrote: >>>>=20 >>>>> Hi, Scott, >>>>>=20 >>>>> The text says "the database is updated." That wording is at least >>>>> confusing. It also says "the database replies with the location >>>>> of the master device". Both of these imply that some state on a >>>>> per-master basis is being kept in the database. >>>>>=20 >>>>> We need to get clarity within the working group whether the database >>>>> can keep state about the devices that query it or whether it is >>>>> designed to be a completely passive repository of information. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>>=20 >>>>> scott.probasco@nokia.com wrote: >>>>>> Hi Pete, >>>>>>=20 >>>>>> Allowing PAWS to carry information back to the database as in 4.2 & >>>>>> 4.3 is just a transport. We don't have to think about what the >>>>>> database does with that. While FCC may not have regulations today >>>>>> which require this type of transport, IMHO it is premature to assume >>>>>> that no regulator in the world will have such need. >>>>>>=20 >>>>>> Similarly for location-based service use case, the only issue from >>>>>> PAWS perspective is some message which allows a query of the >>>>>> database, based on master identity. In addition to the location >>>>>> based service use case already included in the I-D, another example >>>>>> is identification of a Master who is causing interference. FCC does >>>>>> envision something very similar, though not precisely same, to this >>>>>> scenario for determination of interference. >>>>>>=20 >>>>>> Thus I believe these use cases are useful and reasonable. >>>>>>=20 >>>>>> Regards, >>>>>> Scott >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/14/11 11:22 AM, "ext Peter McCann" >>>>>> wrote: >>>>>>=20 >>>>>>> Hi, Scott, >>>>>>>=20 >>>>>>> The problem is when I see text like this in section 4.2 and 4.3: >>>>>>>=20 >>>>>>> 7. The master/AP acknowledges to the database which of the >>>>>> available >>>>>>> WS channels it has selected for its operation. The database >>>>>>> is updated with the information provided by the master/AP. >>>>>>> it makes me think that the database is tracking the use of spectrum >>>>>>> by the whitespace master devices. When it says "database is >>>>>>> updated" that makes me think that the database of exclusion zones >>>>>>> is updated in a way that will impact the results of future queries. >>>>>>>=20 >>>>>>> There is also the location-based service use case where the >>>>>>> database is keeping state about the whitespace master device, >>>>>>> namely its >>>>>>> location: >>>>>>>=20 >>>>>>> 3. The server queries the trusted white space database with >> the >>>>>>> master identity provided by the application in the user's >>>>>>> smartphone. >>>>>>> 4. The trusted white space database replies to the server >>>>>>> with >>>> the >>>>>>> location of the master device. >>>>>>> If the database is to be truly stateless and passive with respect >>>>>>> to queries by whitespace devices, these kinds of statements should >>>>>>> be removed from the use cases. >>>>>>>=20 >>>>>>> -Pete >>>>>>>=20 >>>>>>>=20 >>>>>>> scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> One of the key aspects of this protocol between device and >>>>>>>> database is extensibility. The charter does recognize that the >>>>>>>> contents of the database is defined external to PAWS. Thus hard to >>>>>>>> say that any single specific value or information element is >>>>>>>> beyond the scope. >>>>>>>>=20 >>>>>>>> Also the charter allows for queries and responses, there is no >>>>>>>> restriction that single transactions are mandated. >>>>>>>>=20 >>>>>>>> So IMHO the use cases already approved are still valid, no >>>>>>>> reasons to exclude pieces. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Scott >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Brian, >>>>>>>>>=20 >>>>>>>>> Agreed. A single transaction, to the DB and back to the TVBD, >>>>>>>>> would be sufficient if the protocol is to be kept simple. >>>>>>>>> Coexistence amongst the license-exempt devices would then be >>>>>>>>> left to other processes such as the one being developed by the >>>>>>>>> IEEE 802.19.1. >>>>>>>>>=20 >>>>>>>>> Gerald >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>>>>>>> The problem is that this turns the transaction into multiple >>>>>>>>>> steps. As it is now, you send a query and get a response. >>>>>>>>>>=20 >>>>>>>>>> If the device needs to update with what it used, that's another >>>>>>>>>> step. Also, what happens if it changes its mind? >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>>>>>>>=20 >>>>>>>>>>> Peter, Brian, >>>>>>>>>>>=20 >>>>>>>>>>> My suggestion would be to leave this feature in. It will >>>>>>>>>>> not cost much to make room in the protocol for the TVBD to >>>>>>>>>>> indicate to the database which channel it decided to >>>>>>>>>>> operate on and it would provide easy extensibility to the >>>>>>>>>>> protocol for an eventual consideration of the coexistence >>>>>>>>>>> amongst the license-exempt devices. >>>>>>>>>>>=20 >>>>>>>>>>> I would agree, however, that the current step of the >>>>>>>>>>> protocol development should be limited to protecting of the >>>>>>>>>>> broadcast incumbents as stated in the scope. >>>>>>>>>>>=20 >>>>>>>>>>> Gerald >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>>>>>>> So do these use cases in the accepted working group >>>>>>>>>>>> document need to be modified, then? >>>>>>>>>>>>=20 >>>>>>>>>>>> -Pete >>>>>>>>>>>>=20 >>>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>>> It's beyond the charter. This was discussed when we created >>>>>>>>>>>>> the charter, and explicitly excluded it for this initial >>>>>>>>>>>>>work. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Brian >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> However, the location-based services use case clearly has >>>>>>>>>>>>>> the white space database keeping state on the secondary >>>>>>>>>>>>>> user, at least his location. Step 7 of the Hotspot use case >>>>>>>>>>>>>> has the BS registering the spectrum that it selected for its >>>>>>>>>>>>>> use. If the database is keeping state in this manner, it >>>>>>>>>>>>>> could easily calculate the exclusion zones for the secondary >>>>>>>>>>>>>> users as well. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Or did these use cases as described exceed the mandate of >>>>>>>>>>>>>> the charter? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -Pete >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>>>>> Yes, you are mistaken. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If two queriers with the same location and input parameters >>>>>>>>>>>>>>> query the database, they will get the same response. >>>>>>>>>>>>>>> Suppose two U.S. Mode I devices at essentially the same >>>>>>>>>>>>>>> location (within 25 meters) query the database, and the >>>>>>>>>>>>>>> first is told he may use TV channels 1-5, 9-11 and 25-33. >>>>>>>>>>>>>>> The second one will be told the same thing. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The database knows query patterns, but does not track use. >>>>>>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >>>>>>>>>>>>>>> device actually chooses to use, when it starts using it, >>>>>>>>>>>>>>> and when it ceases to use it. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Based on some of the existing use cases, it looks like >>>>>>>>>>>>>>>> the database is keeping state even for the secondary >>>>>>>>>>>>>>>> users. That is, it is acting as a de-facto registry for >>>>>>>>>>>>>>>> users of the secondary spectrum and will refuse to >>>>>>>>>>>>>>>> allocate the same spectrum to different users in >>>>>>>>>>>>>>>> overlapping geographic regions. Am I >>>>>>>>>> mistaken in >>>>>>>>>>>> this assumption? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -Pete >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>>>>>>> I may be missing something, but it seems to me taht what >>>>>>>>>>>>>>>>> you are describing is not the job of the database query >>>>>>>>>>>>>>>>> protocol. base station coordination is an interesting >>>>>>>>>>>>>>>>> problem, but is it within scope for this WG? (I do not >>>>>>>>>>>>>>>>> think just specifying the same owner to the database will >>>>>>>>>>>>>>>>> resolve the problem, and it makes the database state MUCH >>>>>>>>>>>>>>>>> more complex.) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his >>>>>>>>>>>>>>>>>> third use case, and I think it would be a possible >>>>>>>>>>>>>>>>>> candidate for inclusion in the document if it were >>>>>>>>>>>>>>>>>> properly explained. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum >>>>>>>>>>>>>>>>>> that is available over a wide area that can be used by >>>>>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the same >>>>>>>>>>>>>>>>>> signal to a set of receivers. This is somewhat similar >>>>>>>>>>>>>>>>>> to the wide- area rural coverage scenario currently >>>>>>>>>>>>>>>>>> described in the working group document; however, there >>>>>>>>>>>>>>>>>> would be multiple Master BSs, each of which would >>>>>>>>>>>>>>>>>> independently query the WSDB for available spectrum. >>>>>>>>>>>>>>>>>> However, they need to coordinate the assignment so that >>>>>>>>>>>>>>>>>> they all get the same spectrum over the whole area. As >>>>>>>>>>>>>>>>>> an implementation example, this could be achieved by >>>>>>>>>>>>>>>>>> each BS reporting the same owner/operator and using a >>>>>>>>>>>>>>>>>> key or index value to indicate that they wanted to >>>>>>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be >>>>>>>>>>>>>>>>>> able to elect one >>>>>>>> BS >>>>>>>>>> as the >>>>>>>>>>>>>>>>>> leader and collect location information from all the >>>>>>>>>>>>>>>>>> other BSs and then coordinate the assignment similar to >>>>>>>>>>>>>>>>>> the use case in 4.2; the difference would be that the >>>>>>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use >>>>>>>>>>>>>>>>>> by all of the BSs covering the wider area. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Does this sound like an interesting and novel use case? >>>>>>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >>>>>>>>>>>>>>>>>> art for the draft. >>>=20 >>>=20 >>> > > > From Peter.McCann@huawei.com Wed Sep 14 13:19: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 EAAE521F8B5A for ; Wed, 14 Sep 2011 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qjooeC0kCjCP for ; Wed, 14 Sep 2011 13:19:24 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id BA6B521F8B3C for ; Wed, 14 Sep 2011 13:19:24 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00KSK4JYVB@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:21:34 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00C894JX3X@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:21:34 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 13:21:34 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 13:21:27 -0700 Date: Wed, 14 Sep 2011 20:21:27 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.193.125.70] To: "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A47E@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQD//59BXoAAee4AgAAFyYCAAAalAIAAavvg///CkACAAGoRMP//rqcAAA5bRRAADctJAAAqLx5gAEVt7IAAmXiBsA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.com> Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:19:26 -0000 So what are the criteria for determining what can go into the use cases document? You seem to think we are not limited by the scope of the current charter. -Pete Basavaraj.Patil@nokia.com wrote: > > True. And I am in sync with that. > However during the formation of this WG there has been discussion that > the WG could consider expanding the scope once the initial objective > has been met. > Consequently we could simply focus on the request/response protocol > for now and extend it at a later date if the charter were to be > revised and the scope expanded. > > However can we foresee a requirement by some regulatory entity that > would mandate the database being informed about the channels being > used by a WS device? Do we want such flexibility to be incorporated > into the protocol knowing that the regulatory domain w.r.t this > technology is still in its infancy? > > -Raj > > > On 9/14/11 3:10 PM, "ext Peter McCann" wrote: > >> Any such requirement has been ruled out of scope by the chair. >> >> -Pete >> >> Basavaraj.Patil@nokia.com wrote: >>> >>> Agree. Reason to send is from the perspective that such information >>> may help in future extensions or enhancements that would enable >>> interference mitigation (as an example) or other purposes. >>> >>> On 9/14/11 3:03 PM, "ext Peter McCann" wrote: >>> >>>> "no reason to not send" does not equal "reason to send." >>>> >>>> -Pete >>>> >>>> Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> Pete, >>>>> >>>>> IMO we don't need to be concerned about whether the database is >>>>> keeping state. Its upto the database. I agree that the text >>>>> should not say anything about what the database does if the >>>>> Master WS device informs the database which of the available >>>>> channels were selected for use/operation. >>>>> >>>>> There is no reason for the WS device to not send an acknowledgement >>>>> back to the database indicating which channels (from the list) are >>>>> being used. >>>>> >>>>> What the database does with this information is outside the scope >>>>> of the protocol itself. >>>>> >>>>> -Raj >>>>> >>>>> On 9/14/11 2:05 PM, "ext Peter McCann" >>>>> wrote: >>>>> >>>>>> Hi, Scott, >>>>>> >>>>>> The text says "the database is updated." That wording is at least >>>>>> confusing. It also says "the database replies with the location of >>>>>> the master device". Both of these imply that some state on a >>>>>> per-master basis is being kept in the database. >>>>>> >>>>>> We need to get clarity within the working group whether the >>>>>> database can keep state about the devices that query it or whether >>>>>> it is designed to be a completely passive repository of information. >>>>>> >>>>>> -Pete >>>>>> >>>>>> >>>>>> scott.probasco@nokia.com wrote: >>>>>>> Hi Pete, >>>>>>> >>>>>>> Allowing PAWS to carry information back to the database as in 4.2 >>>>>>> & 4.3 is just a transport. We don't have to think about what the >>>>>>> database does with that. While FCC may not have regulations today >>>>>>> which require this type of transport, IMHO it is premature to >>>>>>> assume that no regulator in the world will have such need. >>>>>>> >>>>>>> Similarly for location-based service use case, the only issue from >>>>>>> PAWS perspective is some message which allows a query of the >>>>>>> database, based on master identity. In addition to the location >>>>>>> based service use case already included in the I-D, another >>>>>>> example is identification of a Master who is causing interference. >>>>>>> FCC does envision something very similar, though not precisely >>>>>>> same, to this scenario for determination of interference. >>>>>>> >>>>>>> Thus I believe these use cases are useful and reasonable. >>>>>>> >>>>>>> Regards, >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/14/11 11:22 AM, "ext Peter McCann" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, Scott, >>>>>>>> >>>>>>>> The problem is when I see text like this in section 4.2 and 4.3: >>>>>>>> >>>>>>>> 7. The master/AP acknowledges to the database which of the >>>>>>> available >>>>>>>> WS channels it has selected for its operation. The >>>>>>>> database is updated with the information provided by the > master/AP. >>>>>>>> it makes me think that the database is tracking the use of >>>>>>>> spectrum by the whitespace master devices. When it says >>>>>>>> "database is updated" that makes me think that the database of >>>>>>>> exclusion zones is updated in a way that will impact the results >>>>>>>> of future queries. >>>>>>>> >>>>>>>> There is also the location-based service use case where the >>>>>>>> database is keeping state about the whitespace master device, >>>>>>>> namely its >>>>>>>> location: >>>>>>>> >>>>>>>> 3. The server queries the trusted white space database with >>> the >>>>>>>> master identity provided by the application in the user's >>>>>>>> smartphone. >>>>>>>> 4. The trusted white space database replies to the server >>>>>>>> with >>>>> the >>>>>>>> location of the master device. >>>>>>>> If the database is to be truly stateless and passive with >>>>>>>> respect to queries by whitespace devices, these kinds of >>>>>>>> statements should be removed from the use cases. >>>>>>>> >>>>>>>> -Pete >>>>>>>> >>>>>>>> >>>>>>>> scott.probasco@nokia.com wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> One of the key aspects of this protocol between device and >>>>>>>>> database is extensibility. The charter does recognize that the >>>>>>>>> contents of the database is defined external to PAWS. Thus hard >>>>>>>>> to say that any single specific value or information element is >>>>>>>>> beyond the scope. >>>>>>>>> >>>>>>>>> Also the charter allows for queries and responses, there is >>>>>>>>> no restriction that single transactions are mandated. >>>>>>>>> >>>>>>>>> So IMHO the use cases already approved are still valid, no >>>>>>>>> reasons to exclude pieces. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> Agreed. A single transaction, to the DB and back to the TVBD, >>>>>>>>>> would be sufficient if the protocol is to be kept simple. >>>>>>>>>> Coexistence amongst the license-exempt devices would then be >>>>>>>>>> left to other processes such as the one being developed by the >>>>>>>>>> IEEE 802.19.1. >>>>>>>>>> >>>>>>>>>> Gerald >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >>>>>>>>>>> The problem is that this turns the transaction into >>>>>>>>>>> multiple steps. As it is now, you send a query and get a response. >>>>>>>>>>> >>>>>>>>>>> If the device needs to update with what it used, that's >>>>>>>>>>> another step. Also, what happens if it changes its mind? >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >>>>>>>>>>> >>>>>>>>>>>> Peter, Brian, >>>>>>>>>>>> >>>>>>>>>>>> My suggestion would be to leave this feature in. It will >>>>>>>>>>>> not cost much to make room in the protocol for the TVBD >>>>>>>>>>>> to indicate to the database which channel it decided to >>>>>>>>>>>> operate on and it would provide easy extensibility to the >>>>>>>>>>>> protocol for an eventual consideration of the coexistence >>>>>>>>>>>> amongst the license-exempt devices. >>>>>>>>>>>> >>>>>>>>>>>> I would agree, however, that the current step of the >>>>>>>>>>>> protocol development should be limited to protecting of >>>>>>>>>>>> the broadcast incumbents as stated in the scope. >>>>>>>>>>>> >>>>>>>>>>>> Gerald >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >>>>>>>>>>>>> So do these use cases in the accepted working group >>>>>>>>>>>>> document need to be modified, then? >>>>>>>>>>>>> >>>>>>>>>>>>> -Pete >>>>>>>>>>>>> >>>>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>>>> It's beyond the charter. This was discussed when we >>>>>>>>>>>>>> created the charter, and explicitly excluded it for this >>>>>>>>>>>>>> initial work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, the location-based services use case clearly has >>>>>>>>>>>>>>> the white space database keeping state on the secondary >>>>>>>>>>>>>>> user, at least his location. Step 7 of the Hotspot use >>>>>>>>>>>>>>> case has the BS registering the spectrum that it selected >>>>>>>>>>>>>>> for its use. If the database is keeping state in this >>>>>>>>>>>>>>> manner, it could easily calculate the exclusion zones for >>>>>>>>>>>>>>> the secondary users as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Or did these use cases as described exceed the mandate of >>>>>>>>>>>>>>> the charter? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Pete >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rosen, Brian wrote: >>>>>>>>>>>>>>>> Yes, you are mistaken. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If two queriers with the same location and input >>>>>>>>>>>>>>>> parameters query the database, they will get the same >>>>>>>>>>>>>>>> response. Suppose two U.S. Mode I devices at essentially >>>>>>>>>>>>>>>> the same location (within 25 meters) query the database, >>>>>>>>>>>>>>>> and the first is told he may use TV channels 1-5, 9-11 >>>>>>>>>>>>>>>> and 25- 33. The second one will be told the same thing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The database knows query patterns, but does not track >>>>>>>>>>>>>>>> use. Specifically, it doesn't know what part of the >>>>>>>>>>>>>>>> spectrum the device actually chooses to use, when it >>>>>>>>>>>>>>>> starts using it, and when it ceases to use it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Based on some of the existing use cases, it looks like >>>>>>>>>>>>>>>>> the database is keeping state even for the secondary >>>>>>>>>>>>>>>>> users. That is, it is acting as a de-facto registry for >>>>>>>>>>>>>>>>> users of the secondary spectrum and will refuse to >>>>>>>>>>>>>>>>> allocate the same spectrum to different users in >>>>>>>>>>>>>>>>> overlapping geographic regions. Am I >>>>>>>>>>> mistaken in >>>>>>>>>>>>> this assumption? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Pete >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Joel M. Halpern wrote: >>>>>>>>>>>>>>>>>> I may be missing something, but it seems to me taht >>>>>>>>>>>>>>>>>> what you are describing is not the job of the database >>>>>>>>>>>>>>>>>> query protocol. base station coordination is an >>>>>>>>>>>>>>>>>> interesting problem, but is it within scope for this >>>>>>>>>>>>>>>>>> WG? (I do not think just specifying the same owner to >>>>>>>>>>>>>>>>>> the database will resolve the problem, and it makes the >>>>>>>>>>>>>>>>>> database state MUCH more complex.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his >>>>>>>>>>>>>>>>>>> third use case, and I think it would be a possible >>>>>>>>>>>>>>>>>>> candidate for inclusion in the document if it were >>>>>>>>>>>>>>>>>>> properly explained. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >>>>>>>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum >>>>>>>>>>>>>>>>>>> that is available over a wide area that can be used by >>>>>>>>>>>>>>>>>>> multiple master BSs to simultaneously broadcast the >>>>>>>>>>>>>>>>>>> same signal to a set of receivers. This is somewhat >>>>>>>>>>>>>>>>>>> similar to the wide- area rural coverage scenario >>>>>>>>>>>>>>>>>>> currently described in the working group document; >>>>>>>>>>>>>>>>>>> however, there would be multiple Master BSs, each of >>>>>>>>>>>>>>>>>>> which would independently query the WSDB for available >>>>>>>>>>>>>>>>>>> spectrum. However, they need to coordinate the >>>>>>>>>>>>>>>>>>> assignment so that they all get the same spectrum over >>>>>>>>>>>>>>>>>>> the whole area. As an implementation example, this >>>>>>>>>>>>>>>>>>> could be achieved by each BS reporting the same >>>>>>>>>>>>>>>>>>> owner/operator and using a key or index value to >>>>>>>>>>>>>>>>>>> indicate that they wanted to coordinate the >>>>>>>>>>>>>>>>>>> assignment. Alternatively, you might be able to elect >>>>>>>>>>>>>>>>>>> one >>>>>>>>> BS >>>>>>>>>>> as the >>>>>>>>>>>>>>>>>>> leader and collect location information from all >>>>>>>>>>>>>>>>>>> the other BSs and then coordinate the assignment >>>>>>>>>>>>>>>>>>> similar to the use case in 4.2; the difference >>>>>>>>>>>>>>>>>>> would be that the resulting assignment is for >>>>>>>>>>>>>>>>>>> simultaneous (not >>>>>>>>>>>>>>>>>>> TDD) use by all of the BSs covering the wider area. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Does this sound like an interesting and novel use >>>>>>>>>>>>>>>>>>> case? If so I can do a more detailed writeup and >>>>>>>>>>>>>>>>>>> supply ASCII art for the draft. From paul@marvell.com Wed Sep 14 13:20: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 0541D21F8CEB for ; Wed, 14 Sep 2011 13:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 3ByVvx3nVLk8 for ; Wed, 14 Sep 2011 13:20:34 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEF721F8BE8 for ; Wed, 14 Sep 2011 13:20:34 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTnENBtFMDeXpeXajeITde9oWKu7PemMo@postini.com; Wed, 14 Sep 2011 13:22:44 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 14 Sep 2011 13:19:46 -0700 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "Peter.McCann@huawei.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Date: Wed, 14 Sep 2011 13:19:50 -0700 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAIAAX3oA///OEACAAF+sgP//uSyAAA8D7XA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141C15B733@SC-VEXCH2.marvell.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A423@dfweml503-mbx.china.huawei.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] Possible new use case: simulcasting 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, 14 Sep 2011 20:20:36 -0000 Raj, On the indication of selected channels: >=20 > IMO we don't need to be concerned about whether the database is keeping > state. > Its upto the database. I agree that the text should not say anything > about > what the database does if the Master WS device informs the database > which > of the available channels were selected for use/operation. >=20 > There is no reason for the WS device to not send an acknowledgement > back to the database indicating which channels (from the list) are=20 > being used. I disagree. There are many reasons to not send the selected channel(s) back to the database: 1) it's an extra unnecessary message 2) it's not useful unless any updates in usage are also sent the devices are likely to change channels, modulation, etc dynamically within the allowed parameters 3) the entity getting this coordination information is not necessarily the same as the database. Local spectrum coordination is a different function than regulatory spectrum access. If we want coordination - we should do it right 4) the usage of such fields are out-of-scope, so why include them If there is no supporting text on usage. Paul >=20 > What the database does with this information is outside the scope of > the protocol itself. >=20 > -Raj >=20 > On 9/14/11 2:05 PM, "ext Peter McCann" wrote: >=20 > >Hi, Scott, > > > >The text says "the database is updated." That wording is at least > >confusing. It also says "the database replies with the location of > >the master device". Both of these imply that some state on a per- > master > >basis is being kept in the database. > > > >We need to get clarity within the working group whether the database > >can keep state about the devices that query it or whether it is > designed > >to be a completely passive repository of information. > > > >-Pete > > > > > >scott.probasco@nokia.com wrote: > >> Hi Pete, > >> > >> Allowing PAWS to carry information back to the database as in 4.2 & > >> 4.3 is just a transport. We don't have to think about what the > >> database does with that. While FCC may not have regulations today > >> which require this type of transport, IMHO it is premature to assume > >> that no regulator in the world will have such need. > >> > >> Similarly for location-based service use case, the only issue from > >> PAWS perspective is some message which allows a query of the > database, > >> based on master identity. In addition to the location based service > >> use case already included in the I-D, another example is > >> identification of a Master who is causing interference. FCC does > >> envision something very similar, though not precisely same, to this > >> scenario for determination of interference. > >> > >> Thus I believe these use cases are useful and reasonable. > >> > >> Regards, > >> Scott > >> > >> > >> > >> On 9/14/11 11:22 AM, "ext Peter McCann" > wrote: > >> > >>> Hi, Scott, > >>> > >>> The problem is when I see text like this in section 4.2 and 4.3: > >>> > >>> 7. The master/AP acknowledges to the database which of the > >> available > >>> WS channels it has selected for its operation. The database > is > >>> updated with the information provided by the master/AP. > >>> it makes me think that the database is tracking the use of spectrum > >>> by the whitespace master devices. When it says "database is > updated" > >>> that makes me think that the database of exclusion zones is updated > >>> in a way that will impact the results of future queries. > >>> > >>> There is also the location-based service use case where the > database is > >>> keeping state about the whitespace master device, namely its > location: > >>> > >>> 3. The server queries the trusted white space database with the > >>> master identity provided by the application in the user's > >>> smartphone. > >>> 4. The trusted white space database replies to the server with > the > >>> location of the master device. > >>> If the database is to be truly stateless and passive with respect > to > >>> queries by whitespace devices, these kinds of statements should be > >>> removed from the use cases. > >>> > >>> -Pete > >>> > >>> > >>> scott.probasco@nokia.com wrote: > >>>> Hi, > >>>> > >>>> One of the key aspects of this protocol between device and > database is > >>>> extensibility. The charter does recognize that the contents of the > >>>> database is defined external to PAWS. Thus hard to say that any > single > >>>> specific value or information element is beyond the scope. > >>>> > >>>> Also the charter allows for queries and responses, there is no > >>>> restriction that single transactions are mandated. > >>>> > >>>> So IMHO the use cases already approved are still valid, no reasons > to > >>>> exclude pieces. > >>>> > >>>> Regards, > >>>> Scott > >>>> > >>>> > >>>> > >>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" > > >>>> wrote: > >>>> > >>>>> Brian, > >>>>> > >>>>> Agreed. A single transaction, to the DB and back to the TVBD, > would > >>>>> be sufficient if the protocol is to be kept simple. Coexistence > >>>>> amongst the license-exempt devices would then be left to other > >>>>> processes such as the one being developed by the IEEE 802.19.1. > >>>>> > >>>>> Gerald > >>>>> > >>>>> > >>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: > >>>>>> The problem is that this turns the transaction into multiple > steps. > >>>>>> As it is now, you send a query and get a response. > >>>>>> > >>>>>> If the device needs to update with what it used, that's another > >>>>>> step. Also, what happens if it changes its mind? > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: > >>>>>> > >>>>>>> Peter, Brian, > >>>>>>> > >>>>>>> My suggestion would be to leave this feature in. It will not > cost > >>>>>>> much to make room in the protocol for the TVBD to indicate to > the > >>>>>>> database which channel it decided to operate on and it would > >>>>>>> provide easy extensibility to the protocol for an eventual > >>>>>>> consideration of the coexistence amongst the license-exempt > >>>>>>>devices. > >>>>>>> > >>>>>>> I would agree, however, that the current step of the protocol > >>>>>>> development should be limited to protecting of the broadcast > >>>>>>> incumbents as stated in the scope. > >>>>>>> > >>>>>>> Gerald > >>>>>>> > >>>>>>> > >>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: > >>>>>>>> So do these use cases in the accepted working group document > need > >>>>>>>> to be modified, then? > >>>>>>>> > >>>>>>>> -Pete > >>>>>>>> > >>>>>>>> Rosen, Brian wrote: > >>>>>>>>> It's beyond the charter. This was discussed when we created > the > >>>>>>>>> charter, and explicitly excluded it for this initial work. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: > >>>>>>>>> > >>>>>>>>>> However, the location-based services use case clearly has > the > >>>>>>>>>> white space database keeping state on the secondary user, at > >>>>>>>>>> least his location. Step 7 of the Hotspot use case has the > >>>>>>>>>> BS registering the spectrum that it selected for its use. If > >>>>>>>>>> the database is keeping state in this manner, it could > easily > >>>>>>>>>> calculate the exclusion zones for the secondary users as > well. > >>>>>>>>>> > >>>>>>>>>> Or did these use cases as described exceed the mandate of > the > >>>>>>>>>> charter? > >>>>>>>>>> > >>>>>>>>>> -Pete > >>>>>>>>>> > >>>>>>>>>> Rosen, Brian wrote: > >>>>>>>>>>> Yes, you are mistaken. > >>>>>>>>>>> > >>>>>>>>>>> If two queriers with the same location and input parameters > >>>>>>>>>>> query the database, they will get the same response. > Suppose > >>>>>>>>>>> two U.S. Mode I devices at essentially the same location > >>>>>>>>>>> (within 25 meters) query the database, and the first is > told he > >>>>>>>>>>> may use TV channels 1-5, 9-11 and 25-33. The second one > will > >>>>>>>>>>> be told the same thing. > >>>>>>>>>>> > >>>>>>>>>>> The database knows query patterns, but does not track use. > >>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the > >>>>>>>>>>> device actually chooses to use, when it starts using it, > and > >>>>>>>>>>> when it ceases to use it. > >>>>>>>>>>> > >>>>>>>>>>> Brian > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Based on some of the existing use cases, it looks like the > >>>>>>>>>>>> database is keeping state even for the secondary users. > >>>>>>>>>>>> That is, it is acting as a de-facto registry for users of > >>>>>>>>>>>> the secondary spectrum and will refuse to allocate the > same > >>>>>>>>>>>> spectrum to different users in overlapping geographic > >>>>>>>>>>>> regions. Am I > >>>>>> mistaken in > >>>>>>>> this assumption? > >>>>>>>>>>>> > >>>>>>>>>>>> -Pete > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Joel M. Halpern wrote: > >>>>>>>>>>>>> I may be missing something, but it seems to me taht what > you > >>>>>>>>>>>>> are describing is not the job of the database query > protocol. > >>>>>>>>>>>>> base station coordination is an interesting problem, but > is > >>>>>>>>>>>>> it within scope for this WG? (I do not think just > specifying > >>>>>>>>>>>>> the same owner to the database will resolve the problem, > and > >>>>>>>>>>>>> it makes the database state MUCH more complex.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yours, > >>>>>>>>>>>>> Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his > third > >>>>>>>>>>>>>> use case, and I think it would be a possible candidate > for > >>>>>>>>>>>>>> inclusion in the document if it were properly explained. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS > >>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum > that > >>>>>>>>>>>>>> is available over a wide area that can be used by > multiple > >>>>>>>>>>>>>> master BSs to simultaneously broadcast the same signal > to a > >>>>>>>>>>>>>> set of receivers. This is somewhat similar to the wide- > area > >>>>>>>>>>>>>> rural coverage scenario currently described in the > working > >>>>>>>>>>>>>> group document; however, there would be multiple Master > BSs, > >>>>>>>>>>>>>> each of which would independently query the WSDB for > >>>>>>>>>>>>>> available spectrum. However, they need to coordinate the > >>>>>>>>>>>>>> assignment so that they all get the same spectrum over > the > >>>>>>>>>>>>>> whole area. As an implementation example, this could be > >>>>>>>>>>>>>> achieved by each BS reporting the same owner/operator > and > >>>>>>>>>>>>>> using a key or index value to indicate that they wanted > to > >>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be > able > >>>>>>>>>>>>>> to elect one > >>>> BS > >>>>>> as the > >>>>>>>>>>>>>> leader and collect location information from all the > >>>>>>>>>>>>>> other BSs and then coordinate the assignment similar to > >>>>>>>>>>>>>> the use case in 4.2; the difference would be that the > >>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use > by > >>>>>>>>>>>>>> all of the BSs covering the wider area. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Does this sound like an interesting and novel use case? > >>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII > >>>>>>>>>>>>>> art for the draft. > > > >_______________________________________________ > >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 stpeter@stpeter.im Wed Sep 14 13:21: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 4C9BC21F8481 for ; Wed, 14 Sep 2011 13:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 S4VCdinR9PjY for ; Wed, 14 Sep 2011 13:21:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB66021F848A for ; Wed, 14 Sep 2011 13:21:21 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4533D41961; Wed, 14 Sep 2011 14:26:48 -0600 (MDT) Message-ID: <4E710D42.8090508@stpeter.im> Date: Wed, 14 Sep 2011 14:23:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Peter McCann References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A45C@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:21:28 -0000 On 9/14/11 2:10 PM, Peter McCann wrote: > Any such requirement has been ruled out of scope by the chair. Hi, this is your Area Director. I'd like to clarify one point. It's not that the chairs can rule things in and out of scope on a whim. Their decisions need to be based on the charter, which is the fundamental contract between this working group and the broader IETF community (represented by the IESG). There was quite a bit of discussion within the IETF and the IESG about this working group as it was being formed. As a result of those discussions, the charter is rather narrowly scoped. This is intentional. The focus of this working group should be on the items defined in the charter. That doesn't mean working group participants can't talk about other topics, but as your Area Director I would like to see progress on the core deliverables before the group starts to work on additional use cases, extensions, etc. Naturally, it might be reasonable to design extension points into the protocol, so the group might want to take additional use cases into account as examples of where extension points might be needed, but those extensions themselves should not not the focus at this time. Peter -- Peter Saint-Andre https://stpeter.im/ From Peter.McCann@huawei.com Wed Sep 14 13:36: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 8E9B321F87FC for ; Wed, 14 Sep 2011 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 OQ0OCujSQoLn for ; Wed, 14 Sep 2011 13:36:41 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1461021F87D9 for ; Wed, 14 Sep 2011 13:36:41 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00KLP5CQVB@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:38:50 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00CNV5CL3X@usaga04-in.huawei.com> for paws@ietf.org; Wed, 14 Sep 2011 15:38:50 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 13:38:49 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.37]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 13:38:48 -0700 Date: Wed, 14 Sep 2011 20:38:48 +0000 From: Peter McCann In-reply-to: <4E710D42.8090508@stpeter.im> X-Originating-IP: [10.193.125.70] To: Peter Saint-Andre Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE71596A4C3@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [paws] Possible new use case: simulcasting Thread-index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAh2b+AAAagmvAADyxVAAAOna2Q//+PKQD//59BXoAAee4AgAAFyYCAAAalAIAAavvg///CkACAAGoRMP//rqcAAA5bRRAADctJAAAqLx5gAEU56wAAmMLIAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A45C@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.com> <4E710D42.8090508@stpeter.im> Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:36:41 -0000 Peter Saint-Andre wrote: > On 9/14/11 2:10 PM, Peter McCann wrote: >> Any such requirement has been ruled out of scope by the chair. > > Hi, this is your Area Director. I'd like to clarify one point. It's not > that the chairs can rule things in and out of scope on a whim. Their > decisions need to be based on the charter, which is the fundamental > contract between this working group and the broader IETF community > (represented by the IESG). There was quite a bit of discussion within > the IETF and the IESG about this working group as it was being formed. > As a result of those discussions, the charter is rather narrowly scoped. > This is intentional. The focus of this working group should be on the > items defined in the charter. That doesn't mean working group > participants can't talk about other topics, but as your Area Director I > would like to see progress on the core deliverables before the group > starts to work on additional use cases, extensions, etc. Naturally, it > might be reasonable to design extension points into the protocol, so the > group might want to take additional use cases into account as examples > of where extension points might be needed, but those extensions > themselves should not not the focus at this time. When you say we "might want to take additional use cases into account" does that mean we might want to include them in the current use cases draft? I am asking because I was told by some working group members that a use case I proposed was outside the scope of the charter and therefore should not be included in the use cases draft. If we are going to exclude out-of-scope use cases in the working group draft then there is a lot in there now that needs to be removed. -Pete From Basavaraj.Patil@nokia.com Wed Sep 14 13:42:50 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 34A4121F8A6C for ; Wed, 14 Sep 2011 13:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 CoVdCHuUsULC for ; Wed, 14 Sep 2011 13:42:49 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C7F0521F8A57 for ; Wed, 14 Sep 2011 13:42:48 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EKinWE031323; Wed, 14 Sep 2011 23:44:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 23:44:48 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 22:44:47 +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; Wed, 14 Sep 2011 22:44:47 +0200 From: To: , , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AQHMcuv8lyb5o88QQp+2liyoyRWRkJVM1WcAgAAFyoD//7LRAIAAX3oA///OEACAAF+sgP//uSyAAA8D7XD//5avAA== Date: Wed, 14 Sep 2011 20:44:46 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0141C15B733@SC-VEXCH2.marvell.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: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 20:44:48.0052 (UTC) FILETIME=[24810F40:01CC731F] X-Nokia-AV: Clean Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 20:42:50 -0000 Hi Paul, Yes. It is an extra message. Is it unnecessary? That depends on your PoV. Is it a significant overhead? I do not believe that would be the case either. Having said that I do agree that an UPDATE message will need to be carefully designed. This could be done at a later time as well and does not impede the current design of the protocol. So unless a requirement for such pops up, I am fine with not including such functionality at this time. -Raj On 9/14/11 3:19 PM, "ext Paul Lambert" wrote: >Raj, > On the indication of selected channels: >>=20 >> IMO we don't need to be concerned about whether the database is keeping >> state. >> Its upto the database. I agree that the text should not say anything >> about >> what the database does if the Master WS device informs the database >> which >> of the available channels were selected for use/operation. >>=20 >> There is no reason for the WS device to not send an acknowledgement >> back to the database indicating which channels (from the list) are >> being used. > >I disagree. There are many reasons to not send the selected channel(s) >back to the database: >1) it's an extra unnecessary message >2) it's not useful unless any updates in usage are also sent > the devices are likely to change channels, modulation, etc dynamically > within the allowed parameters >3) the entity getting this coordination information is not > necessarily the same as the database. Local spectrum coordination > is a different function than regulatory spectrum access. > If we want coordination - we should do it right >4) the usage of such fields are out-of-scope, so why include them > If there is no supporting text on usage. > >Paul >>=20 >> What the database does with this information is outside the scope of >> the protocol itself. >>=20 >> -Raj >>=20 >> On 9/14/11 2:05 PM, "ext Peter McCann" wrote: >>=20 >> >Hi, Scott, >> > >> >The text says "the database is updated." That wording is at least >> >confusing. It also says "the database replies with the location of >> >the master device". Both of these imply that some state on a per- >> master >> >basis is being kept in the database. >> > >> >We need to get clarity within the working group whether the database >> >can keep state about the devices that query it or whether it is >> designed >> >to be a completely passive repository of information. >> > >> >-Pete >> > >> > >> >scott.probasco@nokia.com wrote: >> >> Hi Pete, >> >> >> >> Allowing PAWS to carry information back to the database as in 4.2 & >> >> 4.3 is just a transport. We don't have to think about what the >> >> database does with that. While FCC may not have regulations today >> >> which require this type of transport, IMHO it is premature to assume >> >> that no regulator in the world will have such need. >> >> >> >> Similarly for location-based service use case, the only issue from >> >> PAWS perspective is some message which allows a query of the >> database, >> >> based on master identity. In addition to the location based service >> >> use case already included in the I-D, another example is >> >> identification of a Master who is causing interference. FCC does >> >> envision something very similar, though not precisely same, to this >> >> scenario for determination of interference. >> >> >> >> Thus I believe these use cases are useful and reasonable. >> >> >> >> Regards, >> >> Scott >> >> >> >> >> >> >> >> On 9/14/11 11:22 AM, "ext Peter McCann" >> wrote: >> >> >> >>> Hi, Scott, >> >>> >> >>> The problem is when I see text like this in section 4.2 and 4.3: >> >>> >> >>> 7. The master/AP acknowledges to the database which of the >> >> available >> >>> WS channels it has selected for its operation. The database >> is >> >>> updated with the information provided by the master/AP. >> >>> it makes me think that the database is tracking the use of spectrum >> >>> by the whitespace master devices. When it says "database is >> updated" >> >>> that makes me think that the database of exclusion zones is updated >> >>> in a way that will impact the results of future queries. >> >>> >> >>> There is also the location-based service use case where the >> database is >> >>> keeping state about the whitespace master device, namely its >> location: >> >>> >> >>> 3. The server queries the trusted white space database with the >> >>> master identity provided by the application in the user's >> >>> smartphone. >> >>> 4. The trusted white space database replies to the server with >> the >> >>> location of the master device. >> >>> If the database is to be truly stateless and passive with respect >> to >> >>> queries by whitespace devices, these kinds of statements should be >> >>> removed from the use cases. >> >>> >> >>> -Pete >> >>> >> >>> >> >>> scott.probasco@nokia.com wrote: >> >>>> Hi, >> >>>> >> >>>> One of the key aspects of this protocol between device and >> database is >> >>>> extensibility. The charter does recognize that the contents of the >> >>>> database is defined external to PAWS. Thus hard to say that any >> single >> >>>> specific value or information element is beyond the scope. >> >>>> >> >>>> Also the charter allows for queries and responses, there is no >> >>>> restriction that single transactions are mandated. >> >>>> >> >>>> So IMHO the use cases already approved are still valid, no reasons >> to >> >>>> exclude pieces. >> >>>> >> >>>> Regards, >> >>>> Scott >> >>>> >> >>>> >> >>>> >> >>>> On 9/14/11 10:16 AM, "ext Gerald Chouinard" >> >> >>>> wrote: >> >>>> >> >>>>> Brian, >> >>>>> >> >>>>> Agreed. A single transaction, to the DB and back to the TVBD, >> would >> >>>>> be sufficient if the protocol is to be kept simple. Coexistence >> >>>>> amongst the license-exempt devices would then be left to other >> >>>>> processes such as the one being developed by the IEEE 802.19.1. >> >>>>> >> >>>>> Gerald >> >>>>> >> >>>>> >> >>>>> At 10:55 14-09-11 -0400, Rosen, Brian wrote: >> >>>>>> The problem is that this turns the transaction into multiple >> steps. >> >>>>>> As it is now, you send a query and get a response. >> >>>>>> >> >>>>>> If the device needs to update with what it used, that's another >> >>>>>> step. Also, what happens if it changes its mind? >> >>>>>> >> >>>>>> Brian >> >>>>>> >> >>>>>> On Sep 14, 2011, at 10:38 AM, Gerald Chouinard wrote: >> >>>>>> >> >>>>>>> Peter, Brian, >> >>>>>>> >> >>>>>>> My suggestion would be to leave this feature in. It will not >> cost >> >>>>>>> much to make room in the protocol for the TVBD to indicate to >> the >> >>>>>>> database which channel it decided to operate on and it would >> >>>>>>> provide easy extensibility to the protocol for an eventual >> >>>>>>> consideration of the coexistence amongst the license-exempt >> >>>>>>>devices. >> >>>>>>> >> >>>>>>> I would agree, however, that the current step of the protocol >> >>>>>>> development should be limited to protecting of the broadcast >> >>>>>>> incumbents as stated in the scope. >> >>>>>>> >> >>>>>>> Gerald >> >>>>>>> >> >>>>>>> >> >>>>>>> At 13:26 14-09-11 +0000, Peter McCann wrote: >> >>>>>>>> So do these use cases in the accepted working group document >> need >> >>>>>>>> to be modified, then? >> >>>>>>>> >> >>>>>>>> -Pete >> >>>>>>>> >> >>>>>>>> Rosen, Brian wrote: >> >>>>>>>>> It's beyond the charter. This was discussed when we created >> the >> >>>>>>>>> charter, and explicitly excluded it for this initial work. >> >>>>>>>>> >> >>>>>>>>> Brian >> >>>>>>>>> >> >>>>>>>>> On Sep 14, 2011, at 9:18 AM, Peter McCann wrote: >> >>>>>>>>> >> >>>>>>>>>> However, the location-based services use case clearly has >> the >> >>>>>>>>>> white space database keeping state on the secondary user, at >> >>>>>>>>>> least his location. Step 7 of the Hotspot use case has the >> >>>>>>>>>> BS registering the spectrum that it selected for its use. If >> >>>>>>>>>> the database is keeping state in this manner, it could >> easily >> >>>>>>>>>> calculate the exclusion zones for the secondary users as >> well. >> >>>>>>>>>> >> >>>>>>>>>> Or did these use cases as described exceed the mandate of >> the >> >>>>>>>>>> charter? >> >>>>>>>>>> >> >>>>>>>>>> -Pete >> >>>>>>>>>> >> >>>>>>>>>> Rosen, Brian wrote: >> >>>>>>>>>>> Yes, you are mistaken. >> >>>>>>>>>>> >> >>>>>>>>>>> If two queriers with the same location and input parameters >> >>>>>>>>>>> query the database, they will get the same response. >> Suppose >> >>>>>>>>>>> two U.S. Mode I devices at essentially the same location >> >>>>>>>>>>> (within 25 meters) query the database, and the first is >> told he >> >>>>>>>>>>> may use TV channels 1-5, 9-11 and 25-33. The second one >> will >> >>>>>>>>>>> be told the same thing. >> >>>>>>>>>>> >> >>>>>>>>>>> The database knows query patterns, but does not track use. >> >>>>>>>>>>> Specifically, it doesn't know what part of the spectrum the >> >>>>>>>>>>> device actually chooses to use, when it starts using it, >> and >> >>>>>>>>>>> when it ceases to use it. >> >>>>>>>>>>> >> >>>>>>>>>>> Brian >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Sep 14, 2011, at 8:58 AM, Peter McCann wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Based on some of the existing use cases, it looks like the >> >>>>>>>>>>>> database is keeping state even for the secondary users. >> >>>>>>>>>>>> That is, it is acting as a de-facto registry for users of >> >>>>>>>>>>>> the secondary spectrum and will refuse to allocate the >> same >> >>>>>>>>>>>> spectrum to different users in overlapping geographic >> >>>>>>>>>>>> regions. Am I >> >>>>>> mistaken in >> >>>>>>>> this assumption? >> >>>>>>>>>>>> >> >>>>>>>>>>>> -Pete >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Joel M. Halpern wrote: >> >>>>>>>>>>>>> I may be missing something, but it seems to me taht what >> you >> >>>>>>>>>>>>> are describing is not the job of the database query >> protocol. >> >>>>>>>>>>>>> base station coordination is an interesting problem, but >> is >> >>>>>>>>>>>>> it within scope for this WG? (I do not think just >> specifying >> >>>>>>>>>>>>> the same owner to the database will resolve the problem, >> and >> >>>>>>>>>>>>> it makes the database state MUCH more complex.) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Yours, >> >>>>>>>>>>>>> Joel >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On 9/13/2011 1:37 PM, Peter McCann wrote: >> >>>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I've been interacting with Zhu Lei off-list about his >> third >> >>>>>>>>>>>>>> use case, and I think it would be a possible candidate >> for >> >>>>>>>>>>>>>> inclusion in the document if it were properly explained. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Generally (as opposed to specifically for the LTE MBMS >> >>>>>>>>>>>>>> case), the problem is to find a common bit of spectrum >> that >> >>>>>>>>>>>>>> is available over a wide area that can be used by >> multiple >> >>>>>>>>>>>>>> master BSs to simultaneously broadcast the same signal >> to a >> >>>>>>>>>>>>>> set of receivers. This is somewhat similar to the wide- >> area >> >>>>>>>>>>>>>> rural coverage scenario currently described in the >> working >> >>>>>>>>>>>>>> group document; however, there would be multiple Master >> BSs, >> >>>>>>>>>>>>>> each of which would independently query the WSDB for >> >>>>>>>>>>>>>> available spectrum. However, they need to coordinate the >> >>>>>>>>>>>>>> assignment so that they all get the same spectrum over >> the >> >>>>>>>>>>>>>> whole area. As an implementation example, this could be >> >>>>>>>>>>>>>> achieved by each BS reporting the same owner/operator >> and >> >>>>>>>>>>>>>> using a key or index value to indicate that they wanted >> to >> >>>>>>>>>>>>>> coordinate the assignment. Alternatively, you might be >> able >> >>>>>>>>>>>>>> to elect one >> >>>> BS >> >>>>>> as the >> >>>>>>>>>>>>>> leader and collect location information from all the >> >>>>>>>>>>>>>> other BSs and then coordinate the assignment similar to >> >>>>>>>>>>>>>> the use case in 4.2; the difference would be that the >> >>>>>>>>>>>>>> resulting assignment is for simultaneous (not TDD) use >> by >> >>>>>>>>>>>>>> all of the BSs covering the wider area. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Does this sound like an interesting and novel use case? >> >>>>>>>>>>>>>> If so I can do a more detailed writeup and supply ASCII >> >>>>>>>>>>>>>> art for the draft. >> > >> >_______________________________________________ >> >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 stpeter@stpeter.im Wed Sep 14 15:03:42 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 1357121F8D8B for ; Wed, 14 Sep 2011 15:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 9nS6oZVqyIoA for ; Wed, 14 Sep 2011 15:03:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6821F8D80 for ; Wed, 14 Sep 2011 15:03:41 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 30CAF418BB; Wed, 14 Sep 2011 16:09:08 -0600 (MDT) Message-ID: <4E71253E.3010409@stpeter.im> Date: Wed, 14 Sep 2011 16:05:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Peter McCann References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A45C@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A46D@dfweml503-mbx.china.huawei.com> <4E710D42.8090508@stpeter.im> <5963DDF1F751474D8DEEFDCDBEE43AE71596A4C3@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A4C3@dfweml503-mbx.china.huawei.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] Possible new use case: simulcasting 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, 14 Sep 2011 22:03:42 -0000 On 9/14/11 2:38 PM, Peter McCann wrote: > > Peter Saint-Andre wrote: >> On 9/14/11 2:10 PM, Peter McCann wrote: >>> Any such requirement has been ruled out of scope by the chair. >> >> Hi, this is your Area Director. I'd like to clarify one point. It's not >> that the chairs can rule things in and out of scope on a whim. Their >> decisions need to be based on the charter, which is the fundamental >> contract between this working group and the broader IETF community >> (represented by the IESG). There was quite a bit of discussion within >> the IETF and the IESG about this working group as it was being formed. >> As a result of those discussions, the charter is rather narrowly scoped. >> This is intentional. The focus of this working group should be on the >> items defined in the charter. That doesn't mean working group >> participants can't talk about other topics, but as your Area Director I >> would like to see progress on the core deliverables before the group >> starts to work on additional use cases, extensions, etc. Naturally, it >> might be reasonable to design extension points into the protocol, so the >> group might want to take additional use cases into account as examples >> of where extension points might be needed, but those extensions >> themselves should not not the focus at this time. > > When you say we "might want to take additional use cases into account" > does that mean we might want to include them in the current use cases > draft? I am asking because I was told by some working group members > that a use case I proposed was outside the scope of the charter and > therefore should not be included in the use cases draft. > > If we are going to exclude out-of-scope use cases in the working > group draft then there is a lot in there now that needs to be removed. As your Area Director, I would rather see the current use cases and requirements document focus on addressing the goals of the charter. (Naturally, it would be appropriate for that document to explain why the scope is so sharply limited at this time. You might be able to borrow some wording from RFC 6125 on the topic of limited scope.) Peter -- Peter Saint-Andre https://stpeter.im/ From peter@spectrumbridge.com Thu Sep 15 08:10: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 227F821F8672 for ; Thu, 15 Sep 2011 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_20=-0.74] 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 nLh1Dc5x2rVF for ; Thu, 15 Sep 2011 08:10:07 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 773D121F8549 for ; Thu, 15 Sep 2011 08:09:53 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 15 Sep 2011 11:13:35 -0400 From: Peter Stanforth To: "paws@ietf.org" Date: Thu, 15 Sep 2011 11:12:03 -0400 Thread-Topic: [paws] comments on Draft Use Cases Thread-Index: AcxzugmcbpD2OMUuR4iJH2KdxnyKBw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] comments on Draft Use Cases 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, 15 Sep 2011 15:10:08 -0000 I have a number of comments on the use cases proposed in the draft. First the location based service seems too specific to an advertising model as opposed to a more generic case of an edge device (slave) requesting the location information about a serving master device from the DB. There may well be other reasons for the slave to request information about the master. One instance I can think of is to determine who owns the master (registration information) it may be that the slave only trusts certain masters or has a cost basis to chose one available master over Another. Second. The whole concept is predicated on an ability to provide access to spectrum into the future. I believe that much spectrum (owned by emergency services, defense agencies and others) will not be made available without an ability to withdraw the permission should a predefined emergency situation emerge. There are several ways to address this requirement but I think a use case that considers such a scenario is required. Third, Access to spectrum, as a licensed or unlicensed device, may require payment. It seems highly likely that government agencies (spectrum holders) will need to be persuaded to make spectrum available. This may be in the form of the Agency/holder getting some compensation for the use of the spectrum. This would require that use of the spectrum be tracked such that some backend billing or clearing house system could deal with payments. Fourth, The concept of mobility is not described. Mobility could be addressed by providing a vector or an area to the DB which would result in a set of available channels being delivered. Finally there is no "White Space" only shades of grey. So I think it is important to consider that not all spectrum is equal and that the DB may have to provide some weighting or other Criteria to describe suitability of the available channels for use. Note that this is unrelated to any Co-existence criteria. Regards, Peter Stanforth > From budden@nps.edu Fri Sep 16 09:01: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 01E1921F8C8E for ; Fri, 16 Sep 2011 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=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 VJidV+oNh+wA for ; Fri, 16 Sep 2011 09:01:01 -0700 (PDT) Received: from diamond.nps.edu (diamond.nps.edu [205.155.65.226]) by ietfa.amsl.com (Postfix) with ESMTP id 103CE21F8C7E for ; Fri, 16 Sep 2011 09:01:01 -0700 (PDT) Received: from virginia.nps.edu ([205.155.65.15]) by diamond.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 09:03:13 -0700 Received: from SKYTRAIN.ern.nps.edu ([172.20.24.112]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 09:03:13 -0700 Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 16 Sep 2011 09:03:13 -0700 From: Rex Buddenberg To: Content-Type: text/plain; charset="UTF-8" Date: Fri, 16 Sep 2011 09:02:56 -0700 Message-ID: <1316188976.2243.1.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2011 16:03:13.0511 (UTC) FILETIME=[23662F70:01CC748A] Subject: [paws] fcc test news release, for info 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, 16 Sep 2011 16:01:02 -0000 2. FCC CHAIRMAN GENACHOWSKI ANNOUNCES PUBLIC TESTING OF FIRST TELEVISION WHITE SPACES DATABASE. FCC's Office of Engineering and Technology Issues Public Notice to Start Public Testing for Spectrum Bridge's TV White Spaces Database System. News Release. News Media Contact: Neil Grace at (202) 418-0506, email: Neil.Grace@fcc.gov OCHJG http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-309608A1.doc http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-309608A1.pdf http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-309608A1.txt 3. OFFICE OF ENGINEERING AND TECHNOLOGY ANNOUNCES THE OPENING OF PUBLIC TESTING FOR SPECTRUM BRIDGE'S TV BAND DATABASE SYSTEM. (DA No. 11-1534). (Dkt No 04-186 ). OET . Contact: Alan Stillwell at (202) 418-2470 or Hugh L. VanTuyl at (202) 418-7506. News Media Contact: Bruce Romano at (202) 418-2470 http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11-1534A1.doc http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11-1534A1.pdf http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11-1534A1.txt From scott.probasco@nokia.com Thu Sep 22 11:59: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 8CDF021F8BD7 for ; Thu, 22 Sep 2011 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 97EpLgcm9gyM for ; Thu, 22 Sep 2011 11:59:14 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D573521F8BA0 for ; Thu, 22 Sep 2011 11:59:13 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8MJ1iAP023208; Thu, 22 Sep 2011 22:01:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 22:01:39 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 22 Sep 2011 21:01:37 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Thu, 22 Sep 2011 21:01:37 +0200 From: To: , Thread-Topic: [paws] comments on Draft Use Cases Thread-Index: AQHMc7nmpkdL/z9qBk29Dj0TVJiaYJVZV08A Date: Thu, 22 Sep 2011 19:01:36 +0000 Message-ID: In-Reply-To: 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: 22 Sep 2011 19:01:39.0713 (UTC) FILETIME=[0F457710:01CC795A] X-Nokia-AV: Clean Subject: Re: [paws] comments on Draft Use Cases 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, 22 Sep 2011 18:59:14 -0000 Hi Peter, Good comments. Reviewing them one by one... First. We will re-write the location based service use case to be a generic "regulatory requirement" use case, focusing on the registration information as you suggest. Second. Ability to withdraw permission is essentially same as the "kill switch" described by Ofcom in their "Implementing Geolocation" document. We proposed to add this either as a separate use case or included it to an existing use case. Third. We generally agree with the principle and would like to include the capability. Probably the question will be asked if this is in scope. We would like to identify a regulator who has indicated a need or desire for this. Fourth. We will include a new use case for mobility, FCC has already identified this as a valid use case. Regards, Scott & Raj On 9/15/11 10:12 AM, "ext Peter Stanforth" wrote: >I have a number of comments on the use cases proposed in the draft. > >First the location based service seems too specific to an advertising >model as opposed to a more generic case of an edge device (slave) >requesting the location information about a serving master device from the >DB. There may well be other reasons for the slave to request information >about the master. One instance I can think of is to determine who owns the >master (registration information) it may be that the slave only trusts >certain masters or has a cost basis to chose one available master over >Another. > >Second. The whole concept is predicated on an ability to provide access to >spectrum into the future. I believe that much spectrum (owned by emergency >services, defense agencies and others) will not be made available without >an ability to withdraw the permission should a predefined emergency >situation emerge. There are several ways to address this requirement but I >think >a use case that considers such a scenario is required. > >Third, Access to spectrum, as a licensed or unlicensed device, may require >payment. It seems highly likely that government agencies (spectrum >holders) will need to be >persuaded to make spectrum available. This may be in the form of the >Agency/holder getting some compensation for the use of the spectrum. This >would >require that use of the spectrum be tracked such that some backend billing >or clearing house system could deal with payments. > >Fourth, The concept of mobility is not described. Mobility could be >addressed by providing a vector or an area to the DB which would result in >a set of available channels being delivered. > >Finally there is no "White Space" only shades of grey. So I think it is >important to consider >that not all spectrum is equal and that the DB may have to provide some >weighting or other >Criteria to describe suitability of the available channels for use. Note >that this is unrelated >to any Co-existence criteria. >Regards, >Peter Stanforth > > > > >> > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Thu Sep 22 15:57: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 DF23E11E80C7 for ; Thu, 22 Sep 2011 15:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.875, 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 KaDgqAqEqnyl for ; Thu, 22 Sep 2011 15:57:08 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4F811E8098 for ; Thu, 22 Sep 2011 15:57:07 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 22 Sep 2011 19:01:27 -0400 From: Peter Stanforth To: "scott.probasco@nokia.com" , "paws@ietf.org" Date: Thu, 22 Sep 2011 18:59:36 -0400 Thread-Topic: [paws] comments on Draft Use Cases Thread-Index: Acx5e47lIk/aD7LZQTyIliGF7cMdiw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] comments on Draft Use Cases 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, 22 Sep 2011 22:57:09 -0000 Thanks Scott Your suggestions sound good to me. The third suggestion came from conversations we have had with government agencies, it is not part of any current White Space regulation. The politicians and the bureaucrats both suggested that the way that government spectrum would be made available on a secondary basis (similar to white space) would be if the agency got compensated for it's use. Peter S. On ThuSep/22/11 Thu Sep 22, 3:01 PM, "scott.probasco@nokia.com" wrote: > >Hi Peter, > >Good comments. Reviewing them one by one... > >First. We will re-write the location based service use case to be a >generic "regulatory requirement" use case, focusing on the registration >information as you suggest. > >Second. Ability to withdraw permission is essentially same as the "kill >switch" described by Ofcom in their "Implementing Geolocation" document. >We proposed to add this either as a separate use case or included it to an >existing use case. > >Third. We generally agree with the principle and would like to include the >capability. Probably the question will be asked if this is in scope. We >would like to identify a regulator who has indicated a need or desire for >this. > >Fourth. We will include a new use case for mobility, FCC has already >identified this as a valid use case. > >Regards, >Scott & Raj > > > >On 9/15/11 10:12 AM, "ext Peter Stanforth" >wrote: > >>I have a number of comments on the use cases proposed in the draft. >> >>First the location based service seems too specific to an advertising >>model as opposed to a more generic case of an edge device (slave) >>requesting the location information about a serving master device from >>the >>DB. There may well be other reasons for the slave to request information >>about the master. One instance I can think of is to determine who owns >>the >>master (registration information) it may be that the slave only trusts >>certain masters or has a cost basis to chose one available master over >>Another. >> >>Second. The whole concept is predicated on an ability to provide access >>to >>spectrum into the future. I believe that much spectrum (owned by >>emergency >>services, defense agencies and others) will not be made available without >>an ability to withdraw the permission should a predefined emergency >>situation emerge. There are several ways to address this requirement but >>I >>think >>a use case that considers such a scenario is required. >> >>Third, Access to spectrum, as a licensed or unlicensed device, may >>require >>payment. It seems highly likely that government agencies (spectrum >>holders) will need to be >>persuaded to make spectrum available. This may be in the form of the >>Agency/holder getting some compensation for the use of the spectrum. This >>would >>require that use of the spectrum be tracked such that some backend >>billing >>or clearing house system could deal with payments. >> >>Fourth, The concept of mobility is not described. Mobility could be >>addressed by providing a vector or an area to the DB which would result >>in >>a set of available channels being delivered. >> >>Finally there is no "White Space" only shades of grey. So I think it is >>important to consider >>that not all spectrum is equal and that the DB may have to provide some >>weighting or other >>Criteria to describe suitability of the available channels for use. Note >>that this is unrelated >>to any Co-existence criteria. >>Regards, >>Peter Stanforth >> >> >> >> >>> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > From mksaji@yahoo.com Tue Sep 27 06:50:05 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 ABEA521F8CCB for ; Tue, 27 Sep 2011 06:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.008 X-Spam-Level: *** X-Spam-Status: No, score=3.008 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_60=1, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=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 CQ0LM5niDzUO for ; Tue, 27 Sep 2011 06:50:05 -0700 (PDT) Received: from nm21-vm2.bullet.mail.ne1.yahoo.com (nm21-vm2.bullet.mail.ne1.yahoo.com [98.138.91.209]) by ietfa.amsl.com (Postfix) with SMTP id DDAEF21F8CE1 for ; Tue, 27 Sep 2011 06:50:04 -0700 (PDT) Received: from [98.138.90.53] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2011 13:52:49 -0000 Received: from [98.138.89.160] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2011 13:52:49 -0000 Received: from [127.0.0.1] by omp1016.mail.ne1.yahoo.com with NNFMP; 27 Sep 2011 13:52:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 540296.23865.bm@omp1016.mail.ne1.yahoo.com Received: (qmail 16455 invoked by uid 60001); 27 Sep 2011 13:52:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317131569; bh=vTzBJUFhJR+YqJCV15F/R+F46D/3yMTLOIWo8bz7TmQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Y7baJ5UpYRzxBrh+WrZLJH7fVYRh94qdHWSp4dHlrOJPojhSXAGzNSbkCITDrX31NUOyejOPuC9NOzq1KE5wPNMkFRwfh+xbyTWEd9J3H5UwxwkaUlbnwfLHc01yLRCMRW3BIfqVfOJEKfHSse9th2Ny8MgOasRLT9Tuo7lYMu0= 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:Reply-To:Subject:To:MIME-Version:Content-Type; b=m4E2KUxf8FyGQlvRRPcSXOsd0tnHr7lzrgcMqlc8ob49sbiQFYwK8z6munXPTVlV51tuI1Vgs3Fjsl35xpzbhlczjMer8tdXunTj5AxvDD9PCstxR/MZdDljXx2Vp/w9woaCCxODqDCGhZVEqJgZj0JMFIef9zEFeCmnrAo2Olo=; X-YMail-OSG: ncs9T_4VM1nUoKw62CI5NP77c8V8ojiwb5nVKV08IoPJMY3 NLUizpxQO_04LMjd5Gw4mYq_GEukZzNRmOY2LobW7nmPEoCGe_WDAS4wUPH7 5niMARpm0EAgtI03VVHgVduPGWyVuvq0niOt.s2f_abU4_R_s7nZrx0yC1uo wzP1XOPttuqzWWo5j79N4GXatgV537nh_wvpM1mjkIG4Y_UPz8VjcZwx9heY tiHLEQBk4_DemmzUlm2HiFyDxwPmBT17m6E99QC_Hcnxjqufxd.6Q9Mpv9mu 2cTwVqiJt8PWrg.KmfTO2FlAOR2bDVbH2naUBqRVVN9arTZvq3FBNrrpUDTw nviTyyGluaJIW.KTBFH_esJOtK1KzF_hJK0wytUBmAMCZPwESXZLRG6Idscs CH.JgFzOAAIA_Z34ZbYj94A_8epCIM8ANHcopJDeYKwzii.xTfvyuGV2Erkn UpWiJCShCPJ2t0tNuflpvld4K5T_1KvUO.LaO.coE84vgnXcitb.rFYoY9Hm 3yvNJNGmTK9l_EDMKlogw8pI- Received: from [117.192.24.163] by web36704.mail.mud.yahoo.com via HTTP; Tue, 27 Sep 2011 06:52:49 PDT X-Mailer: YahooMailWebService/0.8.114.317681 Message-ID: <1317131569.94273.YahooMailNeo@web36704.mail.mud.yahoo.com> Date: Tue, 27 Sep 2011 06:52:49 -0700 (PDT) From: "M.K.Sajeev sajeev" To: "paws@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2114655128-1796400575-1317131569=:94273" Subject: [paws] Whitespace radio prototyping X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "M.K.Sajeev sajeev" List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:50:05 -0000 ---2114655128-1796400575-1317131569=:94273 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AIs there any White space radio/WS database protocol proto typing o= r testing activities happening in UK or India? It will be great to know the= details if any, as I am interested in involving such projects.=A0=0A=A0=0A= Best Regards,=0ASajeev Manikkoth=0A=0AMobile: +919663311378=0AEmail: mksaji= @ieee.org=0Ahttp://www.linkedin.com/in/mksajeev ---2114655128-1796400575-1317131569=:94273 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

Is there any White space radio/WS da= tabase protocol proto typing or testing activities happening in UK or India= ? It will be great to know the details if any, as I am interested in involv= ing such projects. 
 
Best Regards,
Sajeev Manikko= th
Mobile: +919663311378
Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

---2114655128-1796400575-1317131569=:94273-- From peter@spectrumbridge.com Tue Sep 27 07:52:57 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 C526321F8C60 for ; Tue, 27 Sep 2011 07:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.700, 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 nI73s5DGE8ib for ; Tue, 27 Sep 2011 07:52:53 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0021F8C50 for ; Tue, 27 Sep 2011 07:52:53 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 27 Sep 2011 10:57:36 -0400 From: Peter Stanforth To: M.K.Sajeev sajeev , "paws@ietf.org" Date: Tue, 27 Sep 2011 10:55:36 -0400 Thread-Topic: [paws] Whitespace radio prototyping Thread-Index: Acx9JcprVlw3sUiwT/aUSGWWsEm4wQ== Message-ID: In-Reply-To: <1317131569.94273.YahooMailNeo@web36704.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAA75BAF140CDpeterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Whitespace radio prototyping 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, 27 Sep 2011 14:52:57 -0000 --_000_CAA75BAF140CDpeterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There have been a number of trials in the USA under experimental licenses. There have also been several trials in Finland. There are 2 active trials in the UK (Isle of Bute and Cambridge) There is also an active trial in Singapore. There may be others but I am not aware of any current trials in India. Regards, Peter Stanforth Spectrum Bridge Inc. From: "M.K.Sajeev sajeev" > Reply-To: "M.K.Sajeev sajeev" > Date: Tue, 27 Sep 2011 09:52:49 -0400 To: "paws@ietf.org" > Subject: [paws] Whitespace radio prototyping Hi, Is there any White space radio/WS database protocol proto typing or testing= activities happening in UK or India? It will be great to know the details = if any, as I am interested in involving such projects. Best Regards, Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev --_000_CAA75BAF140CDpeterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There have been a number= of trials in the USA under experimental licenses.
There have als= o been several trials in Finland.
There are 2 active trials in th= e UK (Isle of Bute and Cambridge)
There is also an active trial i= n Singapore.
There may be others but I am not aware of any curren= t trials in India.

Regards,
Peter Stanfo= rth
Spectrum Bridge Inc.

From: "M.K.Sajeev sajeev" <mksaji@yahoo.com>
Reply-To: "M.K.Sajeev sajeev" <mksaji@yahoo.com>
Date: Tue, 27 Sep 2011 09:52:49 -0400
T= o: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] Whitespace radio prototyping

H= i,

Is there any White space ra= dio/WS database protocol proto typing or testing activities happening in UK= or India? It will be great to know the details if any, as I am interested = in involving such projects. 
 
Best Regards,
= Sajee= v Manikkoth
 --_000_CAA75BAF140CDpeterspectrumbridgecom_-- From Basavaraj.Patil@nokia.com Tue Sep 27 10:29:10 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 208C521F8EE8 for ; Tue, 27 Sep 2011 10:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.155 X-Spam-Level: X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 wD++M3t32Rn4 for ; Tue, 27 Sep 2011 10:29:09 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D221F8EE5 for ; Tue, 27 Sep 2011 10:29:09 -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 p8RHV72x009747; Tue, 27 Sep 2011 20:31:54 +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); Tue, 27 Sep 2011 20:31:07 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 27 Sep 2011 19:31:07 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.188]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Tue, 27 Sep 2011 19:31:06 +0200 From: To: , Thread-Topic: [paws] comments on Draft Use Cases Thread-Index: AQHMc7nm/XA2/qh5lU+FR+ieDi0sr5VhGamA Date: Tue, 27 Sep 2011 17:31:06 +0000 Message-ID: In-Reply-To: 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: [172.19.59.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 17:31:07.0633 (UTC) FILETIME=[3D909610:01CC7D3B] X-Nokia-AV: Clean Subject: Re: [paws] comments on Draft Use Cases 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, 27 Sep 2011 17:29:10 -0000 Hi Peter, On 9/15/11 10:12 AM, "ext Peter Stanforth" wrote: >I have a number of comments on the use cases proposed in the draft. > >First the location based service seems too specific to an advertising >model as opposed to a more generic case of an edge device (slave) >requesting the location information about a serving master device from the >DB. There may well be other reasons for the slave to request information >about the master. One instance I can think of is to determine who owns the >master (registration information) it may be that the slave only trusts >certain masters or has a cost basis to chose one available master over >another. The "4.6. Location based service usage scenario" description in the I-D illustrates the potential of using the information stored in the database, and in this case it is location. The use case itself is orthogonal to the actual scope of the protocol between a WS master device and a database. We do agree that this use case does not have a direct impact on the PAWS protocol. However the point we are attempting to make with this use case is that the information stored in a database associated with white space devices can be utilized by other services. We could extend the use-case to describe the slave device querying the database to obtain information about the master; And the information received could assist the device in choosing between multiple masters that may be visible based on some policy/preference. Do you perceive the slave device using the same protocol (as the one between the master and database) for such a query? >Finally there is no "White Space" only shades of grey. So I think it is >important to consider >that not all spectrum is equal and that the DB may have to provide some >weighting or other >Criteria to describe suitability of the available channels for use. Note >that this is unrelated >to any Co-existence criteria. The weighting of the channels in a query response could be quite useful to a master device.=20 This could be a requirement on the PAWS protocol as follows: Req: The database SHOULD provide the capability to qualify (with various criteria such as relative priority or weight etc.) the list of available channels in a response message -Basavaraj >Regards, >Peter Stanforth From peter@spectrumbridge.com Tue Sep 27 10:36: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 D76FD21F8F27 for ; Tue, 27 Sep 2011 10:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.584, 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 guiROjM1eK1P for ; Tue, 27 Sep 2011 10:36:22 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 26EB721F8F1B for ; Tue, 27 Sep 2011 10:36:22 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 27 Sep 2011 13:41:06 -0400 From: Peter Stanforth To: "Basavaraj.Patil@nokia.com" , "paws@ietf.org" Date: Tue, 27 Sep 2011 13:39:06 -0400 Thread-Topic: [paws] comments on Draft Use Cases Thread-Index: Acx9PKI5jOkqMO6iSWS1aekSe+Q4pw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] comments on Draft Use Cases 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, 27 Sep 2011 17:36:23 -0000 Basavaraj I had not thought through the details of how the slave would communicate with the DB you got the intent right by saying "that the information can be utilized by other services" On the second point I also agree with the way you have described the requirement as a means for a database to "Qualify" the list of channels. Thanks, Peter S. On TueSep/27/11 Tue Sep 27, 1:31 PM, "Basavaraj.Patil@nokia.com" wrote: > >Hi Peter, > >On 9/15/11 10:12 AM, "ext Peter Stanforth" >wrote: > >>I have a number of comments on the use cases proposed in the draft. >> >>First the location based service seems too specific to an advertising >>model as opposed to a more generic case of an edge device (slave) >>requesting the location information about a serving master device from >>the >>DB. There may well be other reasons for the slave to request information >>about the master. One instance I can think of is to determine who owns >>the >>master (registration information) it may be that the slave only trusts >>certain masters or has a cost basis to chose one available master over >>another. > > >The "4.6. Location based service usage scenario" description in the I-D >illustrates the potential of using the information stored in the database, >and in this case it is location. The use case itself is orthogonal to the >actual scope of the protocol between a WS master device and a database. We >do agree that this use case does not have a direct impact on the PAWS >protocol. >However the point we are attempting to make with this use case is that the >information stored in a database associated with white space devices can >be utilized by other services. >We could extend the use-case to describe the slave device querying the >database to obtain information about the master; And the information >received could assist the device in choosing between multiple masters that >may be visible based on some policy/preference. >Do you perceive the slave device using the same protocol (as the one >between the master and database) for such a query? > > >>Finally there is no "White Space" only shades of grey. So I think it is >>important to consider >>that not all spectrum is equal and that the DB may have to provide some >>weighting or other >>Criteria to describe suitability of the available channels for use. Note >>that this is unrelated >>to any Co-existence criteria. > >The weighting of the channels in a query response could be quite useful to >a master device.=20 >This could be a requirement on the PAWS protocol as follows: > >Req: The database SHOULD provide the capability to qualify (with various >criteria such as relative priority or weight etc.) the list of available >channels in a response message > >-Basavaraj > >>Regards, >>Peter Stanforth > From scott.probasco@nokia.com Fri Sep 30 05:09:17 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 179FC21F8772 for ; Fri, 30 Sep 2011 05:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=0.548, 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 GrCEsa6Yn5i8 for ; Fri, 30 Sep 2011 05:09:16 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 032E221F8488 for ; Fri, 30 Sep 2011 05:09:15 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8UCBrH5014721; Fri, 30 Sep 2011 15:12:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 15:12:02 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 30 Sep 2011 14:12:01 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.188]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Fri, 30 Sep 2011 14:12:01 +0200 From: To: , Thread-Topic: [paws] comments on Draft Use Cases Thread-Index: AQHMc7nmpkdL/z9qBk29Dj0TVJiaYJVZV08AgACWTwCAC4nlAA== Date: Fri, 30 Sep 2011 12:12:01 +0000 Message-ID: In-Reply-To: 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.241.166.149] Content-Type: text/plain; charset="us-ascii" Content-ID: <091DED637DCC80499567B2645459D818@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2011 12:12:02.0389 (UTC) FILETIME=[29597050:01CC7F6A] X-Nokia-AV: Clean Subject: Re: [paws] comments on Draft Use Cases 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, 30 Sep 2011 12:09:17 -0000 Hi, Here is draft text for the mobility use case. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In this use case, the user has a non-fixed (portable or mobile) device and is riding in a vehicle. The user wants to have connectivity to another device which is also moving. Typical deployment scenarios include urban areas and rural areas where the user may connect to other users in peer-to-peer or ad-hoc networks. This deployment scenario is typically characterized by a master device with low antenna height, internet connectivity by some connection that does not utilize TV white space, and some means to predict its path of mobility. This knowledge of mobility could be simple (GPS plus accelerometer), sophisticated (GPS plus routing and mapping function) or completely specified by the user via user-interface. A simplified operational scenario utilizing TV white space to provide peer-to-peer connectivity service in a mobility environment consists of the following steps: 1. The mobile master device powers up with its WS radio in idle or listen mode only (no active transmission on the WS frequency band). 2. The mobile master has internet connectivity and establishes a connection to a trusted white space database (see use case "TVWS database discovery above). 3. The mobile master registers its current geolocation, address contact information, etc. associated with the owner/operator of the master with the trusted database administrator (if not currently registered). 4. Following the registration process, the mobile master will send a query to the trusted database requesting a list of available WS channels based upon its current location and a prediction of its future location, extrapolated from the motion or mobility of the device. The current location is specified in latitude and longitude. The method to specify the future location is TBD, potential methods include movement vector (direction and velocity), a set of latitude/longitude points which specify a closed polygon where the future location is within the polygon, or similar. 5. If the mobile master has been previously authenticated, the database responds with a list of available white space channels that the mobile master may use, and optional information which may include (1) a duration of time for the use of each channel (2) a maximum transmit power for each channel. 6. Once the mobile master authenticates the WS channel list response message from the database, the master selects an available WS channel from the list for use. 7. The other user device in the peer-to-peer connection scans the TV bands to locate a mobile master transmission, and associates with the mobile master. The slave/user device queries the master for a channel list, based on the slave's device identification, geolocation and optionally a prediction of its future location. 8. If required by local regulation, the master device verifies the slave's device identification with the database. 8. If allowed by local regulation (e.g. the slave's device identification is verified by the database), the mobile master provides the list of channels locally available to the slave/user device. If the channel that the slave/user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another Master's transmission on a different channel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This represents only one of many possible use case scenarios. Looking forward to the group's discussion. Regards, Scott On 9/22/11 5:59 PM, "ext Peter Stanforth" wrote: >Thanks Scott >Your suggestions sound good to me. The third suggestion came from >conversations we have had with government agencies, it is not part of any >current White Space regulation. The politicians and the bureaucrats both >suggested that the way that government spectrum would be made available on >a secondary basis (similar to white space) would be if the agency got >compensated for it's use. >Peter S. > >On ThuSep/22/11 Thu Sep 22, 3:01 PM, "scott.probasco@nokia.com" > wrote: > >> >>Hi Peter, >> >>Good comments. Reviewing them one by one... >> >>First. We will re-write the location based service use case to be a >>generic "regulatory requirement" use case, focusing on the registration >>information as you suggest. >> >>Second. Ability to withdraw permission is essentially same as the "kill >>switch" described by Ofcom in their "Implementing Geolocation" document. >>We proposed to add this either as a separate use case or included it to >>an >>existing use case. >> >>Third. We generally agree with the principle and would like to include >>the >>capability. Probably the question will be asked if this is in scope. We >>would like to identify a regulator who has indicated a need or desire for >>this. >> >>Fourth. We will include a new use case for mobility, FCC has already >>identified this as a valid use case. >> >>Regards, >>Scott & Raj >> >> >> >>On 9/15/11 10:12 AM, "ext Peter Stanforth" >>wrote: >> >>>I have a number of comments on the use cases proposed in the draft. >>> >>>First the location based service seems too specific to an advertising >>>model as opposed to a more generic case of an edge device (slave) >>>requesting the location information about a serving master device from >>>the >>>DB. There may well be other reasons for the slave to request information >>>about the master. One instance I can think of is to determine who owns >>>the >>>master (registration information) it may be that the slave only trusts >>>certain masters or has a cost basis to chose one available master over >>>Another. >>> >>>Second. The whole concept is predicated on an ability to provide access >>>to >>>spectrum into the future. I believe that much spectrum (owned by >>>emergency >>>services, defense agencies and others) will not be made available >>>without >>>an ability to withdraw the permission should a predefined emergency >>>situation emerge. There are several ways to address this requirement but >>>I >>>think >>>a use case that considers such a scenario is required. >>> >>>Third, Access to spectrum, as a licensed or unlicensed device, may >>>require >>>payment. It seems highly likely that government agencies (spectrum >>>holders) will need to be >>>persuaded to make spectrum available. This may be in the form of the >>>Agency/holder getting some compensation for the use of the spectrum. >>>This >>>would >>>require that use of the spectrum be tracked such that some backend >>>billing >>>or clearing house system could deal with payments. >>> >>>Fourth, The concept of mobility is not described. Mobility could be >>>addressed by providing a vector or an area to the DB which would result >>>in >>>a set of available channels being delivered. >>> >>>Finally there is no "White Space" only shades of grey. So I think it is >>>important to consider >>>that not all spectrum is equal and that the DB may have to provide some >>>weighting or other >>>Criteria to describe suitability of the available channels for use. Note >>>that this is unrelated >>>to any Co-existence criteria. >>>Regards, >>>Peter Stanforth >>> >>> >>> >>> >>>> >>> >>>_______________________________________________ >>>paws mailing list >>>paws@ietf.org >>>https://www.ietf.org/mailman/listinfo/paws >> >