From ietf-ipr@ietf.org Thu Sep 22 07:33: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 6EDDC21F8C20; Thu, 22 Sep 2011 07:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=0.070, 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 53VwiR50revQ; Thu, 22 Sep 2011 07:33:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7821F8C08; Thu, 22 Sep 2011 07:33:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: scott.probasco@nokia.com, Gabor.Bajko@nokia.com, basavaraj.patil@nokia.com, brian.rosen@neustar.biz, X-Test-IDTracker: no Message-ID: <20110922143317.12752.64380.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2011 07:33:17 -0700 X-Mailman-Approved-At: Mon, 03 Oct 2011 10:08:04 -0700 Cc: paws@ietf.org, br@brianrosen.net, presnick@qualcomm.com, ipr-announce@ietf.org Subject: [paws] IPR Disclosure: Microsoft Corporation's Statement about IPR related to draft-ietf-paws-problem-stmt-usecases-rqmts-00 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 14:33:17 -0000 Dear Scott Probasco, Gabor Bajko, Basavaraj Patil, Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Protocol = to Access White Space database: PS, use cases and rqmts" (draft-ietf-paws-prob= lem- stmt-usecases-rqmts) was submitted to the IETF Secretariat on 2011-09-20 an= d has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1614/). The title of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to draft-ietf-paws-pro= blem- stmt-usecases-rqmts-00.""); The IETF Secretariat From paul@marvell.com Tue Oct 11 17:24: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 3AC4C21F8C5B for ; Tue, 11 Oct 2011 17:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 uH7TCJHAqUM0 for ; Tue, 11 Oct 2011 17:24:16 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7759D21F8C5A for ; Tue, 11 Oct 2011 17:24:16 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP; Tue, 11 Oct 2011 17:24:16 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 11 Oct 2011 17:21:38 -0700 From: Paul Lambert To: "paws@ietf.org" Date: Tue, 11 Oct 2011 17:21:35 -0700 Thread-Topic: Testing and certification for devices using PAWS Thread-Index: AQHMc7nm/XA2/qh5lU+FR+ieDi0sr5VhGamAgBboRmA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Agkz BTJ5 BxPh DAWh DeFT ECXN EQx6 FHN2 GxsF HEOY HETb IsD2 Is4C I/D2 JTsX J6iN; 1; cABhAHcAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4F24F7EB-CDA9-4906-B744-D824958F8C77}; cABhAHUAbABAAG0AYQByAHYAZQBsAGwALgBjAG8AbQA=; Wed, 12 Oct 2011 00:21:35 GMT; VABlAHMAdABpAG4AZwAgAGEAbgBkACAAYwBlAHIAdABpAGYAaQBjAGEAdABpAG8AbgAgAGYAbwByACAAZABlAHYAaQBjAGUAcwAgAHUAcwBpAG4AZwAgAFAAQQBXAFMA x-cr-puzzleid: {4F24F7EB-CDA9-4906-B744-D824958F8C77} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 00:24:17 -0000 Seems like we need to consider testing and certification of WS devices. How do we run tests? How do we ensure access to databases of multiple regulatory authorities in = multiple locations? How do we control location? Can location be set for testing? Are special back doors required to GDBs? How do we establish different frequency grants for testing purposes? Requirements: Device-to-GDB must have facilities for testing to: - test multiple locations - test multiple GBD and Regional Authority GDBs - test various frequency grants from a fixed testbed - support international test houses We will need real databases to have special limited backdoor for testing an= d certification. Paul From Basavaraj.Patil@nokia.com Tue Oct 11 19:55: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 6FC2D21F86A5 for ; Tue, 11 Oct 2011 19:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 IP-LKdLbWdze for ; Tue, 11 Oct 2011 19:55:39 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D840021F86A1 for ; Tue, 11 Oct 2011 19:55:38 -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 p9C2tS9m012134; Wed, 12 Oct 2011 05:55:37 +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, 12 Oct 2011 05:55:25 +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, 12 Oct 2011 04:53:53 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.208]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 04:53:42 +0200 From: To: , Thread-Topic: [paws] Testing and certification for devices using PAWS Thread-Index: AQHMiHVNL4Z/XQfjzEyTvIoGBbWNp5V3jf6A Date: Wed, 12 Oct 2011 02:53:41 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@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: [173.74.219.186] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B3B67378D4DFA47B4E997B3D39C1D7A@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2011 02:55:25.0568 (UTC) FILETIME=[643FF800:01CC888A] X-Nokia-AV: Clean Subject: Re: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 02:55:39 -0000 Hi Paul, Your comment below relates to how testing of the protocol between devices to databases is done. IMO this is beyond the scope of the actual protocol itself. I do see the need for testing to be done in a lab with various location settings. But this could potentially be simulated or emulated or manipulated with some lab setting. -Raj On 10/11/11 7:21 PM, "ext Paul Lambert" wrote: >Seems like we need to consider testing and certification of WS devices. > >How do we run tests? >How do we ensure access to databases of multiple regulatory authorities >in multiple locations? >How do we control location? Can location be set for testing? >Are special back doors required to GDBs? >How do we establish different frequency grants for testing purposes? > >Requirements: >Device-to-GDB must have facilities for testing to: >- test multiple locations >- test multiple GBD and Regional Authority GDBs >- test various frequency grants from a fixed testbed >- support international test houses > >We will need real databases to have special limited backdoor for testing >and certification. > >Paul > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From pecclesi@cisco.com Tue Oct 11 19:52: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 F402521F8C7F for ; Tue, 11 Oct 2011 19:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyY5hi4VnT+Q for ; Tue, 11 Oct 2011 19:52:33 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C550321F8C7C for ; Tue, 11 Oct 2011 19:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pecclesi@cisco.com; l=9357; q=dns/txt; s=iport; t=1318387953; x=1319597553; h=mime-version:subject:date:message-id:from:to; bh=zRbKDXrPzoTO9DyBBaa2tvJ6H1m79Uurnizjo6vZq+o=; b=KsyzQfOY+x/x7WRK7fNh1YkhDx4U/sulnwYRfhJ+TPVFh19oXjUs5sn5 Z+V0RuAkv45fK4XYaobPz0tzkY4ToT7s+pKvYpyZnej8zO8HZOfRQsw+3 S8GBg5YguzZVXhTOmWmZ3d0EZisW3yUOchZ1+x4777EeM2Q/pLsIwj/jv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHALr/lE6rRDoJ/2dsb2JhbABAA4JNlwCOYIEFgVUBAQECEgEJEQNbASoGGAdXAQQbGodjmEGBJgGeUIRDgjRhBId/kSeMQg X-IronPort-AV: E=Sophos;i="4.68,526,1312156800"; d="scan'208,217";a="7314630" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 12 Oct 2011 02:52:33 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9C2qX6k004387 for ; Wed, 12 Oct 2011 02:52:33 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 19:52:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8889.FD98FDA9" Date: Tue, 11 Oct 2011 19:52:32 -0700 Message-ID: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5HQ== From: "Peter Ecclesine (pecclesi)" To: X-OriginalArrivalTime: 12 Oct 2011 02:52:33.0408 (UTC) FILETIME=[FDA27000:01CC8889] X-Mailman-Approved-At: Tue, 11 Oct 2011 20:21:47 -0700 Subject: [paws] Several spectrum masks used by multi-bandwidth radios 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, 12 Oct 2011 02:53:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8889.FD98FDA9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, with several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UHF). =20 We see the need to tell the database several spectrum masks, each with: 1 - Lowest applicable frequency in MHz 2 - Highest applicable frequency in MHz 3 - Maximum total EIRP over the frequency range defined by the spectrum mask 4 - General spectrum mask in dBr from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FCC 47 C.F.R. 90.210(m).=20 5- measurement resolution bandwidth for EIRP measurements =20 This detailed actual spectrum occupancy information allows the database to perform more accurate interference calculations. =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 ------_=_NextPart_001_01CC8889.FD98FDA9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In IEEE = 802.11af discussions, we expect to use a modified 802.11ac PHY, with = several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in = several TV bands (VHF and UHF).

 

We see the = need to tell the database several spectrum masks, each = with:

        &= nbsp;       1 – Lowest applicable = frequency in MHz

        &= nbsp;       2 – Highest applicable = frequency in MHz

        &= nbsp;       3 – Maximum total EIRP = over the frequency range defined by the spectrum = mask

        &= nbsp;       4 – General spectrum = mask in dBr from peak transmit power in EIRP, with specific power limit = at any frequency linearly interpolated between adjacent points of the = spectrum mask, expressed like IEEE 802.11p Annex I = [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FCC = 47 C.F.R. 90.210(m).

        &= nbsp;       5- measurement resolution = bandwidth for EIRP measurements

 

   This detailed actual spectrum occupancy = information allows the database to perform more accurate interference = calculations.

 

petere

Peter = Ecclesine, Technology Analyst

MS SJ-14-4 = 170 West Tasman Dr, San Jose, CA 95134-1706

Ph = 408/527-0815, FAX 408/525-9256

"Time = doesn't fool around."  "Without Prejudice" U.C.C. = 1-207

------_=_NextPart_001_01CC8889.FD98FDA9-- From Basavaraj.Patil@nokia.com Tue Oct 11 20:30: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 CECD521F8C9C for ; Tue, 11 Oct 2011 20:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GJ+rBgKy6NHX for ; Tue, 11 Oct 2011 20:30:24 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id CF40C21F8CA6 for ; Tue, 11 Oct 2011 20:30:23 -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 p9C3Rb9m016388; Wed, 12 Oct 2011 06:30:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 06:30:16 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 12 Oct 2011 05:30:16 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.208]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 05:30:15 +0200 From: To: , Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A Date: Wed, 12 Oct 2011 03:30:14 +0000 Message-ID: In-Reply-To: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.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: [173.74.219.186] Content-Type: multipart/alternative; boundary="_000_CABA73C212008basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2011 03:30:16.0623 (UTC) FILETIME=[429DA3F0:01CC888F] X-Nokia-AV: Clean Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 12 Oct 2011 03:30:24 -0000 --_000_CABA73C212008basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So what would be the requirement that we can specify for the (device-2-data= base) protocol as a result of the need for various spectrum masks? From: "ext Peter Ecclesine (pecclesi)" > Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" > Subject: [paws] Several spectrum masks used by multi-bandwidth radios In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, wit= h several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in seve= ral TV bands (VHF and UHF). We see the need to tell the database several spectrum masks, each with: 1 =96 Lowest applicable frequency in MHz 2 =96 Highest applicable frequency in MHz 3 =96 Maximum total EIRP over the frequency range defined b= y the spectrum mask 4 =96 General spectrum mask in dBr from peak transmit power= in EIRP, with specific power limit at any frequency linearly interpolated = between adjacent points of the spectrum mask, expressed like IEEE 802.11p A= nnex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or = FCC 47 C.F.R. 90.210(m). 5- measurement resolution bandwidth for EIRP measurements This detailed actual spectrum occupancy information allows the database = to perform more accurate interference calculations. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CABA73C212008basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <56B3EA91232D644EA0494E4AC58F6CCE@nokia.com> Content-Transfer-Encoding: quoted-printable

So what would be the requirement that we can specify for the (device-2= -database) protocol as a result of the need for various spectrum masks?

From: "ext Peter Ecclesine (pe= cclesi)" <pecclesi@cisco.com<= /a>>
Date: Tue, 11 Oct 2011 19:52:32 -07= 00
To: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] Several spectrum ma= sks used by multi-bandwidth radios

In IEEE 802.11af discussions, we expect to use a mod= ified 802.11ac PHY, with several occupied bandwidths, for example 4 MHz, 8 = MHz and 16 MHz, in several TV bands (VHF and UHF).

 

We see the need to tell the database several spectru= m masks, each with:

   &nbs= p;            1 =96 = Lowest applicable frequency in MHz

   &nbs= p;            2 =96 = Highest applicable frequency in MHz

   &nbs= p;            3 =96 = Maximum total EIRP over the frequency range defined by the spectrum mask

   &nbs= p;            4 =96 = General spectrum mask in dBr from peak transmit power in EIRP, with specifi= c power limit at any frequency linearly interpolated between adjacent point= s of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11= p-2010.pdf] or FCC 47 C.F.R. 90.210(m).

   &nbs= p;            5- mea= surement resolution bandwidth for EIRP measurements

 

   This detailed actual spectrum occupancy= information allows the database to perform more accurate interference calc= ulations.

 

petere

= Peter Ecclesine, Technology Analyst

= MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

= Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without Pre= judice" U.C.C. 1-207

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CABA73C212008basavarajpatilnokiacom_-- From mksaji@yahoo.com Tue Oct 11 21:25: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 8F6F921F8B11 for ; Tue, 11 Oct 2011 21:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.509 X-Spam-Level: **** X-Spam-Status: No, score=4.509 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, 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 LVgEMWULSDPv for ; Tue, 11 Oct 2011 21:25:49 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id 9198C21F8B0F for ; Tue, 11 Oct 2011 21:25:49 -0700 (PDT) Received: from [98.139.52.194] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 12 Oct 2011 04:25:46 -0000 Received: from [98.139.52.172] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 12 Oct 2011 04:25:46 -0000 Received: from [127.0.0.1] by omp1055.mail.ac4.yahoo.com with NNFMP; 12 Oct 2011 04:25:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 183729.5998.bm@omp1055.mail.ac4.yahoo.com Received: (qmail 89821 invoked by uid 60001); 12 Oct 2011 04:25:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318393545; bh=1cQ+yXv0LpR3fHBWrNbErylaXfSC1u8GYEHywrXiOos=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Lq1aVPUOYIOtHnDxK1zJtAx/5zSTBp6UL0sg2XYAL8KV5wwg5GwpiL9xe6Q7+UWE7FqQRofyb+EXpqHPxnjrzlTUULzx3xHT/LZB7X0wAItMfYbAFK2o88AFc2FTfvB4P2g0F3k19bSiz/ol8Cj5OACg8a1CwD4V+Q4SCrMSoBY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OXsiea2/0WqlVcEZyYv1btPOmWbcUQjhZ37zyCs8YzMJ4WAjz7D04n8C9pEV8sRh8AaDKrosRFqWRSpMjUuXDCemmg+X01mI4VK1kGpygPb8VHUbruj4hqejPBysLKpb6dCX7HLHgMW9yFTx6R8BOVSV6mrWptCCRVxXaCM9kDI=; X-YMail-OSG: HN.jyg8VM1ktNYQCBOZxPqDLsADIe26TG39Skm664ppgNCw bI4LJJIgppRrFReExg5meR7FTXrYA7EssGoEtKc0PfQVG0DP0Np811RmslYO fIbjYe7mpsbw2E3tpAmNO6qDZpATLLP9qDoie7062lKJx3WTo2wAzix_wGb2 mHXInxwhvGY6lT2ZLczShR2KUUUeVqsERHvfzkuZBlIY35oFN3XGUONG7uMp jo88SfYeSj.4mNio.7C_7iuB8jSFHc.IMBOkFgkai64GF0A4dsUUNlyGsu8W yqcLwWXrRXmeZTGyGfsQNfjVz2P7uxQxtkTFiX7QUajjvgqBnRSusUgCfZeE v.jJWiAPbYlVYwtpPRbxWpqBjvMc_Bb_BZo6VFyLRuHY8bXaBvvdAShHJKZi mx4eCbVVEKaeeJ0BBJ9Bs88Ttk.5o5UQNF_7A.hxlWe81k7_eAKRGBdH.4W4 jd9xJmeUSmJVzOHWXRI88HJg- Received: from [223.178.166.202] by web36701.mail.mud.yahoo.com via HTTP; Tue, 11 Oct 2011 21:25:45 PDT X-Mailer: YahooMailWebService/0.8.114.317681 References: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@SC-VEXCH2.marvell.com> Message-ID: <1318393545.89081.YahooMailNeo@web36701.mail.mud.yahoo.com> Date: Tue, 11 Oct 2011 21:25:45 -0700 (PDT) From: "M.K.Sajeev sajeev" To: "Basavaraj.Patil@nokia.com" , "paul@marvell.com" , "paws@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2114655128-786286467-1318393545=:89081" Subject: Re: [paws] Testing and certification for devices using PAWS 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: Wed, 12 Oct 2011 04:25:50 -0000 ---2114655128-786286467-1318393545=:89081 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AScenarios mentioned here looks like end to end testing of white sp= ace radios, and certifying those. Where do these fit in? Is it in the scope= of IEEE 802.22?=0A=A0=0ABest Regards,=0A=0ASajeev Manikkoth=0A=0A=0A=0A=0A= =0A________________________________=0AFrom: "Basavaraj.Patil@nokia.com" =0ATo: paul@marvell.com; paws@ietf.org=0ASent: Wedn= esday, 12 October 2011, 8:23=0ASubject: Re: [paws] Testing and certificatio= n for devices using PAWS=0A=0A=0AHi Paul,=0A=0AYour comment below relates t= o how testing of the protocol between devices=0Ato databases is done.=0AIMO= this is beyond the scope of the actual protocol itself.=0A=0AI do see the = need for testing to be done in a lab with various location=0Asettings. But = this could potentially be simulated or emulated or=0Amanipulated with some = lab setting.=0A=0A-Raj=0A=0AOn 10/11/11 7:21 PM, "ext Paul Lambert" wrote:=0A=0A>Seems like we need to consider testing and certifi= cation of WS devices.=0A>=0A>How do we run tests?=0A>How do we ensure acces= s to databases of multiple regulatory authorities=0A>in multiple locations?= =0A>How do we control location? Can location be set for testing?=0A>Are spe= cial back doors required to GDBs?=0A>How do we establish different frequenc= y grants for testing purposes?=0A>=0A>Requirements:=0A>Device-to-GDB must h= ave facilities for testing to:=0A>- test multiple locations=0A>- test multi= ple GBD and Regional Authority GDBs=0A>- test various frequency grants from= a fixed testbed=0A>- support international test houses=0A>=0A>We will need= real databases to have special limited backdoor for testing=0A>and certifi= cation.=0A>=0A>Paul=0A>=0A>_______________________________________________= =0A>paws mailing list=0A>paws@ietf.org=0A>https://www.ietf.org/mailman/list= info/paws=0A=0A_______________________________________________=0Apaws maili= ng list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws ---2114655128-786286467-1318393545=:89081 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

Scenarios mentioned here looks= like end to end testing of white space radios, and certifying those. Where= do these fit in? Is it in the scope of IEEE 802.22?
 = ;
Best Rega= rds,

Sajeev Manikkoth



=
From: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
To: paul@marvell.com; paws@ietf.org
Sent: Wednesday, 12 October 2011, 8:23
Subject: Re: [paws] Testing and ce= rtification for devices using PAWS


Hi Paul,

Your c= omment below relates to how testing of the protocol between devices
to d= atabases is done.
IMO this is beyond the scope of the actual protocol it= self.

I do see the need for testing to be done in a lab with various= location
settings. But this could potentially be simulated or emulated = or
manipulated with some lab setting.

-Raj

On 10/11/11 7:2= 1 PM, "ext Paul Lambert" <paul@marvell.com> wrote:

>Seems = like we need to consider testing and certification of WS devices.
>
>How do we run tests?
>How do we ensure acces= s to databases of multiple regulatory authorities
>in multiple locati= ons?
>How do we control location? Can location be set for testing?>Are special back doors required to GDBs?
>How do we establish di= fferent frequency grants for testing purposes?
>
>Requirements:=
>Device-to-GDB must have facilities for testing to:
>- test mu= ltiple locations
>- test multiple GBD and Regional Authority GDBs
= >- test various frequency grants from a fixed testbed
>- support i= nternational test houses
>
>We will need real databases to have= special limited backdoor for testing
>and certification.
>
= >Paul
>
>_______________________________________________
= >paws mailing list
>paws@ietf.org
>http= s://www.ietf.org/mailman/listinfo/paws

_________________________= ______________________
paws mailing list
paws@ietf.org
https://www.ietf.o= rg/mailman/listinfo/paws


---2114655128-786286467-1318393545=:89081-- From peter@spectrumbridge.com Wed Oct 12 03:41: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 512BC21F8B3D for ; Wed, 12 Oct 2011 03:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4bz4-hUg3zx for ; Wed, 12 Oct 2011 03:41:50 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id A537B21F8B19 for ; Wed, 12 Oct 2011 03:41:50 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 12 Oct 2011 06:43:22 -0400 From: Peter Stanforth To: "Basavaraj.Patil@nokia.com" Date: Wed, 12 Oct 2011 06:42:13 -0400 Thread-Topic: [paws] Testing and certification for devices using PAWS Thread-Index: AcyIy8Lf2PjdTKg7RPeNSWQom8XO6g== Message-ID: <17358DE9-737A-40A9-A944-11A4C002C422@spectrumbridge.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 10:41:51 -0000 Looks good in principle. Covers all the likely activities. Spelling out th= e total extent and apportioning them a percentage is a good idea. Not sure= we can charge them 75% of something we were going to do anyway. But there = will absolutely be some additional effort above and beyond to support Googl= e. I agree with sending something to Alan soon with a follow up call. Woul= d be good to get some insight on how Google thinks. On Oct 11, 2011, at 10:57 PM, "Basavaraj.Patil@nokia.com" wrote: >=20 > Hi Paul, >=20 > Your comment below relates to how testing of the protocol between devices > to databases is done. > IMO this is beyond the scope of the actual protocol itself. >=20 > I do see the need for testing to be done in a lab with various location > settings. But this could potentially be simulated or emulated or > manipulated with some lab setting. >=20 > -Raj >=20 > On 10/11/11 7:21 PM, "ext Paul Lambert" wrote: >=20 >> Seems like we need to consider testing and certification of WS devices. >>=20 >> How do we run tests? >> How do we ensure access to databases of multiple regulatory authorities >> in multiple locations? >> How do we control location? Can location be set for testing? >> Are special back doors required to GDBs? >> How do we establish different frequency grants for testing purposes? >>=20 >> Requirements: >> Device-to-GDB must have facilities for testing to: >> - test multiple locations >> - test multiple GBD and Regional Authority GDBs >> - test various frequency grants from a fixed testbed >> - support international test houses >>=20 >> We will need real databases to have special limited backdoor for testing >> and certification. >>=20 >> Paul >>=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 Gabor.Bajko@nokia.com Wed Oct 12 09:25:06 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 8205021F8C82 for ; Wed, 12 Oct 2011 09:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hvbc1raUTvX for ; Wed, 12 Oct 2011 09:25:04 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3A21F8C7D for ; Wed, 12 Oct 2011 09:25:02 -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 p9CGP0Ad016857; Wed, 12 Oct 2011 19:25:01 +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); Wed, 12 Oct 2011 19:25:00 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 12 Oct 2011 18:25:00 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.138]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 18:24:59 +0200 From: To: , , , Thread-Topic: [paws] Testing and certification for devices using PAWS Thread-Index: AQHMiHVNmTtSRp0zWUaD4CvqZU3h7pV34dqAgAAZuYCAAC574A== Date: Wed, 12 Oct 2011 16:24:59 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47612D88F@008-AM1MPN1-007.mgdnok.nokia.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@SC-VEXCH2.marvell.com> <1318393545.89081.YahooMailNeo@web36701.mail.mud.yahoo.com> In-Reply-To: <1318393545.89081.YahooMailNeo@web36701.mail.mud.yahoo.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: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47612D88F008AM1MPN1007mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2011 16:25:00.0827 (UTC) FILETIME=[7D5C46B0:01CC88FB] X-Nokia-AV: Clean Subject: Re: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 16:25:06 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47612D88F008AM1MPN1007mgdn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 testing of white space radios, and certifying those. Where do these fi= t in? Is it in the scope of IEEE 802.22? If the technology to be used in the WS is WiFi, then I believe it is in sco= pe of WiFi Alliance, www.wi-fi.org If the technology is going to be some 3G/4G cellular, then I believe it fal= ls under the scope of 3GPP. If the technology will be 802.22, then they'll have to find a certification= body. Etc. I am not sure how much ietf can help in setting up the testbed for the cert= ification. The protocol we are supposed to work on will be able to carry lo= cation, but how that location is determined by the client (pre-configuratio= n, GPS, other, etc) is out of paws scope. Same for frequency grants. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= M.K.Sajeev sajeev Sent: Tuesday, October 11, 2011 9:26 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paul@marvell.com; paws@ietf.org Subject: Re: [paws] Testing and certification for devices using PAWS Hi, Scenarios mentioned here looks like end to end testing of white space radio= s, and certifying those. Where do these fit in? Is it in the scope of IEEE = 802.22? Best Regards, Sajeev Manikkoth ________________________________ From: "Basavaraj.Patil@nokia.com" To: paul@marvell.com; paws@ietf.org Sent: Wednesday, 12 October 2011, 8:23 Subject: Re: [paws] Testing and certification for devices using PAWS Hi Paul, Your comment below relates to how testing of the protocol between devices to databases is done. IMO this is beyond the scope of the actual protocol itself. I do see the need for testing to be done in a lab with various location settings. But this could potentially be simulated or emulated or manipulated with some lab setting. -Raj On 10/11/11 7:21 PM, "ext Paul Lambert" > wrote: >Seems like we need to consider testing and certification of WS devices. > >How do we run tests? >How do we ensure access to databases of multiple regulatory authorities >in multiple locations? >How do we control location? Can location be set for testing? >Are special back doors required to GDBs? >How do we establish different frequency grants for testing purposes? > >Requirements: >Device-to-GDB must have facilities for testing to: >- test multiple locations >- test multiple GBD and Regional Authority GDBs >- test various frequency grants from a fixed testbed >- support international test houses > >We will need real databases to have special limited backdoor for testing >and certification. > >Paul > >_______________________________________________ >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 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47612D88F008AM1MPN1007mgdn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  testing of white= space radios, and certifying those. Where do these fit in? Is it in the sc= ope of IEEE 802.22?

If the technology to be u= sed in the WS is WiFi, then I believe it is in scope of WiFi Alliance, www.wi-fi.org

If the technology is goin= g to be some 3G/4G cellular, then I believe it falls under the scope of 3GP= P.

If the technology will be= 802.22, then they’ll have to find a certification body. Etc.

 <= /p>

I am not sure how much ie= tf can help in setting up the testbed for the certification. The protocol w= e are supposed to work on will be able to carry location, but how that location is determined by the client (pre-configuration, GPS,= other, etc) is out of paws scope. Same for frequency grants.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev
Sent: Tuesday, October 11, 2011 9:26 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); paul@marvell.com; paws@ietf.= org
Subject: Re: [paws] Testing and certification for devices using PAWS=

 

Hi,

 

Scenarios mentioned here looks like end to end testing of white space ra= dios, and certifying those. Where do these fit in? Is it in the scope of IE= EE 802.22?

 

Best Regards,

 

<= span style=3D"color:#C00000">Sajeev Manikkoth


<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: "Basavar= aj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
To: paul@marvell.com; paws@ietf.org
Sent: Wednesday, 12 October 2011, 8:23
Subject: Re: [paws] Testing and certification for devices using PAWS=


Hi Paul,

Your comment below relates to how testing of the protocol between devices to databases is done.
IMO this is beyond the scope of the actual protocol itself.

I do see the need for testing to be done in a lab with various location
settings. But this could potentially be simulated or emulated or
manipulated with some lab setting.

-Raj

On 10/11/11 7:21 PM, "ext Paul Lambert" <paul@marvell.com> wrote:

>Seems like we need to consider testing and certification of WS devices.=
>
>How do we run tests?
>How do we ensure access to databases of multiple regulatory authorities=
>in multiple locations?
>How do we control location? Can location be set for testing?
>Are special back doors required to GDBs?
>How do we establish different frequency grants for testing purposes? >
>Requirements:
>Device-to-GDB must have facilities for testing to:
>- test multiple locations
>- test multiple GBD and Regional Authority GDBs
>- test various frequency grants from a fixed testbed
>- support international test houses
>
>We will need real databases to have special limited backdoor for testin= g
>and certification.
>
>Paul
>
>_______________________________________________
>paws mailing list
>paws@ietf.org
>https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47612D88F008AM1MPN1007mgdn_-- From paul@marvell.com Wed Oct 12 12:13: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 9841221F8B82 for ; Wed, 12 Oct 2011 12:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Qbyahn9-SD0T for ; Wed, 12 Oct 2011 12:13:39 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E721F84A3 for ; Wed, 12 Oct 2011 12:13:39 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP; Wed, 12 Oct 2011 12:13:39 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 12 Oct 2011 12:13:25 -0700 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "paws@ietf.org" Date: Wed, 12 Oct 2011 12:13:33 -0700 Thread-Topic: [paws] Testing and certification for devices using PAWS Thread-Index: AQHMiHVNL4Z/XQfjzEyTvIoGBbWNp5V3jf6AgAGGmtA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9058@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 19:13:40 -0000 > IMO this is beyond the scope of the actual protocol itself. Perhaps - but the testability of the system has some unique issues. Some o= f the solutions might include modifications to the protocol. Paul > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Tuesday, October 11, 2011 7:54 PM > To: Paul Lambert; paws@ietf.org > Subject: Re: [paws] Testing and certification for devices using PAWS >=20 >=20 > Hi Paul, >=20 > Your comment below relates to how testing of the protocol between > devices > to databases is done. > IMO this is beyond the scope of the actual protocol itself. >=20 > I do see the need for testing to be done in a lab with various location > settings. But this could potentially be simulated or emulated or > manipulated with some lab setting. >=20 > -Raj >=20 > On 10/11/11 7:21 PM, "ext Paul Lambert" wrote: >=20 > >Seems like we need to consider testing and certification of WS > devices. > > > >How do we run tests? > >How do we ensure access to databases of multiple regulatory > authorities > >in multiple locations? > >How do we control location? Can location be set for testing? > >Are special back doors required to GDBs? > >How do we establish different frequency grants for testing purposes? > > > >Requirements: > >Device-to-GDB must have facilities for testing to: > >- test multiple locations > >- test multiple GBD and Regional Authority GDBs > >- test various frequency grants from a fixed testbed > >- support international test houses > > > >We will need real databases to have special limited backdoor for > testing > >and certification. > > > >Paul > > > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Oct 12 12:21: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 E940721F8B2A for ; Wed, 12 Oct 2011 12:21:42 -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 8gVQR-DjsoTl for ; Wed, 12 Oct 2011 12:21:42 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBA21F8B2B for ; Wed, 12 Oct 2011 12:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1318447284; x=1633806067; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=IOGqnYLfRnjTQpXdFH/W2 aiMKTPfDmJ/TY6vqaxt0rU=; b=mAz4nyTimVz6ShztKvTRx65E13hDMnMTpFIcX KrXBtK09Tm/XhF5eQy42skjlMN/ds/FNIYO0ZBOmUL91T7TPA== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.538287; Wed, 12 Oct 2011 15:21:23 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 12 Oct 2011 15:21:35 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Wed, 12 Oct 2011 15:21:35 -0400 Thread-Topic: [paws] Testing and certification for devices using PAWS Thread-Index: AcyJFCgxWjFez/E9RP+dmwsTXi4w4A== Message-ID: <57901E01-976B-4315-BA06-16643D3E47E9@neustar.biz> References: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9058@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9058@SC-VEXCH2.marvell.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: /n8JVi0FKBjAV6cG4fL/+A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 19:21:43 -0000 Having looked into this a bit, my opinion is that the protocol does not nee= d any special facility to support this kind of testing. If you think it do= es, perhaps an example would be helpful. Brian On Oct 12, 2011, at 3:13 PM, Paul Lambert wrote: >> IMO this is beyond the scope of the actual protocol itself. > Perhaps - but the testability of the system has some unique issues. Some= of the solutions might include modifications to the protocol. >=20 > Paul >=20 >=20 >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Tuesday, October 11, 2011 7:54 PM >> To: Paul Lambert; paws@ietf.org >> Subject: Re: [paws] Testing and certification for devices using PAWS >>=20 >>=20 >> Hi Paul, >>=20 >> Your comment below relates to how testing of the protocol between >> devices >> to databases is done. >> IMO this is beyond the scope of the actual protocol itself. >>=20 >> I do see the need for testing to be done in a lab with various location >> settings. But this could potentially be simulated or emulated or >> manipulated with some lab setting. >>=20 >> -Raj >>=20 >> On 10/11/11 7:21 PM, "ext Paul Lambert" wrote: >>=20 >>> Seems like we need to consider testing and certification of WS >> devices. >>>=20 >>> How do we run tests? >>> How do we ensure access to databases of multiple regulatory >> authorities >>> in multiple locations? >>> How do we control location? Can location be set for testing? >>> Are special back doors required to GDBs? >>> How do we establish different frequency grants for testing purposes? >>>=20 >>> Requirements: >>> Device-to-GDB must have facilities for testing to: >>> - test multiple locations >>> - test multiple GBD and Regional Authority GDBs >>> - test various frequency grants from a fixed testbed >>> - support international test houses >>>=20 >>> We will need real databases to have special limited backdoor for >> testing >>> and certification. >>>=20 >>> Paul >>>=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 Gabor.Bajko@nokia.com Wed Oct 12 15:16: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 515AF21F8C76 for ; Wed, 12 Oct 2011 15:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 GOaCycJg01Rf for ; Wed, 12 Oct 2011 15:16:47 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3A60021F8C49 for ; Wed, 12 Oct 2011 15:16:47 -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 p9CMGkeH007575 for ; Thu, 13 Oct 2011 01:16:46 +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, 13 Oct 2011 01:16:41 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 13 Oct 2011 00:16:41 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.138]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Thu, 13 Oct 2011 00:16:40 +0200 From: To: Thread-Topic: Requirements Thread-Index: AcxvKZlAc7p+3+DsTR20bWVYhgQVbwaAmW2g Date: Wed, 12 Oct 2011 22:16:40 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47612DACE@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760FADF7@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <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: 12 Oct 2011 22:16:41.0650 (UTC) FILETIME=[9E6E5920:01CC892C] X-Nokia-AV: Clean Subject: Re: [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: Wed, 12 Oct 2011 22:16:48 -0000 I forwarded the below initial list of requirements to the list a while ago,= but there was no discussions on them.=20 We got today a set of additional requirements from the 802.11af folks (see = http://www.ietf.org/mail-archive/web/paws/current/msg00434.html). If there = are no objections, I'd like to ask the Editor to include both these set of = requirements to the new version of draft-ietf-paws-problem-stmt-usecases-rq= mts-00. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Friday, September 09, 2011 12:55 PM To: paws@ietf.org Subject: [paws] Requirements 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 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Wed Oct 12 15:23: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 1A54621F8CC6 for ; Wed, 12 Oct 2011 15:23:19 -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 u--AslPTd4vV for ; Wed, 12 Oct 2011 15:23:18 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E109821F8CC0 for ; Wed, 12 Oct 2011 15:23:17 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9CMN4aG022088; Thu, 13 Oct 2011 01:23:13 +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); Thu, 13 Oct 2011 01:23:10 +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; Thu, 13 Oct 2011 00:23:11 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.138]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Thu, 13 Oct 2011 00:23:10 +0200 From: To: , , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAa/KAgAAB7wD//67PgIAAVdYA/9OMKTA= Date: Wed, 12 Oct 2011 22:23:09 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2011 22:23:10.0961 (UTC) FILETIME=[867A7E10:01CC892D] 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, 12 Oct 2011 22:23:19 -0000 Pete, If your use case is covered by 4.3, but the requirements may be different, = please feel free to propose your protocol requirement to the list. -Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Peter McCann Sent: Wednesday, September 14, 2011 10:30 AM To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; Probasco S= cott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: Re: [paws] Possible new use case: simulcasting Hi, Raj, I think my use case is covered by Section 4.3 with a small change along the= lines that Scott suggested. Note there is this text in step 8: 8. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS. The slave/user device provides its geolocation to the BS which, in turn, queries the database for a list of channels available at the slaves' geolocation. What I am suggesting is no different except for the fact that each of the d= evices could have independent Internet access and be capable of querying th= e database itself. There could be one BS that handles all the queries or t= he 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 requ= irement that the protocol carry multiple location elements (instead of just= one) so that we save the cost of multiple queries across the Internet. Th= e WSDB, after doing the polygon intersection test at each location, could a= dditionally do a set intersection test on the remaining free channels and r= eturn the results. That's one concrete way that this use case may impact t= he 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-=20 > case is beyond the scope of the PAWS charter. > The protocol that is being specified is the one between this master-BS=20 > (or master WS device) and the database. > If a network has multiple BS' and there exists co-ordination between=20 > them, with only one of the BS' having the authority to query the=20 > database that=B9s fine. Because it is invisible to the protocol that we=20 > 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=20 >> channel after it has been cleared for use by the WSDB. >>=20 >> It seems like you are asking about how to coordinate the assignment=20 >> of the channel among all the different BS. I agree that one BS could=20 >> act as the "master", collecting information from the peer BSs and=20 >> presenting it all to the WSDB in a query for a vacant channel. Isn't=20 >> this the same as the existing WRAN use case in Section 4.3? Or is=20 >> 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=20 >>> in an area as the master BS that would query the DB for itself and=20 >>> on behalf of the other 'slave' BSs. Coordination could then be done=20 >>> locally by the master BS by sending a filtered version of the=20 >>> available channels list as received from the DB to the appropriate=20 >>> slave BS. >>>=20 >>> Unfortunately,it is still not clear whether the regulations in the=20 >>> various countries will allow such 'proxying' of TVBD's by other=20 >>> TVBD's and that this will not pose security problems. If it is=20 >>> allowed everywhere and appropriate security can be achieved, then=20 >>> such coordination could be transparent to the DB since it would take=20 >>> 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=20 >>> 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=20 >>>> initially to indicate that a single channel is used for operation,=20 >>>> contrasted to the 2 channel requirement for FDD. >>>>=20 >>>> I believe the use case under discussion is using the channel for=20 >>>> full DL broadcast. It's not so much as coordination, just 100% DL. Rig= ht? >>>>=20 >>>> Would help me if you could clarify what spectrum coordination is=20 >>>> 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=20 >>>>>> use case. When I look at this case, the question is: can PAWS be=20 >>>>>> used to allow multiple Master devices to knowingly select the=20 >>>>>> same channel for operation. (The discussion of "why" and "is it a=20 >>>>>> good idea" not undertaken here as this likely wanders outside the=20 >>>>>> scope of PAWS). >>>>>>=20 >>>>>> One of the proposed solutions is coordination among BSs (external=20 >>>>>> to PAWS). This is already described in section 4.3 Wide-Area or=20 >>>>>> Rural internet broadband access: >>>>>>=20 >>>>>>> Some of the masters/BSs may be deployed and operated by a single=20 >>>>>>> entity, i.e. there can be centralized coordination between these=20 >>>>>>> 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=20 >>>>>> "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=20 >>>>> 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=20 >>>>>>> case, and I think it would be a possible candidate for inclusion=20 >>>>>>> in the document if it were properly explained. >>>>>>>=20 >>>>>>> Generally (as opposed to specifically for the LTE MBMS case),=20 >>>>>>> the problem is to find a common bit of spectrum that is=20 >>>>>>> available over a wide area that can be used by multiple master=20 >>>>>>> BSs to simultaneously broadcast the same signal to a set of receive= rs. >>>>>>> This is somewhat similar to the wide-area rural coverage=20 >>>>>>> scenario currently described in the working group document;=20 >>>>>>> however, there would be multiple Master BSs, each of which would=20 >>>>>>> independently query the WSDB for available spectrum. However,=20 >>>>>>> they need to coordinate the assignment so that they all get the=20 >>>>>>> same spectrum over the whole area. As an implementation example,=20 >>>>>>> this could be achieved by each BS reporting the same=20 >>>>>>> owner/operator and using a key or index value to indicate that=20 >>>>>>> they wanted to coordinate the assignment. Alternatively, you=20 >>>>>>> might be able to elect one BS as the leader and collect location=20 >>>>>>> information from all the other BSs and then coordinate the=20 >>>>>>> assignment similar to the use case in 4.2; the difference would=20 >>>>>>> be that the resulting assignment is for simultaneous (not TDD)=20 >>>>>>> use by all of the BSs covering the wider area. >>>>>>>=20 >>>>>>> Does this sound like an interesting and novel use case? If so I=20 >>>>>>> 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 pecclesi@cisco.com Wed Oct 12 15:35: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 14ECD21F854F for ; Wed, 12 Oct 2011 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, 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 hJWMesndajhI for ; Wed, 12 Oct 2011 15:35:55 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBC021F851A for ; Wed, 12 Oct 2011 15:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pecclesi@cisco.com; l=15554; q=dns/txt; s=iport; t=1318458955; x=1319668555; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=o4NoB7iRleHjHd9v8Sn+KdFRUoDwQq1HAySjvkEZlE4=; b=Mg1UdHLMIZwPmzG4l4sbSIc7bczF3pGetOQdBeM5kHBWYJEi5xH/cNgJ 5z6W9caYaEDxCJgfD5vHhh02Ep+0ZZ+mt2fb5gRdfsLlGBnoa+X2cxGrC 0/zE5699laDQBYhn0VZH530b3U1k0a9Fw2vFLuZgeQId/dJNNa9vNZ8jY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosAAHsVlk6rRDoG/2dsb2JhbABAA4JNllNEhykBhzOBBYFTAQEBAQECAQEBDwEJEQM+GwIBCBEDAQEBCwYXAQYBJh8JCAEBBAESCBqHZJo3AZ5FhEOCNGEEh3+RJ4xD X-IronPort-AV: E=Sophos;i="4.69,337,1315180800"; d="scan'208,217";a="7511031" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 12 Oct 2011 22:35:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9CMZtos016459; Wed, 12 Oct 2011 22:35:55 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 15:35:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC892F.4D83CCD9" Date: Wed, 12 Oct 2011 15:35:52 -0700 Message-ID: <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A//5MhEA= References: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.com> From: "Peter Ecclesine (pecclesi)" To: , X-OriginalArrivalTime: 12 Oct 2011 22:35:54.0975 (UTC) FILETIME=[4DDDC6F0:01CC892F] Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 12 Oct 2011 22:35:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC892F.4D83CCD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj, =20 The requirement for the protocol is to describe to the database the EIRP limits that will not be exceeded for each occupied bandwidth in each frequency band, for master devices and for client devices (these are the client spectrum masks I will permit to operate under my control). =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios =20 =20 So what would be the requirement that we can specify for the (device-2-database) protocol as a result of the need for various spectrum masks? =20 From: "ext Peter Ecclesine (pecclesi)" Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" Subject: [paws] Several spectrum masks used by multi-bandwidth radios =20 In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, with several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UHF). =20 We see the need to tell the database several spectrum masks, each with: 1 - Lowest applicable frequency in MHz 2 - Highest applicable frequency in MHz 3 - Maximum total EIRP over the frequency range defined by the spectrum mask 4 - General spectrum mask in dBr from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FCC 47 C.F.R. 90.210(m).=20 5- measurement resolution bandwidth for EIRP measurements =20 This detailed actual spectrum occupancy information allows the database to perform more accurate interference calculations. =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws=20 ------_=_NextPart_001_01CC892F.4D83CCD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raj,

 

The requirement for the = protocol is to describe to the database the EIRP limits that will not be = exceeded for each occupied bandwidth in each frequency band, for master = devices and for client devices (these are the client spectrum masks I = will permit to operate under my control).

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without = Prejudice" U.C.C. 1-207

From:= = Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] =
Sent: Tuesday, October 11, 2011 8:30 PM
To: Peter = Ecclesine (pecclesi); paws@ietf.org
Subject: Re: [paws] = Several spectrum masks used by multi-bandwidth = radios

 

 

=

So what would be the requirement = that we can specify for the (device-2-database) protocol as a result of = the need for various spectrum masks?

 

=

From: = "ext Peter Ecclesine = (pecclesi)" <pecclesi@cisco.com>
Date:= Tue, 11 Oct 2011 19:52:32 -0700
To: "paws@ietf.org" <paws@ietf.org>
Subject: = [paws] Several spectrum masks used by multi-bandwidth = radios

 

=

In IEEE = 802.11af discussions, we expect to use a modified 802.11ac PHY, with = several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in = several TV bands (VHF and UHF).

 

We see the need to tell = the database several spectrum masks, each with:

        &= nbsp;       1 – Lowest applicable = frequency in MHz

        &= nbsp;       2 – Highest applicable = frequency in MHz

        &= nbsp;       3 – Maximum total EIRP = over the frequency range defined by the spectrum mask

        &= nbsp;       4 – General spectrum = mask in dBr from peak transmit power in EIRP, with specific power limit = at any frequency linearly interpolated between adjacent points of the = spectrum mask, expressed like IEEE 802.11p Annex I [h= ttp://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or = FCC 47 C.F.R. 90.210(m).

        &= nbsp;       5- measurement resolution = bandwidth for EIRP measurements

 

   This detailed actual spectrum = occupancy information allows the database to perform more accurate = interference calculations.

 

petere

P= eter Ecclesine, Technology Analyst

M= S SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

P= h 408/527-0815, FAX 408/525-9256

&= quot;Time doesn't fool around."  "Without Prejudice" = U.C.C. 1-207

__________________________________= _____________ paws mailing list paws@ietf.org https://www.ietf.org/= mailman/listinfo/paws

------_=_NextPart_001_01CC892F.4D83CCD9-- From brian.rosen@neustar.biz Wed Oct 12 16:20: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 8726021F8549 for ; Wed, 12 Oct 2011 16:20: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CeIVQQuDZn6D for ; Wed, 12 Oct 2011 16:20:55 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 76BA521F8560 for ; Wed, 12 Oct 2011 16:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1318461686; x=1633813161; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=TY85GKxGwcbr41etAg5k7fohlgcuyqREN6jMYciGt4g=; b=KCIbftzJLkbelqJURz6VAVi17ZFeqDt1SMghYFITsdWVc7AJrSj5PheqhS7fVP pJ6RhFCsfURHTEbHlMQ4cULw== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.859302; Wed, 12 Oct 2011 19:21:25 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 12 Oct 2011 19:20:51 -0400 From: "Rosen, Brian" To: "Peter Ecclesine (pecclesi)" Date: Wed, 12 Oct 2011 19:20:50 -0400 Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyJNZSYigauQAklT3appd+qlTdEHw== Message-ID: <9230B5FF-F42D-4844-9D50-B40CFA2E9118@neustar.biz> References: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.com> <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.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: fjuePxeQU0gtim80+LpmZQ== Content-Type: multipart/alternative; boundary="_000_9230B5FFF42D48449D50B40CFA2E9118neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 12 Oct 2011 23:20:56 -0000 --_000_9230B5FFF42D48449D50B40CFA2E9118neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yeah, I think some form of power level on the input is needed, and I think = some form of power output is needed. I think we need to figure out if this is an actual watt value, or rather an= enumerated list + registry that accounts for differences in each nation's = regulations. Brian On Oct 12, 2011, at 6:35 PM, Peter Ecclesine (pecclesi) wrote: Hi Raj, The requirement for the protocol is to describe to the database the EIRP li= mits that will not be exceeded for each occupied bandwidth in each frequenc= y band, for master devices and for client devices (these are the client spe= ctrum masks I will permit to operate under my control). petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios So what would be the requirement that we can specify for the (device-2-data= base) protocol as a result of the need for various spectrum masks? From: "ext Peter Ecclesine (pecclesi)" > Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" > Subject: [paws] Several spectrum masks used by multi-bandwidth radios In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, wit= h several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in seve= ral TV bands (VHF and UHF). We see the need to tell the database several spectrum masks, each with: 1 =96 Lowest applicable frequency in MHz 2 =96 Highest applicable frequency in MHz 3 =96 Maximum total EIRP over the frequency range defined b= y the spectrum mask 4 =96 General spectrum mask in dBr from peak transmit power= in EIRP, with specific power limit at any frequency linearly interpolated = between adjacent points of the spectrum mask, expressed like IEEE 802.11p A= nnex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or = FCC 47 C.F.R. 90.210(m). 5- measurement resolution bandwidth for EIRP measurements This detailed actual spectrum occupancy information allows the database = to perform more accurate interference calculations. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ 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 --_000_9230B5FFF42D48449D50B40CFA2E9118neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi= Raj,
&nb= sp;
The requirement= for the protocol is to describe to the database the EIRP limits that will = not be exceeded for each occupied bandwidth in each frequency band, for mas= ter devices and for client devices (these are the client spectrum masks I w= ill permit to operate under my control).
 
petere
Peter E= cclesine, Technology Analyst
MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706
Ph 408/527-= 0815, FAX 408/525-9256
"Time doesn't fool around."  "Without Prejudice" U.= C.C. 1-207
From: Basavaraj.Patil@nokia.com [mailto= :Basavaraj.Patil@nokia.com] 
Sent: Tuesd= ay, October 11, 2011 8:30 PM
To: Peter Ecclesine (pecclesi); paws@ietf.org
Subject: Re: [paws] Several spectrum masks used by multi-bandwidth r= adios
 
 
So what would be the requir= ement that we can specify for the (device-2-database) protocol as a result = of the need for various spectrum masks?
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "> 
=
From: "ext Peter E= cclesine (pecclesi)" <pecclesi@cisco.com>
Da= te: Tue, 11 Oct 2011 = 19:52:32 -0700
To: = "paws@ietf.org" <paws@ietf.org>
Subject: [paws] Seve= ral spectrum masks used by multi-bandwidth radios
 
In IEEE 802.11af discu= ssions, we expect to use a modified 802.11ac PHY, with several occupied ban= dwidths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and = UHF).
 
We see the need to tell the database = several spectrum masks, each with:
         =        1 =96 Lowest applicable frequency in M= Hz
        = ;        2 =96 Highest applicable freque= ncy in MHz
      &nbs= p;         3 =96 Maximum total EIRP= over the frequency range defined by the spectrum mask
            = ;    4 =96 General spectrum mask in dBr from peak transmit p= ower in EIRP, with specific power limit at any frequency linearly interpola= ted between adjacent points of the spectrum mask, expressed like IEEE 802.1= 1p Annex I [http://stan= dards.ieee.org/getieee802/download/802.11p-2010.pdf] or FCC 47 C.F.R. 9= 0.210(m).
       = ;         5- measurement resolution= bandwidth for EIRP measurements=
 
   This detailed actual spectrum occupancy information al= lows the database to perform more accurate interference calculations.<= /o:p>
 
=
petere
Peter Ecclesine, = Technology Analyst<= /div>
MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706
Ph 408/527-0815, FAX 408/52= 5-9256
"Time = doesn't fool around."  "Without Prejudice" U.C.C. 1-207
_____________________________________________= __ paws mailing list paws@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/paws" style=3D"color: blue;= text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/paws
___________________________________________= ____
paws mailing list
paws@ietf.org=
https://www.ietf.org/mailman/listinfo/paws

= --_000_9230B5FFF42D48449D50B40CFA2E9118neustarbiz_-- From paul@marvell.com Wed Oct 12 16:29: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 B8CC321F8B43 for ; Wed, 12 Oct 2011 16:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 sXYop7qLvb-9 for ; Wed, 12 Oct 2011 16:29:30 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id F02E221F8B04 for ; Wed, 12 Oct 2011 16:29:29 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP; Wed, 12 Oct 2011 16:29:30 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 12 Oct 2011 16:28:37 -0700 From: Paul Lambert To: "Rosen, Brian" Date: Wed, 12 Oct 2011 16:28:36 -0700 Thread-Topic: [paws] Testing and certification for devices using PAWS Thread-Index: AcyJFCgxWjFez/E9RP+dmwsTXi4w4AAIkinQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9123@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD8E9E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9058@SC-VEXCH2.marvell.com> <57901E01-976B-4315-BA06-16643D3E47E9@neustar.biz> In-Reply-To: <57901E01-976B-4315-BA06-16643D3E47E9@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Testing and certification for devices using PAWS 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, 12 Oct 2011 23:29:30 -0000 Humm ... seems like this could all be done with backdoors in the implementa= tion or agreements on identified trusted database authorizes to provide tes= ting facilities. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Wednesday, October 12, 2011 12:22 PM > To: Paul Lambert > Cc: Basavaraj.Patil@nokia.com; paws@ietf.org > Subject: Re: [paws] Testing and certification for devices using PAWS >=20 > > Having looked into this a bit, my opinion is that the protocol does not > need any special facility to support this kind of testing. If you > think it does, perhaps an example would be helpful. >=20 > Brian >=20 > On Oct 12, 2011, at 3:13 PM, Paul Lambert wrote: >=20 > >> IMO this is beyond the scope of the actual protocol itself. > > Perhaps - but the testability of the system has some unique issues. > Some of the solutions might include modifications to the protocol. > > > > Paul > > > > > >> -----Original Message----- > >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > >> Sent: Tuesday, October 11, 2011 7:54 PM > >> To: Paul Lambert; paws@ietf.org > >> Subject: Re: [paws] Testing and certification for devices using PAWS > >> > >> > >> Hi Paul, > >> > >> Your comment below relates to how testing of the protocol between > >> devices > >> to databases is done. > >> IMO this is beyond the scope of the actual protocol itself. > >> > >> I do see the need for testing to be done in a lab with various > location > >> settings. But this could potentially be simulated or emulated or > >> manipulated with some lab setting. > >> > >> -Raj > >> > >> On 10/11/11 7:21 PM, "ext Paul Lambert" wrote: > >> > >>> Seems like we need to consider testing and certification of WS > >> devices. > >>> > >>> How do we run tests? > >>> How do we ensure access to databases of multiple regulatory > >> authorities > >>> in multiple locations? > >>> How do we control location? Can location be set for testing? > >>> Are special back doors required to GDBs? > >>> How do we establish different frequency grants for testing > purposes? > >>> > >>> Requirements: > >>> Device-to-GDB must have facilities for testing to: > >>> - test multiple locations > >>> - test multiple GBD and Regional Authority GDBs > >>> - test various frequency grants from a fixed testbed > >>> - support international test houses > >>> > >>> We will need real databases to have special limited backdoor for > >> testing > >>> and certification. > >>> > >>> Paul > >>> > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Wed Oct 12 19:09: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 7522521F8B00 for ; Wed, 12 Oct 2011 19:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 afydiMdAu5iA for ; Wed, 12 Oct 2011 19:09:29 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3868821F893C for ; Wed, 12 Oct 2011 19:09:29 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP; Wed, 12 Oct 2011 19:09:29 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 12 Oct 2011 19:09:14 -0700 From: Paul Lambert To: "paws@ietf.org" Date: Wed, 12 Oct 2011 19:09:11 -0700 Thread-Topic: US White Space XML blueprints emitted Thread-Index: AcyJTRl5SeBhhCWNRGea8/vJNqy+sg== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9185@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B8QE CYxa Di80 DsmT D02k EB3X Em9K FC2W HRLa Hohc H2MQ Jm12 Jset KweJ LDmI LNMD; 1; cABhAHcAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {C9ED5773-544A-47DB-B3AB-50DF3E77358D}; cABhAHUAbABAAG0AYQByAHYAZQBsAGwALgBjAG8AbQA=; Thu, 13 Oct 2011 02:09:11 GMT; VQBTACAAVwBoAGkAdABlACAAUwBwAGEAYwBlACAAWABNAEwAIABiAGwAdQBlAHAAcgBpAG4AdABzACAAZQBtAGkAdAB0AGUAZAA= x-cr-puzzleid: {C9ED5773-544A-47DB-B3AB-50DF3E77358D} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9185SCVEXCH2marve_" MIME-Version: 1.0 Subject: [paws] US White Space XML blueprints emitted 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, 13 Oct 2011 02:09:30 -0000 X-List-Received-Date: Thu, 13 Oct 2011 02:09:30 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9185SCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting reference for data in FCC WS Databases: http://www.theregister.co.uk/2011/10/12/white_space_xml/ Paul --_000_7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9185SCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Interesting reference for data in FCC WS Databases:

http://ww= w.theregister.co.uk/2011/10/12/white_space_xml/

 

Paul

 

--_000_7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9185SCVEXCH2marve_-- From scott.probasco@nokia.com Thu Oct 13 08:50: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 34B7021F8B16 for ; Thu, 13 Oct 2011 08:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYQvb8EIkuiB for ; Thu, 13 Oct 2011 08:50:32 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D989921F8B1A for ; Thu, 13 Oct 2011 08:50:31 -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 p9DFoFlv027660 for ; Thu, 13 Oct 2011 18:50:30 +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, 13 Oct 2011 18:50:17 +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; Thu, 13 Oct 2011 17:50:15 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.151]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0339.002; Thu, 13 Oct 2011 17:50:15 +0200 From: To: Thread-Topic: Mobility Use Case Thread-Index: AQHMib/M0pMW9GFXU06V+eAlBrS3dw== Date: Thu, 13 Oct 2011 15:50:14 +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.13.0.110805 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: 13 Oct 2011 15:50:17.0898 (UTC) FILETIME=[CE4048A0:01CC89BF] X-Nokia-AV: Clean Subject: [paws] Mobility Use Case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 15:50:33 -0000 Hi, I have not seen any comments on the mobility use case below. If the work group is OK with the use case, it will be included in the next update of the draft. Regards, Scott On 9/30/11 7:12 AM, "ext scott.probasco@nokia.com" wrote: >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 >>> >> > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Thu Oct 13 09:01:20 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 E460C21F8569 for ; Thu, 13 Oct 2011 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 on+Oxt74y74S for ; Thu, 13 Oct 2011 09:01:18 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1915C21F84D3 for ; Thu, 13 Oct 2011 09:01:17 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9DG1E4d030138; Thu, 13 Oct 2011 19:01:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 19:01:13 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 13 Oct 2011 18:01:13 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.208]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Thu, 13 Oct 2011 18:01:13 +0200 From: To: , Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A//5MhED//TS5YA== Date: Thu, 13 Oct 2011 16:01:12 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719AD7387@008-AM1MPN1-053.mgdnok.nokia.com> References: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.com> <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7InvQ7AKN3wtkoulcln9yQnYc5BtV49MfuqCrnRM9ZKjhpzQTWt7t8C+7pwwLFYtydotYxReZiUypP/i51sFJAjn4hHTuk0c0Y3G1hRO1yqMlMhQLLDIp9AuM3Qhmg+sMhTXSiISTzIYLKI5EkOPIssc4g3hEscHlH2EyXy713GreGvlNdg5DpXDQIarcMgcNAH2CLFImdtPQo0ftUxhMOnkft5qM60lzVzeJsclEYYMhQwScg7mfcmH2MweAiceedQ== x-originating-ip: [173.74.219.186] Content-Type: multipart/alternative; boundary="_000_21E7D9BD69CC7241AAE00F4EA183B719AD7387008AM1MPN1053mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2011 16:01:13.0848 (UTC) FILETIME=[553A4F80:01CC89C1] X-Nokia-AV: Clean Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 13 Oct 2011 16:01:21 -0000 --_000_21E7D9BD69CC7241AAE00F4EA183B719AD7387008AM1MPN1053mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, So how about the following text that we could add in the requirements secti= on of the I-D: - A white space master device should provide to the database in th= e query a description of the EIRP limits that will not be exceeded for each= occupied bandwidth in the set of frequency bands. You indicated that this is applicable to master devices and client devices.= How is it relevant for client devices? It is only the master device that i= s generally making a query to the database. Clients devices can no doubt ma= ke the query as well, but would this requirement be applicable in such a ca= se? -Raj From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com] Sent: Wednesday, October 12, 2011 5:36 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios Hi Raj, The requirement for the protocol is to describe to the database the EIRP li= mits that will not be exceeded for each occupied bandwidth in each frequenc= y band, for master devices and for client devices (these are the client spe= ctrum masks I will permit to operate under my control). petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios So what would be the requirement that we can specify for the (device-2-data= base) protocol as a result of the need for various spectrum masks? From: "ext Peter Ecclesine (pecclesi)" > Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" > Subject: [paws] Several spectrum masks used by multi-bandwidth radios In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, wit= h several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in seve= ral TV bands (VHF and UHF). We see the need to tell the database several spectrum masks, each with: 1 - Lowest applicable frequency in MHz 2 - Highest applicable frequency in MHz 3 - Maximum total EIRP over the frequency range defined by = the spectrum mask 4 - General spectrum mask in dBr from peak transmit power i= n EIRP, with specific power limit at any frequency linearly interpolated be= tween adjacent points of the spectrum mask, expressed like IEEE 802.11p Ann= ex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FC= C 47 C.F.R. 90.210(m). 5- measurement resolution bandwidth for EIRP measurements This detailed actual spectrum occupancy information allows the database = to perform more accurate interference calculations. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_21E7D9BD69CC7241AAE00F4EA183B719AD7387008AM1MPN1053mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

So how about the follo= wing text that we could add in the requirements section of the I-D:

 

-&nb= sp;         A white space = master device should provide to the database in the query a description of = the EIRP limits that will not be exceeded for each occupied bandwidth in th= e set of frequency bands.

 

You indicated that thi= s is applicable to master devices and client devices. How is it relevant fo= r client devices? It is only the master device that is generally making a q= uery to the database. Clients devices can no doubt make the query as well, but would this requirement be applica= ble in such a case?

 

-Raj=

 

From: ext Pete= r Ecclesine (pecclesi) [mailto:pecclesi@cisco.com]
Sent: Wednesday, October 12, 2011 5:36 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org
Subject: RE: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

Hi Raj,

 

The requirement for th= e protocol is to describe to the database the EIRP limits that will not be = exceeded for each occupied bandwidth in each frequency band, for master dev= ices and for client devices (these are the client spectrum masks I will permit to operate under my control).=

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, = CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#1F497D">

"Time doesn't fool aro= und."  "Without Prejudice" U.C.C. 1-207

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, October 11, 2011 8:30 PM
To: Peter Ecclesine (pecclesi); paw= s@ietf.org
Subject: Re: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

&n= bsp;

So what= would be the requirement that we can specify for the (device-2-database) p= rotocol as a result of the need for various spectrum masks?

&n= bsp;

From: "ext Peter Ecclesine (pecclesi)" <pecclesi@cisco.com>
Date: Tue, 11 Oct 2011 19:52:32 -0700
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] Several spectrum masks used by multi-bandwidth radio= s

&n= bsp;

In IEEE 802.11af discuss= ions, we expect to use a modified 802.11ac PHY, with several occupied bandw= idths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UH= F).

 =

We see the need to tell = the database several spectrum masks, each with:

   &nbs= p;            1 R= 11; Lowest applicable frequency in MHz

   &nbs= p;            2 R= 11; Highest applicable frequency in MHz<= o:p>

   &nbs= p;            3 R= 11; Maximum total EIRP over the frequency range defined by the spectrum mas= k

   &nbs= p;            4 R= 11; General spectrum mask in dBr from peak transmit power in EIRP, with spe= cific power limit at any frequency linearly interpolated between adjacent p= oints of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11= p-2010.pdf] or FCC 47 C.F.R. 90.210(m).

   &nbs= p;            5- mea= surement resolution bandwidth for EIRP measurements

 <= /span>

   This detail= ed actual spectrum occupancy information allows the database to perform mor= e accurate interference calculations.

 =

petere=

Peter Ecclesine, Technology Analyst<= span style=3D"color:black">

MS SJ-14-4 170 West Tasman Dr, San Jose, CA= 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool aroun= d."  "Without Prejudice" U.C.C. 1-207

_______= ________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_21E7D9BD69CC7241AAE00F4EA183B719AD7387008AM1MPN1053mgdn_-- From pecclesi@cisco.com Thu Oct 13 13: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 1DA1C21F8A55 for ; Thu, 13 Oct 2011 13:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, 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 yUOptgwNsrp5 for ; Thu, 13 Oct 2011 13:36:19 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7128121F886A for ; Thu, 13 Oct 2011 13:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pecclesi@cisco.com; l=26415; q=dns/txt; s=iport; t=1318538179; x=1319747779; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=UIKZG/DSLSgh6PLQXFQHDhaVPIfdEokFJaTzDzwQcLc=; b=OV3/UqueoZ9B4xHQaDYSXNtD1+TY5DtfHnI+xvgUHgHsvNVczx3U2zuk tDZ4EhIOVVBEuewHUnsDhCKVvP01ZiFaqYyEpVuabDWLCjvAFQfzKagLx Igp3S8aXtIxbHRKYcIbEZgqpNdTeoR9lIUeE3KRThLfJ3i4pHqwBureAy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcAAKhKl06rRDoI/2dsb2JhbABAA4JNlmhEhykBhziBBYFTAQEBAgEBAQEBDwEJEQM+GwIBCBEDAQEBCwYQBwEGASYfCQgBAQQBEggah1wImRUBnimEWII0YQSIAZEojEQ X-IronPort-AV: E=Sophos;i="4.69,342,1315180800"; d="scan'208,217";a="7716354" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 13 Oct 2011 20:36:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9DKaC6J030030; Thu, 13 Oct 2011 20:36:19 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 13:36:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC89E7.BFCF9294" Date: Thu, 13 Oct 2011 13:36:12 -0700 Message-ID: <30D62D93EA229643933BE9BF324FD1F30CF5F220@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719AD7387@008-AM1MPN1-053.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A//5MhED//TS5YP/4XdVA References: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.com> <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.com> <21E7D9BD69CC7241AAE00F4EA183B719AD7387@008-AM1MPN1-053.mgdnok.nokia.com> From: "Peter Ecclesine (pecclesi)" To: , X-OriginalArrivalTime: 13 Oct 2011 20:36:13.0913 (UTC) FILETIME=[C0086C90:01CC89E7] Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 13 Oct 2011 20:36:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC89E7.BFCF9294 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj, =20 >> How is it relevant for client devices? It is only the master device that is generally making a query to the database. Clients devices can no doubt make the query as well, but would this requirement be applicable in such a case?<< =20 The database either makes assumptions about the transmissions of all client devices, or it can be informed what emissions the client devices will not exceed (because the master device will not allow clients to exceed specified limits).=20 =20 The general case is not all devices transmit with the same masks - relatively loose-masked inexpensive devices can joint networks controlled by higher-specification master devices - e.g., outdoor muni wi-fi. =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Thursday, October 13, 2011 9:01 AM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios =20 Hi Peter, =20 So how about the following text that we could add in the requirements section of the I-D: =20 - A white space master device should provide to the database in the query a description of the EIRP limits that will not be exceeded for each occupied bandwidth in the set of frequency bands.=20 =20 You indicated that this is applicable to master devices and client devices. How is it relevant for client devices? It is only the master device that is generally making a query to the database. Clients devices can no doubt make the query as well, but would this requirement be applicable in such a case? =20 -Raj =20 From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com]=20 Sent: Wednesday, October 12, 2011 5:36 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios =20 Hi Raj, =20 The requirement for the protocol is to describe to the database the EIRP limits that will not be exceeded for each occupied bandwidth in each frequency band, for master devices and for client devices (these are the client spectrum masks I will permit to operate under my control). =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios =20 =20 So what would be the requirement that we can specify for the (device-2-database) protocol as a result of the need for various spectrum masks? =20 From: "ext Peter Ecclesine (pecclesi)" Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" Subject: [paws] Several spectrum masks used by multi-bandwidth radios =20 In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, with several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UHF). =20 We see the need to tell the database several spectrum masks, each with: 1 - Lowest applicable frequency in MHz 2 - Highest applicable frequency in MHz 3 - Maximum total EIRP over the frequency range defined by the spectrum mask 4 - General spectrum mask in dBr from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FCC 47 C.F.R. 90.210(m).=20 5- measurement resolution bandwidth for EIRP measurements =20 This detailed actual spectrum occupancy information allows the database to perform more accurate interference calculations. =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws=20 ------_=_NextPart_001_01CC89E7.BFCF9294 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raj,

 

>> How is it relevant for client devices? It is = only the master device that is generally making a query to the database. = Clients devices can no doubt make the query as well, but would this = requirement be applicable in such a = case?<<

 

   The = database either makes assumptions about the transmissions of all client = devices, or it can be informed what emissions the client devices will = not exceed (because the master device will not allow clients to exceed = specified limits).

 

   The general = case is not all devices transmit with the same masks – relatively = loose-masked inexpensive devices can joint networks controlled by = higher-specification master devices – e.g., outdoor muni = wi-fi.

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without = Prejudice" U.C.C. 1-207

From:= = Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] =
Sent: Thursday, October 13, 2011 9:01 AM
To: Peter = Ecclesine (pecclesi); paws@ietf.org
Subject: RE: [paws] = Several spectrum masks used by multi-bandwidth = radios

 

Hi Peter,

 

So how about the = following text that we could add in the requirements section of the = I-D:

 

-          = A white = space master device should provide to the database in the query a = description of the EIRP limits that will not be exceeded for each = occupied bandwidth in the set of frequency bands. =

 

You indicated that this = is applicable to master devices and client devices. How is it relevant = for client devices? It is only the master device that is generally = making a query to the database. Clients devices can no doubt make the = query as well, but would this requirement be applicable in such a = case?

 

-Raj

 

From:= = ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com] =
Sent: Wednesday, October 12, 2011 5:36 PM
To: Patil = Basavaraj (Nokia-CIC/Dallas); paws@ietf.org
Subject: RE: = [paws] Several spectrum masks used by multi-bandwidth = radios

 

Hi Raj,

 

The requirement for the = protocol is to describe to the database the EIRP limits that will not be = exceeded for each occupied bandwidth in each frequency band, for master = devices and for client devices (these are the client spectrum masks I = will permit to operate under my control).

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without = Prejudice" U.C.C. 1-207

From:= = Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Pati= l@nokia.com]
Sent: Tuesday, October 11, 2011 8:30 = PM
To: Peter Ecclesine (pecclesi); paws@ietf.org
Subject: Re: = [paws] Several spectrum masks used by multi-bandwidth = radios

 

 

=

So what would be the requirement = that we can specify for the (device-2-database) protocol as a result of = the need for various spectrum masks?

 

=

From: = "ext Peter Ecclesine = (pecclesi)" <pecclesi@cisco.com>
Date:= Tue, 11 Oct 2011 19:52:32 -0700
To: "paws@ietf.org" <paws@ietf.org>
Subject: = [paws] Several spectrum masks used by multi-bandwidth = radios

 

=

In IEEE = 802.11af discussions, we expect to use a modified 802.11ac PHY, with = several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in = several TV bands (VHF and UHF).

 

We see the need to tell = the database several spectrum masks, each with:

        &= nbsp;       1 – Lowest applicable = frequency in MHz

        &= nbsp;       2 – Highest applicable = frequency in MHz

        &= nbsp;       3 – Maximum total EIRP = over the frequency range defined by the spectrum mask

        &= nbsp;       4 – General spectrum = mask in dBr from peak transmit power in EIRP, with specific power limit = at any frequency linearly interpolated between adjacent points of the = spectrum mask, expressed like IEEE 802.11p Annex I [h= ttp://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or = FCC 47 C.F.R. 90.210(m).

        &= nbsp;       5- measurement resolution = bandwidth for EIRP measurements

 

   This detailed actual spectrum = occupancy information allows the database to perform more accurate = interference calculations.

 

petere

P= eter Ecclesine, Technology Analyst

M= S SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

P= h 408/527-0815, FAX 408/525-9256

&= quot;Time doesn't fool around."  "Without Prejudice" = U.C.C. 1-207

__________________________________= _____________ paws mailing list paws@ietf.org https://www.ietf.org/= mailman/listinfo/paws

------_=_NextPart_001_01CC89E7.BFCF9294-- From Basavaraj.Patil@nokia.com Thu Oct 13 13:42: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 E873121F8B34 for ; Thu, 13 Oct 2011 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aHP+aUK2u1Xn for ; Thu, 13 Oct 2011 13:42:07 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2B021F8726 for ; Thu, 13 Oct 2011 13:42:07 -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 p9DKg4nU001614; Thu, 13 Oct 2011 23:42:04 +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); Thu, 13 Oct 2011 23:42:00 +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, 13 Oct 2011 22:41:58 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.208]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Thu, 13 Oct 2011 22:41:58 +0200 From: To: , Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A//5MhED//TS5YP/4XdVA//C4ExA= Date: Thu, 13 Oct 2011 20:41:57 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719ADA25C@008-AM1MPN1-053.mgdnok.nokia.com> References: <30D62D93EA229643933BE9BF324FD1F30CF5ED53@xmb-sjc-22b.amer.cisco.com> <30D62D93EA229643933BE9BF324FD1F30CF5EFDF@xmb-sjc-22b.amer.cisco.com> <21E7D9BD69CC7241AAE00F4EA183B719AD7387@008-AM1MPN1-053.mgdnok.nokia.com> <30D62D93EA229643933BE9BF324FD1F30CF5F220@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <30D62D93EA229643933BE9BF324FD1F30CF5F220@xmb-sjc-22b.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7InvQ7AKN3wtkoulcln9yQnYc5BtV49MfuqCrnRM9ZKjhpzQTWt7t8C+7pwwLFYtydotYxReZiUypP/i51sFJAjn4hHTuk0c0Y3G1hRO1yqMlMhQLLDIp9AuM3Qhmg+sMhTXSiISTzIYLKI5EkOPIssc4g3hEscHlH2EyXy713GreGvlNdg5DpXDQIarcMgcNAH2CLFImdtPQo0ftUxhMOnkft5qM60lzVzeJsclEYYMhQwScg7mfcmH2MweAiceedQ== x-originating-ip: [172.19.59.28] Content-Type: multipart/alternative; boundary="_000_21E7D9BD69CC7241AAE00F4EA183B719ADA25C008AM1MPN1053mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2011 20:42:00.0855 (UTC) FILETIME=[8ED39270:01CC89E8] X-Nokia-AV: Clean Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 13 Oct 2011 20:42:11 -0000 --_000_21E7D9BD69CC7241AAE00F4EA183B719ADA25C008AM1MPN1053mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, The database making assumptions about the transmissions of client devices i= s not a good idea. It is preferable for the master device to inform the DB = about client device transmission limits that it will enforce. Thanks for the clarification. -Raj From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com] Sent: Thursday, October 13, 2011 3:36 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios Hi Raj, >> How is it relevant for client devices? It is only the master device that= is generally making a query to the database. Clients devices can no doubt = make the query as well, but would this requirement be applicable in such a = case?<< The database either makes assumptions about the transmissions of all cli= ent devices, or it can be informed what emissions the client devices will n= ot exceed (because the master device will not allow clients to exceed speci= fied limits). The general case is not all devices transmit with the same masks - relat= ively loose-masked inexpensive devices can joint networks controlled by hig= her-specification master devices - e.g., outdoor muni wi-fi. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: Thursday, October 13, 2011 9:01 AM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios Hi Peter, So how about the following text that we could add in the requirements secti= on of the I-D: - A white space master device should provide to the database in th= e query a description of the EIRP limits that will not be exceeded for each= occupied bandwidth in the set of frequency bands. You indicated that this is applicable to master devices and client devices.= How is it relevant for client devices? It is only the master device that i= s generally making a query to the database. Clients devices can no doubt ma= ke the query as well, but would this requirement be applicable in such a ca= se? -Raj From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com] Sent: Wednesday, October 12, 2011 5:36 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios Hi Raj, The requirement for the protocol is to describe to the database the EIRP li= mits that will not be exceeded for each occupied bandwidth in each frequenc= y band, for master devices and for client devices (these are the client spe= ctrum masks I will permit to operate under my control). petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios So what would be the requirement that we can specify for the (device-2-data= base) protocol as a result of the need for various spectrum masks? From: "ext Peter Ecclesine (pecclesi)" > Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" > Subject: [paws] Several spectrum masks used by multi-bandwidth radios In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, wit= h several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in seve= ral TV bands (VHF and UHF). We see the need to tell the database several spectrum masks, each with: 1 - Lowest applicable frequency in MHz 2 - Highest applicable frequency in MHz 3 - Maximum total EIRP over the frequency range defined by = the spectrum mask 4 - General spectrum mask in dBr from peak transmit power i= n EIRP, with specific power limit at any frequency linearly interpolated be= tween adjacent points of the spectrum mask, expressed like IEEE 802.11p Ann= ex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FC= C 47 C.F.R. 90.210(m). 5- measurement resolution bandwidth for EIRP measurements This detailed actual spectrum occupancy information allows the database = to perform more accurate interference calculations. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_21E7D9BD69CC7241AAE00F4EA183B719ADA25C008AM1MPN1053mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

The database making as= sumptions about the transmissions of client devices is not a good idea. It = is preferable for the master device to inform the DB about client device tr= ansmission limits that it will enforce.

 

Thanks for the clarifi= cation.

 

-Raj=

 

From: ext Pete= r Ecclesine (pecclesi) [mailto:pecclesi@cisco.com]
Sent: Thursday, October 13, 2011 3:36 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org
Subject: RE: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

Hi Raj,

 

>> How is it rel= evant for client devices? It is only the master device that is generally ma= king a query to the database. Clients devices can no doubt make the query a= s well, but would this requirement be applicable in such a case?<<

 

   The datab= ase either makes assumptions about the transmissions of all client devices,= or it can be informed what emissions the client devices will not exceed (b= ecause the master device will not allow clients to exceed specified limits).

 

   The gener= al case is not all devices transmit with the same masks – relatively = loose-masked inexpensive devices can joint networks controlled by higher-sp= ecification master devices – e.g., outdoor muni wi-fi.

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, = CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#1F497D">

"Time doesn't fool aro= und."  "Without Prejudice" U.C.C. 1-207

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.com]
Sent: Thursday, October 13, 2011 9:01 AM
To: Peter Ecclesine (pecclesi); paw= s@ietf.org
Subject: RE: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

Hi Peter,

 

So how about the follo= wing text that we could add in the requirements section of the I-D:

 

-&nb= sp;         A white space = master device should provide to the database in the query a description of = the EIRP limits that will not be exceeded for each occupied bandwidth in th= e set of frequency bands.

 

You indicated that thi= s is applicable to master devices and client devices. How is it relevant fo= r client devices? It is only the master device that is generally making a q= uery to the database. Clients devices can no doubt make the query as well, but would this requirement be applica= ble in such a case?

 

-Raj=

 

From: ext Pete= r Ecclesine (pecclesi) [mailto:pecclesi@cisco.com]<= /a>
Sent: Wednesday, October 12, 2011 5:36 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org
Subject: RE: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

Hi Raj,

 

The requirement for th= e protocol is to describe to the database the EIRP limits that will not be = exceeded for each occupied bandwidth in each frequency band, for master dev= ices and for client devices (these are the client spectrum masks I will permit to operate under my control).=

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, = CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#1F497D">

"Time doesn't fool aro= und."  "Without Prejudice" U.C.C. 1-207

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, October 11, 2011 8:30 PM
To: Peter Ecclesine (pecclesi); paw= s@ietf.org
Subject: Re: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

&n= bsp;

So what= would be the requirement that we can specify for the (device-2-database) p= rotocol as a result of the need for various spectrum masks?

&n= bsp;

From: "ext Peter Ecclesine (pecclesi)" <pecclesi@cisco.com>
Date: Tue, 11 Oct 2011 19:52:32 -0700
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] Several spectrum masks used by multi-bandwidth radio= s

&n= bsp;

In IEEE 802.11af discuss= ions, we expect to use a modified 802.11ac PHY, with several occupied bandw= idths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UH= F).

 =

We see the need to tell = the database several spectrum masks, each with:

   &nbs= p;            1 R= 11; Lowest applicable frequency in MHz

   &nbs= p;            2 R= 11; Highest applicable frequency in MHz<= o:p>

   &nbs= p;            3 R= 11; Maximum total EIRP over the frequency range defined by the spectrum mas= k

   &nbs= p;            4 R= 11; General spectrum mask in dBr from peak transmit power in EIRP, with spe= cific power limit at any frequency linearly interpolated between adjacent p= oints of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11= p-2010.pdf] or FCC 47 C.F.R. 90.210(m).

   &nbs= p;            5- mea= surement resolution bandwidth for EIRP measurements

 <= /span>

   This detail= ed actual spectrum occupancy information allows the database to perform mor= e accurate interference calculations.

 =

petere=

Peter Ecclesine, Technology Analyst<= span style=3D"color:black">

MS SJ-14-4 170 West Tasman Dr, San Jose, CA= 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool aroun= d."  "Without Prejudice" U.C.C. 1-207

_______= ________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_21E7D9BD69CC7241AAE00F4EA183B719ADA25C008AM1MPN1053mgdn_-- From Peter.McCann@huawei.com Thu Oct 13 14:23: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 D332521F8B95 for ; Thu, 13 Oct 2011 14:23:59 -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 qPKaIr9GaB+C for ; Thu, 13 Oct 2011 14:23:59 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7521F8A56 for ; Thu, 13 Oct 2011 14:23:59 -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 <0LT0003GGWRY07@usaga02-in.huawei.com> for paws@ietf.org; Thu, 13 Oct 2011 16:23:58 -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 <0LT000HFOWRXVM@usaga02-in.huawei.com> for paws@ietf.org; Thu, 13 Oct 2011 16:23:58 -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; Thu, 13 Oct 2011 14:23:59 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 14:23:51 -0700 Date: Thu, 13 Oct 2011 21:23:50 +0000 From: Peter McCann In-reply-to: <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> X-Originating-IP: [10.193.125.57] To: "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "gerald.chouinard@crc.ca" , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716401932@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//7S8AIABAtKAgAB1DzD//49ngIAAdSKAgCvgIYD//vV7sA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.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: Thu, 13 Oct 2011 21:23:59 -0000 Hi, Gabor, I think the requirement could be expressed as a refinement of what you mean by "location" in requirement D.3: D.3: The Data Model MUST support specifying the location of the subject and accuracy of location determination. Here, "location" can be a single point or a set of points. -Pete Gabor.Bajko@nokia.com wrote: > Pete, > If your use case is covered by 4.3, but the requirements may be > different, please feel free to propose your protocol requirement to > the list. > -Gabor > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of ext Peter McCann > Sent: Wednesday, September 14, 2011 10:30 AM > To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; > Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: Re: [paws] Possible new use case: simulcasting > > Hi, Raj, > > I think my use case is covered by Section 4.3 with a small change > along the lines that Scott suggested. Note there is this text in step 8: > > 8. The slave or user device scans the TV bands to locate a WRAN > transmission, and associates with the master/BS. The slave/user > device provides its geolocation to the BS which, in turn, queries > the database for a list of channels available at the slaves' > geolocation. > What I am suggesting is no different except for the fact that each of > the devices could have independent Internet access and be capable of > querying the database itself. There could be one BS that handles all > the queries or the individual BSs could query themselves (each for their > own location) and they could compare notes to find a common free channel. > > As for the protocol between the BS and the WSDB, we may want to have a > requirement that the protocol carry multiple location elements > (instead of just one) so that we save the cost of multiple queries > across the Internet. The WSDB, after doing the polygon intersection > test at each location, could additionally do a set intersection test > on the remaining free channels and return the results. That's one > concrete way that this use case may impact the protocol specification. > > -Pete > From brian.rosen@neustar.biz Thu Oct 13 14:27: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 766E021F8B9B for ; Thu, 13 Oct 2011 14:27: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=[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 92FsWSa4O1Yn for ; Thu, 13 Oct 2011 14:27:40 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9B84421F8ADE for ; Thu, 13 Oct 2011 14:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1318541302; x=1633892657; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=gGmKqsvKJ2NlzOQbrMFOQ l6hlUbEPTW/wIhdsFbDw0I=; b=l/UnF7jK+aoP0oX4EF0hfXV59hiS7DsT2l18t vNgdA55XzI0YhD3B/X03W9V0xs9hkKByhxrDQr2TVHG9fGM2A== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.1124179; Thu, 13 Oct 2011 17:28:21 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 13 Oct 2011 17:27:09 -0400 From: "Rosen, Brian" To: Peter McCann Date: Thu, 13 Oct 2011 17:27:07 -0400 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcyJ7tySD9ttCkIjR0aKeRTfXyamSQ== Message-ID: <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716401932@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: CM4UZl6psOcFwqf4DJrhNA== 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: Thu, 13 Oct 2011 21:27:41 -0000 We don't use the term "accuracy" when talking about location. We use "unce= rtainty" and "confidence", as in "the location is within 10 meters of X,Y w= ith 95% confidence", which is a circular uncertainty area. Brian On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: > Hi, Gabor, >=20 > I think the requirement could be expressed as a refinement of what you > mean by "location" in requirement D.3: >=20 > D.3: The Data Model MUST support specifying the location of the subject a= nd accuracy > of location determination. Here, "location" can be a single point or a s= et of points. >=20 > -Pete >=20 > Gabor.Bajko@nokia.com wrote: >> Pete, >> If your use case is covered by 4.3, but the requirements may be >> different, please feel free to propose your protocol requirement to >> the list. >> -Gabor >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of ext Peter McCann >> Sent: Wednesday, September 14, 2011 10:30 AM >> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; >> Probasco Scott (Nokia-CIC/Dallas) >> Cc: paws@ietf.org >> Subject: Re: [paws] Possible new use case: simulcasting >>=20 >> Hi, Raj, >>=20 >> 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= : >>=20 >> 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= . >>=20 >> 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. >>=20 >> -Pete >>=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Thu Oct 13 14:37:20 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 9084421F8AD9 for ; Thu, 13 Oct 2011 14:37:20 -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 jLrYhOX1nzSl for ; Thu, 13 Oct 2011 14:37:20 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 000F821F8A56 for ; Thu, 13 Oct 2011 14:37:19 -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 <0LT000375XE707@usaga02-in.huawei.com> for paws@ietf.org; Thu, 13 Oct 2011 16:37:19 -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 <0LT000HCZXE7VM@usaga02-in.huawei.com> for paws@ietf.org; Thu, 13 Oct 2011 16:37:19 -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; Thu, 13 Oct 2011 14:37:21 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 14:37:12 -0700 Date: Thu, 13 Oct 2011 21:37:11 +0000 From: Peter McCann In-reply-to: <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> X-Originating-IP: [10.193.125.57] To: "Rosen, Brian" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716401952@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//7S8AIABAtKAgAB1DzD//49ngIAAdSKAgCvgIYD//vV7sIACjTKAgABzA5A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@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: Thu, 13 Oct 2011 21:37:20 -0000 The "accuracy" term comes from the list of requirements already proposed by Gabor. I just added the second sentence. However we define it, I'd like to make sure that the WS device can report its location as several points (with whatever uncertainty/confidence measures for each one). The database should find spectrum that is open at all of the given points. -Pete Rosen, Brian wrote: > We don't use the term "accuracy" when talking about location. We use > "uncertainty" and "confidence", as in "the location is within 10 > meters of X,Y with 95% confidence", which is a circular uncertainty area. > > Brian > > On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: > >> Hi, Gabor, >> >> I think the requirement could be expressed as a refinement of what you >> mean by "location" in requirement D.3: >> >> D.3: The Data Model MUST support specifying the location of the subject >> and accuracy of location determination. Here, "location" can be a >> single point or a set of points. >> >> -Pete >> >> Gabor.Bajko@nokia.com wrote: >>> Pete, >>> If your use case is covered by 4.3, but the requirements may be >>> different, please feel free to propose your protocol requirement to >>> the list. >>> -Gabor >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>> Behalf Of ext Peter McCann >>> Sent: Wednesday, September 14, 2011 10:30 AM >>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; >>> Probasco Scott (Nokia-CIC/Dallas) >>> Cc: paws@ietf.org >>> Subject: Re: [paws] Possible new use case: simulcasting >>> >>> Hi, Raj, >>> >>> I think my use case is covered by Section 4.3 with a small change >>> along the lines that Scott suggested. Note there is this text in step >>> 8: >>> >>> 8. The slave or user device scans the TV bands to locate a WRAN >>> transmission, and associates with the master/BS. The slave/user >>> device provides its geolocation to the BS which, in turn, >>> queries the database for a list of channels available at the >>> slaves' geolocation. >>> What I am suggesting is no different except for the fact that each of >>> the devices could have independent Internet access and be capable of >>> querying the database itself. There could be one BS that handles all >>> the queries or the individual BSs could query themselves (each for >>> their own location) and they could compare notes to find a common free >>> channel. >>> >>> As for the protocol between the BS and the WSDB, we may want to have a >>> requirement that the protocol carry multiple location elements >>> (instead of just one) so that we save the cost of multiple queries >>> across the Internet. The WSDB, after doing the polygon intersection >>> test at each location, could additionally do a set intersection test >>> on the remaining free channels and return the results. That's one >>> concrete way that this use case may impact the protocol specification. >>> >>> -Pete >>> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Oct 13 15:01:06 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 D37E821F8558 for ; Thu, 13 Oct 2011 15:01:06 -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 5SqsYM38aB+7 for ; Thu, 13 Oct 2011 15:01:06 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 21C7521F854F for ; Thu, 13 Oct 2011 15:01:06 -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 p9DM100b013430; Fri, 14 Oct 2011 01:01: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); Fri, 14 Oct 2011 01:00:55 +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, 14 Oct 2011 00:00:54 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.138]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 00:00:54 +0200 From: To: , , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAa/KAgAAB7wD//67PgIAAVdYA/9OMKTCAWki/AP//1TGQ Date: Thu, 13 Oct 2011 22:00:53 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2011 22:00:55.0483 (UTC) FILETIME=[94E278B0:01CC89F3] 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: Thu, 13 Oct 2011 22:01:06 -0000 Pete, Would D.6/D.7 cover your requirement: 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. -Gabor -----Original Message----- From: ext Peter McCann [mailto:Peter.McCann@huawei.com]=20 Sent: Thursday, October 13, 2011 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj (Nokia-CIC/Dalla= s); gerald.chouinard@crc.ca; Probasco Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: simulcasting Hi, Gabor, I think the requirement could be expressed as a refinement of what you mean= by "location" in requirement D.3: D.3: The Data Model MUST support specifying the location of the subject and= accuracy of location determination. Here, "location" can be a single poin= t or a set of points. -Pete Gabor.Bajko@nokia.com wrote: > Pete, > If your use case is covered by 4.3, but the requirements may be=20 > different, please feel free to propose your protocol requirement to=20 > the list. > -Gabor >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Peter McCann > Sent: Wednesday, September 14, 2011 10:30 AM > To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca;=20 > Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: Re: [paws] Possible new use case: simulcasting >=20 > Hi, Raj, >=20 > I think my use case is covered by Section 4.3 with a small change=20 > along the lines that Scott suggested. Note there is this text in step 8: >=20 > 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=20 > the devices could have independent Internet access and be capable of=20 > querying the database itself. There could be one BS that handles all=20 > the queries or the individual BSs could query themselves (each for=20 > their own location) and they could compare notes to find a common free ch= annel. >=20 > As for the protocol between the BS and the WSDB, we may want to have a=20 > requirement that the protocol carry multiple location elements=20 > (instead of just one) so that we save the cost of multiple queries=20 > across the Internet. The WSDB, after doing the polygon intersection=20 > test at each location, could additionally do a set intersection test=20 > on the remaining free channels and return the results. That's one=20 > concrete way that this use case may impact the protocol specification. >=20 > -Pete >=20 From Peter.McCann@huawei.com Fri Oct 14 04:50: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 A0A1D21F853A for ; Fri, 14 Oct 2011 04:50: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 j0ln3zsz9veb for ; Fri, 14 Oct 2011 04:50: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 D351921F8512 for ; Fri, 14 Oct 2011 04:50: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 <0LT2003TP0WS03@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 06:50:53 -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 <0LT2009FW0WSNN@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 06:50:52 -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; Fri, 14 Oct 2011 04:50:45 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 04:50:46 -0700 Date: Fri, 14 Oct 2011 11:50:44 +0000 From: Peter McCann In-reply-to: <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> X-Originating-IP: [10.193.125.57] To: "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "gerald.chouinard@crc.ca" , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE7164019F4@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//7S8AIABAtKAgAB1DzD//49ngIAAdSKAgCvgIYD//vV7sIAClqKA//+N7qA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.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: Fri, 14 Oct 2011 11:50:54 -0000 D.6 comes close, but also seems to allow returning the union set of all channels available at the multiple locations. I want to make sure the WSDB can do a set intersection of the available channels at each of the listed locations. -Pete Gabor.Bajko@nokia.com wrote: > Pete, > > Would D.6/D.7 cover your requirement: > D.6: The Data Model MUST support specifying channel availability > information for multiple locations. > D.7: The Data Model MUST support specifying channel availability > information for an area around a specified location. > > -Gabor > > -----Original Message----- From: ext Peter McCann > [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011 2:24 > PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj (Nokia- > CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: simulcasting > > Hi, Gabor, > > I think the requirement could be expressed as a refinement of what you > mean by "location" in requirement D.3: > > D.3: The Data Model MUST support specifying the location of the > subject and accuracy of location determination. Here, "location" can > be a single point or a set of points. > > -Pete > > Gabor.Bajko@nokia.com wrote: >> Pete, >> If your use case is covered by 4.3, but the requirements may be >> different, please feel free to propose your protocol requirement to >> the list. >> -Gabor >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of ext Peter McCann >> Sent: Wednesday, September 14, 2011 10:30 AM >> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; >> Probasco Scott (Nokia-CIC/Dallas) >> Cc: paws@ietf.org >> Subject: Re: [paws] Possible new use case: simulcasting >> >> Hi, Raj, >> >> I think my use case is covered by Section 4.3 with a small change along >> the lines that Scott suggested. Note there is this text in step 8: >> >> 8. The slave or user device scans the TV bands to locate a WRAN >> transmission, and associates with the master/BS. The slave/user >> device provides its geolocation to the BS which, in turn, >> queries the database for a list of channels available at the >> slaves' geolocation. >> What I am suggesting is no different except for the fact that each of >> the devices could have independent Internet access and be capable of >> querying the database itself. There could be one BS that handles all >> the queries or the individual BSs could query themselves (each for >> their own location) and they could compare notes to find a common free >> channel. >> >> As for the protocol between the BS and the WSDB, we may want to have a >> requirement that the protocol carry multiple location elements (instead >> of just one) so that we save the cost of multiple queries across the >> Internet. The WSDB, after doing the polygon intersection test at each >> location, could additionally do a set intersection test on the >> remaining free channels and return the results. That's one concrete >> way that this use case may impact the protocol specification. >> >> -Pete >> > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Fri Oct 14 05:03:06 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 78D4A21F8AFF for ; Fri, 14 Oct 2011 05:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEuxe1qD0axo for ; Fri, 14 Oct 2011 05:03:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91221F8AFD for ; Fri, 14 Oct 2011 05:03:04 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 14 Oct 2011 13:03:03 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.67]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 14 Oct 2011 13:03:03 +0100 From: To: , Date: Fri, 14 Oct 2011 13:03:01 +0100 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIABAtKAgAB1DzD//49ngIAAdSKAgCvgIYD//vV7sIACjTKAgABzA5D///VjkA== Message-ID: <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB 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: Fri, 14 Oct 2011 12:03:06 -0000 Peter, Brian I agree that "uncertainty" and "confidence" are better terms, but "location= accuracy" is also used by Ofcom in their consultation proposals. They allo= w the location accuracy to be varied in database queries to include the tra= nsmissions of the slaves, for example a 500m cell could be catered for by s= pecifying the master location plus an accuracy of 600m, made up of 500m for= the cell radius and 100m for the actual location uncertainty of the measur= ement made by the master device. We are close to being able to propose two new use cases on the reflector an= d also have additional requirements that fall from those, particularly addr= essing the UK/Ofcom needs.=20 Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pet= er McCann Sent: 13 October 2011 22:37 To: Rosen, Brian Cc: paws@ietf.org Subject: Re: [paws] Possible new use case: simulcasting The "accuracy" term comes from the list of requirements already proposed by= Gabor. I just added the second sentence. However we define it, I'd like = to make sure that the WS device can report its location as several points (= with whatever uncertainty/confidence measures for each one). The database should find spectrum that is open at all of the given points. -Pete Rosen, Brian wrote: > We don't use the term "accuracy" when talking about location. We use=20 > "uncertainty" and "confidence", as in "the location is within 10=20 > meters of X,Y with 95% confidence", which is a circular uncertainty area. >=20 > Brian >=20 > On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: >=20 >> Hi, Gabor, >>=20 >> I think the requirement could be expressed as a refinement of what=20 >> you mean by "location" in requirement D.3: >>=20 >> D.3: The Data Model MUST support specifying the location of the=20 >> subject and accuracy of location determination. Here, "location" can=20 >> be a single point or a set of points. >>=20 >> -Pete >>=20 >> Gabor.Bajko@nokia.com wrote: >>> Pete, >>> If your use case is covered by 4.3, but the requirements may be=20 >>> different, please feel free to propose your protocol requirement to=20 >>> the list. >>> -Gabor >>>=20 >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 >>> Of ext Peter McCann >>> Sent: Wednesday, September 14, 2011 10:30 AM >>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca;=20 >>> Probasco Scott (Nokia-CIC/Dallas) >>> Cc: paws@ietf.org >>> Subject: Re: [paws] Possible new use case: simulcasting >>>=20 >>> Hi, Raj, >>>=20 >>> I think my use case is covered by Section 4.3 with a small change=20 >>> along the lines that Scott suggested. Note there is this text in=20 >>> step >>> 8: >>>=20 >>> 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=20 >>> of the devices could have independent Internet access and be capable=20 >>> of querying the database itself. There could be one BS that handles=20 >>> all the queries or the individual BSs could query themselves (each=20 >>> for their own location) and they could compare notes to find a=20 >>> common free channel. >>>=20 >>> As for the protocol between the BS and the WSDB, we may want to have=20 >>> a requirement that the protocol carry multiple location elements=20 >>> (instead of just one) so that we save the cost of multiple queries=20 >>> across the Internet. The WSDB, after doing the polygon intersection=20 >>> test at each location, could additionally do a set intersection test=20 >>> on the remaining free channels and return the results. That's one=20 >>> concrete way that this use case may impact the protocol specification. >>>=20 >>> -Pete >>>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Fri Oct 14 05:39: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 97A6E21F8A7B for ; Fri, 14 Oct 2011 05:39: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=[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 6haE2N4tCGGo for ; Fri, 14 Oct 2011 05:39:40 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7B21F8AFC for ; Fri, 14 Oct 2011 05:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1318595960; x=1633942700; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=DU7OZCmT66FLjmrDmEdKL LkLjkCslUfB1AQ5u9SCM/o=; b=Xaw3ICqGUEB3lumHCxgy7R3I8/lylCnXrkD/w JLK+uLPnS1IeBkk07RDOZa9s0smq7v/Lea8L8Og5pvArqSt0g== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.605925; Fri, 14 Oct 2011 08:39:18 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 14 Oct 2011 08:39:30 -0400 From: "Rosen, Brian" To: "" Date: Fri, 14 Oct 2011 08:39:29 -0400 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcyKblFggpqN/qKPSC+N3AGSpOQApA== Message-ID: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: V49Ylq308OAM0/AVxx0Qbw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "Peter.McCann@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: Fri, 14 Oct 2011 12:39:41 -0000 While I recognize that regulators are not bound by the laws of physics, eng= ineers generally are. There are no measurement mechanisms I am aware of t= hat will yield a lat/lon/altitude that do not have some form of confidence = factor. We have lots of experience with these issues in the U.S. cell phon= e emergency call system. If you don't specify confidence, someone can give= you an uncertainty of 10 meters, and just not tell you that confidence is = 20%. More specifically, we actually did experience some measurements with = 65% confidence being compared to some measurements with 95% confidence but = the same uncertainty. Big difference. So, while a regulator can choose to ignore confidence, the protocol cannot,= IMHO. There is no definition of "accuracy" that I'm aware of in the conte= xt of measured lat/lon which meets any engineering rigor. If the regulator= says "accuracy", I would propose that the protocol translate that to "unce= rtainty" and if "confidence" is unspecified, I would default to 95%. Brian On Oct 14, 2011, at 8:03 AM, wrote: > Peter, Brian >=20 > I agree that "uncertainty" and "confidence" are better terms, but "locati= on accuracy" is also used by Ofcom in their consultation proposals. They al= low the location accuracy to be varied in database queries to include the t= ransmissions of the slaves, for example a 500m cell could be catered for by= specifying the master location plus an accuracy of 600m, made up of 500m f= or the cell radius and 100m for the actual location uncertainty of the meas= urement made by the master device. >=20 > We are close to being able to propose two new use cases on the reflector = and also have additional requirements that fall from those, particularly ad= dressing the UK/Ofcom needs.=20 >=20 > Andy >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of P= eter McCann > Sent: 13 October 2011 22:37 > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] Possible new use case: simulcasting >=20 > The "accuracy" term comes from the list of requirements already proposed = by Gabor. I just added the second sentence. However we define it, I'd lik= e to make sure that the WS device can report its location as several points= (with whatever uncertainty/confidence measures for each one). > The database should find spectrum that is open at all of the given points= . >=20 > -Pete >=20 > Rosen, Brian wrote: >> We don't use the term "accuracy" when talking about location. We use=20 >> "uncertainty" and "confidence", as in "the location is within 10=20 >> meters of X,Y with 95% confidence", which is a circular uncertainty area= . >>=20 >> Brian >>=20 >> On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: >>=20 >>> Hi, Gabor, >>>=20 >>> I think the requirement could be expressed as a refinement of what=20 >>> you mean by "location" in requirement D.3: >>>=20 >>> D.3: The Data Model MUST support specifying the location of the=20 >>> subject and accuracy of location determination. Here, "location" can=20 >>> be a single point or a set of points. >>>=20 >>> -Pete >>>=20 >>> Gabor.Bajko@nokia.com wrote: >>>> Pete, >>>> If your use case is covered by 4.3, but the requirements may be=20 >>>> different, please feel free to propose your protocol requirement to=20 >>>> the list. >>>> -Gabor >>>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 >>>> Of ext Peter McCann >>>> Sent: Wednesday, September 14, 2011 10:30 AM >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca;=20 >>>> Probasco Scott (Nokia-CIC/Dallas) >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] Possible new use case: simulcasting >>>>=20 >>>> Hi, Raj, >>>>=20 >>>> I think my use case is covered by Section 4.3 with a small change=20 >>>> along the lines that Scott suggested. Note there is this text in=20 >>>> step >>>> 8: >>>>=20 >>>> 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=20 >>>> of the devices could have independent Internet access and be capable=20 >>>> of querying the database itself. There could be one BS that handles=20 >>>> all the queries or the individual BSs could query themselves (each=20 >>>> for their own location) and they could compare notes to find a=20 >>>> common free channel. >>>>=20 >>>> As for the protocol between the BS and the WSDB, we may want to have=20 >>>> a requirement that the protocol carry multiple location elements=20 >>>> (instead of just one) so that we save the cost of multiple queries=20 >>>> across the Internet. The WSDB, after doing the polygon intersection=20 >>>> test at each location, could additionally do a set intersection test=20 >>>> on the remaining free channels and return the results. That's one=20 >>>> concrete way that this use case may impact the protocol specification. >>>>=20 >>>> -Pete >>>>=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 scott.probasco@nokia.com Fri Oct 14 05:50: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 891E421F8B86 for ; Fri, 14 Oct 2011 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 G2Y18nDiejHn for ; Fri, 14 Oct 2011 05:50:38 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id DBDE821F8BB5 for ; Fri, 14 Oct 2011 05:50:37 -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 p9ECoYdg013451; Fri, 14 Oct 2011 15:50:34 +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); Fri, 14 Oct 2011 15:50:02 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Oct 2011 14:50:01 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.151]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 14:50:01 +0200 From: To: , , Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A//5MhED//TS5YP/4XdVAAfw/7AA= Date: Fri, 14 Oct 2011 12:50:01 +0000 Message-ID: In-Reply-To: <30D62D93EA229643933BE9BF324FD1F30CF5F220@xmb-sjc-22b.amer.cisco.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 x-originating-ip: [10.241.160.8] Content-Type: multipart/alternative; boundary="_000_CABD98DAB413scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2011 12:50:02.0588 (UTC) FILETIME=[CA3CB1C0:01CC8A6F] X-Nokia-AV: Clean Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 14 Oct 2011 12:50:39 -0000 --_000_CABD98DAB413scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Peter, Could you describe how the master enforces the specified limits on the clie= nt/slave devices? Perhaps the 'how' is beyond scope of PAWS, I am just tryi= ng to understand how the system would operate. Regards, Scott From: "ext Peter Ecclesine (pecclesi)" > Date: Thu, 13 Oct 2011 13:36:12 -0700 To: Raj Patil >= , "paws@ietf.org" > Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios Hi Raj, >> How is it relevant for client devices? It is only the master device that= is generally making a query to the database. Clients devices can no doubt = make the query as well, but would this requirement be applicable in such a = case?<< The database either makes assumptions about the transmissions of all cli= ent devices, or it can be informed what emissions the client devices will n= ot exceed (because the master device will not allow clients to exceed speci= fied limits). The general case is not all devices transmit with the same masks =96 rel= atively loose-masked inexpensive devices can joint networks controlled by h= igher-specification master devices =96 e.g., outdoor muni wi-fi. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: Thursday, October 13, 2011 9:01 AM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios Hi Peter, So how about the following text that we could add in the requirements secti= on of the I-D: - A white space master device should provide to the database in th= e query a description of the EIRP limits that will not be exceeded for each= occupied bandwidth in the set of frequency bands. You indicated that this is applicable to master devices and client devices.= How is it relevant for client devices? It is only the master device that i= s generally making a query to the database. Clients devices can no doubt ma= ke the query as well, but would this requirement be applicable in such a ca= se? -Raj From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com] Sent: Wednesday, October 12, 2011 5:36 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios Hi Raj, The requirement for the protocol is to describe to the database the EIRP li= mits that will not be exceeded for each occupied bandwidth in each frequenc= y band, for master devices and for client devices (these are the client spe= ctrum masks I will permit to operate under my control). petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios So what would be the requirement that we can specify for the (device-2-data= base) protocol as a result of the need for various spectrum masks? From: "ext Peter Ecclesine (pecclesi)" > Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" > Subject: [paws] Several spectrum masks used by multi-bandwidth radios In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, wit= h several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in seve= ral TV bands (VHF and UHF). We see the need to tell the database several spectrum masks, each with: 1 =96 Lowest applicable frequency in MHz 2 =96 Highest applicable frequency in MHz 3 =96 Maximum total EIRP over the frequency range defined b= y the spectrum mask 4 =96 General spectrum mask in dBr from peak transmit power= in EIRP, with specific power limit at any frequency linearly interpolated = between adjacent points of the spectrum mask, expressed like IEEE 802.11p A= nnex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or = FCC 47 C.F.R. 90.210(m). 5- measurement resolution bandwidth for EIRP measurements This detailed actual spectrum occupancy information allows the database = to perform more accurate interference calculations. petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ 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 --_000_CABD98DAB413scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <16D91C8ABA668C4A9E4570A44F8D6A0A@nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Peter,

Could you describe how the master enforces the specified limits on the= client/slave devices? Perhaps the 'how' is beyond scope of PAWS, I am just= trying to understand how the system would operate.

Regards,
Scott

From: "ext Peter Ecclesine (pe= cclesi)" <pecclesi@cisco.com<= /a>>
Date: Thu, 13 Oct 2011 13:36:12 -07= 00
To: Raj Patil <Basavaraj.Patil@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Several spectru= m masks used by multi-bandwidth radios

Hi Raj,

 

>> How is it relevant for client devices? It is only t= he master device that is generally making a query to the database. Clients = devices can no doubt make the query as well, but would this requirement be applicable in such a case?<<

 

   The datab= ase either makes assumptions about the transmissions of all client devices,= or it can be informed what emissions the client devices will not exceed (b= ecause the master device will not allow clients to exceed specified limits).

 

   The gener= al case is not all devices transmit with the same masks =96 relatively loos= e-masked inexpensive devices can joint networks controlled by higher-specif= ication master devices =96 e.g., outdoor muni wi-fi.

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-= 1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."= ;  "Without Prejudice" U.C.C. 1-207

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.= com]
Sent: Thursday, October 13, 2011 9:01 AM
To: Peter Ecclesine (pecclesi); paw= s@ietf.org
Subject: RE: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

Hi Peter,

 

So how about the follo= wing text that we could add in the requirements section of the I-D:

 

-    =       A white space master dev= ice should provide to the database in the query a description of the EIRP l= imits that will not be exceeded for each occupied bandwidth in the set of f= requency bands.

 

You indicated that thi= s is applicable to master devices and client devices. How is it relevant fo= r client devices? It is only the master device that is generally making a q= uery to the database. Clients devices can no doubt make the query as well, but would this requirement be applica= ble in such a case?

 

-Raj=

 

From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com]
Sent: Wednesday, October 12, 2011 5:36 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org
Subject: RE: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

Hi Raj,

 

The requirement for th= e protocol is to describe to the database the EIRP limits that will not be = exceeded for each occupied bandwidth in each frequency band, for master dev= ices and for client devices (these are the client spectrum masks I will permit to operate under my control).=

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-= 1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."= ;  "Without Prejudice" U.C.C. 1-207

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, October 11, 2011 8:30 PM
To: Peter Ecclesine (pecclesi); paw= s@ietf.org
Subject: Re: [paws] Several spectrum masks used by multi-bandwidth r= adios

 

&n= bsp;

So what= would be the requirement that we can specify for the (device-2-database) p= rotocol as a result of the need for various spectrum masks?

&n= bsp;

From: "ext Peter Ecclesine (pecclesi)" <pecclesi@cisco.com>
Date: Tue, 11 Oct 2011 19:52:32 -0700
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] Several spectrum masks used by multi-bandwidth radio= s

&n= bsp;

In IEEE 802.11af discuss= ions, we expect to use a modified 802.11ac PHY, with several occupied bandw= idths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UH= F).

 =

We see the need to tell = the database several spectrum masks, each with:

   &nbs= p;            1 =96 = Lowest applicable frequency in MHz<= /o:p>

   &nbs= p;            2 =96 = Highest applicable frequency in MHz=

   &nbs= p;            3 =96 = Maximum total EIRP over the frequency range defined by the spectrum mask

   &nbs= p;            4 =96 = General spectrum mask in dBr from peak transmit power in EIRP, with specifi= c power limit at any frequency linearly interpolated between adjacent point= s of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11= p-2010.pdf] or FCC 47 C.F.R. 90.210(m).

   &nbs= p;            5- mea= surement resolution bandwidth for EIRP measurements

 <= /span>

   This detail= ed actual spectrum occupancy information allows the database to perform mor= e accurate interference calculations.

 =

petere=

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  &qu= ot;Without Prejudice" U.C.C. 1-207<= o:p>

_______= ________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CABD98DAB413scottprobasconokiacom_-- From andy.sago@bt.com Fri Oct 14 06:27: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 8884D21F8C1F for ; Fri, 14 Oct 2011 06:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 7uwqASHZbgo9 for ; Fri, 14 Oct 2011 06:27:41 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC821F8C1E for ; Fri, 14 Oct 2011 06:27:41 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 14 Oct 2011 14:27:40 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.67]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 14 Oct 2011 14:27:40 +0100 From: To: Date: Fri, 14 Oct 2011 14:27:38 +0100 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcyKblFggpqN/qKPSC+N3AGSpOQApAABKpWQ Message-ID: <619CDADDCCD2B44380834BE8BF6F714140491FDF92@EMV62-UKRD.domain1.systemhost.net> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org, Peter.McCann@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: Fri, 14 Oct 2011 13:27:42 -0000 Brian I've gone back to Ofcom's original consultation and it does say the accurac= y should be specified to a 95% certainty, so the rules of physics have been= allowed for. Sorry I didn't include that in the earlier mail. They then al= low for the accuracy to be varied to account for slave devices. Some of the= language is probably a bit lax, but the protocol may need to cater for var= ying confidence levels across regulatory domains as you say. With the cavea= t that this is only one paragraph from Ofcom's consultation and not the ful= l story, and their views may have moved on, their text on varying the locat= ion accuracy says: The slave devices will be some distance from the master device. As a result= , they may be closer to a licensed receiver than the master and when they transmit= they may cause interference. To prevent this occurring the master device needs t= o inform the database of the possible distance away that slave devices may be locate= d and the database can then take this information into account when assigning fre= quencies and power levels. We propose that an effective way for the master device to do this is to inc= rease its location uncertainty by an amount related to the maximum expected range bet= ween the master and slave device. Hence, if the master device knew its location = accuracy to 100m and it knew that the maximum range to a slave device was 500m it wo= uld report a location accuracy of 600m to the database. The database would then= search across all pixels within the possible location circle and return a result b= ased on the minimum power level across all pixels for each frequency. (Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at http:= //stakeholders.ofcom.org.uk/binaries/consultations/geolocation/summary/geol= ocation.pdf) Regards Andy -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: 14 October 2011 13:39 To: Sago,AJ,Andy,COD R Cc: Peter.McCann@huawei.com; paws@ietf.org Subject: Re: [paws] Possible new use case: simulcasting While I recognize that regulators are not bound by the laws of physics, eng= ineers generally are. There are no measurement mechanisms I am aware of t= hat will yield a lat/lon/altitude that do not have some form of confidence = factor. We have lots of experience with these issues in the U.S. cell phon= e emergency call system. If you don't specify confidence, someone can give= you an uncertainty of 10 meters, and just not tell you that confidence is = 20%. More specifically, we actually did experience some measurements with = 65% confidence being compared to some measurements with 95% confidence but = the same uncertainty. Big difference. So, while a regulator can choose to ignore confidence, the protocol cannot,= IMHO. There is no definition of "accuracy" that I'm aware of in the conte= xt of measured lat/lon which meets any engineering rigor. If the regulator= says "accuracy", I would propose that the protocol translate that to "unce= rtainty" and if "confidence" is unspecified, I would default to 95%. Brian On Oct 14, 2011, at 8:03 AM, wrote: > Peter, Brian >=20 > I agree that "uncertainty" and "confidence" are better terms, but "locati= on accuracy" is also used by Ofcom in their consultation proposals. They al= low the location accuracy to be varied in database queries to include the t= ransmissions of the slaves, for example a 500m cell could be catered for by= specifying the master location plus an accuracy of 600m, made up of 500m f= or the cell radius and 100m for the actual location uncertainty of the meas= urement made by the master device. >=20 > We are close to being able to propose two new use cases on the reflector = and also have additional requirements that fall from those, particularly ad= dressing the UK/Ofcom needs.=20 >=20 > Andy >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Peter McCann > Sent: 13 October 2011 22:37 > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] Possible new use case: simulcasting >=20 > The "accuracy" term comes from the list of requirements already proposed = by Gabor. I just added the second sentence. However we define it, I'd lik= e to make sure that the WS device can report its location as several points= (with whatever uncertainty/confidence measures for each one). > The database should find spectrum that is open at all of the given points= . >=20 > -Pete >=20 > Rosen, Brian wrote: >> We don't use the term "accuracy" when talking about location. We use=20 >> "uncertainty" and "confidence", as in "the location is within 10=20 >> meters of X,Y with 95% confidence", which is a circular uncertainty area= . >>=20 >> Brian >>=20 >> On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: >>=20 >>> Hi, Gabor, >>>=20 >>> I think the requirement could be expressed as a refinement of what=20 >>> you mean by "location" in requirement D.3: >>>=20 >>> D.3: The Data Model MUST support specifying the location of the=20 >>> subject and accuracy of location determination. Here, "location"=20 >>> can be a single point or a set of points. >>>=20 >>> -Pete >>>=20 >>> Gabor.Bajko@nokia.com wrote: >>>> Pete, >>>> If your use case is covered by 4.3, but the requirements may be=20 >>>> different, please feel free to propose your protocol requirement to=20 >>>> the list. >>>> -Gabor >>>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >>>> Behalf Of ext Peter McCann >>>> Sent: Wednesday, September 14, 2011 10:30 AM >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca;=20 >>>> Probasco Scott (Nokia-CIC/Dallas) >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] Possible new use case: simulcasting >>>>=20 >>>> Hi, Raj, >>>>=20 >>>> I think my use case is covered by Section 4.3 with a small change=20 >>>> along the lines that Scott suggested. Note there is this text in=20 >>>> step >>>> 8: >>>>=20 >>>> 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=20 >>>> of the devices could have independent Internet access and be=20 >>>> capable of querying the database itself. There could be one BS=20 >>>> that handles all the queries or the individual BSs could query=20 >>>> themselves (each for their own location) and they could compare=20 >>>> notes to find a common free channel. >>>>=20 >>>> As for the protocol between the BS and the WSDB, we may want to=20 >>>> have a requirement that the protocol carry multiple location=20 >>>> elements (instead of just one) so that we save the cost of multiple=20 >>>> queries across the Internet. The WSDB, after doing the polygon=20 >>>> intersection test at each location, could additionally do a set=20 >>>> intersection test on the remaining free channels and return the=20 >>>> results. That's one concrete way that this use case may impact the pr= otocol specification. >>>>=20 >>>> -Pete >>>>=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 gerald.chouinard@crc.ca Fri Oct 14 07:19: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 0031721F8C09 for ; Fri, 14 Oct 2011 07:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 b3VGIAmP+Grr for ; Fri, 14 Oct 2011 07:19:55 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id A735021F8BD3 for ; Fri, 14 Oct 2011 07:19:54 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 0543C6B0452; Fri, 14 Oct 2011 10:19:49 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id DE8C46B03DD; Fri, 14 Oct 2011 10:19:48 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id D12986B03EB; Fri, 14 Oct 2011 10:19:48 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 1BE8F6B03DD; Fri, 14 Oct 2011 10:19:44 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id 68EC56B1777; Fri, 14 Oct 2011 10:19:43 -0400 (EDT) Message-Id: <5.1.0.14.2.20111014101317.01b9fb20@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Oct 2011 10:19:27 -0400 To: , From: Gerald Chouinard In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140491FDF92@EMV62-UKRD.doma in1.systemhost.net> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> 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@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: Fri, 14 Oct 2011 14:19:56 -0000 Andy, As shown in the excerpt that you included below, Ofcom seem to use the terms "accuracy" and "uncertainty" interchangeably. The IETF-PAWS should align with the intent but use the more correct term "uncertainty" in its proceedings. "Uncertainty" can then be extended to include a larger "uncertainty" radius around a location to take into account of the existence of the slave devices. Gerald At 14:27 14-10-11 +0100, andy.sago@bt.com wrote: >Brian > >I've gone back to Ofcom's original consultation and it does say the >accuracy should be specified to a 95% certainty, so the rules of physics >have been allowed for. Sorry I didn't include that in the earlier mail. >They then allow for the accuracy to be varied to account for slave >devices. Some of the language is probably a bit lax, but the protocol may >need to cater for varying confidence levels across regulatory domains as >you say. With the caveat that this is only one paragraph from Ofcom's >consultation and not the full story, and their views may have moved on, >their text on varying the location accuracy says: > >The slave devices will be some distance from the master device. As a >result, they >may be closer to a licensed receiver than the master and when they >transmit they >may cause interference. To prevent this occurring the master device needs >to inform >the database of the possible distance away that slave devices may be >located and >the database can then take this information into account when assigning >frequencies >and power levels. >We propose that an effective way for the master device to do this is to >increase its >location uncertainty by an amount related to the maximum expected range >between >the master and slave device. Hence, if the master device knew its location >accuracy >to 100m and it knew that the maximum range to a slave device was 500m it would >report a location accuracy of 600m to the database. The database would >then search >across all pixels within the possible location circle and return a result >based on the >minimum power level across all pixels for each frequency. > >(Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at >http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/summary/geolocation.pdf) > >Regards > >Andy > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: 14 October 2011 13:39 >To: Sago,AJ,Andy,COD R >Cc: Peter.McCann@huawei.com; paws@ietf.org >Subject: Re: [paws] Possible new use case: simulcasting > > >While I recognize that regulators are not bound by the laws of physics, >engineers generally are. There are no measurement mechanisms I am aware >of that will yield a lat/lon/altitude that do not have some form of >confidence factor. We have lots of experience with these issues in the >U.S. cell phone emergency call system. If you don't specify confidence, >someone can give you an uncertainty of 10 meters, and just not tell you >that confidence is 20%. More specifically, we actually did experience >some measurements with 65% confidence being compared to some measurements >with 95% confidence but the same uncertainty. Big difference. > >So, while a regulator can choose to ignore confidence, the protocol >cannot, IMHO. There is no definition of "accuracy" that I'm aware of in >the context of measured lat/lon which meets any engineering rigor. If the >regulator says "accuracy", I would propose that the protocol translate >that to "uncertainty" and if "confidence" is unspecified, I would default >to 95%. > >Brian > >On Oct 14, 2011, at 8:03 AM, wrote: > > > Peter, Brian > > > > I agree that "uncertainty" and "confidence" are better terms, but > "location accuracy" is also used by Ofcom in their consultation > proposals. They allow the location accuracy to be varied in database > queries to include the transmissions of the slaves, for example a 500m > cell could be catered for by specifying the master location plus an > accuracy of 600m, made up of 500m for the cell radius and 100m for the > actual location uncertainty of the measurement made by the master device. > > > > We are close to being able to propose two new use cases on the > reflector and also have additional requirements that fall from those, > particularly addressing the UK/Ofcom needs. > > > > Andy > > > > -----Original Message----- > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > > Of Peter McCann > > Sent: 13 October 2011 22:37 > > To: Rosen, Brian > > Cc: paws@ietf.org > > Subject: Re: [paws] Possible new use case: simulcasting > > > > The "accuracy" term comes from the list of requirements already > proposed by Gabor. I just added the second sentence. However we define > it, I'd like to make sure that the WS device can report its location as > several points (with whatever uncertainty/confidence measures for each one). > > The database should find spectrum that is open at all of the given points. > > > > -Pete > > > > Rosen, Brian wrote: > >> We don't use the term "accuracy" when talking about location. We use > >> "uncertainty" and "confidence", as in "the location is within 10 > >> meters of X,Y with 95% confidence", which is a circular uncertainty area. > >> > >> Brian > >> > >> On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: > >> > >>> Hi, Gabor, > >>> > >>> I think the requirement could be expressed as a refinement of what > >>> you mean by "location" in requirement D.3: > >>> > >>> D.3: The Data Model MUST support specifying the location of the > >>> subject and accuracy of location determination. Here, "location" > >>> can be a single point or a set of points. > >>> > >>> -Pete > >>> > >>> Gabor.Bajko@nokia.com wrote: > >>>> Pete, > >>>> If your use case is covered by 4.3, but the requirements may be > >>>> different, please feel free to propose your protocol requirement to > >>>> the list. > >>>> -Gabor > >>>> > >>>> -----Original Message----- > >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >>>> Behalf Of ext Peter McCann > >>>> Sent: Wednesday, September 14, 2011 10:30 AM > >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; > >>>> Probasco Scott (Nokia-CIC/Dallas) > >>>> Cc: paws@ietf.org > >>>> Subject: Re: [paws] Possible new use case: simulcasting > >>>> > >>>> Hi, Raj, > >>>> > >>>> I think my use case is covered by Section 4.3 with a small change > >>>> along the lines that Scott suggested. Note there is this text in > >>>> step > >>>> 8: > >>>> > >>>> 8. The slave or user device scans the TV bands to locate a WRAN > >>>> transmission, and associates with the master/BS. The slave/user > >>>> device provides its geolocation to the BS which, in turn, > >>>> queries the database for a list of channels available at the > >>>> slaves' geolocation. > >>>> What I am suggesting is no different except for the fact that each > >>>> of the devices could have independent Internet access and be > >>>> capable of querying the database itself. There could be one BS > >>>> that handles all the queries or the individual BSs could query > >>>> themselves (each for their own location) and they could compare > >>>> notes to find a common free channel. > >>>> > >>>> As for the protocol between the BS and the WSDB, we may want to > >>>> have a requirement that the protocol carry multiple location > >>>> elements (instead of just one) so that we save the cost of multiple > >>>> queries across the Internet. The WSDB, after doing the polygon > >>>> intersection test at each location, could additionally do a set > >>>> intersection test on the remaining free channels and return the > >>>> results. That's one concrete way that this use case may impact the > protocol specification. > >>>> > >>>> -Pete > >>>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Peter.McCann@huawei.com Fri Oct 14 07:28:01 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 68D8C21F8C6B for ; Fri, 14 Oct 2011 07:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 xF-d+E2+1EqT for ; Fri, 14 Oct 2011 07:28:00 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD7621F8C6D for ; Fri, 14 Oct 2011 07:28:00 -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 <0LT20071Q86LDX@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 09:27:59 -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 <0LT2006UN84L53@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 09:27:57 -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; Fri, 14 Oct 2011 07:27:33 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 07:27:21 -0700 Date: Fri, 14 Oct 2011 14:27:21 +0000 From: Peter McCann In-reply-to: <5.1.0.14.2.20111014101317.01b9fb20@imap.crc.ca> X-Originating-IP: [10.193.125.57] To: Gerald Chouinard , "andy.sago@bt.com" , "Brian.Rosen@neustar.biz" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716401A91@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+2liyoyRWRkAYQIvHfAAAv3hA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> <5.1.0.14.2.20111014101317.01b9fb20@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: Fri, 14 Oct 2011 14:28:01 -0000 Slave devices (or peer master devices engaged in simulcasting) may not be arranged in a circular area and enlarging the uncertainty radius to include all of them may result in a geographic footprint that is way too large. It should be possible to include multiple points/uncertainty radii and have the WSDB return spectrum that is free in all of the circles. -Pete Gerald Chouinard wrote: > Andy, > > As shown in the excerpt that you included below, Ofcom seem to use the > terms "accuracy" and "uncertainty" interchangeably. The IETF-PAWS > should align with the intent but use the more correct term > "uncertainty" in its proceedings. "Uncertainty" can then be extended > to include a larger "uncertainty" radius around a location to take > into account of the existence of the slave devices. > > Gerald > > > At 14:27 14-10-11 +0100, andy.sago@bt.com wrote: >> Brian >> >> I've gone back to Ofcom's original consultation and it does say the >> accuracy should be specified to a 95% certainty, so the rules of >> physics have been allowed for. Sorry I didn't include that in the >> earlier mail. They then allow for the accuracy to be varied to account >> for slave devices. Some of the language is probably a bit lax, but the >> protocol may need to cater for varying confidence levels across >> regulatory domains as you say. With the caveat that this is only one >> paragraph from Ofcom's consultation and not the full story, and their >> views may have moved on, their text on varying the location accuracy >> says: >> >> The slave devices will be some distance from the master device. As a >> result, they may be closer to a licensed receiver than the master and >> when they transmit they may cause interference. To prevent this >> occurring the master device needs to inform the database of the >> possible distance away that slave devices may be located and the >> database can then take this information into account when assigning >> frequencies and power levels. We propose that an effective way for the >> master device to do this is to increase its location uncertainty by an >> amount related to the maximum expected range between the master and >> slave device. Hence, if the master device knew its location accuracy to >> 100m and it knew that the maximum range to a slave device was 500m it >> would report a location accuracy of 600m to the database. The database >> would then search across all pixels within the possible location circle >> and return a result based on the minimum power level across all pixels >> for each frequency. >> >> (Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at >> http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/s u >> m mary/geolocation.pdf) >> >> Regards >> >> Andy >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: 14 October 2011 13:39 >> To: Sago,AJ,Andy,COD R >> Cc: Peter.McCann@huawei.com; paws@ietf.org >> Subject: Re: [paws] Possible new use case: simulcasting >> >> While I recognize that regulators are not bound by the >> laws of physics, engineers generally are. There are no measurement >> mechanisms I am aware of that will yield a lat/lon/altitude that do not >> have some form of confidence factor. We have lots of experience with >> these issues in the U.S. cell phone emergency call system. If you >> don't specify confidence, someone can give you an uncertainty of 10 >> meters, and just not tell you that confidence is 20%. More >> specifically, we actually did experience some measurements with 65% >> confidence being compared to some measurements with 95% confidence but >> the same uncertainty. Big difference. >> >> So, while a regulator can choose to ignore confidence, the protocol >> cannot, IMHO. There is no definition of "accuracy" that I'm aware of >> in the context of measured lat/lon which meets any engineering rigor. >> If the regulator says "accuracy", I would propose that the protocol >> translate that to "uncertainty" and if "confidence" is unspecified, I >> would default to 95%. >> >> Brian >> >> On Oct 14, 2011, at 8:03 AM, wrote: >> >>> Peter, Brian >>> >>> I agree that "uncertainty" and "confidence" are better terms, but >> "location accuracy" is also used by Ofcom in their consultation >> proposals. They allow the location accuracy to be varied in database >> queries to include the transmissions of the slaves, for example a 500m >> cell could be catered for by specifying the master location plus an >> accuracy of 600m, made up of 500m for the cell radius and 100m for the >> actual location uncertainty of the measurement made by the master > device. >>> >>> We are close to being able to propose two new use cases on the >> reflector and also have additional requirements that fall from >> those, particularly addressing the UK/Ofcom needs. >>> >>> Andy >>> >>> -----Original Message----- From: paws-bounces@ietf.org >>> [mailto:paws-bounces@ietf.org] On Behalf Of Peter McCann Sent: 13 >>> October 2011 22:37 To: Rosen, Brian Cc: paws@ietf.org Subject: Re: >>> [paws] Possible new use case: simulcasting >>> >>> The "accuracy" term comes from the list of requirements already >> proposed by Gabor. I just added the second sentence. However we >> define it, I'd like to make sure that the WS device can report its >> location as several points (with whatever uncertainty/confidence > measures for each one). >>> The database should find spectrum that is open at all of the given >>> points. >>> >>> -Pete >>> >>> Rosen, Brian wrote: >>>> We don't use the term "accuracy" when talking about location. We use >>>> "uncertainty" and "confidence", as in "the location is within 10 >>>> meters of X,Y with 95% confidence", which is a circular uncertainty >>>> area. >>>> >>>> Brian >>>> >>>> On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: >>>> >>>>> Hi, Gabor, >>>>> >>>>> I think the requirement could be expressed as a refinement of what >>>>> you mean by "location" in requirement D.3: >>>>> >>>>> D.3: The Data Model MUST support specifying the location of the >>>>> subject and accuracy of location determination. Here, "location" >>>>> can be a single point or a set of points. >>>>> >>>>> -Pete >>>>> >>>>> Gabor.Bajko@nokia.com wrote: >>>>>> Pete, >>>>>> If your use case is covered by 4.3, but the requirements may be >>>>>> different, please feel free to propose your protocol >>>>>> requirement to the list. >>>>>> -Gabor >>>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>> Behalf Of ext Peter McCann >>>>>> Sent: Wednesday, September 14, 2011 10:30 AM >>>>>> To: Patil Basavaraj (Nokia-CIC/Dallas); >>>>>> gerald.chouinard@crc.ca; Probasco Scott (Nokia-CIC/Dallas) >>>>>> Cc: paws@ietf.org >>>>>> Subject: Re: [paws] Possible new use case: simulcasting >>>>>> >>>>>> Hi, Raj, >>>>>> >>>>>> I think my use case is covered by Section 4.3 with a small change >>>>>> along the lines that Scott suggested. Note there is this text in >>>>>> step 8: >>>>>> >>>>>> 8. The slave or user device scans the TV bands to locate a > WRAN >>>>>> transmission, and associates with the master/BS. The >>>>>> slave/user device provides its geolocation to the BS which, in >>>>>> turn, queries the database for a list of channels available at >>>>>> the slaves' geolocation. >>>>>> What I am suggesting is no different except for the fact that each >>>>>> of the devices could have independent Internet access and be >>>>>> capable of querying the database itself. There could be one BS >>>>>> that handles all the queries or the individual BSs could query >>>>>> themselves (each for their own location) and they could compare >>>>>> notes to find a common free channel. >>>>>> >>>>>> As for the protocol between the BS and the WSDB, we may want to >>>>>> have a requirement that the protocol carry multiple location >>>>>> elements (instead of just one) so that we save the cost of multiple >>>>>> queries across the Internet. The WSDB, after doing the polygon >>>>>> intersection test at each location, could additionally do a set >>>>>> intersection test on the remaining free channels and return the >>>>>> results. That's one concrete way that this use case may impact the >>>>>> protocol specification. >>>>>> >>>>>> -Pete From gerald.chouinard@crc.ca Fri Oct 14 07:33: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 1EFB021F8C70 for ; Fri, 14 Oct 2011 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 CaC5RC5kmksm for ; Fri, 14 Oct 2011 07:33:50 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 2333C21F8C6B for ; Fri, 14 Oct 2011 07:33:50 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id B712D6B0405; Fri, 14 Oct 2011 10:33:49 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 9A7456B0377; Fri, 14 Oct 2011 10:33:49 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 8CCF56B03DD; Fri, 14 Oct 2011 10:33:49 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id A9BDD6B0377; Fri, 14 Oct 2011 10:33:48 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id 2E69F6B1777; Fri, 14 Oct 2011 10:33:48 -0400 (EDT) Message-Id: <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Oct 2011 10:33:31 -0400 To: Peter McCann , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" From: Gerald Chouinard References: < <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.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: Fri, 14 Oct 2011 14:33:51 -0000 Peter, In the 802.22 WRAN model, the process of intersection is done at the base station because the base station should be able to decide whether to accept association with a new user terminal or not, depending on the extent this new terminal limits the number of available channels. This would not be possible if this is done at the database. The base station (or the master in more general terms) should maintain a local table of available channel sets (or maximum allowed EIRP per channel) to have all the information necessary to continuously optimize its use of the RF spectrum. One can imagine a new terminal that asks to be associated that may reduce the number of available channels to only a few but, by disassociating another terminal in a different location, the local network would regain even more available channels, as a result of the intersection process. The base station could then decide to stop its association with this second terminal and associate the first terminal. This intelligence should not be relegated to the database but should be kept local at the base station. Whether the base station queries the database for each of its associated terminals one at a time or in 'batch' mode for all its terminals, the complete information should be obtained from the database so that the process of 'intersection' can take place at the base station. Gerald At 11:50 14-10-11 +0000, Peter McCann wrote: >D.6 comes close, but also seems to allow returning the union >set of all channels available at the multiple locations. I >want to make sure the WSDB can do a set intersection of the >available channels at each of the listed locations. > >-Pete > >Gabor.Bajko@nokia.com wrote: > > Pete, > > > > Would D.6/D.7 cover your requirement: > > D.6: The Data Model MUST support specifying channel availability > > information for multiple locations. > > D.7: The Data Model MUST support specifying channel availability > > information for an area around a specified location. > > > > -Gabor > > > > -----Original Message----- From: ext Peter McCann > > [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011 2:24 > > PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj (Nokia- > > CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott (Nokia-CIC/Dallas) > > Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: simulcasting > > > > Hi, Gabor, > > > > I think the requirement could be expressed as a refinement of what you > > mean by "location" in requirement D.3: > > > > D.3: The Data Model MUST support specifying the location of the > > subject and accuracy of location determination. Here, "location" can > > be a single point or a set of points. > > > > -Pete > > > > Gabor.Bajko@nokia.com wrote: > >> Pete, > >> If your use case is covered by 4.3, but the requirements may be > >> different, please feel free to propose your protocol requirement to > >> the list. > >> -Gabor > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > >> Of ext Peter McCann > >> Sent: Wednesday, September 14, 2011 10:30 AM > >> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; > >> Probasco Scott (Nokia-CIC/Dallas) > >> Cc: paws@ietf.org > >> Subject: Re: [paws] Possible new use case: simulcasting > >> > >> Hi, Raj, > >> > >> I think my use case is covered by Section 4.3 with a small change along > >> the lines that Scott suggested. Note there is this text in step 8: > >> > >> 8. The slave or user device scans the TV bands to locate a WRAN > >> transmission, and associates with the master/BS. The slave/user > >> device provides its geolocation to the BS which, in turn, > >> queries the database for a list of channels available at the > >> slaves' geolocation. > >> What I am suggesting is no different except for the fact that each of > >> the devices could have independent Internet access and be capable of > >> querying the database itself. There could be one BS that handles all > >> the queries or the individual BSs could query themselves (each for > >> their own location) and they could compare notes to find a common free > >> channel. > >> > >> As for the protocol between the BS and the WSDB, we may want to have a > >> requirement that the protocol carry multiple location elements (instead > >> of just one) so that we save the cost of multiple queries across the > >> Internet. The WSDB, after doing the polygon intersection test at each > >> location, could additionally do a set intersection test on the > >> remaining free channels and return the results. That's one concrete > >> way that this use case may impact the protocol specification. > >> > >> -Pete > >> > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Fri Oct 14 07:35:00 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E75821F8C70 for ; Fri, 14 Oct 2011 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 A3ycW9u9VDbr for ; Fri, 14 Oct 2011 07:34:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62F21F8C6B for ; Fri, 14 Oct 2011 07:34:59 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 14 Oct 2011 15:34:57 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.67]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 14 Oct 2011 15:34:57 +0100 From: To: , , Date: Fri, 14 Oct 2011 15:34:56 +0100 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAYQIvHfAAAv3hAAADjFkA== Message-ID: <619CDADDCCD2B44380834BE8BF6F714140491FE04E@EMV62-UKRD.domain1.systemhost.net> References: <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> <5.1.0.14.2.20111014101317.01b9fb20@imap.crc.ca> <5963DDF1F751474D8DEEFDCDBEE43AE716401A91@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716401A91@dfweml503-mbx.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB 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: Fri, 14 Oct 2011 14:35:00 -0000 Agreed. I brought up the idea of 'varying the uncertainty radius' as anothe= r option, already put forward by Ofcom, it is not necessarily ideal for the= simulcasting use case. Maybe I should have started a new thread. Andy -----Original Message----- From: Peter McCann [mailto:Peter.McCann@huawei.com]=20 Sent: 14 October 2011 15:27 To: Gerald Chouinard; Sago,AJ,Andy,COD R; Brian.Rosen@neustar.biz Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: simulcasting Slave devices (or peer master devices engaged in simulcasting) may not be a= rranged in a circular area and enlarging the uncertainty radius to include = all of them may result in a geographic footprint that is way too large. It= should be possible to include multiple points/uncertainty radii and have t= he WSDB return spectrum that is free in all of the circles. -Pete Gerald Chouinard wrote: > Andy, >=20 > As shown in the excerpt that you included below, Ofcom seem to use the=20 > terms "accuracy" and "uncertainty" interchangeably. The IETF-PAWS=20 > should align with the intent but use the more correct term=20 > "uncertainty" in its proceedings. "Uncertainty" can then be extended=20 > to include a larger "uncertainty" radius around a location to take=20 > into account of the existence of the slave devices. >=20 > Gerald >=20 >=20 > At 14:27 14-10-11 +0100, andy.sago@bt.com wrote: >> Brian >>=20 >> I've gone back to Ofcom's original consultation and it does say the=20 >> accuracy should be specified to a 95% certainty, so the rules of=20 >> physics have been allowed for. Sorry I didn't include that in the=20 >> earlier mail. They then allow for the accuracy to be varied to=20 >> account for slave devices. Some of the language is probably a bit=20 >> lax, but the protocol may need to cater for varying confidence levels=20 >> across regulatory domains as you say. With the caveat that this is=20 >> only one paragraph from Ofcom's consultation and not the full story,=20 >> and their views may have moved on, their text on varying the location=20 >> accuracy >> says: >>=20 >> The slave devices will be some distance from the master device. As a=20 >> result, they may be closer to a licensed receiver than the master and=20 >> when they transmit they may cause interference. To prevent this=20 >> occurring the master device needs to inform the database of the=20 >> possible distance away that slave devices may be located and the=20 >> database can then take this information into account when assigning=20 >> frequencies and power levels. We propose that an effective way for=20 >> the master device to do this is to increase its location uncertainty=20 >> by an amount related to the maximum expected range between the master=20 >> and slave device. Hence, if the master device knew its location=20 >> accuracy to 100m and it knew that the maximum range to a slave device=20 >> was 500m it would report a location accuracy of 600m to the database.=20 >> The database would then search across all pixels within the possible=20 >> location circle and return a result based on the minimum power level=20 >> across all pixels for each frequency. >>=20 >> (Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at=20 >> http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/s=20 >> u m mary/geolocation.pdf) >>=20 >> Regards >>=20 >> Andy >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: 14 October 2011 13:39 >> To: Sago,AJ,Andy,COD R >> Cc: Peter.McCann@huawei.com; paws@ietf.org >> Subject: Re: [paws] Possible new use case: simulcasting >>=20 >> While I recognize that regulators are not bound by the >> laws of physics, engineers generally are. There are no measurement >> mechanisms I am aware of that will yield a lat/lon/altitude that do=20 >> not have some form of confidence factor. We have lots of experience=20 >> with these issues in the U.S. cell phone emergency call system. If=20 >> you don't specify confidence, someone can give you an uncertainty of=20 >> 10 meters, and just not tell you that confidence is 20%. More=20 >> specifically, we actually did experience some measurements with 65%=20 >> confidence being compared to some measurements with 95% confidence=20 >> but the same uncertainty. Big difference. >>=20 >> So, while a regulator can choose to ignore confidence, the protocol=20 >> cannot, IMHO. There is no definition of "accuracy" that I'm aware of=20 >> in the context of measured lat/lon which meets any engineering rigor. >> If the regulator says "accuracy", I would propose that the protocol=20 >> translate that to "uncertainty" and if "confidence" is unspecified, I=20 >> would default to 95%. >>=20 >> Brian >>=20 >> On Oct 14, 2011, at 8:03 AM, wrote: >>=20 >>> Peter, Brian >>>=20 >>> I agree that "uncertainty" and "confidence" are better terms, but >> "location accuracy" is also used by Ofcom in their consultation=20 >> proposals. They allow the location accuracy to be varied in database=20 >> queries to include the transmissions of the slaves, for example a=20 >> 500m cell could be catered for by specifying the master location plus=20 >> an accuracy of 600m, made up of 500m for the cell radius and 100m for=20 >> the actual location uncertainty of the measurement made by the master > device. >>>=20 >>> We are close to being able to propose two new use cases on the >> reflector and also have additional requirements that fall from those,=20 >> particularly addressing the UK/Ofcom needs. >>>=20 >>> Andy >>>=20 >>> -----Original Message----- From: paws-bounces@ietf.org=20 >>> [mailto:paws-bounces@ietf.org] On Behalf Of Peter McCann Sent: 13=20 >>> October 2011 22:37 To: Rosen, Brian Cc: paws@ietf.org Subject: Re: >>> [paws] Possible new use case: simulcasting >>>=20 >>> The "accuracy" term comes from the list of requirements already >> proposed by Gabor. I just added the second sentence. However we=20 >> define it, I'd like to make sure that the WS device can report its=20 >> location as several points (with whatever uncertainty/confidence > measures for each one). >>> The database should find spectrum that is open at all of the given=20 >>> points. >>>=20 >>> -Pete >>>=20 >>> Rosen, Brian wrote: >>>> We don't use the term "accuracy" when talking about location. We=20 >>>> use "uncertainty" and "confidence", as in "the location is within=20 >>>> 10 meters of X,Y with 95% confidence", which is a circular=20 >>>> uncertainty area. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: >>>>=20 >>>>> Hi, Gabor, >>>>>=20 >>>>> I think the requirement could be expressed as a refinement of what=20 >>>>> you mean by "location" in requirement D.3: >>>>>=20 >>>>> D.3: The Data Model MUST support specifying the location of the=20 >>>>> subject and accuracy of location determination. Here, "location" >>>>> can be a single point or a set of points. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>> Gabor.Bajko@nokia.com wrote: >>>>>> Pete, >>>>>> If your use case is covered by 4.3, but the requirements may be=20 >>>>>> different, please feel free to propose your protocol requirement=20 >>>>>> to the list. >>>>>> -Gabor >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >>>>>> Behalf Of ext Peter McCann >>>>>> Sent: Wednesday, September 14, 2011 10:30 AM >>>>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca;=20 >>>>>> Probasco Scott (Nokia-CIC/Dallas) >>>>>> Cc: paws@ietf.org >>>>>> Subject: Re: [paws] Possible new use case: simulcasting >>>>>>=20 >>>>>> Hi, Raj, >>>>>>=20 >>>>>> I think my use case is covered by Section 4.3 with a small change=20 >>>>>> along the lines that Scott suggested. Note there is this text in=20 >>>>>> step 8: >>>>>>=20 >>>>>> 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=20 >>>>>> each of the devices could have independent Internet access and be=20 >>>>>> capable of querying the database itself. There could be one BS=20 >>>>>> that handles all the queries or the individual BSs could query=20 >>>>>> themselves (each for their own location) and they could compare=20 >>>>>> notes to find a common free channel. >>>>>>=20 >>>>>> As for the protocol between the BS and the WSDB, we may want to=20 >>>>>> have a requirement that the protocol carry multiple location=20 >>>>>> elements (instead of just one) so that we save the cost of=20 >>>>>> multiple queries across the Internet. The WSDB, after doing the=20 >>>>>> polygon intersection test at each location, could additionally do=20 >>>>>> a set intersection test on the remaining free channels and return=20 >>>>>> the results. That's one concrete way that this use case may=20 >>>>>> impact the protocol specification. >>>>>>=20 >>>>>> -Pete From gerald.chouinard@crc.ca Fri Oct 14 07:38:03 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 325B521F8C8B for ; Fri, 14 Oct 2011 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 ptOo5UpOshSi for ; Fri, 14 Oct 2011 07:38:02 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id C57E321F8C86 for ; Fri, 14 Oct 2011 07:38:01 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 643DC6B0405; Fri, 14 Oct 2011 10:38:01 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 487426B0377; Fri, 14 Oct 2011 10:38:01 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 3A2146B03DE; Fri, 14 Oct 2011 10:38:01 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id C7B9B6B0377; Fri, 14 Oct 2011 10:37:59 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id 487966B1777; Fri, 14 Oct 2011 10:37:59 -0400 (EDT) Message-Id: <5.1.0.14.2.20111014103447.01b87cb8@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Oct 2011 10:37:52 -0400 To: Peter McCann , "andy.sago@bt.com" , "Brian.Rosen@neustar.biz" From: Gerald Chouinard References: <5.1.0.14.2.20111014101317.01b9fb20@imap.crc.ca> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <6B8D4C5D-6413-47A6-81C3-FF654B5897DB@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716401952@dfweml503-mbx.china.huawei.com> <619CDADDCCD2B44380834BE8BF6F714140491FDEB3@EMV62-UKRD.domain1.systemhost.net> <5.1.0.14.2.20111014101317.01b9fb20@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: Fri, 14 Oct 2011 14:38:03 -0000 Peter, I guess what Ofcom was referring to is something similar to the Mode I devices in the US that do not need to be geolocated since they are assumed to be close to the master device. In the case where these slave devices need to be geolocated, I agree with you that their actual locatiohn should be used rather than arbitrarily extending the radius of an imaginary circle around the master device. Gerald At 14:27 14-10-11 +0000, Peter McCann wrote: >Slave devices (or peer master devices engaged in simulcasting) may not >be arranged in a circular area and enlarging the uncertainty radius to >include all of them may result in a geographic footprint that is way >too large. It should be possible to include multiple points/uncertainty >radii and have the WSDB return spectrum that is free in all of the >circles. > >-Pete > >Gerald Chouinard wrote: > > Andy, > > > > As shown in the excerpt that you included below, Ofcom seem to use the > > terms "accuracy" and "uncertainty" interchangeably. The IETF-PAWS > > should align with the intent but use the more correct term > > "uncertainty" in its proceedings. "Uncertainty" can then be extended > > to include a larger "uncertainty" radius around a location to take > > into account of the existence of the slave devices. > > > > Gerald > > > > > > At 14:27 14-10-11 +0100, andy.sago@bt.com wrote: > >> Brian > >> > >> I've gone back to Ofcom's original consultation and it does say the > >> accuracy should be specified to a 95% certainty, so the rules of > >> physics have been allowed for. Sorry I didn't include that in the > >> earlier mail. They then allow for the accuracy to be varied to account > >> for slave devices. Some of the language is probably a bit lax, but the > >> protocol may need to cater for varying confidence levels across > >> regulatory domains as you say. With the caveat that this is only one > >> paragraph from Ofcom's consultation and not the full story, and their > >> views may have moved on, their text on varying the location accuracy > >> says: > >> > >> The slave devices will be some distance from the master device. As a > >> result, they may be closer to a licensed receiver than the master and > >> when they transmit they may cause interference. To prevent this > >> occurring the master device needs to inform the database of the > >> possible distance away that slave devices may be located and the > >> database can then take this information into account when assigning > >> frequencies and power levels. We propose that an effective way for the > >> master device to do this is to increase its location uncertainty by an > >> amount related to the maximum expected range between the master and > >> slave device. Hence, if the master device knew its location accuracy to > >> 100m and it knew that the maximum range to a slave device was 500m it > >> would report a location accuracy of 600m to the database. The database > >> would then search across all pixels within the possible location circle > >> and return a result based on the minimum power level across all pixels > >> for each frequency. > >> > >> (Ref paragraphs 3.14-3.15 in Implementing Geolocation (9 Nov 2010) at > >> http://stakeholders.ofcom.org.uk/binaries/consultations/geolocation/s u > >> m mary/geolocation.pdf) > >> > >> Regards > >> > >> Andy > >> > >> -----Original Message----- > >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >> Sent: 14 October 2011 13:39 > >> To: Sago,AJ,Andy,COD R > >> Cc: Peter.McCann@huawei.com; paws@ietf.org > >> Subject: Re: [paws] Possible new use case: simulcasting > >> > >> While I recognize that regulators are not bound by the > >> laws of physics, engineers generally are. There are no measurement > >> mechanisms I am aware of that will yield a lat/lon/altitude that do not > >> have some form of confidence factor. We have lots of experience with > >> these issues in the U.S. cell phone emergency call system. If you > >> don't specify confidence, someone can give you an uncertainty of 10 > >> meters, and just not tell you that confidence is 20%. More > >> specifically, we actually did experience some measurements with 65% > >> confidence being compared to some measurements with 95% confidence but > >> the same uncertainty. Big difference. > >> > >> So, while a regulator can choose to ignore confidence, the protocol > >> cannot, IMHO. There is no definition of "accuracy" that I'm aware of > >> in the context of measured lat/lon which meets any engineering rigor. > >> If the regulator says "accuracy", I would propose that the protocol > >> translate that to "uncertainty" and if "confidence" is unspecified, I > >> would default to 95%. > >> > >> Brian > >> > >> On Oct 14, 2011, at 8:03 AM, wrote: > >> > >>> Peter, Brian > >>> > >>> I agree that "uncertainty" and "confidence" are better terms, but > >> "location accuracy" is also used by Ofcom in their consultation > >> proposals. They allow the location accuracy to be varied in database > >> queries to include the transmissions of the slaves, for example a 500m > >> cell could be catered for by specifying the master location plus an > >> accuracy of 600m, made up of 500m for the cell radius and 100m for the > >> actual location uncertainty of the measurement made by the master > > device. > >>> > >>> We are close to being able to propose two new use cases on the > >> reflector and also have additional requirements that fall from > >> those, particularly addressing the UK/Ofcom needs. > >>> > >>> Andy > >>> > >>> -----Original Message----- From: paws-bounces@ietf.org > >>> [mailto:paws-bounces@ietf.org] On Behalf Of Peter McCann Sent: 13 > >>> October 2011 22:37 To: Rosen, Brian Cc: paws@ietf.org Subject: Re: > >>> [paws] Possible new use case: simulcasting > >>> > >>> The "accuracy" term comes from the list of requirements already > >> proposed by Gabor. I just added the second sentence. However we > >> define it, I'd like to make sure that the WS device can report its > >> location as several points (with whatever uncertainty/confidence > > measures for each one). > >>> The database should find spectrum that is open at all of the given > >>> points. > >>> > >>> -Pete > >>> > >>> Rosen, Brian wrote: > >>>> We don't use the term "accuracy" when talking about location. We use > >>>> "uncertainty" and "confidence", as in "the location is within 10 > >>>> meters of X,Y with 95% confidence", which is a circular uncertainty > >>>> area. > >>>> > >>>> Brian > >>>> > >>>> On Oct 13, 2011, at 5:23 PM, Peter McCann wrote: > >>>> > >>>>> Hi, Gabor, > >>>>> > >>>>> I think the requirement could be expressed as a refinement of what > >>>>> you mean by "location" in requirement D.3: > >>>>> > >>>>> D.3: The Data Model MUST support specifying the location of the > >>>>> subject and accuracy of location determination. Here, "location" > >>>>> can be a single point or a set of points. > >>>>> > >>>>> -Pete > >>>>> > >>>>> Gabor.Bajko@nokia.com wrote: > >>>>>> Pete, > >>>>>> If your use case is covered by 4.3, but the requirements may be > >>>>>> different, please feel free to propose your protocol > >>>>>> requirement to the list. > >>>>>> -Gabor > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >>>>>> Behalf Of ext Peter McCann > >>>>>> Sent: Wednesday, September 14, 2011 10:30 AM > >>>>>> To: Patil Basavaraj (Nokia-CIC/Dallas); > >>>>>> gerald.chouinard@crc.ca; Probasco Scott (Nokia-CIC/Dallas) > >>>>>> Cc: paws@ietf.org > >>>>>> Subject: Re: [paws] Possible new use case: simulcasting > >>>>>> > >>>>>> Hi, Raj, > >>>>>> > >>>>>> I think my use case is covered by Section 4.3 with a small change > >>>>>> along the lines that Scott suggested. Note there is this text in > >>>>>> step 8: > >>>>>> > >>>>>> 8. The slave or user device scans the TV bands to locate a > > WRAN > >>>>>> transmission, and associates with the master/BS. The > >>>>>> slave/user device provides its geolocation to the BS which, in > >>>>>> turn, queries the database for a list of channels available at > >>>>>> the slaves' geolocation. > >>>>>> What I am suggesting is no different except for the fact that each > >>>>>> of the devices could have independent Internet access and be > >>>>>> capable of querying the database itself. There could be one BS > >>>>>> that handles all the queries or the individual BSs could query > >>>>>> themselves (each for their own location) and they could compare > >>>>>> notes to find a common free channel. > >>>>>> > >>>>>> As for the protocol between the BS and the WSDB, we may want to > >>>>>> have a requirement that the protocol carry multiple location > >>>>>> elements (instead of just one) so that we save the cost of multiple > >>>>>> queries across the Internet. The WSDB, after doing the polygon > >>>>>> intersection test at each location, could additionally do a set > >>>>>> intersection test on the remaining free channels and return the > >>>>>> results. That's one concrete way that this use case may impact the > >>>>>> protocol specification. > >>>>>> > >>>>>> -Pete From Peter.McCann@huawei.com Fri Oct 14 07:53: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 ACEC421F8C00 for ; Fri, 14 Oct 2011 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 g5Lpt2GZLyuA for ; Fri, 14 Oct 2011 07:53:25 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id E559321F8C80 for ; Fri, 14 Oct 2011 07:53:24 -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 <0LT200GDC9CZSC@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 09:53:24 -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 <0LT2006Y79CR53@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 09:53:23 -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; Fri, 14 Oct 2011 07:50:39 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 07:50:41 -0700 Date: Fri, 14 Oct 2011 14:50:40 +0000 From: Peter McCann In-reply-to: <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> X-Originating-IP: [10.193.125.57] To: Gerald Chouinard , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716401ACD@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//7S8AIABAtKAgAB1DzD//49ngIAAdSKAgCvgIYD//vV7sIADNsQ5///8V/A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@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: Fri, 14 Oct 2011 14:53:25 -0000 Hi, Gerald, I think doing the intersection at the master device might be acceptable, as long as the "batch" location mode is supported. However, it might lead to a lot of redundant data being sent back from the WSDB if there are many channels free in all given locations. Perhaps some sort of compression could be defined so that the common channels are sent only once? That would be roughly equivalent to doing an intersection but you would also send the additional information about the channels that were free only in specific locations. This would allow the master device to do the kind of computations you outline below. -Pete Gerald Chouinard wrote: > Peter, > > In the 802.22 WRAN model, the process of intersection is done at the > base station because the base station should be able to decide whether > to accept association with a new user terminal or not, depending on > the extent this new terminal limits the number of available channels. > This would not be possible if this is done at the database. > > The base station (or the master in more general terms) should maintain > a local table of available channel sets (or maximum allowed EIRP per > channel) to have all the information necessary to continuously > optimize its use of the RF spectrum. One can imagine a new terminal > that asks to be associated that may reduce the number of available > channels to only a few but, by disassociating another terminal in a > different location, the local network would regain even more available > channels, as a result of the intersection process. The base station > could then decide to stop its association with this second terminal > and associate the first terminal. This intelligence should not be > relegated to the database but should be kept local at the base station. > > Whether the base station queries the database for each of its > associated terminals one at a time or in 'batch' mode for all its > terminals, the complete information should be obtained from the > database so that the process of 'intersection' can take place at the > base station. > > Gerald > > > At 11:50 14-10-11 +0000, Peter McCann wrote: >> D.6 comes close, but also seems to allow returning the union set of all >> channels available at the multiple locations. I want to make sure the >> WSDB can do a set intersection of the available channels at each of the >> listed locations. >> >> -Pete >> >> Gabor.Bajko@nokia.com wrote: >>> Pete, >>> >>> Would D.6/D.7 cover your requirement: >>> D.6: The Data Model MUST support specifying channel availability >>> information for multiple locations. >>> D.7: The Data Model MUST support specifying channel availability >>> information for an area around a specified location. >>> >>> -Gabor >>> >>> -----Original Message----- From: ext Peter McCann >>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011 >>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj >>> (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott >>> (Nokia-CIC/Dallas) >>> Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: >>> simulcasting >>> >>> Hi, Gabor, >>> >>> I think the requirement could be expressed as a refinement of what >>> you mean by "location" in requirement D.3: >>> >>> D.3: The Data Model MUST support specifying the location of the >>> subject and accuracy of location determination. Here, "location" >>> can be a single point or a set of points. >>> >>> -Pete >>> >>> Gabor.Bajko@nokia.com wrote: >>>> Pete, If your use case is covered by 4.3, but the requirements may be >>>> different, please feel free to propose your protocol requirement to >>>> the list. -Gabor >>>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>> Behalf Of ext Peter McCann >>>> Sent: Wednesday, September 14, 2011 10:30 AM >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; >>>> Probasco Scott (Nokia-CIC/Dallas) >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] Possible new use case: simulcasting >>>> >>>> Hi, Raj, >>>> >>>> I think my use case is covered by Section 4.3 with a small change >>>> along the lines that Scott suggested. Note there is this text in >>>> step 8: >>>> >>>> 8. The slave or user device scans the TV bands to locate a > WRAN >>>> transmission, and associates with the master/BS. The >>>> slave/user device provides its geolocation to the BS which, in >>>> turn, queries the database for a list of channels available at >>>> the slaves' geolocation. >>>> What I am suggesting is no different except for the fact that >>>> each of the devices could have independent Internet access and be >>>> capable of querying the database itself. There could be one BS >>>> that handles all the queries or the individual BSs could query >>>> themselves (each for their own location) and they could compare >>>> notes to find a common free channel. >>>> >>>> As for the protocol between the BS and the WSDB, we may want to have >>>> a requirement that the protocol carry multiple location elements >>>> (instead of just one) so that we save the cost of multiple queries >>>> across the Internet. The WSDB, after doing the polygon intersection >>>> test at each location, could additionally do a set intersection test >>>> on the remaining free channels and return the results. That's one >>>> concrete way that this use case may impact the protocol specification. >>>> >>>> -Pete >>>> From gerald.chouinard@crc.ca Fri Oct 14 08:10: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 0732821F8C5D for ; Fri, 14 Oct 2011 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 moDYjL0T4Ff2 for ; Fri, 14 Oct 2011 08:09:49 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id CC9B521F889A for ; Fri, 14 Oct 2011 08:09:31 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id E85F26B03BB; Fri, 14 Oct 2011 11:09:26 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id CB1C56B0377; Fri, 14 Oct 2011 11:09:26 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id A94266B03DE; Fri, 14 Oct 2011 11:09:26 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 9DE226B0377; Fri, 14 Oct 2011 11:09:25 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id 1FB4F6B1777; Fri, 14 Oct 2011 11:09:25 -0400 (EDT) Message-Id: <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Oct 2011 11:08:58 -0400 To: Peter McCann , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" From: Gerald Chouinard References: <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@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: Fri, 14 Oct 2011 15:10:14 -0000 Pete, Agreed. A simple compression scheme could be proposed in the PAWS protocol and that is to query only only on a 'differential' basis, i.e., the database would only send what has changed since the last query. This could also be applied to the query message from the base station, i.e., sending only the information that would have changed since the last query (e.g., new terminal, changed geoposition, etc.). Gerald At 14:50 14-10-11 +0000, Peter McCann wrote: >Hi, Gerald, > >I think doing the intersection at the master device might be >acceptable, as long as the "batch" location mode is supported. >However, it might lead to a lot of redundant data being >sent back from the WSDB if there are many channels free in >all given locations. Perhaps some sort of compression could >be defined so that the common channels are sent only once? >That would be roughly equivalent to doing an intersection >but you would also send the additional information about the >channels that were free only in specific locations. This >would allow the master device to do the kind of computations >you outline below. > >-Pete > > >Gerald Chouinard wrote: > > Peter, > > > > In the 802.22 WRAN model, the process of intersection is done at the > > base station because the base station should be able to decide whether > > to accept association with a new user terminal or not, depending on > > the extent this new terminal limits the number of available channels. > > This would not be possible if this is done at the database. > > > > The base station (or the master in more general terms) should maintain > > a local table of available channel sets (or maximum allowed EIRP per > > channel) to have all the information necessary to continuously > > optimize its use of the RF spectrum. One can imagine a new terminal > > that asks to be associated that may reduce the number of available > > channels to only a few but, by disassociating another terminal in a > > different location, the local network would regain even more available > > channels, as a result of the intersection process. The base station > > could then decide to stop its association with this second terminal > > and associate the first terminal. This intelligence should not be > > relegated to the database but should be kept local at the base station. > > > > Whether the base station queries the database for each of its > > associated terminals one at a time or in 'batch' mode for all its > > terminals, the complete information should be obtained from the > > database so that the process of 'intersection' can take place at the > > base station. > > > > Gerald > > > > > > At 11:50 14-10-11 +0000, Peter McCann wrote: > >> D.6 comes close, but also seems to allow returning the union set of all > >> channels available at the multiple locations. I want to make sure the > >> WSDB can do a set intersection of the available channels at each of the > >> listed locations. > >> > >> -Pete > >> > >> Gabor.Bajko@nokia.com wrote: > >>> Pete, > >>> > >>> Would D.6/D.7 cover your requirement: > >>> D.6: The Data Model MUST support specifying channel availability > >>> information for multiple locations. > >>> D.7: The Data Model MUST support specifying channel availability > >>> information for an area around a specified location. > >>> > >>> -Gabor > >>> > >>> -----Original Message----- From: ext Peter McCann > >>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011 > >>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj > >>> (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott > >>> (Nokia-CIC/Dallas) > >>> Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: > >>> simulcasting > >>> > >>> Hi, Gabor, > >>> > >>> I think the requirement could be expressed as a refinement of what > >>> you mean by "location" in requirement D.3: > >>> > >>> D.3: The Data Model MUST support specifying the location of the > >>> subject and accuracy of location determination. Here, "location" > >>> can be a single point or a set of points. > >>> > >>> -Pete > >>> > >>> Gabor.Bajko@nokia.com wrote: > >>>> Pete, If your use case is covered by 4.3, but the requirements may be > >>>> different, please feel free to propose your protocol requirement to > >>>> the list. -Gabor > >>>> > >>>> -----Original Message----- > >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >>>> Behalf Of ext Peter McCann > >>>> Sent: Wednesday, September 14, 2011 10:30 AM > >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; > >>>> Probasco Scott (Nokia-CIC/Dallas) > >>>> Cc: paws@ietf.org > >>>> Subject: Re: [paws] Possible new use case: simulcasting > >>>> > >>>> Hi, Raj, > >>>> > >>>> I think my use case is covered by Section 4.3 with a small change > >>>> along the lines that Scott suggested. Note there is this text in > >>>> step 8: > >>>> > >>>> 8. The slave or user device scans the TV bands to locate a > > WRAN > >>>> transmission, and associates with the master/BS. The > >>>> slave/user device provides its geolocation to the BS which, in > >>>> turn, queries the database for a list of channels available at > >>>> the slaves' geolocation. > >>>> What I am suggesting is no different except for the fact that > >>>> each of the devices could have independent Internet access and be > >>>> capable of querying the database itself. There could be one BS > >>>> that handles all the queries or the individual BSs could query > >>>> themselves (each for their own location) and they could compare > >>>> notes to find a common free channel. > >>>> > >>>> As for the protocol between the BS and the WSDB, we may want to have > >>>> a requirement that the protocol carry multiple location elements > >>>> (instead of just one) so that we save the cost of multiple queries > >>>> across the Internet. The WSDB, after doing the polygon intersection > >>>> test at each location, could additionally do a set intersection test > >>>> on the remaining free channels and return the results. That's one > >>>> concrete way that this use case may impact the protocol specification. > >>>> > >>>> -Pete > >>>> From pecclesi@cisco.com Fri Oct 14 09:17: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 CBA4221F8C22 for ; Fri, 14 Oct 2011 09:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.543 X-Spam-Level: X-Spam-Status: No, score=-4.543 tagged_above=-999 required=5 tests=[AWL=2.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WR2OdnLmR6gj for ; Fri, 14 Oct 2011 09:17:31 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9152221F8C14 for ; Fri, 14 Oct 2011 09:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pecclesi@cisco.com; l=29727; q=dns/txt; s=iport; t=1318609051; x=1319818651; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=HFX7YcVrA9MCseemSGlOGi+Gb9ATZLMKaWD7Tb48Tfw=; b=bXF76I4EGfT2ctdW1+IKpWizXtUhrTDpNWjHPN3+2gE1mzecn0F6usSP nB3t2vn4U8hCAgOFZqZgfq8/DeCW66XRt9xtmV/AmlCVf8pVl3l60yZ4x UUP66Xg3acSilWqfU3VLmGsV+k3nASFkMAud7KSwmd8AsyDGn3p+tIdGa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAAAKdfmE6rRDoG/2dsb2JhbABAA4JNlm9EhygBhzuBBYFuAQEBAgEBAQEBDwEJEQM+GwIBCBEDAQEBCwYQAQYBBgEmHwkIAgQBEggah10ImHkBnleEZII0YQSIAZEnjEQ X-IronPort-AV: E=Sophos;i="4.69,347,1315180800"; d="scan'208,217";a="7920299" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 Oct 2011 16:17:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9EGHVV4024220; Fri, 14 Oct 2011 16:17:31 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 09:17:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8A8C.C59236BA" Date: Fri, 14 Oct 2011 09:17:28 -0700 Message-ID: <30D62D93EA229643933BE9BF324FD1F30CF5F3D4@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] Several spectrum masks used by multi-bandwidth radios Thread-Index: AcyIif0iCZ0iSWcPRNy/1BOX+QJ5Hf//lS2A//5MhED//TS5YP/4XdVAAfw/7AD//1JfoA== References: <30D62D93EA229643933BE9BF324FD1F30CF5F220@xmb-sjc-22b.amer.cisco.com> From: "Peter Ecclesine (pecclesi)" To: , , X-OriginalArrivalTime: 14 Oct 2011 16:17:30.0893 (UTC) FILETIME=[C6014BD0:01CC8A8C] Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios 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, 14 Oct 2011 16:17:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8A8C.C59236BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, =20 In the current IEEE 802.11af Draft 1.04 we have a requirement that a client STA joining has to supply Device Identification Information (to support the FCC model where the database can deny any channels based on FCC ID) to the master STA in order to receive its own list of white space channels (to support the FCC model). We have added the provision that the device's spectrum masks are provided to support one of the information requests, and will expand that to other joining requirements. See 802.11-11/1349 (a work in progress) for how communicating the spectrum masks evolves. =20 petere =20 Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Friday, October 14, 2011 5:50 AM To: Peter Ecclesine (pecclesi); Basavaraj.Patil@nokia.com; paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios =20 Hi Peter, =20 Could you describe how the master enforces the specified limits on the client/slave devices? Perhaps the 'how' is beyond scope of PAWS, I am just trying to understand how the system would operate. =20 Regards, Scott =20 From: "ext Peter Ecclesine (pecclesi)" Date: Thu, 13 Oct 2011 13:36:12 -0700 To: Raj Patil , "paws@ietf.org" Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios =20 Hi Raj, =20 >> How is it relevant for client devices? It is only the master device that is generally making a query to the database. Clients devices can no doubt make the query as well, but would this requirement be applicable in such a case?<< =20 The database either makes assumptions about the transmissions of all client devices, or it can be informed what emissions the client devices will not exceed (because the master device will not allow clients to exceed specified limits).=20 =20 The general case is not all devices transmit with the same masks - relatively loose-masked inexpensive devices can joint networks controlled by higher-specification master devices - e.g., outdoor muni wi-fi. =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Thursday, October 13, 2011 9:01 AM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios =20 Hi Peter, =20 So how about the following text that we could add in the requirements section of the I-D: =20 - A white space master device should provide to the database in the query a description of the EIRP limits that will not be exceeded for each occupied bandwidth in the set of frequency bands.=20 =20 You indicated that this is applicable to master devices and client devices. How is it relevant for client devices? It is only the master device that is generally making a query to the database. Clients devices can no doubt make the query as well, but would this requirement be applicable in such a case? =20 -Raj =20 From: ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com]=20 Sent: Wednesday, October 12, 2011 5:36 PM To: Patil Basavaraj (Nokia-CIC/Dallas); paws@ietf.org Subject: RE: [paws] Several spectrum masks used by multi-bandwidth radios =20 Hi Raj, =20 The requirement for the protocol is to describe to the database the EIRP limits that will not be exceeded for each occupied bandwidth in each frequency band, for master devices and for client devices (these are the client spectrum masks I will permit to operate under my control). =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Tuesday, October 11, 2011 8:30 PM To: Peter Ecclesine (pecclesi); paws@ietf.org Subject: Re: [paws] Several spectrum masks used by multi-bandwidth radios =20 =20 So what would be the requirement that we can specify for the (device-2-database) protocol as a result of the need for various spectrum masks? =20 From: "ext Peter Ecclesine (pecclesi)" Date: Tue, 11 Oct 2011 19:52:32 -0700 To: "paws@ietf.org" Subject: [paws] Several spectrum masks used by multi-bandwidth radios =20 In IEEE 802.11af discussions, we expect to use a modified 802.11ac PHY, with several occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in several TV bands (VHF and UHF). =20 We see the need to tell the database several spectrum masks, each with: 1 - Lowest applicable frequency in MHz 2 - Highest applicable frequency in MHz 3 - Maximum total EIRP over the frequency range defined by the spectrum mask 4 - General spectrum mask in dBr from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask, expressed like IEEE 802.11p Annex I [http://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or FCC 47 C.F.R. 90.210(m).=20 5- measurement resolution bandwidth for EIRP measurements =20 This detailed actual spectrum occupancy information allows the database to perform more accurate interference calculations. =20 petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706=20 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 _______________________________________________ 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 ------_=_NextPart_001_01CC8A8C.C59236BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,

 

   In the = current IEEE 802.11af Draft 1.04 we have a requirement that a client STA = joining has to supply Device Identification Information (to support the = FCC model where the database can deny any channels based on FCC ID) to = the master STA in order to receive its own list of white space channels = (to support the FCC model). We have added the provision that the = device’s spectrum masks are provided to support one of the = information requests, and will expand that to other joining = requirements. See 802.11-11/1349 (a work in progress) for how = communicating the spectrum masks evolves.

 

petere

 

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without = Prejudice" U.C.C. 1-207

From:= = scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] =
Sent: Friday, October 14, 2011 5:50 AM
To: Peter = Ecclesine (pecclesi); Basavaraj.Patil@nokia.com; = paws@ietf.org
Subject: Re: [paws] Several spectrum masks used = by multi-bandwidth radios

 

Hi = Peter,

 

=

Could you describe how the master = enforces the specified limits on the client/slave devices? Perhaps the = 'how' is beyond scope of PAWS, I am just trying to understand how the = system would operate.

 

=

Regards,

Scott

<= div>

 

=

From: = "ext Peter Ecclesine = (pecclesi)" <pecclesi@cisco.com>
Date:= Thu, 13 Oct 2011 13:36:12 -0700
To: Raj Patil <Basavaraj.Patil@nokia.com&g= t;, "paws@ietf.org" = <paws@ietf.org>
Subject: = Re: [paws] Several spectrum masks used by multi-bandwidth = radios

 

=

Hi = Raj,

 

>> How is it relevant for client devices? = It is only the master device that is generally making a query to the = database. Clients devices can no doubt make the query as well, but would = this requirement be applicable in such a case?<<

 

   The database either makes = assumptions about the transmissions of all client devices, or it can be = informed what emissions the client devices will not exceed (because the = master device will not allow clients to exceed specified limits). =

 

   The general case is not all devices = transmit with the same masks – relatively loose-masked inexpensive = devices can joint networks controlled by higher-specification master = devices – e.g., outdoor muni wi-fi.

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without = Prejudice" U.C.C. 1-207

= From:= Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.co= m]
Sent: Thursday, October 13, 2011 9:01 AM
To: = Peter Ecclesine (pecclesi); paws@ietf.org
Subject: RE: = [paws] Several spectrum masks used by multi-bandwidth radios

 

Hi Peter,

 

So how about the following text that we could = add in the requirements section of the I-D:

 

-       &= nbsp;  A white space master = device should provide to the database in the query a description of the = EIRP limits that will not be exceeded for each occupied bandwidth in the = set of frequency bands.

 

You indicated that this is applicable to master = devices and client devices. How is it relevant for client devices? It is = only the master device that is generally making a query to the database. = Clients devices can no doubt make the query as well, but would this = requirement be applicable in such a case?

 

-Raj

 

= From:= ext Peter Ecclesine (pecclesi) [mailto:pecclesi@cisco.com] =
Sent: Wednesday, October 12, 2011 5:36 PM
To: Patil = Basavaraj (Nokia-CIC/Dallas); paws@ietf.org
Subject: RE: = [paws] Several spectrum masks used by multi-bandwidth radios

 

Hi Raj,

 

The requirement for the protocol is to describe = to the database the EIRP limits that will not be exceeded for each = occupied bandwidth in each frequency band, for master devices and for = client devices (these are the client spectrum masks I will permit to = operate under my control).

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without = Prejudice" U.C.C. 1-207

= From:= Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Pati= l@nokia.com]
Sent: Tuesday, October 11, 2011 8:30 = PM
To: Peter Ecclesine (pecclesi); paws@ietf.org
Subject: Re: = [paws] Several spectrum masks used by multi-bandwidth radios

 

 

So what = would be the requirement that we can specify for the (device-2-database) = protocol as a result of the need for various spectrum masks?

 

From: = "ext Peter Ecclesine = (pecclesi)" <pecclesi@cisco.com>
Date:= Tue, 11 Oct 2011 19:52:32 -0700
To: "paws@ietf.org" <paws@ietf.org>
Subject: = [paws] Several spectrum masks used by multi-bandwidth = radios

 

In IEEE 802.11af = discussions, we expect to use a modified 802.11ac PHY, with several = occupied bandwidths, for example 4 MHz, 8 MHz and 16 MHz, in several TV = bands (VHF and UHF).

 

We see the need to tell = the database several spectrum masks, each with:

        &= nbsp;       1 – Lowest applicable = frequency in MHz

        &= nbsp;       2 – Highest applicable = frequency in MHz

        &= nbsp;       3 – Maximum total EIRP = over the frequency range defined by the spectrum mask

        &= nbsp;       4 – General spectrum = mask in dBr from peak transmit power in EIRP, with specific power limit = at any frequency linearly interpolated between adjacent points of the = spectrum mask, expressed like IEEE 802.11p Annex I [h= ttp://standards.ieee.org/getieee802/download/802.11p-2010.pdf] or = FCC 47 C.F.R. 90.210(m).

        &= nbsp;       5- measurement resolution = bandwidth for EIRP measurements

 

   This detailed actual spectrum = occupancy information allows the database to perform more accurate = interference calculations.

 

petere

P= eter Ecclesine, Technology Analyst

M= S SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

P= h 408/527-0815, FAX 408/525-9256

&= quot;Time doesn't fool around."  "Without Prejudice" = U.C.C. 1-207

__________________________________= _____________ 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

------_=_NextPart_001_01CC8A8C.C59236BA-- From paul@marvell.com Fri Oct 14 10:46: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 A037621F8AC3 for ; Fri, 14 Oct 2011 10:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 mK3OmcrFdG-l for ; Fri, 14 Oct 2011 10:46:40 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 391AC21F8B0E for ; Fri, 14 Oct 2011 10:46:39 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP; Fri, 14 Oct 2011 10:46:39 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 14 Oct 2011 10:45:17 -0700 From: Paul Lambert To: Gerald Chouinard , Peter McCann , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" Date: Fri, 14 Oct 2011 10:45:15 -0700 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcyKg2IsK6++6Pl5QZahADrxhUfncAAFVfXw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9547@SC-VEXCH2.marvell.com> References: <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> In-Reply-To: <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] 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: Fri, 14 Oct 2011 17:46:41 -0000 I think we may be over designing. The union is interesting - but it limits= a device from using all available channels in any particular location. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Gerald Chouinard > Sent: Friday, October 14, 2011 8:09 AM > To: Peter McCann; Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; > scott.probasco@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] Possible new use case: simulcasting >=20 > Pete, >=20 > Agreed. A simple compression scheme could be proposed in the PAWS > protocol > and that is to query only only on a 'differential' basis, i.e., the > database would only send what has changed since the last query. This > could > also be applied to the query message from the base station, i.e., > sending > only the information that would have changed since the last query > (e.g., > new terminal, changed geoposition, etc.). >=20 > Gerald >=20 > At 14:50 14-10-11 +0000, Peter McCann wrote: > >Hi, Gerald, > > > >I think doing the intersection at the master device might be > >acceptable, as long as the "batch" location mode is supported. > >However, it might lead to a lot of redundant data being > >sent back from the WSDB if there are many channels free in > >all given locations. Perhaps some sort of compression could > >be defined so that the common channels are sent only once? > >That would be roughly equivalent to doing an intersection > >but you would also send the additional information about the > >channels that were free only in specific locations. This > >would allow the master device to do the kind of computations > >you outline below. > > > >-Pete > > > > > >Gerald Chouinard wrote: > > > Peter, > > > > > > In the 802.22 WRAN model, the process of intersection is done at > the > > > base station because the base station should be able to decide > whether > > > to accept association with a new user terminal or not, depending on > > > the extent this new terminal limits the number of available > channels. > > > This would not be possible if this is done at the database. > > > > > > The base station (or the master in more general terms) should > maintain > > > a local table of available channel sets (or maximum allowed EIRP > per > > > channel) to have all the information necessary to continuously > > > optimize its use of the RF spectrum. One can imagine a new terminal > > > that asks to be associated that may reduce the number of available > > > channels to only a few but, by disassociating another terminal in a > > > different location, the local network would regain even more > available > > > channels, as a result of the intersection process. The base > station > > > could then decide to stop its association with this second terminal > > > and associate the first terminal. This intelligence should not be > > > relegated to the database but should be kept local at the base > station. > > > > > > Whether the base station queries the database for each of its > > > associated terminals one at a time or in 'batch' mode for all its > > > terminals, the complete information should be obtained from the > > > database so that the process of 'intersection' can take place at > the > > > base station. > > > > > > Gerald > > > > > > > > > At 11:50 14-10-11 +0000, Peter McCann wrote: > > >> D.6 comes close, but also seems to allow returning the union set > of all > > >> channels available at the multiple locations. I want to make sure > the > > >> WSDB can do a set intersection of the available channels at each > of the > > >> listed locations. > > >> > > >> -Pete > > >> > > >> Gabor.Bajko@nokia.com wrote: > > >>> Pete, > > >>> > > >>> Would D.6/D.7 cover your requirement: > > >>> D.6: The Data Model MUST support specifying channel availability > > >>> information for multiple locations. > > >>> D.7: The Data Model MUST support specifying channel availability > > >>> information for an area around a specified location. > > >>> > > >>> -Gabor > > >>> > > >>> -----Original Message----- From: ext Peter McCann > > >>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011 > > >>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil > Basavaraj > > >>> (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott > > >>> (Nokia-CIC/Dallas) > > >>> Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: > > >>> simulcasting > > >>> > > >>> Hi, Gabor, > > >>> > > >>> I think the requirement could be expressed as a refinement of > what > > >>> you mean by "location" in requirement D.3: > > >>> > > >>> D.3: The Data Model MUST support specifying the location of the > > >>> subject and accuracy of location determination. Here, "location" > > >>> can be a single point or a set of points. > > >>> > > >>> -Pete > > >>> > > >>> Gabor.Bajko@nokia.com wrote: > > >>>> Pete, If your use case is covered by 4.3, but the requirements > may be > > >>>> different, please feel free to propose your protocol requirement > to > > >>>> the list. -Gabor > > >>>> > > >>>> -----Original Message----- > > >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > > >>>> Behalf Of ext Peter McCann > > >>>> Sent: Wednesday, September 14, 2011 10:30 AM > > >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; > > >>>> Probasco Scott (Nokia-CIC/Dallas) > > >>>> Cc: paws@ietf.org > > >>>> Subject: Re: [paws] Possible new use case: simulcasting > > >>>> > > >>>> Hi, Raj, > > >>>> > > >>>> I think my use case is covered by Section 4.3 with a small > change > > >>>> along the lines that Scott suggested. Note there is this text > in > > >>>> step 8: > > >>>> > > >>>> 8. The slave or user device scans the TV bands to locate a > > > WRAN > > >>>> transmission, and associates with the master/BS. The > > >>>> slave/user device provides its geolocation to the BS > which, in > > >>>> turn, queries the database for a list of channels > available at > > >>>> the slaves' geolocation. > > >>>> What I am suggesting is no different except for the fact that > > >>>> each of the devices could have independent Internet access and > be > > >>>> capable of querying the database itself. There could be one BS > > >>>> that handles all the queries or the individual BSs could query > > >>>> themselves (each for their own location) and they could compare > > >>>> notes to find a common free channel. > > >>>> > > >>>> As for the protocol between the BS and the WSDB, we may want to > have > > >>>> a requirement that the protocol carry multiple location elements > > >>>> (instead of just one) so that we save the cost of multiple > queries > > >>>> across the Internet. The WSDB, after doing the polygon > intersection > > >>>> test at each location, could additionally do a set intersection > test > > >>>> on the remaining free channels and return the results. That's > one > > >>>> concrete way that this use case may impact the protocol > specification. > > >>>> > > >>>> -Pete > > >>>> >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@crc.ca Fri Oct 14 12:51: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 8E26221F8D5C for ; Fri, 14 Oct 2011 12:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 kGVcu3ijLx5O for ; Fri, 14 Oct 2011 12:51:54 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 7AF1021F8D5B for ; Fri, 14 Oct 2011 12:51:54 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id B71F76B0459; Fri, 14 Oct 2011 15:51:50 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 984C06B0377; Fri, 14 Oct 2011 15:51:50 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 8B8786B03BF; Fri, 14 Oct 2011 15:51:50 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 159D16B03DD; Fri, 14 Oct 2011 15:51:48 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id 68F0C6B177E; Fri, 14 Oct 2011 15:51:47 -0400 (EDT) Message-Id: <5.1.0.14.2.20111014154259.01babe28@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Oct 2011 15:51:31 -0400 To: Paul Lambert ,Peter McCann , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" From: Gerald Chouinard In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9547@SC-VEXCH2.marve ll.com> References: <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <5.1.0.14.2.20111014110412.01b7bed0@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: Fri, 14 Oct 2011 19:51:55 -0000 Paul, Obviously, the 'union', as you call it, assumes that all the devices included form a network and need to operate on the same channel. If a device wants to operate on a different channel, it no longer belongs to the same wireless network and needs to query the database for itself, either directly or through another master device as 15.711(3)(e) of the MO&O allows. In such case, the process of intersection of the lists of available channels would not apply. Gerald At 10:45 14-10-11 -0700, Paul Lambert wrote: >I think we may be over designing. The union is interesting - but it >limits a device from using all available channels in any particular location. > >Paul > > >Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > > > > -----Original Message----- > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > > Gerald Chouinard > > Sent: Friday, October 14, 2011 8:09 AM > > To: Peter McCann; Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; > > scott.probasco@nokia.com > > Cc: paws@ietf.org > > Subject: Re: [paws] Possible new use case: simulcasting > > > > Pete, > > > > Agreed. A simple compression scheme could be proposed in the PAWS > > protocol > > and that is to query only only on a 'differential' basis, i.e., the > > database would only send what has changed since the last query. This > > could > > also be applied to the query message from the base station, i.e., > > sending > > only the information that would have changed since the last query > > (e.g., > > new terminal, changed geoposition, etc.). > > > > Gerald > > > > At 14:50 14-10-11 +0000, Peter McCann wrote: > > >Hi, Gerald, > > > > > >I think doing the intersection at the master device might be > > >acceptable, as long as the "batch" location mode is supported. > > >However, it might lead to a lot of redundant data being > > >sent back from the WSDB if there are many channels free in > > >all given locations. Perhaps some sort of compression could > > >be defined so that the common channels are sent only once? > > >That would be roughly equivalent to doing an intersection > > >but you would also send the additional information about the > > >channels that were free only in specific locations. This > > >would allow the master device to do the kind of computations > > >you outline below. > > > > > >-Pete > > > > > > > > >Gerald Chouinard wrote: > > > > Peter, > > > > > > > > In the 802.22 WRAN model, the process of intersection is done at > > the > > > > base station because the base station should be able to decide > > whether > > > > to accept association with a new user terminal or not, depending on > > > > the extent this new terminal limits the number of available > > channels. > > > > This would not be possible if this is done at the database. > > > > > > > > The base station (or the master in more general terms) should > > maintain > > > > a local table of available channel sets (or maximum allowed EIRP > > per > > > > channel) to have all the information necessary to continuously > > > > optimize its use of the RF spectrum. One can imagine a new terminal > > > > that asks to be associated that may reduce the number of available > > > > channels to only a few but, by disassociating another terminal in a > > > > different location, the local network would regain even more > > available > > > > channels, as a result of the intersection process. The base > > station > > > > could then decide to stop its association with this second terminal > > > > and associate the first terminal. This intelligence should not be > > > > relegated to the database but should be kept local at the base > > station. > > > > > > > > Whether the base station queries the database for each of its > > > > associated terminals one at a time or in 'batch' mode for all its > > > > terminals, the complete information should be obtained from the > > > > database so that the process of 'intersection' can take place at > > the > > > > base station. > > > > > > > > Gerald > > > > > > > > > > > > At 11:50 14-10-11 +0000, Peter McCann wrote: > > > >> D.6 comes close, but also seems to allow returning the union set > > of all > > > >> channels available at the multiple locations. I want to make sure > > the > > > >> WSDB can do a set intersection of the available channels at each > > of the > > > >> listed locations. > > > >> > > > >> -Pete > > > >> > > > >> Gabor.Bajko@nokia.com wrote: > > > >>> Pete, > > > >>> > > > >>> Would D.6/D.7 cover your requirement: > > > >>> D.6: The Data Model MUST support specifying channel availability > > > >>> information for multiple locations. > > > >>> D.7: The Data Model MUST support specifying channel availability > > > >>> information for an area around a specified location. > > > >>> > > > >>> -Gabor > > > >>> > > > >>> -----Original Message----- From: ext Peter McCann > > > >>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011 > > > >>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil > > Basavaraj > > > >>> (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott > > > >>> (Nokia-CIC/Dallas) > > > >>> Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: > > > >>> simulcasting > > > >>> > > > >>> Hi, Gabor, > > > >>> > > > >>> I think the requirement could be expressed as a refinement of > > what > > > >>> you mean by "location" in requirement D.3: > > > >>> > > > >>> D.3: The Data Model MUST support specifying the location of the > > > >>> subject and accuracy of location determination. Here, "location" > > > >>> can be a single point or a set of points. > > > >>> > > > >>> -Pete > > > >>> > > > >>> Gabor.Bajko@nokia.com wrote: > > > >>>> Pete, If your use case is covered by 4.3, but the requirements > > may be > > > >>>> different, please feel free to propose your protocol requirement > > to > > > >>>> the list. -Gabor > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > > > >>>> Behalf Of ext Peter McCann > > > >>>> Sent: Wednesday, September 14, 2011 10:30 AM > > > >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; > > > >>>> Probasco Scott (Nokia-CIC/Dallas) > > > >>>> Cc: paws@ietf.org > > > >>>> Subject: Re: [paws] Possible new use case: simulcasting > > > >>>> > > > >>>> Hi, Raj, > > > >>>> > > > >>>> I think my use case is covered by Section 4.3 with a small > > change > > > >>>> along the lines that Scott suggested. Note there is this text > > in > > > >>>> step 8: > > > >>>> > > > >>>> 8. The slave or user device scans the TV bands to locate a > > > > WRAN > > > >>>> transmission, and associates with the master/BS. The > > > >>>> slave/user device provides its geolocation to the BS > > which, in > > > >>>> turn, queries the database for a list of channels > > available at > > > >>>> the slaves' geolocation. > > > >>>> What I am suggesting is no different except for the fact that > > > >>>> each of the devices could have independent Internet access and > > be > > > >>>> capable of querying the database itself. There could be one BS > > > >>>> that handles all the queries or the individual BSs could query > > > >>>> themselves (each for their own location) and they could compare > > > >>>> notes to find a common free channel. > > > >>>> > > > >>>> As for the protocol between the BS and the WSDB, we may want to > > have > > > >>>> a requirement that the protocol carry multiple location elements > > > >>>> (instead of just one) so that we save the cost of multiple > > queries > > > >>>> across the Internet. The WSDB, after doing the polygon > > intersection > > > >>>> test at each location, could additionally do a set intersection > > test > > > >>>> on the remaining free channels and return the results. That's > > one > > > >>>> concrete way that this use case may impact the protocol > > specification. > > > >>>> > > > >>>> -Pete > > > >>>> > > > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Fri Oct 14 13:07: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 9E50A21F8876 for ; Fri, 14 Oct 2011 13:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 shulfNik06xN for ; Fri, 14 Oct 2011 13:07:29 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C421F8AF1 for ; Fri, 14 Oct 2011 13:07:22 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP; Fri, 14 Oct 2011 13:07:22 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 14 Oct 2011 13:01:16 -0700 From: Paul Lambert To: Gerald Chouinard , Peter McCann , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" Date: Fri, 14 Oct 2011 13:01:14 -0700 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcyKqrhbM8Yq8nVUQVeqRSrMGMyZNQAAHgPA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9593@SC-VEXCH2.marvell.com> References: <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014154259.01babe28@imap.crc.ca> In-Reply-To: <5.1.0.14.2.20111014154259.01babe28@imap.crc.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] 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: Fri, 14 Oct 2011 20:07:30 -0000 Masters in multiple locations might not all operate on the same channel. T= here is no need for them to all be in the same channel. They may all be co= nnected in a mesh or other type of typology. I feel it would be better to have simple set of queries/operations that can= be combined by clients into more complex operations than attempt to accomm= odate all possible complex processing that we can envision in a database. = =20 Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > -----Original Message----- > From: Gerald Chouinard [mailto:gerald.chouinard@crc.ca] > Sent: Friday, October 14, 2011 12:52 PM > To: Paul Lambert; Peter McCann; Gabor.Bajko@nokia.com; > Basavaraj.Patil@nokia.com; scott.probasco@nokia.com > Cc: paws@ietf.org > Subject: RE: [paws] Possible new use case: simulcasting >=20 > Paul, >=20 > Obviously, the 'union', as you call it, assumes that all the devices > included form a network and need to operate on the same channel. If a > device wants to operate on a different channel, it no longer belongs to > the > same wireless network and needs to query the database for itself, > either > directly or through another master device as 15.711(3)(e) of the MO&O > allows. In such case, the process of intersection of the lists of > available channels would not apply. >=20 > Gerald >=20 >=20 > At 10:45 14-10-11 -0700, Paul Lambert wrote: > >I think we may be over designing. The union is interesting - but it > >limits a device from using all available channels in any particular > location. > > > >Paul > > > > > >Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > > > > > > > -----Original Message----- > > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > Behalf Of > > > Gerald Chouinard > > > Sent: Friday, October 14, 2011 8:09 AM > > > To: Peter McCann; Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; > > > scott.probasco@nokia.com > > > Cc: paws@ietf.org > > > Subject: Re: [paws] Possible new use case: simulcasting > > > > > > Pete, > > > > > > Agreed. A simple compression scheme could be proposed in the PAWS > > > protocol > > > and that is to query only only on a 'differential' basis, i.e., the > > > database would only send what has changed since the last query. > This > > > could > > > also be applied to the query message from the base station, i.e., > > > sending > > > only the information that would have changed since the last query > > > (e.g., > > > new terminal, changed geoposition, etc.). > > > > > > Gerald > > > > > > At 14:50 14-10-11 +0000, Peter McCann wrote: > > > >Hi, Gerald, > > > > > > > >I think doing the intersection at the master device might be > > > >acceptable, as long as the "batch" location mode is supported. > > > >However, it might lead to a lot of redundant data being > > > >sent back from the WSDB if there are many channels free in > > > >all given locations. Perhaps some sort of compression could > > > >be defined so that the common channels are sent only once? > > > >That would be roughly equivalent to doing an intersection > > > >but you would also send the additional information about the > > > >channels that were free only in specific locations. This > > > >would allow the master device to do the kind of computations > > > >you outline below. > > > > > > > >-Pete > > > > > > > > > > > >Gerald Chouinard wrote: > > > > > Peter, > > > > > > > > > > In the 802.22 WRAN model, the process of intersection is done > at > > > the > > > > > base station because the base station should be able to decide > > > whether > > > > > to accept association with a new user terminal or not, > depending on > > > > > the extent this new terminal limits the number of available > > > channels. > > > > > This would not be possible if this is done at the database. > > > > > > > > > > The base station (or the master in more general terms) should > > > maintain > > > > > a local table of available channel sets (or maximum allowed > EIRP > > > per > > > > > channel) to have all the information necessary to continuously > > > > > optimize its use of the RF spectrum. One can imagine a new > terminal > > > > > that asks to be associated that may reduce the number of > available > > > > > channels to only a few but, by disassociating another terminal > in a > > > > > different location, the local network would regain even more > > > available > > > > > channels, as a result of the intersection process. The base > > > station > > > > > could then decide to stop its association with this second > terminal > > > > > and associate the first terminal. This intelligence should not > be > > > > > relegated to the database but should be kept local at the base > > > station. > > > > > > > > > > Whether the base station queries the database for each of its > > > > > associated terminals one at a time or in 'batch' mode for all > its > > > > > terminals, the complete information should be obtained from the > > > > > database so that the process of 'intersection' can take place > at > > > the > > > > > base station. > > > > > > > > > > Gerald > > > > > > > > > > > > > > > At 11:50 14-10-11 +0000, Peter McCann wrote: > > > > >> D.6 comes close, but also seems to allow returning the union > set > > > of all > > > > >> channels available at the multiple locations. I want to make > sure > > > the > > > > >> WSDB can do a set intersection of the available channels at > each > > > of the > > > > >> listed locations. > > > > >> > > > > >> -Pete > > > > >> > > > > >> Gabor.Bajko@nokia.com wrote: > > > > >>> Pete, > > > > >>> > > > > >>> Would D.6/D.7 cover your requirement: > > > > >>> D.6: The Data Model MUST support specifying channel > availability > > > > >>> information for multiple locations. > > > > >>> D.7: The Data Model MUST support specifying channel > availability > > > > >>> information for an area around a specified location. > > > > >>> > > > > >>> -Gabor > > > > >>> > > > > >>> -----Original Message----- From: ext Peter McCann > > > > >>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, > 2011 > > > > >>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil > > > Basavaraj > > > > >>> (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott > > > > >>> (Nokia-CIC/Dallas) > > > > >>> Cc: paws@ietf.org Subject: RE: [paws] Possible new use case: > > > > >>> simulcasting > > > > >>> > > > > >>> Hi, Gabor, > > > > >>> > > > > >>> I think the requirement could be expressed as a refinement of > > > what > > > > >>> you mean by "location" in requirement D.3: > > > > >>> > > > > >>> D.3: The Data Model MUST support specifying the location of > the > > > > >>> subject and accuracy of location determination. Here, > "location" > > > > >>> can be a single point or a set of points. > > > > >>> > > > > >>> -Pete > > > > >>> > > > > >>> Gabor.Bajko@nokia.com wrote: > > > > >>>> Pete, If your use case is covered by 4.3, but the > requirements > > > may be > > > > >>>> different, please feel free to propose your protocol > requirement > > > to > > > > >>>> the list. -Gabor > > > > >>>> > > > > >>>> -----Original Message----- > > > > >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > On > > > > >>>> Behalf Of ext Peter McCann > > > > >>>> Sent: Wednesday, September 14, 2011 10:30 AM > > > > >>>> To: Patil Basavaraj (Nokia-CIC/Dallas); > gerald.chouinard@crc.ca; > > > > >>>> Probasco Scott (Nokia-CIC/Dallas) > > > > >>>> Cc: paws@ietf.org > > > > >>>> Subject: Re: [paws] Possible new use case: simulcasting > > > > >>>> > > > > >>>> Hi, Raj, > > > > >>>> > > > > >>>> I think my use case is covered by Section 4.3 with a small > > > change > > > > >>>> along the lines that Scott suggested. Note there is this > text > > > in > > > > >>>> step 8: > > > > >>>> > > > > >>>> 8. The slave or user device scans the TV bands to locate > a > > > > > WRAN > > > > >>>> transmission, and associates with the master/BS. The > > > > >>>> slave/user device provides its geolocation to the BS > > > which, in > > > > >>>> turn, queries the database for a list of channels > > > available at > > > > >>>> the slaves' geolocation. > > > > >>>> What I am suggesting is no different except for the fact > that > > > > >>>> each of the devices could have independent Internet access > and > > > be > > > > >>>> capable of querying the database itself. There could be one > BS > > > > >>>> that handles all the queries or the individual BSs could > query > > > > >>>> themselves (each for their own location) and they could > compare > > > > >>>> notes to find a common free channel. > > > > >>>> > > > > >>>> As for the protocol between the BS and the WSDB, we may want > to > > > have > > > > >>>> a requirement that the protocol carry multiple location > elements > > > > >>>> (instead of just one) so that we save the cost of multiple > > > queries > > > > >>>> across the Internet. The WSDB, after doing the polygon > > > intersection > > > > >>>> test at each location, could additionally do a set > intersection > > > test > > > > >>>> on the remaining free channels and return the results. > That's > > > one > > > > >>>> concrete way that this use case may impact the protocol > > > specification. > > > > >>>> > > > > >>>> -Pete > > > > >>>> > > > > > > > > > > > > _______________________________________________ > > > paws mailing list > > > paws@ietf.org > > > https://www.ietf.org/mailman/listinfo/paws >=20 >=20 From Peter.McCann@huawei.com Fri Oct 14 13:50:00 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7BB21F8D2F for ; Fri, 14 Oct 2011 13:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 NSPaN5ZM0T2S for ; Fri, 14 Oct 2011 13:49:59 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9D821F8D29 for ; Fri, 14 Oct 2011 13:49:59 -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 <0LT200JZZPV9K2@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 15:49:58 -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 <0LT2001KSPV96P@usaga02-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 15:49:57 -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; Fri, 14 Oct 2011 13:49:59 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 13:49:50 -0700 Date: Fri, 14 Oct 2011 20:49:49 +0000 From: Peter McCann In-reply-to: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9593@SC-VEXCH2.marvell.com> X-Originating-IP: [10.212.245.94] To: Paul Lambert , Gerald Chouinard , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716401C2A@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+2liyoyRWRkAAAHgPABh2IlFA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014154259.01babe28@imap.crc.ca> <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9593@SC-VEXCH2.marvell.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: Fri, 14 Oct 2011 20:50:00 -0000 I think all that is being suggested is the ability to "batch" several simple requests into one message, such as when the master knows the locations of several other nodes (they could be slaves or other masters) and the database then independently processes each query. It is only for efficiency that the responses could be processed together to remove redundancy. Think of it as a compression algorithm that runs on the list of XML responses being returned. -Pete Paul Lambert wrote: > Masters in multiple locations might not all operate on the same > channel. There is no need for them to all be in the same channel. > They may all be connected in a mesh or other type of typology. > > I feel it would be better to have simple set of queries/operations > that can be combined by clients into more complex operations than > attempt to accommodate all possible complex processing that we can > envision in a database. > > Paul > > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > > >> -----Original Message----- >> From: Gerald Chouinard [mailto:gerald.chouinard@crc.ca] >> Sent: Friday, October 14, 2011 12:52 PM >> To: Paul Lambert; Peter McCann; Gabor.Bajko@nokia.com; >> Basavaraj.Patil@nokia.com; scott.probasco@nokia.com >> Cc: paws@ietf.org >> Subject: RE: [paws] Possible new use case: simulcasting >> >> Paul, >> >> Obviously, the 'union', as you call it, assumes that all the devices >> included form a network and need to operate on the same channel. If >> a device wants to operate on a different channel, it no longer >> belongs to the same wireless network and needs to query the database >> for itself, either directly or through another master device as >> 15.711(3)(e) of the MO&O allows. In such case, the process of >> intersection of the lists of available channels would not apply. >> >> Gerald >> >> >> At 10:45 14-10-11 -0700, Paul Lambert wrote: >>> I think we may be over designing. The union is interesting - but it >>> limits a device from using all available channels in any particular >>> location. >>> >>> Paul >>> >>> >>> Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 >>> >>> >>>> -----Original Message----- From: paws-bounces@ietf.org >>>> [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard Sent: >>>> Friday, October 14, 2011 8:09 AM To: Peter McCann; >>>> Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; >>>> scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] >>>> Possible new use case: simulcasting >>>> >>>> Pete, >>>> >>>> Agreed. A simple compression scheme could be proposed in the PAWS >>>> protocol and that is to query only only on a 'differential' basis, >>>> i.e., the database would only send what has changed since the last >>>> query. This could also be applied to the query message from the base >>>> station, i.e., sending only the information that would have changed >>>> since the last query (e.g., new terminal, changed geoposition, etc.). >>>> >>>> Gerald >>>> >>>> At 14:50 14-10-11 +0000, Peter McCann wrote: >>>>> Hi, Gerald, >>>>> >>>>> I think doing the intersection at the master device might be >>>>> acceptable, as long as the "batch" location mode is supported. >>>>> However, it might lead to a lot of redundant data being sent back >>>>> from the WSDB if there are many channels free in all given >>>>> locations. Perhaps some sort of compression could be defined so >>>>> that the common channels are sent only once? That would be roughly >>>>> equivalent to doing an intersection but you would also send the >>>>> additional information about the channels that were free only in >>>>> specific locations. This would allow the master device to do the >>>>> kind of computations you outline below. >>>>> >>>>> -Pete >>>>> >>>>> >>>>> Gerald Chouinard wrote: >>>>>> Peter, >>>>>> >>>>>> In the 802.22 WRAN model, the process of intersection is >>>>>> done >> at >>>> the >>>>>> base station because the base station should be able to > decide >>>> whether >>>>>> to accept association with a new user terminal or not, depending on >>>>>> the extent this new terminal limits the number of available >>>>>> channels. This would not be possible if this is done at the >>>>>> database. >>>>>> >>>>>> The base station (or the master in more general terms) should >>>>>> maintain a local table of available channel sets (or maximum allowed >> EIRP >>>> per >>>>>> channel) to have all the information necessary to continuously >>>>>> optimize its use of the RF spectrum. One can imagine a new terminal >>>>>> that asks to be associated that may reduce the number of available >>>>>> channels to only a few but, by disassociating another > terminal >> in a >>>>>> different location, the local network would regain even more >>>>>> available channels, as a result of the intersection process. The >>>>>> base station could then decide to stop its association with this >>>>>> second terminal and associate the first terminal. This >>>>>> intelligence should not be relegated to the database but should be >>>>>> kept local at the > base >>>> station. >>>>>> >>>>>> Whether the base station queries the database for each of its >>>>>> associated terminals one at a time or in 'batch' mode for all its >>>>>> terminals, the complete information should be obtained from the >>>>>> database so that the process of 'intersection' can take place >> at >>>> the >>>>>> base station. >>>>>> >>>>>> Gerald >>>>>> >>>>>> >>>>>> At 11:50 14-10-11 +0000, Peter McCann wrote: >>>>>>> D.6 comes close, but also seems to allow returning the >>>>>>> union >> set >>>> of all >>>>>>> channels available at the multiple locations. I want to > make >> sure >>>> the >>>>>>> WSDB can do a set intersection of the available channels at >> each >>>> of the >>>>>>> listed locations. >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> Gabor.Bajko@nokia.com wrote: >>>>>>>> Pete, >>>>>>>> >>>>>>>> Would D.6/D.7 cover your requirement: D.6: The Data Model MUST >>>>>>>> support specifying channel availability information for multiple >>>>>>>> locations. D.7: The Data Model MUST support specifying channel >>>>>>>> availability information for an area around a specified location. >>>>>>>> >>>>>>>> -Gabor >>>>>>>> >>>>>>>> -----Original Message----- From: ext Peter McCann >>>>>>>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October > 13, >> 2011 >>>>>>>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil >>>>>>>> Basavaraj (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco >>>>>>>> Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: RE: [paws] >>>>>>>> Possible new use case: simulcasting >>>>>>>> >>>>>>>> Hi, Gabor, >>>>>>>> >>>>>>>> I think the requirement could be expressed as a refinement of >>>>>>>> what you mean by "location" in requirement D.3: >>>>>>>> >>>>>>>> D.3: The Data Model MUST support specifying the location of the >>>>>>>> subject and accuracy of location determination. Here, "location" >>>>>>>> can be a single point or a set of points. >>>>>>>> >>>>>>>> -Pete >>>>>>>> >>>>>>>> Gabor.Bajko@nokia.com wrote: >>>>>>>>> Pete, If your use case is covered by 4.3, but the >> requirements >>>> may be >>>>>>>>> different, please feel free to propose your protocol >> requirement >>>> to >>>>>>>>> the list. -Gabor >>>>>>>>> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter McCann >>>>>>>>> Sent: Wednesday, September 14, 2011 10:30 AM To: Patil Basavaraj >>>>>>>>> (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott >>>>>>>>> (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: Re: [paws] >>>>>>>>> Possible new use case: simulcasting >>>>>>>>> >>>>>>>>> Hi, Raj, >>>>>>>>> >>>>>>>>> I think my use case is covered by Section 4.3 with a small >>>>>>>>> change along the lines that Scott suggested. Note there is this >> text >>>> in >>>>>>>>> step 8: >>>>>>>>> >>>>>>>>> 8. The slave or user device scans the TV bands to >>>>>>>>> locate >> a >>>>>> WRAN >>>>>>>>> transmission, and associates with the master/BS. The >>>>>>>>> slave/user device provides its geolocation to the > BS >>>> which, in >>>>>>>>> turn, queries the database for a list of channels >>>>>>>>> available at the slaves' geolocation. >>>>>>>>> What I am suggesting is no different except for the fact that >>>>>>>>> each of the devices could have independent Internet access >> and >>>> be >>>>>>>>> capable of querying the database itself. There could be one BS >>>>>>>>> that handles all the queries or the individual BSs could query >>>>>>>>> themselves (each for their own location) and they could compare >>>>>>>>> notes to find a common free channel. >>>>>>>>> >>>>>>>>> As for the protocol between the BS and the WSDB, we may >>>>>>>>> want >> to >>>> have >>>>>>>>> a requirement that the protocol carry multiple location elements >>>>>>>>> (instead of just one) so that we save the cost of multiple >>>>>>>>> queries across the Internet. The WSDB, after doing the polygon >>>>>>>>> intersection test at each location, could additionally do a set >> intersection >>>> test >>>>>>>>> on the remaining free channels and return the results. >> That's >>>> one >>>>>>>>> concrete way that this use case may impact the protocol >>>>>>>>> specification. >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> From Basavaraj.Patil@nokia.com Fri Oct 14 13:55: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 EDB3E21F8D5F for ; Fri, 14 Oct 2011 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 s6ZIZG2sYdKR for ; Fri, 14 Oct 2011 13:55:36 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D383921F8D60 for ; Fri, 14 Oct 2011 13:55:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9EKtJw4029235; Fri, 14 Oct 2011 23:55:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 23:55:21 +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, 14 Oct 2011 22:54:23 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.208]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 22:54:22 +0200 From: To: , , , , Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAaEvSAAA7b8uD//7S8AIAAa/KAgAAB7wD//67PgIAAVdYA/9OMKTCAWki/AP//1TGQAC2F8iAAAT/k5wAJ2rppAAPejwAABgq/gAAWZyyA Date: Fri, 14 Oct 2011 20:54:21 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716401C2A@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.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2011 20:55:21.0057 (UTC) FILETIME=[96327510:01CC8AB3] 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: Fri, 14 Oct 2011 20:55:37 -0000 Pete, How would it be different from a query by a mobile master device which requests channel availability information at a set of locations that it may potentially be moving across rather than just its current location? -Raj On 10/14/11 3:49 PM, "ext Peter McCann" wrote: >I think all that is being suggested is the ability to "batch" several >simple requests into one message, such as when the master knows the >locations >of several other nodes (they could be slaves or other masters) and the >database then independently processes each query. It is only for >efficiency >that the responses could be processed together to remove redundancy. >Think >of it as a compression algorithm that runs on the list of XML responses >being >returned. > >-Pete > >Paul Lambert wrote: >> Masters in multiple locations might not all operate on the same >> channel. There is no need for them to all be in the same channel. >> They may all be connected in a mesh or other type of typology. >>=20 >> I feel it would be better to have simple set of queries/operations >> that can be combined by clients into more complex operations than >> attempt to accommodate all possible complex processing that we can >> envision in a database. >>=20 >> Paul >>=20 >> Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 >>=20 >>=20 >>> -----Original Message----- >>> From: Gerald Chouinard [mailto:gerald.chouinard@crc.ca] >>> Sent: Friday, October 14, 2011 12:52 PM >>> To: Paul Lambert; Peter McCann; Gabor.Bajko@nokia.com; >>> Basavaraj.Patil@nokia.com; scott.probasco@nokia.com >>> Cc: paws@ietf.org >>> Subject: RE: [paws] Possible new use case: simulcasting >>>=20 >>> Paul, >>>=20 >>> Obviously, the 'union', as you call it, assumes that all the devices >>> included form a network and need to operate on the same channel. If >>> a device wants to operate on a different channel, it no longer >>> belongs to the same wireless network and needs to query the database >>> for itself, either directly or through another master device as >>> 15.711(3)(e) of the MO&O allows. In such case, the process of >>> intersection of the lists of available channels would not apply. >>>=20 >>> Gerald >>>=20 >>>=20 >>> At 10:45 14-10-11 -0700, Paul Lambert wrote: >>>> I think we may be over designing. The union is interesting - but it >>>> limits a device from using all available channels in any particular >>>> location. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>> Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 >>>>=20 >>>>=20 >>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard Sent: >>>>> Friday, October 14, 2011 8:09 AM To: Peter McCann; >>>>> Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; >>>>> scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] >>>>> Possible new use case: simulcasting >>>>>=20 >>>>> Pete, >>>>>=20 >>>>> Agreed. A simple compression scheme could be proposed in the PAWS >>>>> protocol and that is to query only only on a 'differential' basis, >>>>> i.e., the database would only send what has changed since the last >>>>> query. This could also be applied to the query message from the base >>>>> station, i.e., sending only the information that would have changed >>>>> since the last query (e.g., new terminal, changed geoposition, etc.). >>>>>=20 >>>>> Gerald >>>>>=20 >>>>> At 14:50 14-10-11 +0000, Peter McCann wrote: >>>>>> Hi, Gerald, >>>>>>=20 >>>>>> I think doing the intersection at the master device might be >>>>>> acceptable, as long as the "batch" location mode is supported. >>>>>> However, it might lead to a lot of redundant data being sent back >>>>>> from the WSDB if there are many channels free in all given >>>>>> locations. Perhaps some sort of compression could be defined so >>>>>> that the common channels are sent only once? That would be roughly >>>>>> equivalent to doing an intersection but you would also send the >>>>>> additional information about the channels that were free only in >>>>>> specific locations. This would allow the master device to do the >>>>>> kind of computations you outline below. >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>>=20 >>>>>> Gerald Chouinard wrote: >>>>>>> Peter, >>>>>>>=20 >>>>>>> In the 802.22 WRAN model, the process of intersection is >>>>>>> done >>> at >>>>> the >>>>>>> base station because the base station should be able to >> decide >>>>> whether >>>>>>> to accept association with a new user terminal or not, depending on >>>>>>> the extent this new terminal limits the number of available >>>>>>> channels. This would not be possible if this is done at the >>>>>>> database. >>>>>>>=20 >>>>>>> The base station (or the master in more general terms) should >>>>>>> maintain a local table of available channel sets (or maximum >>>>>>>allowed >>> EIRP >>>>> per >>>>>>> channel) to have all the information necessary to continuously >>>>>>> optimize its use of the RF spectrum. One can imagine a new terminal >>>>>>> that asks to be associated that may reduce the number of available >>>>>>> channels to only a few but, by disassociating another >> terminal >>> in a >>>>>>> different location, the local network would regain even more >>>>>>> available channels, as a result of the intersection process. The >>>>>>> base station could then decide to stop its association with this >>>>>>> second terminal and associate the first terminal. This >>>>>>> intelligence should not be relegated to the database but should be >>>>>>> kept local at the >> base >>>>> station. >>>>>>>=20 >>>>>>> Whether the base station queries the database for each of its >>>>>>> associated terminals one at a time or in 'batch' mode for all its >>>>>>> terminals, the complete information should be obtained from the >>>>>>> database so that the process of 'intersection' can take place >>> at >>>>> the >>>>>>> base station. >>>>>>>=20 >>>>>>> Gerald >>>>>>>=20 >>>>>>>=20 >>>>>>> At 11:50 14-10-11 +0000, Peter McCann wrote: >>>>>>>> D.6 comes close, but also seems to allow returning the >>>>>>>> union >>> set >>>>> of all >>>>>>>> channels available at the multiple locations. I want to >> make >>> sure >>>>> the >>>>>>>> WSDB can do a set intersection of the available channels at >>> each >>>>> of the >>>>>>>> listed locations. >>>>>>>>=20 >>>>>>>> -Pete >>>>>>>>=20 >>>>>>>> Gabor.Bajko@nokia.com wrote: >>>>>>>>> Pete, >>>>>>>>>=20 >>>>>>>>> Would D.6/D.7 cover your requirement: D.6: The Data Model MUST >>>>>>>>> support specifying channel availability information for multiple >>>>>>>>> locations. D.7: The Data Model MUST support specifying channel >>>>>>>>> availability information for an area around a specified location. >>>>>>>>>=20 >>>>>>>>> -Gabor >>>>>>>>>=20 >>>>>>>>> -----Original Message----- From: ext Peter McCann >>>>>>>>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October >> 13, >>> 2011 >>>>>>>>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil >>>>>>>>> Basavaraj (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Probasco >>>>>>>>> Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: RE: [paws] >>>>>>>>> Possible new use case: simulcasting >>>>>>>>>=20 >>>>>>>>> Hi, Gabor, >>>>>>>>>=20 >>>>>>>>> I think the requirement could be expressed as a refinement of >>>>>>>>> what you mean by "location" in requirement D.3: >>>>>>>>>=20 >>>>>>>>> D.3: The Data Model MUST support specifying the location of the >>>>>>>>> subject and accuracy of location determination. Here, "location" >>>>>>>>> can be a single point or a set of points. >>>>>>>>>=20 >>>>>>>>> -Pete >>>>>>>>>=20 >>>>>>>>> Gabor.Bajko@nokia.com wrote: >>>>>>>>>> Pete, If your use case is covered by 4.3, but the >>> requirements >>>>> may be >>>>>>>>>> different, please feel free to propose your protocol >>> requirement >>>>> to >>>>>>>>>> the list. -Gabor >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter McCann >>>>>>>>>> Sent: Wednesday, September 14, 2011 10:30 AM To: Patil Basavaraj >>>>>>>>>> (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott >>>>>>>>>> (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: Re: [paws] >>>>>>>>>> Possible new use case: simulcasting >>>>>>>>>>=20 >>>>>>>>>> Hi, Raj, >>>>>>>>>>=20 >>>>>>>>>> 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: >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> -Pete >>>>>>>>>>=20 > From Peter.McCann@huawei.com Fri Oct 14 13:58: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 885B921F8CDF for ; Fri, 14 Oct 2011 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 xqrOoJ9mcBfV for ; Fri, 14 Oct 2011 13:58: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 1C56F21F8CCA for ; Fri, 14 Oct 2011 13:58: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 <0LT200KO6Q9E8Q@usaga04-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 15:58:26 -0500 (CDT) Received: from dfweml201-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 <0LT200G4RQ9DHK@usaga04-in.huawei.com> for paws@ietf.org; Fri, 14 Oct 2011 15:58:26 -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; Fri, 14 Oct 2011 13:58:17 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 13:58:14 -0700 Date: Fri, 14 Oct 2011 20:58:13 +0000 From: Peter McCann In-reply-to: X-Originating-IP: [10.212.245.94] To: "Basavaraj.Patil@nokia.com" , "paul@marvell.com" , "gerald.chouinard@crc.ca" , "Gabor.Bajko@nokia.com" , "scott.probasco@nokia.com" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716401C50@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+2liyoyRWRkAAAHgPABh2IlFAADuyQgAAOkchA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5963DDF1F751474D8DEEFDCDBEE43AE716401C2A@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: Fri, 14 Oct 2011 20:58:39 -0000 Right, I don't think the protocol needs to care why the multiple locations are being given. Hopefully the protocol will satisfy the simulcasting and mobility scenarios with the same mechanisms. -Pete Basavaraj.Patil@nokia.com wrote: > > Pete, > > How would it be different from a query by a mobile master device which > requests channel availability information at a set of locations that > it may potentially be moving across rather than just its current location? > > -Raj > > On 10/14/11 3:49 PM, "ext Peter McCann" wrote: > >> I think all that is being suggested is the ability to "batch" several >> simple requests into one message, such as when the master knows the >> locations of several other nodes (they could be slaves or other >> masters) and the database then independently processes each query. It >> is only for efficiency that the responses could be processed together >> to remove redundancy. Think of it as a compression algorithm that runs >> on the list of XML responses being returned. >> >> -Pete >> >> Paul Lambert wrote: >>> Masters in multiple locations might not all operate on the same >>> channel. There is no need for them to all be in the same channel. >>> They may all be connected in a mesh or other type of typology. >>> >>> I feel it would be better to have simple set of queries/operations >>> that can be combined by clients into more complex operations than >>> attempt to accommodate all possible complex processing that we can >>> envision in a database. >>> >>> Paul >>> >>> Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 >>> >>> >>>> -----Original Message----- >>>> From: Gerald Chouinard [mailto:gerald.chouinard@crc.ca] >>>> Sent: Friday, October 14, 2011 12:52 PM >>>> To: Paul Lambert; Peter McCann; Gabor.Bajko@nokia.com; >>>> Basavaraj.Patil@nokia.com; scott.probasco@nokia.com >>>> Cc: paws@ietf.org >>>> Subject: RE: [paws] Possible new use case: simulcasting >>>> >>>> Paul, >>>> >>>> Obviously, the 'union', as you call it, assumes that all the devices >>>> included form a network and need to operate on the same channel. If a >>>> device wants to operate on a different channel, it no longer belongs >>>> to the same wireless network and needs to query the database for >>>> itself, either directly or through another master device as >>>> 15.711(3)(e) of the MO&O allows. In such case, the process of >>>> intersection of the lists of available channels would not apply. >>>> >>>> Gerald >>>> >>>> >>>> At 10:45 14-10-11 -0700, Paul Lambert wrote: >>>>> I think we may be over designing. The union is interesting - but >>>>> it limits a device from using all available channels in any >>>>> particular location. >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 >>>>> >>>>> >>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard Sent: >>>>>> Friday, October 14, 2011 8:09 AM To: Peter McCann; >>>>>> Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; >>>>>> scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] >>>>>> Possible new use case: simulcasting >>>>>> >>>>>> Pete, >>>>>> >>>>>> Agreed. A simple compression scheme could be proposed in the PAWS >>>>>> protocol and that is to query only only on a 'differential' basis, >>>>>> i.e., the database would only send what has changed since the last >>>>>> query. This could also be applied to the query message from the >>>>>> base station, i.e., sending only the information that would have >>>>>> changed since the last query (e.g., new terminal, changed >>>>>> geoposition, etc.). >>>>>> >>>>>> Gerald >>>>>> >>>>>> At 14:50 14-10-11 +0000, Peter McCann wrote: >>>>>>> Hi, Gerald, >>>>>>> >>>>>>> I think doing the intersection at the master device might be >>>>>>> acceptable, as long as the "batch" location mode is supported. >>>>>>> However, it might lead to a lot of redundant data being sent back >>>>>>> from the WSDB if there are many channels free in all given >>>>>>> locations. Perhaps some sort of compression could be defined so >>>>>>> that the common channels are sent only once? That would be roughly >>>>>>> equivalent to doing an intersection but you would also send the >>>>>>> additional information about the channels that were free only in >>>>>>> specific locations. This would allow the master device to do the >>>>>>> kind of computations you outline below. >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> >>>>>>> Gerald Chouinard wrote: >>>>>>>> Peter, >>>>>>>> >>>>>>>> In the 802.22 WRAN model, the process of intersection is done >>>> at >>>>>> the >>>>>>>> base station because the base station should be able to >>> decide >>>>>> whether >>>>>>>> to accept association with a new user terminal or not, depending >>>>>>>> on the extent this new terminal limits the number of available >>>>>>>> channels. This would not be possible if this is done at the >>>>>>>> database. >>>>>>>> >>>>>>>> The base station (or the master in more general terms) should >>>>>>>> maintain a local table of available channel sets (or maximum >>>>>>>> allowed >>>> EIRP >>>>>> per >>>>>>>> channel) to have all the information necessary to continuously >>>>>>>> optimize its use of the RF spectrum. One can imagine a new >>>>>>>> terminal that asks to be associated that may reduce the number >>>>>>>> of available channels to only a few but, by disassociating >>>>>>>> another >>> terminal >>>> in a >>>>>>>> different location, the local network would regain even more >>>>>>>> available channels, as a result of the intersection process. >>>>>>>> The base station could then decide to stop its association >>>>>>>> with this second terminal and associate the first terminal. >>>>>>>> This intelligence should not be relegated to the database but >>>>>>>> should be kept local at the >>> base >>>>>> station. >>>>>>>> >>>>>>>> Whether the base station queries the database for each of its >>>>>>>> associated terminals one at a time or in 'batch' mode for all >>>>>>>> its terminals, the complete information should be obtained >>>>>>>> from the database so that the process of 'intersection' can >>>>>>>> take place >>>> at >>>>>> the >>>>>>>> base station. >>>>>>>> >>>>>>>> Gerald >>>>>>>> >>>>>>>> >>>>>>>> At 11:50 14-10-11 +0000, Peter McCann wrote: >>>>>>>>> D.6 comes close, but also seems to allow returning the union >>>> set >>>>>> of all >>>>>>>>> channels available at the multiple locations. I want to >>> make >>>> sure >>>>>> the >>>>>>>>> WSDB can do a set intersection of the available channels at >>>> each >>>>>> of the >>>>>>>>> listed locations. >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>> Gabor.Bajko@nokia.com wrote: >>>>>>>>>> Pete, >>>>>>>>>> >>>>>>>>>> Would D.6/D.7 cover your requirement: D.6: The Data Model MUST >>>>>>>>>> support specifying channel availability information for >>>>>>>>>> multiple locations. D.7: The Data Model MUST support specifying >>>>>>>>>> channel availability information for an area around a specified >>>>>>>>>> location. >>>>>>>>>> >>>>>>>>>> -Gabor >>>>>>>>>> >>>>>>>>>> -----Original Message----- From: ext Peter McCann >>>>>>>>>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October >>> 13, >>>> 2011 >>>>>>>>>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil >>>>>>>>>> Basavaraj (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; >>>>>>>>>> Probasco Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: >>>>>>>>>> RE: [paws] Possible new use case: simulcasting >>>>>>>>>> >>>>>>>>>> Hi, Gabor, >>>>>>>>>> >>>>>>>>>> I think the requirement could be expressed as a refinement >>>>>>>>>> of what you mean by "location" in requirement D.3: >>>>>>>>>> >>>>>>>>>> D.3: The Data Model MUST support specifying the location of the >>>>>>>>>> subject and accuracy of location determination. Here, >>>>>>>>>> "location" can be a single point or a set of points. >>>>>>>>>> >>>>>>>>>> -Pete >>>>>>>>>> >>>>>>>>>> Gabor.Bajko@nokia.com wrote: >>>>>>>>>>> Pete, If your use case is covered by 4.3, but the >>>> requirements >>>>>> may be >>>>>>>>>>> different, please feel free to propose your protocol >>>> requirement >>>>>> to >>>>>>>>>>> the list. -Gabor >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter >>>>>>>>>>> McCann >>>>>>>>>>> Sent: Wednesday, September 14, 2011 10:30 AM To: Patil >>>>>>>>>>> Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; >>>>>>>>>>> Probasco Scott >>>>>>>>>>> (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: Re: [paws] >>>>>>>>>>> Possible new use case: simulcasting >>>>>>>>>>> >>>>>>>>>>> Hi, Raj, >>>>>>>>>>> >>>>>>>>>>> I think my use case is covered by Section 4.3 with a small >>>>>>>>>>> change along the lines that Scott suggested. Note there is >>>>>>>>>>> this >>>> text >>>>>> in >>>>>>>>>>> step 8: >>>>>>>>>>> >>>>>>>>>>> 8. The slave or user device scans the TV bands to >>>>>>>>>>> locate >>>> a >>>>>>>> WRAN >>>>>>>>>>> transmission, and associates with the master/BS. The >>>>>>>>>>> slave/user device provides its geolocation to the >>> BS >>>>>> which, in >>>>>>>>>>> turn, queries the database for a list of channels >>>>>>>>>>> available at the slaves' geolocation. >>>>>>>>>>> What I am suggesting is no different except for the fact that >>>>>>>>>>> each of the devices could have independent Internet access >>>> and >>>>>> be >>>>>>>>>>> capable of querying the database itself. There could be one >>>>>>>>>>> BS that handles all the queries or the individual BSs could >>>>>>>>>>> query themselves (each for their own location) and they could >>>>>>>>>>> compare notes to find a common free channel. >>>>>>>>>>> >>>>>>>>>>> As for the protocol between the BS and the WSDB, we may >>>>>>>>>>> want >>>> to >>>>>> have >>>>>>>>>>> a requirement that the protocol carry multiple location >>>>>>>>>>> elements (instead of just one) so that we save the cost of >>>>>>>>>>> multiple queries across the Internet. The WSDB, after doing >>>>>>>>>>> the polygon intersection test at each location, could >>>>>>>>>>> additionally do a > set >>>> intersection >>>>>> test >>>>>>>>>>> on the remaining free channels and return the results. >>>> That's >>>>>> one >>>>>>>>>>> concrete way that this use case may impact the protocol >>>>>>>>>>> specification. >>>>>>>>>>> >>>>>>>>>>> -Pete >>>>>>>>>>> >> From paul@marvell.com Fri Oct 14 14:14: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 0053A21F8B04 for ; Fri, 14 Oct 2011 14:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 V8La3GGq8wQo for ; Fri, 14 Oct 2011 14:14:07 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE4421F8C13 for ; Fri, 14 Oct 2011 14:14:06 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP; Fri, 14 Oct 2011 14:14:06 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 14 Oct 2011 14:12:32 -0700 From: Paul Lambert To: Peter McCann , Gerald Chouinard , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" Date: Fri, 14 Oct 2011 14:12:32 -0700 Thread-Topic: [paws] Possible new use case: simulcasting Thread-Index: AcxyO9Iolyb5o88QQp+2liyoyRWRkAAAHgPABh2IlFAAAI0ogA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD95C8@SC-VEXCH2.marvell.com> References: <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <5.1.0.14.2.20111014154259.01babe28@imap.crc.ca> <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9593@SC-VEXCH2.marvell.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401C2A@dfweml503-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716401C2A@dfweml503-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] 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: Fri, 14 Oct 2011 21:14:08 -0000 It may not be processing efficient for a server to combine the results of m= ultiple queries. Queries should be considered atomic and the answers shoul= d be associated with a particular query. =20 Looking up channels for a simple region is a much different processing than= combining multiple results that may have other constraints (like different= validity times). Multiple queries could also be for different spectral masks or operating mo= des. Sometimes they could be combined and sometimes not. Now ... I'm not a fan of overly complex geo shapes ... but what you're aski= ng for sounds more like a request for polygon or line based regions (e.g. N= Y to Boston). Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > -----Original Message----- > From: Peter McCann [mailto:Peter.McCann@huawei.com] > Sent: Friday, October 14, 2011 1:50 PM > To: Paul Lambert; Gerald Chouinard; Gabor.Bajko@nokia.com; > Basavaraj.Patil@nokia.com; scott.probasco@nokia.com > Cc: paws@ietf.org > Subject: RE: [paws] Possible new use case: simulcasting >=20 > I think all that is being suggested is the ability to "batch" several > simple requests into one message, such as when the master knows the > locations > of several other nodes (they could be slaves or other masters) and the > database then independently processes each query. It is only for > efficiency > that the responses could be processed together to remove redundancy. > Think > of it as a compression algorithm that runs on the list of XML responses > being > returned. >=20 > -Pete >=20 > Paul Lambert wrote: > > Masters in multiple locations might not all operate on the same > > channel. There is no need for them to all be in the same channel. > > They may all be connected in a mesh or other type of typology. > > > > I feel it would be better to have simple set of queries/operations > > that can be combined by clients into more complex operations than > > attempt to accommodate all possible complex processing that we can > > envision in a database. > > > > Paul > > > > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > > > > > >> -----Original Message----- > >> From: Gerald Chouinard [mailto:gerald.chouinard@crc.ca] > >> Sent: Friday, October 14, 2011 12:52 PM > >> To: Paul Lambert; Peter McCann; Gabor.Bajko@nokia.com; > >> Basavaraj.Patil@nokia.com; scott.probasco@nokia.com > >> Cc: paws@ietf.org > >> Subject: RE: [paws] Possible new use case: simulcasting > >> > >> Paul, > >> > >> Obviously, the 'union', as you call it, assumes that all the devices > >> included form a network and need to operate on the same channel. If > >> a device wants to operate on a different channel, it no longer > >> belongs to the same wireless network and needs to query the database > >> for itself, either directly or through another master device as > >> 15.711(3)(e) of the MO&O allows. In such case, the process of > >> intersection of the lists of available channels would not apply. > >> > >> Gerald > >> > >> > >> At 10:45 14-10-11 -0700, Paul Lambert wrote: > >>> I think we may be over designing. The union is interesting - but > it > >>> limits a device from using all available channels in any particular > >>> location. > >>> > >>> Paul > >>> > >>> > >>> Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > >>> > >>> > >>>> -----Original Message----- From: paws-bounces@ietf.org > >>>> [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard Sent: > >>>> Friday, October 14, 2011 8:09 AM To: Peter McCann; > >>>> Gabor.Bajko@nokia.com; Basavaraj.Patil@nokia.com; > >>>> scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] > >>>> Possible new use case: simulcasting > >>>> > >>>> Pete, > >>>> > >>>> Agreed. A simple compression scheme could be proposed in the PAWS > >>>> protocol and that is to query only only on a 'differential' basis, > >>>> i.e., the database would only send what has changed since the last > >>>> query. This could also be applied to the query message from the > base > >>>> station, i.e., sending only the information that would have > changed > >>>> since the last query (e.g., new terminal, changed geoposition, > etc.). > >>>> > >>>> Gerald > >>>> > >>>> At 14:50 14-10-11 +0000, Peter McCann wrote: > >>>>> Hi, Gerald, > >>>>> > >>>>> I think doing the intersection at the master device might be > >>>>> acceptable, as long as the "batch" location mode is supported. > >>>>> However, it might lead to a lot of redundant data being sent back > >>>>> from the WSDB if there are many channels free in all given > >>>>> locations. Perhaps some sort of compression could be defined so > >>>>> that the common channels are sent only once? That would be > roughly > >>>>> equivalent to doing an intersection but you would also send the > >>>>> additional information about the channels that were free only in > >>>>> specific locations. This would allow the master device to do the > >>>>> kind of computations you outline below. > >>>>> > >>>>> -Pete > >>>>> > >>>>> > >>>>> Gerald Chouinard wrote: > >>>>>> Peter, > >>>>>> > >>>>>> In the 802.22 WRAN model, the process of intersection is > >>>>>> done > >> at > >>>> the > >>>>>> base station because the base station should be able to > > decide > >>>> whether > >>>>>> to accept association with a new user terminal or not, depending > on > >>>>>> the extent this new terminal limits the number of available > >>>>>> channels. This would not be possible if this is done at the > >>>>>> database. > >>>>>> > >>>>>> The base station (or the master in more general terms) should > >>>>>> maintain a local table of available channel sets (or maximum > allowed > >> EIRP > >>>> per > >>>>>> channel) to have all the information necessary to continuously > >>>>>> optimize its use of the RF spectrum. One can imagine a new > terminal > >>>>>> that asks to be associated that may reduce the number of > available > >>>>>> channels to only a few but, by disassociating another > > terminal > >> in a > >>>>>> different location, the local network would regain even more > >>>>>> available channels, as a result of the intersection process. > The > >>>>>> base station could then decide to stop its association with this > >>>>>> second terminal and associate the first terminal. This > >>>>>> intelligence should not be relegated to the database but should > be > >>>>>> kept local at the > > base > >>>> station. > >>>>>> > >>>>>> Whether the base station queries the database for each of its > >>>>>> associated terminals one at a time or in 'batch' mode for all > its > >>>>>> terminals, the complete information should be obtained from the > >>>>>> database so that the process of 'intersection' can take place > >> at > >>>> the > >>>>>> base station. > >>>>>> > >>>>>> Gerald > >>>>>> > >>>>>> > >>>>>> At 11:50 14-10-11 +0000, Peter McCann wrote: > >>>>>>> D.6 comes close, but also seems to allow returning the > >>>>>>> union > >> set > >>>> of all > >>>>>>> channels available at the multiple locations. I want to > > make > >> sure > >>>> the > >>>>>>> WSDB can do a set intersection of the available channels at > >> each > >>>> of the > >>>>>>> listed locations. > >>>>>>> > >>>>>>> -Pete > >>>>>>> > >>>>>>> Gabor.Bajko@nokia.com wrote: > >>>>>>>> Pete, > >>>>>>>> > >>>>>>>> Would D.6/D.7 cover your requirement: D.6: The Data Model MUST > >>>>>>>> support specifying channel availability information for > multiple > >>>>>>>> locations. D.7: The Data Model MUST support specifying channel > >>>>>>>> availability information for an area around a specified > location. > >>>>>>>> > >>>>>>>> -Gabor > >>>>>>>> > >>>>>>>> -----Original Message----- From: ext Peter McCann > >>>>>>>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October > > 13, > >> 2011 > >>>>>>>> 2:24 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil > >>>>>>>> Basavaraj (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; > Probasco > >>>>>>>> Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: RE: [paws] > >>>>>>>> Possible new use case: simulcasting > >>>>>>>> > >>>>>>>> Hi, Gabor, > >>>>>>>> > >>>>>>>> I think the requirement could be expressed as a refinement of > >>>>>>>> what you mean by "location" in requirement D.3: > >>>>>>>> > >>>>>>>> D.3: The Data Model MUST support specifying the location of > the > >>>>>>>> subject and accuracy of location determination. Here, > "location" > >>>>>>>> can be a single point or a set of points. > >>>>>>>> > >>>>>>>> -Pete > >>>>>>>> > >>>>>>>> Gabor.Bajko@nokia.com wrote: > >>>>>>>>> Pete, If your use case is covered by 4.3, but the > >> requirements > >>>> may be > >>>>>>>>> different, please feel free to propose your protocol > >> requirement > >>>> to > >>>>>>>>> the list. -Gabor > >>>>>>>>> > >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter McCann > >>>>>>>>> Sent: Wednesday, September 14, 2011 10:30 AM To: Patil > Basavaraj > >>>>>>>>> (Nokia-CIC/Dallas); gerald.chouinard@crc.ca; Probasco Scott > >>>>>>>>> (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: Re: [paws] > >>>>>>>>> Possible new use case: simulcasting > >>>>>>>>> > >>>>>>>>> Hi, Raj, > >>>>>>>>> > >>>>>>>>> I think my use case is covered by Section 4.3 with a small > >>>>>>>>> change along the lines that Scott suggested. Note there is > this > >> text > >>>> in > >>>>>>>>> step 8: > >>>>>>>>> > >>>>>>>>> 8. The slave or user device scans the TV bands to > >>>>>>>>> locate > >> a > >>>>>> WRAN > >>>>>>>>> transmission, and associates with the master/BS. The > >>>>>>>>> slave/user device provides its geolocation to the > > BS > >>>> which, in > >>>>>>>>> turn, queries the database for a list of channels > >>>>>>>>> available at the slaves' geolocation. > >>>>>>>>> What I am suggesting is no different except for the fact that > >>>>>>>>> each of the devices could have independent Internet access > >> and > >>>> be > >>>>>>>>> capable of querying the database itself. There could be one > BS > >>>>>>>>> that handles all the queries or the individual BSs could > query > >>>>>>>>> themselves (each for their own location) and they could > compare > >>>>>>>>> notes to find a common free channel. > >>>>>>>>> > >>>>>>>>> As for the protocol between the BS and the WSDB, we may > >>>>>>>>> want > >> to > >>>> have > >>>>>>>>> a requirement that the protocol carry multiple location > elements > >>>>>>>>> (instead of just one) so that we save the cost of multiple > >>>>>>>>> queries across the Internet. The WSDB, after doing the > polygon > >>>>>>>>> intersection test at each location, could additionally do a > set > >> intersection > >>>> test > >>>>>>>>> on the remaining free channels and return the results. > >> That's > >>>> one > >>>>>>>>> concrete way that this use case may impact the protocol > >>>>>>>>> specification. > >>>>>>>>> > >>>>>>>>> -Pete > >>>>>>>>> From mksaji@yahoo.com Fri Oct 14 20:13: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 0664A21F8B35 for ; Fri, 14 Oct 2011 20:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3-VMlN+2Ou3d for ; Fri, 14 Oct 2011 20:13:39 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ne1.yahoo.com (nm4-vm0.bullet.mail.ne1.yahoo.com [98.138.90.253]) by ietfa.amsl.com (Postfix) with SMTP id 7417B21F8B2E for ; Fri, 14 Oct 2011 20:13:39 -0700 (PDT) Received: from [98.138.90.56] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 15 Oct 2011 03:13:34 -0000 Received: from [98.138.87.6] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 Oct 2011 03:13:34 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 15 Oct 2011 03:13:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35164.67159.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 26757 invoked by uid 60001); 15 Oct 2011 03:13:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318648413; bh=ga39s7tWQAOOXLagLDQXfZOiyxDd9dpJrbWR/sg/JgQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sEVNwCMvBxHnYy4OfNp4RdVgRF+6dyBT0U6eYSRj/EHUdjTJD4/OiBWbPXH7aBt2wauxx6ex0EzZCdSHQnoRZCWyVCpU+9GvI25ZxN73j7rXrzg9Fmc0fuWrpBi3nagDI8NOqm+4ruzEprIqPByz4s+unQ3k1o2TbMKej2M7zvs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MNQVZAjtfhwi/MTt+xlh7fw4nATlCVmUnigjORa3WCOYPbRn1+TJoQjz1VhrNU+ryo49JidtELROmixDrkS+6RQwOS4/kXgY2f++pUBH/p9OzDmJfz2L5lLd6JtuCZi69jnBO60BYrB0t0j1cCpQmyP7VX6S0CeFwfu3MlCgSGo=; X-YMail-OSG: kOZc4b8VM1nOqQZ75IVk09.Z6hnOiFj8u2V57NX6M809jpL AeHZblF5hWSW4mTd1A6QPqSH.HrYwqVfxZMV7VQJxvr.INBbm2JXSXexBJNU 29VNUTcGU.EkQgbGdbAmgBfE_4v.x7suTDMOkEl76SJyh3dvWkatasOvOiKk _WC7PuwoJ1o3sukuLVWMnQokdceh9_O7mDqTVINdzy_VoC.tAOQZLW._._JR FgjQM89H1mJm63ffXKYv4EyKAoAnw_EkFM2FIeZklMo6PMlJi4VvdNbSIhU6 KsfFJo3xymEKzTAwp3vfl.VpYQUGy8GKM0f_k9su7vq.Q7p5IYc_SA2Q1BPq uEZ0uEjyZeebDWedDGRAopGDOdANz1qbWD_RGJgzlpFG_DCja5b0hycCyfA9 yFfH2Hz6PtHHx3GjK77hXGQ9lTzPiFGAxR5w7P19F9tP7rokW0VgrmAtR_4J 1d6lnwERzXmIsV304fA68ToNtLORRDTQgjIrccC8n2DQWenZcliM5ZJsouXs NItfBgzJ1TpjYOqjJbw-- Received: from [49.249.131.252] by web36701.mail.mud.yahoo.com via HTTP; Fri, 14 Oct 2011 20:13:33 PDT X-Mailer: YahooMailWebService/0.8.114.317681 References: <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <" <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A"@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A37A@dfweml503-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE71596A39B@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612DAEC@008-AM1MPN1-007.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716401932@dfweml503-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47612E03A@008-AM1MPN1-007.mgdnok.nokia.com> <5.1.0.14.2.20111014101957.01bb6ff8@imap.crc.ca> <5.1.0.14.2.20111014110412.01b7bed0@imap.crc.ca> <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9547@SC-VEXCH2.marvell.com> Message-ID: <1318648413.12112.YahooMailNeo@web36701.mail.mud.yahoo.com> Date: Fri, 14 Oct 2011 20:13:33 -0700 (PDT) From: "M.K.Sajeev sajeev" To: Paul Lambert , Gerald Chouinard , Peter McCann , "Gabor.Bajko@nokia.com" , "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0141EAD9547@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2114655128-659143803-1318648413=:12112" 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 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: Sat, 15 Oct 2011 03:13:41 -0000 ---2114655128-659143803-1318648413=:12112 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI agree with this comment. Compression/decompression, etc. can mak= e the whole transaction slow, and complex too. Net bandwidth now should be = able to accommodate data without compression (which is going to improve too= in coming days). Differential response and catching looks like good option= ..=0A=A0=0ABest Regards,=0ASajeev Manikkoth=0A=0A=0A=0A=0A=0A______________= __________________=0AFrom: Paul Lambert =0ATo: Gerald Cho= uinard ; Peter McCann ; "= Gabor.Bajko@nokia.com" ; "Basavaraj.Patil@nokia.com"= ; "scott.probasco@nokia.com" =0ACc: "paws@ietf.org" =0ASent: Friday, 14 October 2= 011, 23:15=0ASubject: Re: [paws] Possible new use case: simulcasting=0A=0AI= think we may be over designing.=A0 The union is interesting - but it limit= s a device from using all available channels in any particular location.=0A= =0APaul=0A=0A=0APaul A. Lambert | Marvell Semiconductor | +1-650-787-9141= =0A=0A=0A> -----Original Message-----=0A> From: paws-bounces@ietf.org [mail= to:paws-bounces@ietf.org] On Behalf Of=0A> Gerald Chouinard=0A> Sent: Frida= y, October 14, 2011 8:09 AM=0A> To: Peter McCann; Gabor.Bajko@nokia.com; Ba= savaraj.Patil@nokia.com;=0A> scott.probasco@nokia.com=0A> Cc: paws@ietf.org= =0A> Subject: Re: [paws] Possible new use case: simulcasting=0A> =0A> Pete,= =0A> =0A> Agreed.=A0 A simple compression scheme could be proposed in the P= AWS=0A> protocol=0A> and that is to query only only on a 'differential' bas= is, i.e., the=0A> database would only send what has changed since the last = query. This=0A> could=0A> also be applied to the query message from the bas= e station, i.e.,=0A> sending=0A> only the information that would have chang= ed since the last query=0A> (e.g.,=0A> new terminal, changed geoposition, e= tc.).=0A> =0A> Gerald=0A> =0A> At 14:50 14-10-11 +0000, Peter McCann wrote:= =0A> >Hi, Gerald,=0A> >=0A> >I think doing the intersection at the master d= evice might be=0A> >acceptable, as long as the "batch" location mode is sup= ported.=0A> >However, it might lead to a lot of redundant data being=0A> >s= ent back from the WSDB if there are many channels free in=0A> >all given lo= cations.=A0 Perhaps some sort of compression could=0A> >be defined so that = the common channels are sent only once?=0A> >That would be roughly equivale= nt to doing an intersection=0A> >but you would also send the additional inf= ormation about the=0A> >channels that were free only in specific locations.= =A0 This=0A> >would allow the master device to do the kind of computations= =0A> >you outline below.=0A> >=0A> >-Pete=0A> >=0A> >=0A> >Gerald Chouinard= wrote:=0A> > > Peter,=0A> > >=0A> > > In the 802.22 WRAN model, the proces= s of intersection is done at=0A> the=0A> > > base station because the base = station should be able to decide=0A> whether=0A> > > to accept association = with a new user terminal or not, depending on=0A> > > the extent this new t= erminal limits the number of available=0A> channels.=0A> > > This would not= be possible if this is done at the database.=0A> > >=0A> > > The base stat= ion (or the master in more general terms) should=0A> maintain=0A> > > a loc= al table of available channel sets (or maximum allowed EIRP=0A> per=0A> > >= channel) to have all the information necessary to continuously=0A> > > opt= imize its use of the RF spectrum. One can imagine a new terminal=0A> > > th= at asks to be associated that may reduce the number of available=0A> > > ch= annels to only a few but, by disassociating another terminal in a=0A> > > d= ifferent location, the local network would regain even more=0A> available= =0A> > > channels, as a result of the intersection process.=A0 The base=0A>= station=0A> > > could then decide to stop its association with this second= terminal=0A> > > and associate the first terminal.=A0 This intelligence sh= ould not be=0A> > > relegated to the database but should be kept local at t= he base=0A> station.=0A> > >=0A> > > Whether the base station queries the d= atabase for each of its=0A> > > associated terminals one at a time or in 'b= atch' mode for all its=0A> > > terminals, the complete information should b= e obtained from the=0A> > > database so that the process of 'intersection' = can take place at=0A> the=0A> > > base station.=0A> > >=0A> > > Gerald=0A> = > >=0A> > >=0A> > > At 11:50 14-10-11 +0000, Peter McCann wrote:=0A> > >> D= .6 comes close, but also seems to allow returning the union set=0A> of all= =0A> > >> channels available at the multiple locations.=A0 I want to make s= ure=0A> the=0A> > >> WSDB can do a set intersection of the available channe= ls at each=0A> of the=0A> > >> listed locations.=0A> > >>=0A> > >> -Pete=0A= > > >>=0A> > >> Gabor.Bajko@nokia.com wrote:=0A> > >>> Pete,=0A> > >>>=0A> = > >>> Would D.6/D.7 cover your requirement:=0A> > >>> D.6: The Data Model M= UST support specifying channel availability=0A> > >>> information for multi= ple locations.=0A> > >>> D.7: The Data Model MUST support specifying channe= l availability=0A> > >>> information for an area around a specified locatio= n.=0A> > >>>=0A> > >>> -Gabor=0A> > >>>=0A> > >>> -----Original Message----= - From: ext Peter McCann=0A> > >>> [mailto:Peter.McCann@huawei.com] Sent: T= hursday, October 13, 2011=0A> > >>> 2:24 PM To: Bajko Gabor (Nokia-CIC/Sili= conValley); Patil=0A> Basavaraj=0A> > >>> (Nokia- CIC/Dallas); gerald.choui= nard@crc.ca; Probasco Scott=0A> > >>> (Nokia-CIC/Dallas)=0A> > >>> Cc: paws= @ietf.org Subject: RE: [paws] Possible new use case:=0A> > >>> simulcasting= =0A> > >>>=0A> > >>> Hi, Gabor,=0A> > >>>=0A> > >>> I think the requirement= could be expressed as a refinement of=0A> what=0A> > >>> you mean by "loca= tion" in requirement D.3:=0A> > >>>=0A> > >>> D.3: The Data Model MUST supp= ort specifying the location of the=0A> > >>> subject and accuracy of locati= on determination.=A0 Here, "location"=0A> > >>> can be a single point or a = set of points.=0A> > >>>=0A> > >>> -Pete=0A> > >>>=0A> > >>> Gabor.Bajko@no= kia.com wrote:=0A> > >>>> Pete, If your use case is covered by 4.3, but the= requirements=0A> may be=0A> > >>>> different, please feel free to propose = your protocol requirement=0A> to=0A> > >>>> the list. -Gabor=0A> > >>>>=0A>= > >>>> -----Original Message-----=0A> > >>>> From: paws-bounces@ietf.org [= mailto:paws-bounces@ietf.org] On=0A> > >>>> Behalf Of ext Peter McCann=0A> = > >>>> Sent: Wednesday, September 14, 2011 10:30 AM=0A> > >>>> To: Patil Ba= savaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca;=0A> > >>>> Probasco Sc= ott (Nokia-CIC/Dallas)=0A> > >>>> Cc: paws@ietf.org=0A> > >>>> Subject: Re:= [paws] Possible new use case: simulcasting=0A> > >>>>=0A> > >>>> Hi, Raj,= =0A> > >>>>=0A> > >>>> I think my use case is covered by Section 4.3 with a= small=0A> change=0A> > >>>> along the lines that Scott suggested.=A0 Note = there is this text=0A> in=0A> > >>>> step 8:=0A> > >>>>=0A> > >>>>=A0 =A0 8= .=A0 The slave or user device scans the TV bands to locate a=0A> > > WRAN= =0A> > >>>>=A0 =A0 =A0 =A0 transmission, and associates with the master/BS.= =A0 The=0A> > >>>>=A0 =A0 =A0 =A0 slave/user device provides its geolocatio= n to the BS=0A> which, in=0A> > >>>>=A0 =A0 =A0 =A0 turn, queries the datab= ase for a list of channels=0A> available at=0A> > >>>>=A0 =A0 =A0 =A0 the s= laves' geolocation.=0A> > >>>> What I am suggesting is no different except = for the fact that=0A> > >>>> each of the devices could have independent Int= ernet access and=0A> be=0A> > >>>> capable of querying the database itself.= =A0 There could be one BS=0A> > >>>> that handles all the queries or the in= dividual BSs could query=0A> > >>>> themselves (each for their own location= ) and they could compare=0A> > >>>> notes to find a common free channel.=0A= > > >>>>=0A> > >>>> As for the protocol between the BS and the WSDB, we may= want to=0A> have=0A> > >>>> a requirement that the protocol carry multiple= location elements=0A> > >>>> (instead of just one) so that we save the cos= t of multiple=0A> queries=0A> > >>>> across the Internet.=A0 The WSDB, afte= r doing the polygon=0A> intersection=0A> > >>>> test at each location, coul= d additionally do a set intersection=0A> test=0A> > >>>> on the remaining f= ree channels and return the results.=A0 That's=0A> one=0A> > >>>> concrete = way that this use case may impact the protocol=0A> specification.=0A> > >>>= >=0A> > >>>> -Pete=0A> > >>>>=0A> =0A> =0A> =0A> __________________________= _____________________=0A> paws mailing list=0A> paws@ietf.org=0A> https://w= ww.ietf.org/mailman/listinfo/paws=0A_______________________________________= ________=0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman= /listinfo/paws ---2114655128-659143803-1318648413=:12112 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

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



From: Paul Lambert <paul@marvell.com>
To: Gerald Chouinard <gerald= .chouinard@crc.ca>; Peter McCann <Peter.McCann@huawei.com>; "Gabor= .Bajko@nokia.com" <Gabor.Bajko@nokia.com>; "Basavaraj.Patil@nokia.com= " <Basavaraj.Patil@nokia.com>; "scott.probasco@nokia.com" <scott.p= robasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Sent: Friday, 14 October 2011, 23:15
Subject: Re: [paws] Possible new use case: = simulcasting

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

Paul


Paul A. Lambert | Marve= ll Semiconductor | +1-650-787-9141


> -----Original Message-----=
> From: paws-bounces@ietf.org [mailto:paws-bounces= @ietf.org] On Behalf Of
> Gerald Chouinard
> Sent: Friday, = October 14, 2011 8:09 AM
> To: Peter McCann; Gabor.Bajko@nokia= .com; Basavaraj.Patil@nokia.com;
> scott.probasco@nokia.com
> Cc: paws@ietf.org
> Subject: Re: [= paws] Possible new use case: simulcasting
>
> Pete,
> > Agreed.  A simple compression scheme could be proposed in the PAWS> protocol
> and that is to query only only on a 'differential' b= asis, i.e., the
> database would only send what has changed since the= last query. This
> could
> also be applied to the query messag= e from the base station, i.e.,
> sending
> only the information= that would have changed since the last query
> (e.g.,
> new te= rminal, changed geoposition, etc.).
>
> Gerald
>
>= ; At 14:50 14-10-11 +0000, Peter McCann wrote:
> >Hi, Gerald,
&= gt; >
> >I think doing the intersection at the master device mi= ght be
> >acceptable, as long as the "batch" location mode is supp= orted.
> >However, it might lead to a lot of redundant data being<= br>> >sent back from the WSDB if there are many channels free in
&= gt; >all given locations.  Perhaps some sort of compression could
> >be defined so that the common channels are sent only onc= e?
> >That would be roughly equivalent to doing an intersection> >but you would also send the additional information about the
&= gt; >channels that were free only in specific locations.  This
&= gt; >would allow the master device to do the kind of computations
>= ; >you outline below.
> >
> >-Pete
> >
>= ; >
> >Gerald Chouinard wrote:
> > > Peter,
>= > >
> > > In the 802.22 WRAN model, the process of inter= section is done at
> the
> > > base station because the b= ase station should be able to decide
> whether
> > > to a= ccept association with a new user terminal or not, depending on
> >= ; > the extent this new terminal limits the number of available
> = channels.
> > > This would not be possible if this is done at the database.
> > >
> > > The base station= (or the master in more general terms) should
> maintain
> >= > a local table of available channel sets (or maximum allowed EIRP
&= gt; per
> > > channel) to have all the information necessary to= continuously
> > > optimize its use of the RF spectrum. One ca= n imagine a new terminal
> > > that asks to be associated that = may reduce the number of available
> > > channels to only a few= but, by disassociating another terminal in a
> > > different l= ocation, the local network would regain even more
> available
>= > > channels, as a result of the intersection process.  The bas= e
> station
> > > could then decide to stop its associati= on with this second terminal
> > > and associate the first term= inal.  This intelligence should not be
> > > relegated to the database but should be kept local at the base
> sta= tion.
> > >
> > > Whether the base station queries = the database for each of its
> > > associated terminals one at = a time or in 'batch' mode for all its
> > > terminals, the comp= lete information should be obtained from the
> > > database so = that the process of 'intersection' can take place at
> the
> &g= t; > base station.
> > >
> > > Gerald
> &g= t; >
> > >
> > > At 11:50 14-10-11 +0000, Peter = McCann wrote:
> > >> D.6 comes close, but also seems to allo= w returning the union set
> of all
> > >> channels ava= ilable at the multiple locations.  I want to make sure
> the
= > > >> WSDB can do a set intersection of the available channels= at each
> of the
> > >> listed locations.
> > >>
> > >> -Pete
> > = >>
> > >> Gabor.Bajko@nokia.com wrote:
&= gt; > >>> Pete,
> > >>>
> > >>= > Would D.6/D.7 cover your requirement:
> > >>> D.6: T= he Data Model MUST support specifying channel availability
> > >= ;>> information for multiple locations.
> > >>> D.7= : The Data Model MUST support specifying channel availability
> > = >>> information for an area around a specified location.
> &= gt; >>>
> > >>> -Gabor
> > >>>=
> > >>> -----Original Message----- From: ext Peter McCan= n
> > >>> [mailto:Peter.McCann@huawei.com] Sent: Thursday, October 13, 2011
> > >>> 2:24 PM To: Baj= ko Gabor (Nokia-CIC/SiliconValley); Patil
> Basavaraj
> > &g= t;>> (Nokia- CIC/Dallas); gerald.chouinard@crc.ca; Pro= basco Scott
> > >>> (Nokia-CIC/Dallas)
> > >&= gt;> Cc: paws@ietf.org Subject: RE: [paws] Possible new use case:
> >= ; >>> simulcasting
> > >>>
> > >>= > Hi, Gabor,
> > >>>
> > >>> I think= the requirement could be expressed as a refinement of
> what
>= > >>> you mean by "location" in requirement D.3:
> > = >>>
> > >>> D.3: The Data Model MUST support spe= cifying the location of the
> > >>> subject and accuracy of location determination.  Here, "location"
> > >>>= ; can be a single point or a set of points.
> > >>>
&g= t; > >>> -Pete
> > >>>
> > >>&= gt; Gabor.Bajko@nokia.com wrote:
> > >>>> P= ete, If your use case is covered by 4.3, but the requirements
> may b= e
> > >>>> different, please feel free to propose your= protocol requirement
> to
> > >>>> the list. -G= abor
> > >>>>
> > >>>> -----Origi= nal Message-----
> > >>>> From: paws-bounces@ie= tf.org [mailto:paws-bounces@ietf.org] On
> > >>>> Behalf Of ext Peter McCann
> > >>>> = Sent: Wednesday, September 14, 2011 10:30 AM
> > >>>> = To: Patil Basavaraj (Nokia-CIC/Dallas); gerald.chouinard@crc.ca<= /a>;
> > >>>> Probasco Scott (Nokia-CIC/Dallas)
>= ; > >>>> Cc: paws@ietf.org
> > >>>> Subject:= Re: [paws] Possible new use case: simulcasting
> > >>>&g= t;
> > >>>> Hi, Raj,
> > >>>>
= > > >>>> I think my use case is covered by Section 4.3 wi= th a small
> change
> > >>>> along the lines tha= t Scott suggested.  Note there is this text
> in
> > &g= t;>>> step 8:
> > >>>>
> > >>>>    8.  The slave or user device scans the = TV bands to locate a
> > > WRAN
> > >>>>&n= bsp;       transmission, and associates with the master/BS.&= nbsp; The
> > >>>>        slave/us= er device provides its geolocation to the BS
> which, in
> >= >>>>        turn, queries the database for= a list of channels
> available at
> > >>>> = ;       the slaves' geolocation.
> > >>>&g= t; What I am suggesting is no different except for the fact that
> &g= t; >>>> each of the devices could have independent Internet acc= ess and
> be
> > >>>> capable of querying the da= tabase itself.  There could be one BS
> > >>>> th= at handles all the queries or the individual BSs could query
> > >>>> themselves (each for their own location) and they co= uld compare
> > >>>> notes to find a common free chann= el.
> > >>>>
> > >>>> As for the = protocol between the BS and the WSDB, we may want to
> have
> &= gt; >>>> a requirement that the protocol carry multiple locatio= n elements
> > >>>> (instead of just one) so that we s= ave the cost of multiple
> queries
> > >>>> acro= ss the Internet.  The WSDB, after doing the polygon
> intersecti= on
> > >>>> test at each location, could additionally = do a set intersection
> test
> > >>>> on the rem= aining free channels and return the results.  That's
> one
&g= t; > >>>> concrete way that this use case may impact the pro= tocol
> specification.
> > >>>>
> > >>>> -Pete
> > >>>>
>
>=
>
> _______________________________________________
> = paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listi= nfo/paws
_______________________________________________
paws mai= ling list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

---2114655128-659143803-1318648413=:12112-- From andy.sago@bt.com Mon Oct 17 01:49: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 62FC221F8AFD for ; Mon, 17 Oct 2011 01:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IoPT6T-6x0Hl for ; Mon, 17 Oct 2011 01:49:37 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBAB21F8AFB for ; Mon, 17 Oct 2011 01:49:37 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 17 Oct 2011 09:49:36 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.67]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 17 Oct 2011 09:49:35 +0100 From: To: , Date: Mon, 17 Oct 2011 09:49:34 +0100 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyMqaywLGptZ9r7QaW3AHrkv+e5BA== Message-ID: <619CDADDCCD2B44380834BE8BF6F714140491FE3ED@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140491FE3EDEMV62UKRDdoma_" MIME-Version: 1.0 Subject: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 08:49:38 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140491FE3EDEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_619CDADDCCD2B44380834BE8BF6F714140491FE3EDEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Scott, all
 
I-D http://www.ietf.org/id/d= raft-zuniga-paws-uk-use-cases-and-requirements-00.txt propos= es revision of the database discovery use case, two new use cases for indoor networking and machine to machine co= mmunications, and a set of requirements that drop out of all the use cases = included so far in the working document. These especially address the UK Of= com requirements as currently known. Also, a definition is proposed for the term ‘device ID’ which w= e suggest should be used throughout the use cases and requirements for cons= istency in place of terms such as ‘model ID’ and ‘FCC ID&= #8217;. This Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Carlos Zuniga (Interdigital). We would welcome comm= ents made to the reflector on these proposals. We are willing to present in= Taipei if it would be helpful in providing further explanation to the cont= ent in the document.
 
Regards
 
Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital)
 
 
 
 
 --_000_619CDADDCCD2B44380834BE8BF6F714140491FE3EDEMV62UKRDdoma_-- From andy.sago@bt.com Tue Oct 18 03:00: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 1F6AD21F8C77 for ; Tue, 18 Oct 2011 03:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 4tlj9gk8MU6e for ; Tue, 18 Oct 2011 03:00:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 017EF21F8C56 for ; Tue, 18 Oct 2011 03:00:08 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 18 Oct 2011 11:00:06 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.67]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 18 Oct 2011 11:00:06 +0100 From: To: , , Date: Tue, 18 Oct 2011 11:00:05 +0100 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyNAuHcyB6+/YJKRHuFagQyvF5Y+gAZFwwwAAMfgqA= Message-ID: <619CDADDCCD2B44380834BE8BF6F714140492FFAF7@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F714140491FE3ED@EMV62-UKRD.domain1.systemhost.net> <8F653581B7AD41BB85E4F5CA2C9D5E21@SRA3> In-Reply-To: <8F653581B7AD41BB85E4F5CA2C9D5E21@SRA3> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140492FFAF7EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:00:12 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140492FFAF7EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks very much for your comments which give food for thought. I've consid= ered these in the context of the requirements for a protocol for TVWS datab= ase systems, the subject of this reflector. Taking your points one by one: 1) Defining the master device location - yes the regulator wants to kn= ow the location of the radiating antenna of the master device. For consumer= installed equipment, such as an access point for home networking, the loca= tion of any GPS receive antenna will be pretty close to (or potentially co= uld share an antenna with) the TVWS antenna. Bearing in mind the granularit= y of the protection contours provided for the TV transmissions and the use = of 100m pixels in UK, this will be more than adequate. I don't know what sy= stem would have a master device located miles from its transmitting antenna= (an example you gave), but we can expect that such a system would be profe= ssionally installed, and the installer would configure the device location = to be that of the antenna. Mostly this is of concern to the regulator and i= s outside the scope of PAWS, as the protocol just sends the lat-long coordi= nates to the database. 2) Determining a master's location - yes I can envisage that professio= nally installed rural broadband systems (for example) could have their loca= tions entered by an installer, triangulated over other wireless technologie= s or derived from other known location data or by other means. GSP is not m= andated. In my view these are all covered by the process of a master device= "determining" its location. Where location is entered manually, the potent= ial for deliberate or accidental entry of incorrect information needs to be= guarded against in system design (but is outside the scope of PAWS). 3) No entity really "knows its location" - you are getting philosophic= al now! Yes it's estimated, but see my answer to (1) for the accuracy requi= red. 4) Security - thanks for the pointers. I am highly confident that ther= e are appropriate security solutions out there, which the PAWS protocol can= point to. We can address this when we get to the solution phase. Andy From: Richard Roy [mailto:dickroy@alum.mit.edu] Sent: 18 October 2011 08:39 To: Sago,AJ,Andy,COD R; paws@ietf.org; scott.probasco@nokia.com Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case I read with great interest your IETF draft. I had a few thoughts I thought= I'd share with you: 1) How is the location of the master device defined? Is it the locatio= n of the GPS antenna, the box itself, or perhaps the location of the TVWS t= ransmitting antenna (its phase center actually). I claim behind door three= is the prize. No regulator cares where the GPS antenna is located. It's = not transmitting anything ... yet. No one cares where the master box is lo= cated; in can be miles from the transmitting antenna. It's the location of= the TVWS transmitting antenna that counts. 2) Why does a master box have to be able to "determine" its location? (= See 1)) It should be sufficient to just "know it" by any means not specifie= d in any standard. 3) No entity really "knows its location". It estimates its location re= lative to some previously agreed upon coordinate system (including the four= th dimension of time a la GPS) and should also be estimating the covariance= matrix of the estimation error as do all GPS systems. It is this covarian= ce matrix (really the upper triangular part of the square root of the covar= iance matrix if you want to get down to the details) that is the critical s= tatistical information that needs to be transmitted along with the estimate= d location. 4) FYI ... the security system described in this use case is the same a= s the one being developed by IEEE 1609.2/ETSI TCITS WG5/TC204 WG17 SWG7 and= standards have been and are being written. You might want to contact thes= e groups for more info. I hope this is helpful. Cheers, RR ________________________________ From: andy.sago@bt.com [mailto:andy.sago@bt.com] Sent: Monday, October 17, 2011 1:50 AM To: paws@ietf.org; scott.probasco@nokia.com Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_619CDADDCCD2B44380834BE8BF6F714140492FFAF7EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks very much for your co= mments which give food for thought. I’ve considered these in the cont= ext of the requirements for a protocol for TVWS database systems, the subje= ct of this reflector.

 

Taking your points one by one:

 

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

2)      Determining a master’s location – yes I can envisag= e that professionally installed rural broadband systems (for example) could= have their locations entered by an installer, triangulated over other wire= less technologies or derived from other known location data or by other mea= ns. GSP is not mandated. In my view these are all covered by the process of= a master device “determining” its location. Where location is = entered manually, the potential for deliberate or accidental entry of incor= rect information needs to be guarded against in system design (but is outsi= de the scope of PAWS).

3) &= nbsp;    No entity really “knows = its location” – you are getting philosophical now! Yes it’= ;s estimated, but see my answer to (1) for the accuracy required.

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

 

Andy

 <= /o:p>

From:= Richard Roy [mailto:dickroy@alum.mit.edu]
Sent: 18 October= 2011 08:39
To: Sago,AJ,Andy,COD R; paws@ietf.org; scott.probasco= @nokia.com
Subject: RE: [paws] New indoor and M2M use cases, revi= sion of DB discovery use case

 

I read wi= th great interest your IETF draft.  I had a few thoughts I thought I&#= 8217;d share with you:

 

1)     How is the location of the master device defined?  Is it = the location of the GPS antenna, the box itself, or perhaps the location of= the TVWS transmitting antenna (its phase center actually).  I claim b= ehind door three is the prize.  No regulator cares where the GPS anten= na is located.  It’s not transmitting anything … yet. = ; No one cares where the master box is located; in can be miles from the tr= ansmitting antenna.  It’s the location of the TVWS transmitting = antenna that counts.

2)     Why does a master box have to be able to “deter= mine” its location? (See 1)) It should be sufficient to just “k= now it” by any means not specified in any standard.  =

3) = ;    No entity= really “knows its location”.  It estimates its location r= elative to some previously agreed upon coordinate system (including the fou= rth dimension of time a la GPS) and should also be estimating the covarianc= e matrix of the estimation error as do all GPS systems.  It is this co= variance matrix (really the upper triangular part of the square root of the= covariance matrix if you want to get down to the details) that is the crit= ical statistical information that needs to be transmitted along with the es= timated location.

4)     FYI … the security system described in this use ca= se is the same as the one being developed by IEEE 1609.2/ETSI TCITS WG5/TC2= 04 WG17 SWG7 and standards have been and are being written.  You might= want to contact these groups for more info.

 

I hope this is helpful.

 

Cheers,


RR

&nbs= p;

    <= o:p>

 <= /span>

 

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

=  =

Regards

=

 

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

 

=

 

 

 

= --_000_619CDADDCCD2B44380834BE8BF6F714140492FFAF7EMV62UKRDdoma_-- From Andrew.Gowans@ofcom.org.uk Wed Oct 19 03:44: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 5176B21F8BBA for ; Wed, 19 Oct 2011 03:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 J0GDp1Ry7M3R for ; Wed, 19 Oct 2011 03:44:11 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8605721F8478 for ; Wed, 19 Oct 2011 03:44:10 -0700 (PDT) X-Env-Sender: Andrew.Gowans@ofcom.org.uk X-Msg-Ref: server-3.tower-27.messagelabs.com!1319021020!42568035!1 X-Originating-IP: [194.33.160.65] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20443 invoked from network); 19 Oct 2011 10:43:40 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 19 Oct 2011 10:43:40 -0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local (10.130.130.68) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 19 Oct 2011 11:44:05 +0100 Received: from WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b]) by WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19%15]) with mapi id 14.01.0289.001; Wed, 19 Oct 2011 11:44:08 +0100 From: Andrew Gowans To: "andy.sago@bt.com" , "paws@ietf.org" , "scott.probasco@nokia.com" Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyMqaywLGptZ9r7QaW3AHrkv+e5BABnu71g Date: Wed, 19 Oct 2011 10:44:07 +0000 Message-ID: <9983D74B649EED43B27BF353837B20C54EDF3237@WOK-INTRA-EXC01.intra.ofcom.local> References: <619CDADDCCD2B44380834BE8BF6F714140491FE3ED@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140491FE3ED@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.39.12] Content-Type: multipart/alternative; boundary="_000_9983D74B649EED43B27BF353837B20C54EDF3237WOKINTRAEXC01in_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 10:44:13 -0000 --_000_9983D74B649EED43B27BF353837B20C54EDF3237WOKINTRAEXC01in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, all, Although I am not a co-signatory of this document, myself and colleagues fr= om Ofcom have made comments to the authors of this submission during the dr= afting process. As we in Ofcom are still in the process of confirming the d= etails of our proposed requirements for the interaction between the WSD and= the Geo-location Databases we felt it was not right at this time for us to= be co-signatory on this document as some of our requirements may vary slig= htly from those presented in the document after our final analysis is compl= eted. I am hoping that myself or a colleague will be in a position to provi= de a formal update of our progress on the proposed requirements to the IETF= PAWS group in the near future. Best Regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of and= y.sago@bt.com Sent: 17 October 2011 09:50 To: paws@ietf.org; scott.probasco@nokia.com Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_9983D74B649EED43B27BF353837B20C54EDF3237WOKINTRAEXC01in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott, all,

 

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

 

Best Regards

 

Andy Gowans

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of andy.sago@bt.com
Sent: 17 October 2011 09:50
To: paws@ietf.org; scott.probasco@nokia.com
Subject: [paws] New indoor and M2M use cases, revision of DB discove= ry use case

 

Hi Scott, all

 

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

 

Regards

 

Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Int= erdigital)

 

 

 

 



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

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

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

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

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_9983D74B649EED43B27BF353837B20C54EDF3237WOKINTRAEXC01in_-- From jstine@mitre.org Fri Oct 21 10:51: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 B993521F8AFE for ; Fri, 21 Oct 2011 10:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jJlMPtCFjA10 for ; Fri, 21 Oct 2011 10:51:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEAA21F8AFA for ; Fri, 21 Oct 2011 10:51:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 054FD21B0B29 for ; Fri, 21 Oct 2011 13:51:51 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F33BD21B0AF9 for ; Fri, 21 Oct 2011 13:51:50 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 21 Oct 2011 13:51:50 -0400 From: "Stine, John A." To: "paws@ietf.org" Date: Fri, 21 Oct 2011 13:51:49 -0400 Thread-Topic: Spectrum Consumption Modeling Thread-Index: AcyQGhoeRW16OA2MRfWs3I1cl9oCHg== Message-ID: <69CC32C3AD4CA84BBABA634B3EE3E589056F11C0F4@IMCMBX2.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C0F4IMCMBX2MITREO_" MIME-Version: 1.0 Subject: [paws] Spectrum Consumption Modeling 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, 21 Oct 2011 17:51:53 -0000 --_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C0F4IMCMBX2MITREO_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been monitoring the traffic on this list to determine if the work I = have been doing in a research project called Model-Based Spectrum Managemen= t (MBSM) would be useful. The recent discussions of using spectrum masks a= nd having means to specify locations in many different ways reveal that it = just might. In MBSM, I have tried to develop a minimal way to model spectrum consumptio= n that can be used to capture the consumption of any type of spectrum use. = Modeling is complemented with a definition of how to compute whether two o= r more models are compatible. These models can be used to find reuse oppor= tunities, to manage spectrum use real time, to manage DSA systems, and to g= ive policy to DSA systems. In the whitespace domain, models can be made of= existing TV channel uses that match the contour approach and then of new u= ses that are added. The collection of models can be used to find reuse opp= ortunities. Models can be used to convey to a device the spectrum it may u= se, they can convey the differences in what spectrum may be used based on m= obility, and they can convey how a device may be interfered with by peer sy= stems. An advantage of modeling for whitespace work is that the nuances of rules o= f different spectrum management administrations for computing compatibility= can be captured without having to create different data modeling approache= s. Using this approach to describing spectrum consumption can make the wor= k in paws much more general. In the US, many federal agencies would be ver= y willing to share spectrum if there were a way to do so dynamically. This= type of modeling approach could make the work of paws applicable to much m= ore spectrum than just TV whitespace. As a minimal definition, our spectrum consumption modeling approach does no= t attempt to identify the users of spectrum, to provide descriptions of the= ir systems, to make any differentiation between a master and slave, or to p= rovide data elements for any sort of messaging that might be used in a busi= ness process. It just provides a means to model spectrum consumption. Our= effort to make it minimal in this way is to allow it to be used to communi= cate spectrum availability among disparate spectrum management systems that= may be used for different spectrum management processes as well as to and = among spectrum dependent devices. As an example, it can provide a means fo= r a government system to convey the availability of spectrum to a commercia= l whitespace service. It provides a means to convey policy from a spectrum= management system to a DSA system. We provide an XML schema with the expe= ctation that it can be used together with other schema to expand it as nece= ssary for use in a particular business process. I have written a manual on spectrum consumption modeling that can be downlo= aded at the following URL: http://www.mitre.org/work/tech_papers/2011/11-2071 Our objective is to collect comments and then do one more rewrite of this m= anual considering those comments. We would then try to propose that the co= ncepts of this modeling approach that are described in this manual be used = as the foundation of an international standard that could be used and cited= by other spectrum management, whitespace, and DySPAN standards. I invite you to look over the manual, provide comments, and even suggest wh= ere you think it would be most appropriate to standardize it. Currently, I= am thinking somewhere in the work of IEEE DySPAN (SC) or the Wireless Inno= vation Forum. Allowing the data model of spectrum consumption to be a broadly used standa= rd as proposed would allow the work of paws to be much more broadly applica= ble to whitespace management as this concept of dynamic access extends beyo= nd TV whitespace. John A. Stine Chief Technology Advisor Operations Research and Systems Analysis The MITRE Corporation email: jstine@mitre.org, Phone:703-983-6281 --_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C0F4IMCMBX2MITREO_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been moni= toring the traffic on this list to determine if the work I have been doing = in a research project called Model-Based Spectrum Management (MBSM) would b= e useful.  The recent discussions of using spectrum masks and having m= eans to specify locations in many different ways reveal that it just might.=

In MBSM, I have tried to develop a mini= mal way to model spectrum consumption that can be used to capture the consu= mption of any type of spectrum use.  Modeling is complemented with a d= efinition of how to compute whether two or more models are compatible. = ; These models can be used to find reuse opportunities, to manage spectrum = use real time, to manage DSA systems, and to give policy to DSA systems.&nb= sp; In the whitespace domain, models can be made of existing TV channel use= s that match the contour approach and then of new uses that are added. = ; The collection of models can be used to find reuse opportunities.  M= odels can be used to convey to a device the spectrum it may use, they can c= onvey the differences in what spectrum may be used based on mobility, and t= hey can convey how a device may be interfered with by peer systems.

An advantage of modeling for whitespace work is= that the nuances of rules of different spectrum management administrations= for computing compatibility can be captured without having to create diffe= rent data modeling approaches.  Using this approach to describing spec= trum consumption can make the work in paws much more general.  In the = US, many federal agencies would be very willing to share spectrum if there = were a way to do so dynamically.  This type of modeling approach could= make the work of paws applicable to much more spectrum than just TV whites= pace.

As a minimal definition, our spect= rum consumption modeling approach does not attempt to identify the users of= spectrum, to provide descriptions of their systems, to make any differenti= ation between a master and slave, or to provide data elements for any sort = of messaging that might be used in a business process.  It just provid= es a means to model spectrum consumption.  Our effort to make it minim= al in this way is to allow it to be used to communicate spectrum availabili= ty among disparate spectrum management systems that may be used for differe= nt spectrum management processes as well as to and among spectrum dependent= devices.  As an example, it can provide a means for a government syst= em to convey the availability of spectrum to a commercial whitespace servic= e.  It provides a means to convey policy from a spectrum management sy= stem to a DSA system.  We provide an XML schema with the expectation t= hat it can be used together with other schema to expand it as necessary for= use in a particular business process.

I= have written a manual on spectrum consumption modeling that can be downloa= ded at the following URL:

http://www.mitre.org/wo= rk/tech_papers/2011/11-2071

Our objective is to collect comment= s and then do one more rewrite of this manual considering those comments.&n= bsp; We would then try to propose that the concepts of this modeling approa= ch that are described in this manual be used as the foundation of an intern= ational standard that could be used and cited by other spectrum management,= whitespace, and DySPAN standards.

I inv= ite you to look over the manual, provide comments, and even suggest where y= ou think it would be most appropriate to standardize it.  Currently, I= am thinking somewhere in the work of IEEE DySPAN (SC) or the Wireless Inno= vation Forum.

Allowing the data model of= spectrum consumption to be a broadly used standard as proposed would allow= the work of paws to be much more broadly applicable to whitespace manageme= nt as this concept of dynamic access extends beyond TV whitespace.

 

John A. Sti= ne

Chief Techn= ology Advisor

Operations Research and Systems Analysis

The MITRE Corporation

email: jstine@mitre.org,  Phone:703-983-6281

 

= --_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C0F4IMCMBX2MITREO_-- From jstine@mitre.org Fri Oct 21 13:00: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 05E911F0C36 for ; Fri, 21 Oct 2011 13:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 W1tueiRc+jwE for ; Fri, 21 Oct 2011 13:00:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE81F0C35 for ; Fri, 21 Oct 2011 13:00:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B2CCD21B0261; Fri, 21 Oct 2011 16:00:26 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A9C3421B006B; Fri, 21 Oct 2011 16:00:26 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 21 Oct 2011 16:00:26 -0400 From: "Stine, John A." To: Eli Salomon , "paws@ietf.org" Date: Fri, 21 Oct 2011 16:00:25 -0400 Thread-Topic: [paws] Spectrum Consumption Modeling Thread-Index: AcyQK7Xoc8pBgIwaTUSzdLGFzY4K7QAACTgw Message-ID: <69CC32C3AD4CA84BBABA634B3EE3E589056F11C17C@IMCMBX2.MITRE.ORG> References: <69CC32C3AD4CA84BBABA634B3EE3E589056F11C0F4@IMCMBX2.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C17CIMCMBX2MITREO_" MIME-Version: 1.0 Subject: Re: [paws] Spectrum Consumption Modeling 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, 21 Oct 2011 20:00:33 -0000 --_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C17CIMCMBX2MITREO_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, please try this link http://www.mitre.org/work/tech_papers/2011/11_2071/ John From: Eli Salomon [mailto:eli@2m.com] Sent: Friday, October 21, 2011 3:58 PM To: Stine, John A. Subject: Re: [paws] Spectrum Consumption Modeling John, Thank you for sharing. Can you re-send the link? It appears to be dead. Regards, -- Eli Salomon 2M Companies, Inc. 4441 Buena Vista St | Dallas, TX 75205 917.617.3766 www.2m.com On Fri, Oct 21, 2011 at 12:51 PM, Stine, John A. > wrote: I have been monitoring the traffic on this list to determine if the work I = have been doing in a research project called Model-Based Spectrum Managemen= t (MBSM) would be useful. The recent discussions of using spectrum masks a= nd having means to specify locations in many different ways reveal that it = just might. In MBSM, I have tried to develop a minimal way to model spectrum consumptio= n that can be used to capture the consumption of any type of spectrum use. = Modeling is complemented with a definition of how to compute whether two o= r more models are compatible. These models can be used to find reuse oppor= tunities, to manage spectrum use real time, to manage DSA systems, and to g= ive policy to DSA systems. In the whitespace domain, models can be made of= existing TV channel uses that match the contour approach and then of new u= ses that are added. The collection of models can be used to find reuse opp= ortunities. Models can be used to convey to a device the spectrum it may u= se, they can convey the differences in what spectrum may be used based on m= obility, and they can convey how a device may be interfered with by peer sy= stems. An advantage of modeling for whitespace work is that the nuances of rules o= f different spectrum management administrations for computing compatibility= can be captured without having to create different data modeling approache= s. Using this approach to describing spectrum consumption can make the wor= k in paws much more general. In the US, many federal agencies would be ver= y willing to share spectrum if there were a way to do so dynamically. This= type of modeling approach could make the work of paws applicable to much m= ore spectrum than just TV whitespace. As a minimal definition, our spectrum consumption modeling approach does no= t attempt to identify the users of spectrum, to provide descriptions of the= ir systems, to make any differentiation between a master and slave, or to p= rovide data elements for any sort of messaging that might be used in a busi= ness process. It just provides a means to model spectrum consumption. Our= effort to make it minimal in this way is to allow it to be used to communi= cate spectrum availability among disparate spectrum management systems that= may be used for different spectrum management processes as well as to and = among spectrum dependent devices. As an example, it can provide a means fo= r a government system to convey the availability of spectrum to a commercia= l whitespace service. It provides a means to convey policy from a spectrum= management system to a DSA system. We provide an XML schema with the expe= ctation that it can be used together with other schema to expand it as nece= ssary for use in a particular business process. I have written a manual on spectrum consumption modeling that can be downlo= aded at the following URL: http://www.mitre.org/work/tech_papers/2011/11-2071 Our objective is to collect comments and then do one more rewrite of this m= anual considering those comments. We would then try to propose that the co= ncepts of this modeling approach that are described in this manual be used = as the foundation of an international standard that could be used and cited= by other spectrum management, whitespace, and DySPAN standards. I invite you to look over the manual, provide comments, and even suggest wh= ere you think it would be most appropriate to standardize it. Currently, I= am thinking somewhere in the work of IEEE DySPAN (SC) or the Wireless Inno= vation Forum. Allowing the data model of spectrum consumption to be a broadly used standa= rd as proposed would allow the work of paws to be much more broadly applica= ble to whitespace management as this concept of dynamic access extends beyo= nd TV whitespace. John A. Stine Chief Technology Advisor Operations Research and Systems Analysis The MITRE Corporation email: jstine@mitre.org, Phone:703-983-6281 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- Eli Salomon 2M Companies, Inc. 4441 Buena Vista St | Dallas, TX 75205 917.617.3766 www.2m.com --_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C17CIMCMBX2MITREO_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, ple= ase try this link

&nb= sp;

http://www.mitre.org/work/tech_papers/= 2011/11_2071/

&nb= sp;

John

<= p class=3DMsoNormal> 

From: Eli Salomon [mailto:eli@2m.com]
Sent= : Friday, October 21, 2011 3:58 PM
To: Stine, John A.
S= ubject: Re: [paws] Spectrum Consumption Modeling

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

John,

Thank you for sharing= .  Can you re-send the link?  It appears to be dead. 
Regards,

--
Eli Salomon
2M Companies= , Inc.

4441 Buena Vista St | Dallas, TX 752= 05

917.617.3766  =

www.2m.com<= span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif";color:b= lack'>

 

On Fri, Oct 21, 2011 at 12:51 PM, Stine, John A. <jstine@mitre.org> wrote:<= /p>

I have been monitoring the traffic on = this list to determine if the work I have been doing in a research project = called Model-Based Spectrum Management (MBSM) would be useful.  The re= cent discussions of using spectrum masks and having means to specify locati= ons in many different ways reveal that it just might.

In MBSM, I have tried to develop a minimal way to model sp= ectrum consumption that can be used to capture the consumption of any type = of spectrum use.  Modeling is complemented with a definition of how to= compute whether two or more models are compatible.  These models can = be used to find reuse opportunities, to manage spectrum use real time, to m= anage DSA systems, and to give policy to DSA systems.  In the whitespa= ce domain, models can be made of existing TV channel uses that match the co= ntour approach and then of new uses that are added.  The collection of= models can be used to find reuse opportunities.  Models can be used t= o convey to a device the spectrum it may use, they can convey the differenc= es in what spectrum may be used based on mobility, and they can convey how = a device may be interfered with by peer systems.

An advantage of modeling for whitespace work is that the nuance= s of rules of different spectrum management administrations for computing c= ompatibility can be captured without having to create different data modeli= ng approaches.  Using this approach to describing spectrum consumption= can make the work in paws much more general.  In the US, many federal= agencies would be very willing to share spectrum if there were a way to do= so dynamically.  This type of modeling approach could make the work o= f paws applicable to much more spectrum than just TV whitespace.=

As a minimal definition, our spectrum consumpti= on modeling approach does not attempt to identify the users of spectrum, to= provide descriptions of their systems, to make any differentiation between= a master and slave, or to provide data elements for any sort of messaging = that might be used in a business process.  It just provides a means to= model spectrum consumption.  Our effort to make it minimal in this wa= y is to allow it to be used to communicate spectrum availability among disp= arate spectrum management systems that may be used for different spectrum m= anagement processes as well as to and among spectrum dependent devices.&nbs= p; As an example, it can provide a means for a government system to convey = the availability of spectrum to a commercial whitespace service.  It p= rovides a means to convey policy from a spectrum management system to a DSA= system.  We provide an XML schema with the expectation that it can be= used together with other schema to expand it as necessary for use in a par= ticular business process.

I have writ= ten a manual on spectrum consumption modeling that can be downloaded at the= following URL:

http://www.m= itre.org/work/tech_papers/2011/11-2071

Our objective is to collect comments and then do one more rewrite= of this manual considering those comments.  We would then try to prop= ose that the concepts of this modeling approach that are described in this = manual be used as the foundation of an international standard that could be= used and cited by other spectrum management, whitespace, and DySPAN standa= rds.

I invite you to look over the ma= nual, provide comments, and even suggest where you think it would be most a= ppropriate to standardize it.  Currently, I am thinking somewhere in t= he work of IEEE DySPAN (SC) or the Wireless Innovation Forum.

Allowing the data model of spectrum consumption to= be a broadly used standard as proposed would allow the work of paws to be = much more broadly applicable to whitespace management as this concept of dy= namic access extends beyond TV whitespace.

 

John A. Stine

Chief Technology Advisor

Operations Research and Systems Analysis

The MITRE Corporation

email: jstine@mitre.org,  Phone:703-983-6281

=  


____= ___________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/l= istinfo/paws




--
Eli Salomon=
2M Companies, Inc.

4441 Buena Vista St = | Dallas, TX 75205

917.617.3766  =

 

= --_000_69CC32C3AD4CA84BBABA634B3EE3E589056F11C17CIMCMBX2MITREO_-- From Gabor.Bajko@nokia.com Mon Oct 24 14:42: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 DEDC111E817F for ; Mon, 24 Oct 2011 14:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8WFICQWRFvn for ; Mon, 24 Oct 2011 14:42:27 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3401D11E8165 for ; Mon, 24 Oct 2011 14:42:27 -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.4) with ESMTP id p9OLgQnT014864 for ; Tue, 25 Oct 2011 00:42:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 00:42:17 +0300 Received: from 008-AM1MMR1-008.mgdnok.nokia.com (65.54.30.24) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 24 Oct 2011 23:42:07 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.138]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0339.002; Mon, 24 Oct 2011 23:42:06 +0200 From: To: Thread-Topic: slot requests for the Taipei meeting Thread-Index: AcySlWJaOHtoMGzhSPeNxzQISKeofw== Date: Mon, 24 Oct 2011 21:42:05 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4761316F4@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: [10.162.89.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2011 21:42:17.0785 (UTC) FILETIME=[CD3A8A90:01CC9295] X-Nokia-AV: Clean Subject: [paws] slot requests for the Taipei meeting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:42:28 -0000 Everyone, The Taipei IETF meeting agenda has been published, see: https://datatracker= .ietf.org/meeting/82/agenda.txt PAWS got a 2.5 hour slot on Tuesday morning 9:00am to 11:30am. If you'd like to present, please send slot requests to the chairs. -gabor From gerald.chouinard@crc.ca Tue Oct 25 12:09: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 5142E21F8591 for ; Tue, 25 Oct 2011 12:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 R7Gv9T9EbRqI for ; Tue, 25 Oct 2011 12:09:20 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 4744321F85B5 for ; Tue, 25 Oct 2011 12:09:20 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 363426B042A; Tue, 25 Oct 2011 15:09:15 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 158896B03A6; Tue, 25 Oct 2011 15:09:15 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id 0724D6B03D2; Tue, 25 Oct 2011 15:09:15 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 2E26E6B03A6; Tue, 25 Oct 2011 15:09:13 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-02.rem.crc.ca [142.92.171.12]) by mailhub.crc.ca (Postfix) with ESMTP id A72BB6B18C8; Tue, 25 Oct 2011 15:09:12 -0400 (EDT) Message-Id: <5.1.0.14.2.20111025150353.01db3de8@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Oct 2011 15:09:10 -0400 To: From: Gerald Chouinard In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476131D86@008-AM1MPN1-007.mgd nok.nokia.com> References: <5.1.0.14.2.20111025111828.01ec9950@imap.crc.ca> <132C7B325F671542B8CA2F02A1FFAF1FCF3F4E3A@CRPMBOXPRD01.polycom.com> <3A42B187196E964C907ADE0AFA7C3B3602850A73@008-AM1MPN1-015.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D0141EE2E8D4@SC-VEXCH2.marvell.com> <132C7B325F671542B8CA2F02A1FFAF1FCF3F4E3A@CRPMBOXPRD01.polycom.com> <5.1.0.14.2.20111025111828.01ec9950@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, STDS-802-11-TGAF@LISTSERV.IEEE.ORG Subject: Re: [paws] [STDS-802-11-TGAF] About LCI format in .11af spec 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, 25 Oct 2011 19:09:22 -0000 Gabor, Wouldn't it be easier for the master WSD to simply forward the NMEA string that it would have obtained from the GPS device rather than having to re-format it? NMEA 0183 is more friendly with any geolocation technology than DHCP. Gerald At 18:55 25-10-11 +0000, Gabor.Bajko@nokia.com wrote: >I know it is rather confusing that this binary encoding of location was >defined as part of a dhcp option. It was done the same way in RFC3825 as >well. But 802.11 never intended to use the dhcp option code itself, only >the location encoding format. The same assumption applies to RFC6225 as >well, ie use only the binary encoding part of the location. This binary >encoding can be transmitted using any protocol, being that 802.11 frame, a >dhcp option field, or sg else. > >The document does use uncertainty, that is actually the major improvement >over the previous format (defined in rfc3825). Confidence even though it >is mentioned, it is not elaborated. I think it is assumed to be 95%, which >is an industry wide accepted value. > >-Gabor > > >-----Original Message----- >From: ext Gerald Chouinard [mailto:gerald.chouinard@crc.ca] >Sent: Tuesday, October 25, 2011 9:54 AM >To: Bajko Gabor (Nokia-CIC/SiliconValley); STDS-802-11-TGAF@LISTSERV.IEEE.ORG >Subject: Re: [STDS-802-11-TGAF] About LCI format in .11af spec > >Gabor, all, > >It should be pointed out that the IEEE 802.22 Standard contains primitives >for the database interface, as presented during the Quebec City meeting, >that propose to use the NMEA 0183 strings to document the geolocation of >the WSDs. Such strings are more in line with the various existing >geo-positioning technologies such as GPS (e.g., most GPS professional and >consumer devices output their data using NMEA strings. > >Using a DHCP-based protocol to provide the WSD geolocation seems to result >in a catch-22, that is a DHCP message can only be transmitted to a device >that is associated to a network while the geolocation of a WSD needs to be >provided to the database before the device can be considered associated to >the network so that the database can confirm which channels can be used by >this device before it starts to operate. This apparent conundrum needs to >be resolved somehow. > >Finally, the enhanced DHCP protocol described in RFC6225 does not contain >parameters such as the 'uncertainty' and the 'confidence level'. Although >the NMEA strings include some information that can be used to deduce this >information (e.g., number of satellites in view), the master WSD would >need to translate it into the required parameters which, in passing, may >be different from one regulatory domain to another. > >My 2-cents ... > >Gerald > > >At 14:59 25-10-11 +0000, Gabor Bajko wrote: > > >Yes, I brought up this LCI topic for discussion both in TGv and TGmb, a > >while ago. The conclusion was that even though LCI based on RFC3825 has > >known deficiencies, if used within 802.11, we can live with it. And > >since there was significant resistance to make the change, there was no > >motion brought to the floor. > > > > > > > >What is different now is that the location of the STA encoded in the > >802.11 L2, in some of the 11af use cases, will need to be converted by > >an AP to XML before sent to the DB. And there is no mathematical > >formula I know of, which can be used to convert an RFC3825 LCI or the > >11af defined extended location encoding into XML. The newly published > >RFC6225 is backward compatible with LCI as used in 802.11y, field wise, > >but the fields have different meaning and the encoding is different. > >And there is an easy formula on how to convert it to XML. > > > > > > > >Therefore, I felt it is time LCI as defined in RFC3825 is not > >propagated to new 802.11 amendments but rather the format defined in > RFC6225 is used. > > > > > > > >-Gabor > > > > > > > >From: *** 802.11 TGaf - TV White Spaces OperationTask Group *** > >[mailto:STDS-802-11-TGAF@ieee.org] On Behalf Of ext Hamilton, Mark > >Sent: Monday, October 24, 2011 1:52 PM > >To: STDS-802-11-TGAF@LISTSERV.IEEE.ORG > >Subject: Re: [STDS-802-11-TGAF] About LCI format in .11af spec > > > > > > > >Is the proposal being made here suggesting the TGaf needs a different > >LCI format, or that the base text s current LCI format be modified per > >the updated RFC? > > > > > > > >For those who didn t know, this has been discussed in TGmb (and TGv, I > >believe) for a while. Both groups decided to wait until the IETF had > >settled on a way forward, and then to evaluate what we thought. Along > >the way, comments have been made that the new format will be (is?) > >backward compatible with the RFC 3825 format. I gather from Paul s > >description that this can be the case, as RFC 6225 has specified > >multiple formats to superset RFC 3825. If the intent is to replace the > >baseline 802.11 LCI format with a new format, those discussions should > be given consideration. > > > > > > > >Mark > > > > > > > >From: *** 802.11 TGaf - TV White Spaces OperationTask Group *** > >[mailto:STDS-802-11-TGAF@ieee.org] On Behalf Of Paul Lambert > >Sent: Monday, October 24, 2011 1:52 PM > >To: STDS-802-11-TGAF@LISTSERV.IEEE.ORG > >Subject: Re: [STDS-802-11-TGAF] About LCI format in .11af spec > > > > > > > >Three formats are defined in RFC 6225, one of which is identical to the > >current format we ve used from RFC 3825. > > > > > > > >Uncertainty versus resolution look like just an improvement in naming. > >The Res field also has been carved up to include Version. > > > > > > > >Which specific RFC 6225 format are you proposing (I d assume Code 144 yes) ? > > > > > > > >Paul > > > > > > > > > correct binary LCI format so that it can be converted to XML format > > expected to be > > > > >used for device to GDB interface, e.g. by IETF PAWS protocol. > > > > > > > > > > > >Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > > > > > > > >From: *** 802.11 TGaf - TV White Spaces OperationTask Group *** > >[mailto:STDS-802-11-TGAF@ieee.org] On Behalf Of Padam Kafle > >Sent: Monday, October 24, 2011 10:49 AM > >To: STDS-802-11-TGAF@LISTSERV.IEEE.ORG > >Subject: [STDS-802-11-TGAF] About LCI format in .11af spec > > > > > > > >Hi All, > > > > > > > >I would like to bring to the attention of this group about the use of > >location information in .11af. In my opinion, the format for device > >location information in .11af specification needs to be fixed. We have > >been referring to RFC 3825 for LCI format, which has already been > >obsoleted by a new RFC 6225. One problem with this is the LCI format > >used currently in .11af is not current, and not likely to be adopted > >industry wise. The encoding has been revised by the new RFC 6225 (see > >http://tools.ietf.org/html/rfc6225 ). > > > > > > > >I think TGaf should revise the current device location information and > >device position information IEs to align with the RFC 6225 instead of > >referring to RFC 3825. The main difference is use of uncertainty > >instead of resolution for latitude, longitude and altitude, the length > >of the fields are otherwise same. One important reason is that we need > >to use correct binary LCI format so that it can be converted to XML > >format expected to be used for device to GDB interface, e.g. by IETF > PAWS protocol. > > > > > > > >Please have a look to the RFC from the referred link. If there is time, > >we can discuss this issue briefly in the TGaf telco tomorrow. I will be > >uploading the proposed text (11-11-1402r0) before the call. > > > > > > > >Regards, > > > > > > > >Padam Kafle > > > >Nokia > > > > > > > >From: *** 802.11 TGaf - TV White Spaces OperationTask Group *** > >[mailto:STDS-802-11-TGAF@ieee.org] On Behalf Of ext Richard Kennedy > >Sent: Monday, October 17, 2011 9:31 PM > >To: > >STDS-802-11-TGAF@LISTSERV.IE > >EE.ORG > >Subject: [STDS-802-11-TGAF] FW: Tuesday's Teleconference > > > > > > > > > > > > > > > >Rich Kennedy > > > >Standards Manager > > > >Research In Motion Corporation > > > >mobile: +1 (972) 207-3554 > > > >office: +1 (972) 910-3448 > > > >rikennedy@rim.com > > > > > > > >IEEE 802.11 TGaf Chair > > > >IEEE 802.11 to 802.18 Liaison > > > >IEEE 802.11 Regulatory Standing Committee Chair > > > >Wi-Fi Alliance Spectrum & Regulatory Task Group Chair > > > > > > > >From: Richard Kennedy > >Sent: Tuesday, October 18, 2011 10:26 AM > >To: 'STDS-IEEE-802-11-TGAF@LISTSERV.IEEE.ORG' > >Subject: Tuesday's Teleconference > > > > > > > >All: > > > > > > > >I have just uploaded a teleconference plan and agenda for the call at: > > leconference-plan-and-agenda.ppt>https://mentor.ieee.org/802.11/dcn/11/11-11-1381-00-00af-october-18th-teleconference-plan-and-agenda.ppt. > > > > > > > >I am in Taipei for the Wi-Fi Alliance meeting, so Peter will act as > >Chair for this session. Time is running out for comment resolutions if > >we intend to finish in November. Please get the resolutions done and > >provide inputs to the remaining teleconferences. > > > > > > > >Teleconference details: > > > >Topic: 11af > >Date: Every Tuesday, from Tuesday, October 4, 2011 to Tuesday, November > >22, 2011 > >Time: 6:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting > >Number: 207 473 454 Meeting Password: 11af > > > > > >------------------------------------------------------- > >To join the online meeting (Now from mobile devices!) > >------------------------------------------------------- > >1. Go to > >7 > 92&PW=NZTgyYmE4OThl&RT=MiM0>https://ciscosales.webex.com/ciscosales/j. > >php?ED=175158422&UID=1630286792&PW=NZTgyYmE4OThl&RT=MiM0 > > > >2. Enter your name and email address. > >3. Enter the meeting password: 11af > >4. Click "Join Now". > > > >To view in other time zones or languages, please click the link: > >7 > 92&PW=NZTgyYmE4OThl&ORT=MiM0>https://ciscosales.webex.com/ciscosales/j > >.php?ED=175158422&UID=1630286792&PW=NZTgyYmE4OThl&ORT=MiM0 > > > > > >---------------------------------------------------------------- > >ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > >---------------------------------------------------------------- > > > >The affected toll free numbers are: (866) 432-9903 for the San > >Jose/Milpitas area and (866) 349-3520 for the RTP area. > > > >Please dial the local access number for your area from the list below: > >- San Jose/Milpitas (408) area: 525-6800 > >- RTP (919) area: 392-3330 > > > >------------------------------------------------------- > >To join the teleconference only > >------------------------------------------------------- > >1. Dial into Cisco WebEx (view all Global Access Numbers at > >ht > >tp://cisco.com/en/US/about/doing_business/conferencing/index.html > > > >2. Follow the prompts to enter the Meeting Number (listed above) or > >Access Code followed by the # sign. > > > >San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > > >US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > > >India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > > >Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > > >------------------------------------------------------- > >For assistance > >------------------------------------------------------- > >1. Go to > >https://ciscosales.webex.co > >m/ciscosales/mc > > > >2. On the left navigation bar, click "Support". > > > >You can contact me at: > >pecclesi@cisco.com > >1-408-527 0815 > > > >To add this meeting to your calendar program (for example Microsoft > >Outlook), click this link: > >7 > 92&ICS=MI&LD=1&RD=2&ST=1&SHA2=jDwVsaHy/ACC2OzP5RIU8ktKab3T8gKl5fA6i3r0 > >CRY=&RT=MiM0>https://ciscosales.webex.com/ciscosales/j.php?ED=175158422 > >&UID=1630286792&ICS=MI&LD=1&RD=2&ST=1&SHA2=jDwVsaHy/ACC2OzP5RIU8ktKab3T > >8gKl5fA6i3r0CRY=&RT=MiM0 > > > > > >The playback of UCF (Universal Communications Format) rich media files > >requires appropriate players. To view this type of rich media files in > >the meeting, please check whether you have the players installed on > >your computer by going to > >https://ci > >scosales.webex.com/ciscosales/systemdiagnosis.php > > > > > >Sign up for a free trial of WebEx > >http://www.webex.com/go/mcemfree > >trial > > > >http://www.webex.com > > > >CCP:+14085256800x207473454# > > > >IMPORTANT NOTICE: This WebEx service includes a feature that allows > >audio and any documents and other materials exchanged or viewed during > >the session to be recorded. By joining this session, you automatically > >consent to such recordings. If you do not consent to the recording, > >discuss your concerns with the meeting host prior to the start of the > >recording or do not join the session. Please note that any such > >recordings may be subject to discovery in the event of litigation. > > > > > > > > > > > >Thank you. > > > > > > > >Rich Kennedy > > > >Standards Manager > > > >Research In Motion Corporation > > > >mobile: +1 (972) 207-3554 > > > >office: +1 (972) 910-3448 > > > >rikennedy@rim.com > > > > > > > >IEEE 802.11 TGaf Chair > > > >IEEE 802.11 to 802.18 Liaison > > > >IEEE 802.11 Regulatory Standing Committee Chair > > > >Wi-Fi Alliance Spectrum & Regulatory Task Group Chair > > > > From scott.probasco@nokia.com Tue Oct 25 13:38: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 6804821F8BA7 for ; Tue, 25 Oct 2011 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoG95Z5Bi8Ng for ; Tue, 25 Oct 2011 13:38:43 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD421F8B9B for ; Tue, 25 Oct 2011 13:38:42 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9PKccYi010396; Tue, 25 Oct 2011 23:38:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 23:38:37 +0300 Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 25 Oct 2011 22:38:37 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.151]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Tue, 25 Oct 2011 22:38:37 +0200 From: To: , Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyMqaywLGptZ9r7QaW3AHrkv+e5BAGcbgGA Date: Tue, 25 Oct 2011 20:38:36 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140491FE3ED@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.243.0.17] Content-Type: multipart/alternative; boundary="_000_CACC7B4BBA4Dscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2011 20:38:37.0774 (UTC) FILETIME=[12BCDEE0:01CC9356] X-Nokia-AV: Clean Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 20:38:44 -0000 --_000_CACC7B4BBA4Dscottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case= =85" which might mistakenly imply some preference to this solution, and not= e this to be an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2=85" [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_CACC7B4BBA4Dscottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <64F60F09D1028C4491E59266D9470623@nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Andy, Mike & Juan Carlos,

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

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

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

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

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

[Step 6]
6. The slave devices fitted to the machines scan the TV bands to locat= e the master transmissions, and associate with the master device. Furt= her signaling can take place outside  scope of PAWS to establish direc= t links among those slave devices that have associated with the master device.

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

Regards,
Scott


Hi Scott, all
 
I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-= cases-and-requirements-00.txt proposes revision of the datab= ase discovery use case, two new use cases for indoor networking and machine= to machine communications, and a set of requirements that drop out of all the use cases included so far in = the working document. These especially address the UK Ofcom requirements as= currently known. Also, a definition is proposed for the term =91device ID= =92 which we suggest should be used throughout the use cases and requirements for consistency in place of terms such as = =91model ID=92 and =91FCC ID=92. This Internet Draft is a joint submission = from Mike Fitch (BT), Andy Sago (BT) and Juan Carlos Zuniga (Interdigital).= We would welcome comments made to the reflector on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document.
 
Regards
 
Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital)
 
 
 
 
--_000_CACC7B4BBA4Dscottprobasconokiacom_-- From scott.probasco@nokia.com Tue Oct 25 13:42: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 C589921F8C10 for ; Tue, 25 Oct 2011 13:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 wrmz0TXN2pcn for ; Tue, 25 Oct 2011 13:42:01 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 81B4721F8C0E for ; Tue, 25 Oct 2011 13:42:01 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9PKfvl3013714; Tue, 25 Oct 2011 23:41:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 23:41:56 +0300 Received: from 008-AM1MMR1-008.mgdnok.nokia.com (65.54.30.24) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 25 Oct 2011 22:41:56 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.151]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0339.002; Tue, 25 Oct 2011 22:41:55 +0200 From: To: , , Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AQHMjlLCqLCdMsHVWUiUyIrbzY+HgpWNGxEA Date: Tue, 25 Oct 2011 20:41:56 +0000 Message-ID: In-Reply-To: <9983D74B649EED43B27BF353837B20C54EDF3237@WOK-INTRA-EXC01.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.243.0.17] Content-Type: multipart/alternative; boundary="_000_CACC7BBFBA51scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2011 20:41:56.0926 (UTC) FILETIME=[89710DE0:01CC9356] X-Nokia-AV: Clean Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 20:42:02 -0000 --_000_CACC7BBFBA51scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Andy, Thank you for commenting to the authors and participation in the developmen= t of the PAWS specifications. Your input is appreciated and will help ensur= e PAWS may be deployed on a global scale. I look forward to a formal update= from Ofcom in the near future. Kind Regards, Scott From: ext Andrew Gowans > Date: Wed, 19 Oct 2011 10:44:07 +0000 To: "andy.sago@bt.com" >, "paws@ietf.org" >, Database Device > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Scott, all, Although I am not a co-signatory of this document, myself and colleagues fr= om Ofcom have made comments to the authors of this submission during the dr= afting process. As we in Ofcom are still in the process of confirming the d= etails of our proposed requirements for the interaction between the WSD and= the Geo-location Databases we felt it was not right at this time for us to= be co-signatory on this document as some of our requirements may vary slig= htly from those presented in the document after our final analysis is compl= eted. I am hoping that myself or a colleague will be in a position to provi= de a formal update of our progress on the proposed requirements to the IETF= PAWS group in the near future. Best Regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of andy.sago@bt.com Sent: 17 October 2011 09:50 To: paws@ietf.org; scott.probasco@nokia.com Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_CACC7BBFBA51scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Andy,

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

Kind Regards,
Scott

From: ext Andrew Gowans <Andrew.Gowans@ofcom.org.uk> Date: Wed, 19 Oct 2011 10:44:07 = 3;0000
To: "andy.sago@bt.com" <andy.sago@bt.com>, "paws@ie= tf.org" <paws@ietf.org>= , Database Device <scott.prob= asco@nokia.com>
Subject: RE: [paws] New indoor and = M2M use cases, revision of DB discovery use case

Hi Scott, all,

 

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

 

Best Regards

 

Andy Gowans 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com
Sent: 17 October 2011 09:50
To: paws@ietf.org; scott.probasco@nokia.com
Subject: [paws] New indoor and M2M use cases, revision of DB discove= ry use case

 

H= i Scott, all

 

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

&= nbsp;

R= egards

&= nbsp;

A= ndy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital)

 

 

 

 



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

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

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

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

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_CACC7BBFBA51scottprobasconokiacom_-- From apurva.mody@baesystems.com Fri Oct 28 13:05:03 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 7D2721F0C34 for ; Fri, 28 Oct 2011 13:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 jR7nge43sWEm for ; Fri, 28 Oct 2011 13:05:03 -0700 (PDT) Received: from dmzms99801.na.baesystems.com (dmzms99801.na.baesystems.com [149.32.232.65]) by ietfa.amsl.com (Postfix) with ESMTP id 64AD611E8089 for ; Fri, 28 Oct 2011 13:05:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="pdf'?scan'208";a="201729617" X-IronPort-AV: E=Sophos;i="4.69,420,1315180800"; d="pdf'?scan'208";a="135092894" From: "Mody, Apurva (US SSA)" To: "paws@ietf.org" Date: Fri, 28 Oct 2011 16:04:54 -0400 Thread-Topic: IEEE 802.22 Feedback on PAWS Requirements Thread-Index: AcyJLY8H0bjED5cjTgqFaAdMmKqbFwMd1rLQ In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47612DACE@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_DA677CE046E02E42991EB3154C5E54060C0AF540BFGLDMS60322gol_" MIME-Version: 1.0 Message-Id: <20111028200501.64AD611E8089@ietfa.amsl.com> Subject: [paws] IEEE 802.22 Feedback on 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, 28 Oct 2011 20:05:03 -0000 --_002_DA677CE046E02E42991EB3154C5E54060C0AF540BFGLDMS60322gol_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Dear Gabor and All the PAWS members, Greetings. The IEEE 802.22 Working Group has been discussing the requirements for the = IETF PAWS and here is our feedback which can be found at the following URL. https://mentor.ieee.org/802.22/dcn/11/22-11-0127-06-0000-ieee-802-22-inputs= -to-ietf-paws.doc The pdf version of the document has been attached to this e-mail, and for c= onvenience, I am also putting this in a text format below: Requirements D. Data Model Requirements: [AMENDED] D.1: The Data Model MUST support specifying the Following Paramet= ersantenna height parameter of the subject * Antenna Parameters (Master WSD =3D> database) * Height Parameters o mandatory AGL in meters: Unsigned INT, 2 Bytes (0 - 65,535 cm) Example of the Primitive Field: Antenna Height Type: Integer Length: 1 Byte Description: Antenna height above ground level in meters [Note: portable is defined as 1.5 m and base stations in Canada can be at u= p to 500 m HAAT which could be completely contributed by the antenna AGL (e= .g., mounted on a broadcast tower). Two bytes are therefore necessary.] [Note: our assumption is that the database will compute the HAAT in meters = from the antenna AGL and ground elevation at the specified location (lat, l= ong) obtained from a topographic database by the database server.] * Gain Parameters o Antenna directionality information in dB: relative to the main lobe= maximum gain for every 5 degree azimuth clockwise starting from the direct= ion of the maximum antenna gain expressed in unit of 0.25 dB over the range= -63.75 dB (encoded 0x00) to 0 dB (0xFF): Character String of 72 bytes o Antenna azimuth in degrees, clockwise from true North: 2 bytes INT Example of the 802.22 Prmitive Field: Antenna Information: Type: Character String Length: 72 Bytes Description: Antenna directionality information of the device in dB relativ= e to the main lobe maximum gain for every 5 degree azimuth clockwise starti= ng from the direction of the maximum antenna gain expressed in unit of 0.25= dB over the range -63.75 dB (encoded 0x00) to 0 dB (0xFF). (to allow the d= atabase calculation of the channel availability and the maximum allowed EIR= P values at the registering location19) Field: Antenna Azimuth Type: Integer Length: 2 Bytes Description: Antenna azimuth in degrees clockwise from true North * RF Mask Parameters (Master WSD =3D> database) o Regulatory Domain (3 ASCII Letters), Device Type (Regulatory Class:= e. g., Fixed, Personal/Portable, Mobile, etc.) (1 byte INT), Mask Number I= ndex (2 byte INT) (where Mask Number Index corresponds to a particular RF M= ask of an equipment that is stored in the database and that has passed the = regulatory certification). Example: 802.22 primitive: Example of IEEE 802.22 Primitive Field: Device Type Type: Integer Length: 1 Byte Description: The value identifies the type of device at the geolocation reg= istering 0x00 =3D Fixed base station 0x01 =3D Fixed CPE 0x02 =3D Personal/portable mode 0x03-0xFF =3D Reserved [AMENDED] D.2: The data model MUST support specifying an ID of the subject.= This ID would becontain the ID of the device used to bethat has been certi= fied by a regulatory body for a its regulatory domain as well as an identif= ication of the technology that is being used. (Master WSD =3D> database) Example of IEEE 802.22 Primitive: Field: Device Type Type: Integer Length: 1 Byte Description: The value identifies the type of device at the geolocation reg= istering 0x00 =3D Fixed base station 0x01 =3D Fixed CPE 0x02 =3D Personal/portable mode 0x03-0xFF =3D Reserved Field: Device-ID Length Type: Integer Length: 2 Bytes Description: Length of Device-ID field (# of characters) Field: Device ID Type: Character String Length: Variable Description: In US, this is FCC-ID Field: Serial Number Length Type: Integer Length: 2 Bytes Description: Length of Serial Number field (# of characters) Field: Serial Number Type: Character String Length: Variable Description: Serial Number of the Device Note: The device-ID and Serial Number could be replaced by a universal iden= tifier made of one or many parts . The master WSD must also specify, as pa= rt of its registration process with the database, the technology that it us= es (e.g., IEEE 802.22, IEEE 802.11af, etc.) (see requirement O.7). [AMENDED] D.3: The Data Model MUST support specifying the location of the s= ubjectWSD, the uncertainty in meters and confidence in percentage and accur= acy of for the location determination. (Master WSD =3D> database) Field: Location Data String Length Type: Integer Length: 2 Bytes Description: Length of Location Data String field (# of characters) Field: Location Data String Type: Character String Length: NMEA 0183 Character String Description: The value identifies the location of the device (latitude, lon= gitude).20 Note: NMEA 0183 $GPGGA or $GPGLL String can carry latitude and longitude in= formation. In the work of the IEEE 802.22 Working Group, it was assumed tha= t the altitude of a geographic point would be derived at the database based= on the latitude and longitude of the location of the WSD (see the note rel= ated to HAAT in D.1 above for which ground elevation information would need= to be known). In 802.22 networks, the CPEs acquire their geolocation and t= ransmit their latitude and longitude to the base station at the time of ass= ociation. The base station would augment the location information defined i= n the NMEA string format with uncertainty (m) and confidence level (%) as t= he local regulator may want to define it. These uncertainty and confidence= values would be generated at the base station based, for example, on the t= echnology used by the WSDs to acquire their geolocation. The uncertainty c= ould also be artificially increased to take into account the size of the ar= ea around a WSD where other WSD's not requiring geolocation (e.g., Mode I d= evices in the USA) would operate. [AMENDED] D.4: The Data Model MUST support specifying a list of available c= hannel along with the maximum EIRP (dBm) that can be accommodated list and = time constraints for the channel list availability. (Database =3D> Master W= SD) Field: Number of Channels Available Type: Integer Length: 1 Byte Description: Number of TVWS Channels that are available {If( Number of Channels Available > 0) For (i=3D1; i=98 Number of Channels Available; i++) Field: Max_EIRP and Channel Availability Schedule for Each Channel Type: Vector of 2xN bytes and a number of pairs of NMEA 0183 $ZDA strings Length: Variable Description: List of available channel numbers and corresponding maximum al= lowed EIRP expressed in dBm over the range -64 dBm (encoded 0x00) to +63.5 = dBm (encoded 0xFF) as well as the availability schedule (start and stop dat= e/time) for each channel in Universal date and time system. } } D.5: The Data Model MUST support specifying the maximum output power of the subject. (See D.4 above. Also, specifying the "maximum output power" is= not sufficient since it may or may not include the antenna gain. Specifyin= g the EIRP is needed. D.5 should be deleted since it is proposed to be cove= red in D.4.) [AMENDED] D.6: The Data Model MUST support specifying channel availability = information for single and multiple locations. The database MUST also allow= a master device to act as a proxy for other WSDs and query on their behalf= . (Master WSD =3D> Database) In case of 802.22 systems which are to provide point-to-multipoint broadban= d access service primarily to rural areas, the BS acts as a proxy for all i= ts associated CPEs and queries the database for each device. If a query is = to be grouped or made in a batch mode, all the information related to each = device shall be provided to the BS (i.e., the database is not to perform th= e intersection for all these devices and locations). [Note: This option may be useful to 'batch' the database query process but = it is not clear whether this would really increase the data transfer effici= ency. In the case of the 802.22 WRAN systems, the base station will need to= acquire all the information about the available channels for each of these= CPEs (and the related maximum EIRP's) so that the operating channel and th= e backup channels (to which the WRAN cell will need to move if the current = operating channel becomes unavailable to ensure a transparent channel move)= can be determined locally from the best 'intersection' of these channels f= or all the associated CPEs. This will allow database queries for only new = CPEs coming on board or being moved, and constraints to be added locally at= the base station to execute the 'intersection' process to produce the upda= ted list of operational and backup channels that is to be transmitted to al= l CPEs for refreshing. [DISAGREE] D.7: The Data Model MUST support specifying channel availability information for an area around a specified location. (Database =3D> Master = WSD) In our opinion, this can be done through the normal query process if a quer= y to the database can be done with dummy device IDs, for example for planni= ng purposes, and hence, we feel that this is not really needed. If a query = is done to the database with dummy device ID, the database should not regis= ter these new devices and only provide the list of available channels. Ther= e should therefore be a need to identify whether the included device ID is = a real one or not. [NEW] D.8: The Data Model should support reporting to the database the chan= nels that the master WSD has selected as the operating channel and the back= up channels (see requirement O.7). P. Protocol Requirements: [AGREE] P.1: The protocol MUST provide a mechanism for the subject to disco= ver the WS Database it has to use at a given location. [AGREE] P.2: The protocol MUST support regulatory domain discovery. [AGREE] P.3: The protocol between the master device and the WS Database MUS= T support the ability for the database to pushing updates in on channel avail= ability changes to subjects. [AGREE] P.4: The protocol between the master device and the WS Database MUS= T support mutual authentication and authorization. [AGREE] P.5: The protocol between the master device and the WS Database MUS= T support integrity and confidentiality protection. [AGREE]P.6: The protocol MUST support both username/password and digital certificates based authentication. [NEW] P.7: The protocol MUST require the master WSD to maintain contact wit= h the database as specified by the local regulator as well as to specify an= d re-register its operating and backup channels with at least the same peri= odicity. O. Operational Requirements: [AMENDED] O.1: A master device MUST query the WS Database for the available channels as often as required by the regulation (e.g., FCC requires once per day) to verify that the operating channels, and backup channels in the = case of providing transparent switch-over, continue to remain available. [AMENDED] O.2: A master device MUST determine its location with the accurac= yalong with its uncertainty (e.g., FCC requires +/- 50m) and confidence lev= el (e.g., 95%) and send it to the database so that the proper WSD position = and buffer distance around the device can be added to make sure that the wo= rst case situation required by the regulation (e.g., FCC requires +/- ) is = considered in the distance calculations taking place at before placing aque= ry to the DB. [AMENDED] O.3: A master device which changes its location during its opera= tion, MUST query the WS Database for available operating channels each time it moves more than the distance specified by the regulation (e.g., FCC spec= ifies 100 m) from the location it occupied when it previously made the quer= y from. [AMENDED] O.4: The WS Database MUST provide the available channel list and = the maximum EIRP corresponding to each channel when requested and MAY also = provide time constraints for the each channel in the available list and max= imum output power to the master device. [AMENDED] O.5: A master device MUST be able to query the WS Database for it= self as well as for its and include the FCC ID of the slave associated devi= ces and compile the channel availability (and maximum EIRP thereof) so that= a common channel can be selected for use by all these WSDs to form a netw= ork. Furthermore, common channels may also need to be selected in a similar= way to become backup channels to allow for network channel switch that wou= ld be transparent to the users in the query before allowing the slave devic= e to use the available channel. [AMENDED] O.6: A master device MUST be capable to of validateing the digita= l certificate of the WS Database and whether it has been revoked or not. O.7: A master device MUST be capable to check the validity of the WS Database certificate and whether it has been revoked or not.[Repeat, see O.= 6] [NEW] O.7: The database must be capable of keeping track of the channels th= at are currently being utilized by the master devices and the technology th= at they use (e.g., IEEE 802.22, IEEE 802.11af, etc.). If a request for the available channel is made by another master WSD from t= he same area and it is found that the new requesting master device technolo= gy cannot co-exist, then that channel should be removed from the available = channels list going to this new device. Unless the given master WSD fails = to re-query within the specified contact period, the database should make t= hat channel available. Accordingly, the protocol should provide the master = WSDs with a means to release their operating channel when not needed. Note that without an active channel management mechanism (e.g., 802.22 spec= trum manager), it is unlikely that having the database just specifying whic= h channels are available to protect incumbent services on a 24 hours cycle = will be sufficient to allow for proper operation of multiple WSDs in an are= a without interference being caused among themselves. Without area specific= centralized spectrum management that directs and juggles master WSD channe= l assignments virtually instantaneously, the result will be inefficient use= of White Space spectrum. Apurva N. Mody, Ph. D. Chair, IEEE 802.22 Standard Working Group Mobile: (404)-819-0314 E-mail: apurva.mody@ieee.org -----Original Message----- From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Wednesday, October 12, 2011 6:17 PM To: paws@ietf.org Subject: Re: [paws] Requirements I forwarded the below initial list of requirements to the list a while ago,= but there was no discussions on them. We got today a set of additional requirements from the 802.11af folks (see = http://www.ietf.org/mail-archive/web/paws/current/msg00434.html). If there = are no objections, I'd like to ask the Editor to include both these set of = requirements to the new version of draft-ietf-paws-problem-stmt-usecases-rq= mts-00. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Friday, September 09, 2011 12:55 PM To: paws@ietf.org Subject: [paws] Requirements 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 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 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 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 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 and rqmts Author(s) : Scott Probasco Gabor Bajko Basavaraj Patil Brian Rosen Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-00.tx= t 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 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_002_DA677CE046E02E42991EB3154C5E54060C0AF540BFGLDMS60322gol_ Content-Type: application/pdf; name="22-11-0127-06-0000-ieee-802-22-inputs-to-ietf-paws.pdf" Content-Description: 22-11-0127-06-0000-ieee-802-22-inputs-to-ietf-paws.pdf Content-Disposition: attachment; filename="22-11-0127-06-0000-ieee-802-22-inputs-to-ietf-paws.pdf"; size=252400; creation-date="Fri, 28 Oct 2011 19:23:38 GMT"; modification-date="Fri, 28 Oct 2011 19:23:38 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDUxIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDYvS2lkc1sgMyAwIFIgMjEg MCBSIDQyIDAgUiA0NCAwIFIgNDYgMCBSIDQ4IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwv VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgNyAw IFIvRjMgMTEgMCBSL0Y0IDEzIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMv SW1hZ2VJXSA+Pi9Bbm5vdHNbIDkgMCBSIDEwIDAgUiAxOCAwIFIgMTkgMCBSIDIwIDAgUl0gL01l ZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVu ZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NzQzPj4NCnN0cmVh bQ0KeJy9Xd1z27ayf89M/gfOfZLORDQBAgTZyXhqp05Pek5Sn8b39qE9D7Kt2DqVJVeW08n96+/u 4oPgB0Daku906kjkcnexWOz+sACoo5PtbvllfrVL3r49Otnt5le3i+vkt6OLzf2/jy6+3S+Ozuc3 y/V8t9ysj4+T0x/eJacXr18dvWcJE2kmkosvr1+xJIP/WCJFoqRKc55c3L1+lSU3+OfH169+m/x8 tdtMZ2JyOa0mi23Cp8Ukm4oJm85y+PPv5OKn16/OgC/yttxYLtImx98mSYCWl2WayXG0uapS1qK9 3qAmV+l3yTSffADNzs7O8GMJH1FRjrdTVJsHuIpSpYI3uc5CtBVLq7JJy6w5joxI+sLhg8IP22kZ NJSULGUtQxVB2jJlYTv9iT02y9KsKrKsTArGUwaNquCfZLt4/erXvyVr07OSp7IATgz/kVmBLcpS xYnuy99ev/rX61fJ2cd3yVHAxU43u93mLu5lPAHxLRfj4BboeKT8ZzTO4+XdEv99eKB/NuuQRzFo WdFkEPQoxVPOmrT3c+iOmwX8CT5VqVSp5lOhbsuzPC2rcdqIjKdFi+/J/eN2KidfUankU5p83FxP Z6ycfJvybPImmc6qyelUTU7OEjASy/T1B/q4W9w9RB0kqNSTHSQv0rwUvoNkWd7xkeToHL3j47sP PyTZ0T/n65tksljPfjydDgYdXgga+lymTuMP6AZmCJ+DecYP41xAIFFNbsHOLrK0qBKVlWlVGNpf yQO3CxiuK/yEHx7IN/FP8guIPgFFPsH/oR7IYUjlrMl2ry4oqhJtHxujwLMo0rIQSQH9D3FMqDLN wTnBGqXH1e8n1tdPYxk1hqXKUwUNKRTG+3YPMg7dB1/a/WfNufjzEZLK0gbJxR0+sVjvtMG/bLYJ xfOL9zBWknNj/18/ewb9F9n0yWqLvMR+aqidNNn2uTc3lqIOKvToKMoildAzotR/bPcM3yaV6bbR uEEghUx54T2fgVM/kcLqoO1Ct2qr+CxqAuTRpGk7GaR2z8h5KnnAyfIBJ4syskGjooHUiBmga5UU gqeVqMHKb5Mf5tNZMdnRyP0u6CIjhPIeoZD1y65QsBgExIsrcJ7k4BJhxOc9zdT4ayYRZMhGgjqE 2JyBWNUjdnZoQTzDHN1n0YIsyrJDS8xBYp/jHLxpOVDKSNO43Ediz5jIBVB2jTkqpgkzMF2sUMgj HLD0/VjEqjkEA5Jupg5IrpE+j5qAAlKDph2QOPdsxlg4IMmBgBRlFDQ+gM2M49MiVb7tTx4hFvHJ LU1Ptr9PcLg+AKj5fYoXwhHqeVowpkCNrhYjPKBoeQC4b9QD9P2YB9Qcgh6gW0m36jb6PGoC5NGk aXsAzA2AtqrSvIg6gBpwgBifsOUzgQMbsVzD8p/mBOnvphyATrC3nyeSV9TZbZGBzgZxDOVxK65A NCmipioDphrFKKw4zN/zrt7vNsZUTOBEDYbH+lvHYvtJ5pBvMLGNNxmHGIT5QstjAIqKuHdVAZON YhRWvGQwXegqfnJ9vV0AUC4bkxFtqv0kIgZgPb0UNlVe5KnIXdcohI8xS7HeeeJIRmG9S0gTPZY6 r8PwujsQ9xIp4Cn+JFMJQCFV3TUwJ+Zxr2KhudooTmHNFc4aOoovYCDmOmbNMWEtVx2D7SkXQp0q R1usYQneSlScxROVvg8C2wQYSvIGgyxjXRKMNprERJsGBYcsV7IoEzsONYkZhw2KvADIJqNMrIMa TchBGwTYITKuiO0zo4jus97U7TMJpG7d8T2p25q1JkBFmjTWajEaa5QYjW10jMa2yacZgBKyKsdB CTYwu40yCk4dSsBUAiyYZS0gfzJlbHIPg1NNHmECuMVg9hU+zBMszX/cYB64ptvdxLmXRkwAoOzT aBBrGHkjsAYTcbAR5xRWHcvAvEf10+lMaYueYWpI8M9nrLl+A4siRN9hGOQQBlVPct1PKc5pteMp 9jRRxAgcAURYaKIzilNYdWhrUfWo/nGhK3j2z5IK1YDmqsn8Ci/8AXZ940z96e8hwPJMxXBmL/Mn 2dQEVduJw4iliCOWKKOw4kVJiKWleF0pKLI8BFieKREwkmI9puoWQfaUU1AID7aszKrDSsRllky9 fMtEJql03JFDRTmBfyS4+6FbxyUBzSe4uMn5dkyFkObn+/m6dvPQDHkUM6t92V7nETLDJbAiY7bc rq9vb+ynX2ipmaZ+91PMcTNMchJynNJXU/xzt5lWmOYKXBDjk+9NsJEAWyGY13+IeAOPIoubpoVq yU6rDFGLEmlFiAeyYwMcNMJAaFq8n30k9K4sm/YZjYqrFirOqjgq1vcjqLhmEETFmiSGiiNMLCrW JDFUHGFiUbHRJIyKIzwsKjaKRFCxz6QfFZueD6NijyCIiqM0xihRGtPoKI1pU4NmCBVDNB+Finlo Yj+GURgVwzilh8tW8PtxscVgMF9RTAguwTxPKtPThq7Ud1MxuYUQv8HIg2hc4501wvEtXrs+sCK4 FNzX/GEIruWNgOA8VGUYxSmsepWlLGDCXxCFvwvC6+cJ5NBpTD3JVhZ7aoEj4DXnA/A6yimsuihx xa+r+s+73ZzmI39hbpu/wRkfAemf15DeduhzYrKkPVo1yEYLz6mYQ355jcaeB3H38zTGDRd5X/cO 427Tu4O4m4em2WMYDeHutuIe7mZh3P08iRp3d00VRqfPlEO4O9yyqioPK9Hg7hdvmcHdXTlcQ274 k9HS+GGlatz9FBe3UNCMqeEKLw+VP0ZxCoNu3A6FqlctUHkTKuk+V5Bk+um2IMLiCMEJwa8sdid0 TnWBW/y6IbyvNJBfW7yPj13Dl+8dMV65cuiePnUD2n4tkRAAOe9pyZi9QbKJw2UVX0g398M43GMQ wuGGJILDY0xc0UUN4PAYEzerVXEcHuPhJk9qAIc3mARwuO75CA6vCcI4PEZjjRKjsY2O0dg2+TRD OBxFG/jIc/TeQEQJVatG8AmjcBwU8KxiKSv9wfELQo01AowbV5HGawsCHUNV6eeowkSOvtpVZRgR kzgzYKImDFVCxjCK4GGO2727in9erL4EofCzRPEMYpl8ko1sQCB5Jh5EbWSrIcvd7MNFDxCOMYrg 4AKruVIVrZQrdI63fwjm/rDQuSX5J7reH+h15H8/aFCM5aOFBcxMuGUUgM3d2eKeWuf6YYmjuQ1P aMWhBuekBi40XNopJKjLJIwSVmqKc1yO0LPJVvH8J1zqoY9kBeX+sNbW6AM0KpcQDvOeRg0DfO2z lA6iLhTaNDGCzyC8b7l+DYJV3jXUXgINuu+MtTAGfp4YDe6D7Sqq8LTlOQIttn/hdllo3xFDqL4M O/deQg2yf0J8tDhFjyUNU7rO3Sio56GC2BheEcTNrYOrMlJPd9h7jUD7plFLx3sE0BFlt2rqd3Aj 93A6QvS7cBndKJNhDVvhAsVQGT0f2NPyPKtI3CYqmlYZi97z1t4SWco4etf3I+i9ZhBE75okht4j TFzpRg6h9wgTNzeWA+g9wsNNueQQeveZBNA7dbzdF2y63bequ49qNEmszSIk1iIREtvgCIltjkci WiRt3J4DdrYgF54KnpgY2lQS4RPG7fo8mBQKPcQbFoQkFoQxqJRNC/YaPtGt1IGOf8xXBK2CIP45 ejFRpqpHrWEMT9IsHo6Zc2hfSYxRtKbdpzdWXAnndc8n7SWPZxVuu3iKoWxsIHkW9MUMNbRhJMYo AokrPFApAUQ20SNzFTtul8u5Q/Q/bjAXwWyo0t//Z6n3JP415XnPEs9eGuZAyfIeDc30gdZ1cJuV nUMcVDoXLC3wWCyDOOIJ//uc5iq4GQl3INWzgMXuDR2MI7PQigBNJOg7d/Mism6Bfypn1P/+fHJg y0lJYbKt+/DEQI8BjdViLjm04SbCJ6w1HqpiTxpKNrtpKxlEEtN7aAdFjFEY8BWMJmK44NKANv/R vqHqEusfOHwI2D1swWcIz9HNHdzcIXmKN9eObBcsoj5LVQn0fZqOAWFlC4QV9SGRXhCm70dAWMH9 +lsvCNMkMRAWYeLNruv1s14QFmHizWLcAkUvCIvw8IBzXffuBWFF41xNLwijftcgzPW6b1V3n7BR g8TaLEJiLRIhsQ2OkNjmeCSiRdIGYVw5kMJYGqpI5KGKxDCb2LZehRCMV81o+Wm+ntIUC/JbXfsh EEEbKedfp8LtLghhr2fog5t6ZVedYeRFsuo1+ZANRWjWO4LPYO20rXW0dPocQbZyOt48NgyQtHoV PWie0PR3BJ/IgeGS0MR4rW3c0Tay66JBpUO7HobZDObj8TrbOKct5Jb3gkqHJlQj+NgjLL0LqwUi EAhSvtbrKb4kR5ihi/n1a72sKSATm4LLXG9upJQsJ7c461rRWRtL+cc0F7r6sqZZF1GGkvRgC3or JfhQpwFjTgu3jgtj/M28FI2Bup2lNUmdpX0aL6VkzdTWpjLzp6yRq30iL/VEWHmoN2tkbJ/IS1ER Vh4Szfy87dN4mSzCyQNcWSN7+0RexsuaCbxldOoX6OG8dMughegSFLbSEmQRo9Cpp9Brd5GOrfUw K6BFt6jjBMX6nogGuj4mzNHEhLkAXNSrJSHniAlzNDFhLnAWrnodcp+YLEcTk+WiRVEXVkMO5gsT LWGOpvBqX0FGMaJuaOktQriXB7F2EMuzAk/SSFbgLu5AGOtKsafdGRJjtVrSKc4S7pRJmYPGbfxo StoCrAbdBWT0liGQGnq7jgjNAUdxirwuSdEOQTx5zxqBG1+Lc0kvzdlt54gou+liT9F5DvZnPaJb OaNr79CO+ScoxHt6HxXBxyUt9XkKfYCce3YGifUsKTM6ANZ405BJz/iqIYmvGtJvZagmyRda6KCb yQfE4mcXeO99cg4GPQF+Pe8d2rMNXNFbxLptSA8vidbUu5LGpHx3wEDheMNX++HrKVTCca+KrGNn 8pe/+gT//JS8ijzz2ZuhQXMgyLC8xLOGQkncuMah9/IQsJPBjeajWLnjyU2fwrAlwNc5DrP2exA/ 4eGT3fJqAe7U8/aOJ8jlLbkM3xDHQ3J7trXvJUviLCog6wLxKe3KWz4ktCXhWm/Rgz9XEGToXM4d jg58kx7VkHYJvbuBHsLX2dFztLOhICJHiNcL3HxR4DvWhP6ET9C365pktzFbHJjh+ACjb/lAgtTk AwxuGMVniVkbxi2fCsufuLEQJsr0yXzV6xfA5gOuZ+5MsZTVraOGfcGbXxY9mnjtoTf10cVL11Li wg0DYrXVJNfags5iugXUrHWTO331JGqW+vLGmldomcv11PTH0lXwcE1XP0nUHved68qeZZs9HEjm EnLk/4uv2vHIOc5s27LQunWjd9slDE+yE5l8h18bJsrJgnROWuHOIOiRa/z6aPtz9fvk4fepIa27 k9u+pd1tts+W/zufkpRZ7mlBHFJi4YReeB0h7MU7WpkXk91iuyTZdL00Ghqi3S1+oc7WXpiPHI7I SD8Bye0RVSTD/GdxNa0p6mGWa25uCDuzeQo3FPMc/q4m6fqzYez10mKN7mxVwCeIF5jhZVwHX7Co Oq5DMvUZQ21jGvwJvetx96iP8OgNEZm3CtrpSN7jg2Rrc4BRW3iLwrRrbfUJRQgdmES2Xy0vfXfn tkQ7/tvlje0YHQiApVnSmdtQhe5c7w/Dy02PsL3Ba5/G1TSIfstaIhFt8WG6o0MI8Wl7qWg3er5c W51rUbfGeyiiat/pgpp9OlhIhdSBDh5CpZI9DzHk/W5mam9P1iJUUjsAiOFlgUXMtkq/oOOtFnMI jvp1stg/h0YzCndUBRQ4MJrB415BWZ0BWwZHLKWNg2qGr2kOdgMlZzccy5yi7dYF0B0G76KyoAPU pogFg2lWUVvseIc7y+128XVa1klhPjV4YYV7OcpsslrqjVweFqP4o593aQA/u2Co5XtYq5Q1JdzR Q9oZk2LcvctNWx00tPjeKFKOCSPYOod0fA0puVFnAiAMYADlkrPSd98gOtzP/URgrMG/ZWf4v80y IY4F/APRZlbgV6X/zfLjWVV078t3xzwz91lW4ZXsmJX4L29yEO/g/+qYMfu5IGbEROGl41nuPeYE FEZ4bglPj2fIX5RaEVl/tBJBClJn749nvKH7O+Ir/Ws9LGv6oi3Ctj6iMD5d8j51AiZ01zmox0v8 /3iGBPiZbqJueWHEKWLAZE8nWcZSC7SXmybMzcXyWCGNNI++r1tkmt3fVuXJZWeeglLpvrXN7ljR PJs3HYeMi+5wooWemtvKY236jfqo3XGyp9/6DHlaeIbw+8s207htxwfqzmJVy+FjvfYCyJDjnvaq E5jpnfS7OaHUazdBpU8EqAEQ3tv4ooOsC64U4pohx2BgjGlfDSBaB06q7xGFmMKNdP0NavatG17G X0/0P6e1k4G61keUdtP6qutVob2nEa7youVb1vHfkzh9yQ6t2i0MZ+vHVj9ZDwHiyY/9IWpdDyZE gdBg2Hpe/c5/TDZGUjNEKjuMjitvSGMTirdRrewAhj5suLryWu6Zqg4I9UOO+2nAUP2D0cSKplUK 3bbcxqPS3hV+TxizdINzJFI1DWys0O1ML6c4z9F+Vb19sVEtZd90QFdS6pkeDWWhvCmwqLyi1HYz NTOiRwuq7ExYVN5MGL7QbOnWAR+CXMi5RkV9T9WlL5oJS9ZEXk4bPXdf0TRNM7DFDNEAZ8jBRa6q N3CBTk8IXK50Jir7T7eMARcj819r3a0hJeT3sDFbEu2VK1ruVl7Biyy6wrODwtQg8BWnpgntEsNL uJAQadlF7FZZ6wz3DqdbUEpm1JP0GqTaCYcKVKnQqEuc09t8wS1enuGvgSh96bI2+yFbjDuLSxZq scPt142SxL1TvuVGCeLrS1c3IeKnFGsP2TJ8hS1MuwItG5yXB7fhH8C98M3mzygVhLayH6JUwAW+ Ybit0rmes9GIq8iz88n5Bkex6/JvzmnnJghghdJs3D6HMFqa8aLfTok1N4hs9srDgesOFcOdjYHW HLjuUOUIufpF7VMnJGoTOWjOT4GAhuKSfpRmOd8mf+F7sr3inReEnMTWyFO4NxyHmtLj9NytQNQl 2RKvmrqu38d2MLeDr2Oz1eVg5YJjnTt1Gjus8UWh8KFxHd0dScFfATjA4GY5nnhoq/S2V6XGOUEZ PLG/x/guszTPWlr1HRO8xfG9o2Wue/j43dGRroTP0TEMoEBPpF2pJY3wh3S5WOA+VezfVBeXFQ3t G+z2oxu9slLRGos04/3ockq/ZYX+NYec9xc8B95x9HC5l3+0m43nKmAmNNjsnt/92EuqGCUVf0bP mgBGtbHBfumvo4uiw+gDutAPUZWCTg7fX7f20NYPOC9i+AJ9nkncjpWlZV7B1+BuHhn8rYV9AEtJ b6YPDLNjrzBaFV6JcvXolv18EF0VzaAJ39HnhX79b9azsFaVk/+CMOnFVriin6kDYxN4V7lZ65uV LpT2Klenix69eiDyAQoJoSiW5anooqZHv3BcVN7auf7uJjU2o9Cqlj2x1KgZrzBDPjqLdZaz+7iZ xXtTFafb94PzmAf8LT2p3LRuZvbkXlvz2lKzLHqL36VOoKXOYza90eKxm5cUqt6l8Oiq3+vWzNHV 8PGnLirtW1pOW26n5XBZMVpR06nZKb/Virt1BGcb1Wca58XAzC7/HXZjAITdot97KNTodxTcvojP IiDLurBaw497/Wt+ugMJyLJ66s97LP6gry9st9ZBYKkzoV7EADbNrR/czYhtF3v90OcVgndWYjWb SzfYtXvoq25K1ow2h+1HXkkMsgGL6rY6UFhZdVhVr/6a2HDfM8P1TOctF7WIyPyqGWB4a6DA93Dg JUCCkVoT6r9n8+3KnLRxynsbdVbkELrisq2F+H4CCtAWfvUycZeVHA/6ti3+a71WiIdAGykMRvyP 6D86tD06q3uBwRpQFr2RRdo9J54nm98AkY2IOqt3F7lgaUse0k5Rbqay3q0AV73CBT5Fdl0tzLFa 1QxL0tuS0g7Hsoj0tr5PkyYp7aCdlaFR25KzbU5YvMHZo0Tts3pL1yUVevDYpR7B1rWgX5qRQRZ1 il/NzW+6qkPPjPD9dQDOAo5kS5Av4boKqLuIrG0+ZwK7GqIHHVm1i7Zk6edt2zFkeM2us+FI+sCK OpYys8EsPf2JkZlpeLVwlY26nLtpMa/31HmeDzwPG355qvKQRVu23NY7qHRi96tzanBxShosqUsL q94x20RbNYZqoaemu1sYM04TW22WlpkuK+A2lcLvPW9XJDEgmbpI+hI+XeAP+8V9mnE+eXeLM1xs 1lLvF5SjJvyhffH7zPsYwx+AbijeNwU9uTf4O6cZ+1ft0Mo26KPZGqtopt96c58VkdGLMiX+FPnw XDB4pHafEpyilzYEeum47h+3iZdnGrRT5liZF67peN2m643zq8Ubui28xRxuANxWx3+TWM2dxh7S hZ33OCC6rTcEL6+M4MbOSgiIdj6L7Jb0Wgibz/FKJ6HrZRNzd0fbPW9d5sYe1QEX0YPf9N+bqnYf RBDb++SjI3Kx/WV2cjL8sfqy0899kMZg5MA06LBgGc+IsTKkXQ1p9b7iog8mMRdymd3LPWp3lSm0 O/J6T1niiruIW/syBQuWLezTLguYybnytprH0nhrB317dkN72JPOBnW7t95WVuqd+o3SdWvNSFPE 8DHcbuBj4xEm4Ryy5CZZjhGx4QjwXyohONn4q7/pGPzhS73P9psdnY/UpYdUy44ewfBE3rBaWAp2 R5fdYsKfdu1GFz12SzMdqHSBJffXN2CaNLd4TS8a7W6nVWthoqK6Cu9dY6IfA8X3zeFogUizpNK0 dIdJ6MGTawqGmmCtj1nD94fd1iaz3YZeqyncaFCG/4jkXLzE6SJ8W37F2l3Rzc731AWg7RXaaaOx MTTze1oaWrhduz2V90bDrLy8wrJMUehTuqXIQOVgqi5CrybYp+WCSfot47FOeHzY5SKe4ZGzhvQ6 RB94Vzrn+J6egKzAYbv/Aw/bT/YNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBl L0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L1RpbWVzIzIwTmV3IzIwUm9t YW4sQm9sZC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNiAwIFIvRmly c3RDaGFyIDMyL0xhc3RDaGFyIDEyMS9XaWR0aHMgNTA3IDAgUj4+DQplbmRvYmoNCjYgMCBvYmoN Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVGltZXMjMjBOZXcjMjBSb21hbixCb2xk L0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0 IDY3Ny9BdmdXaWR0aCA0MjcvTWF4V2lkdGggMjU1OC9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0IDI1 MC9MZWFkaW5nIDQyL1N0ZW1WIDQyL0ZvbnRCQm94WyAtNTU4IC0yMTYgMjAwMCA2NzddID4+DQpl bmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjIvQmFz ZUZvbnQvVGltZXMjMjBOZXcjMjBSb21hbi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERl c2NyaXB0b3IgOCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyNS9XaWR0aHMgNTA4IDAgUj4+ DQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVGltZXMj MjBOZXcjMjBSb21hbi9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTEvRGVzY2VudCAt MjE2L0NhcEhlaWdodCA2OTMvQXZnV2lkdGggNDAxL01heFdpZHRoIDI1NjgvRm9udFdlaWdodCA0 MDAvWEhlaWdodCAyNTAvTGVhZGluZyA0Mi9TdGVtViA0MC9Gb250QkJveFsgLTU2OCAtMjE2IDIw MDAgNjkzXSA+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNDQ4LjMz IDU5OS42MSA1MjcuNzIgNjA4LjgxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1Mv VVJJL1VSSShtYWlsdG86YXB1cnZhLm1vZHlAaWVlZS5vcmcpID4+L1N0cnVjdFBhcmVudCAxPj4N CmVuZG9iag0KMTAgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA0NTAuMzMgNTY5Ljg2IDUy NS43MiA1NzkuMDZdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKG1h aWx0bzpyYW5nYS5yZWRkeUBtZS5jb20pID4+L1N0cnVjdFBhcmVudCAyPj4NCmVuZG9iag0KMTEg MCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQUJD REVFK0FyaWFsIzIwVW5pY29kZSMyME1TL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVz Y3JpcHRvciAxMiAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDMyL1dpZHRocyA1MDkgMCBSPj4N CmVuZG9iag0KMTIgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVF K0FyaWFsIzIwVW5pY29kZSMyME1TL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwNjkv RGVzY2VudCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRoIDMyNzEvRm9u dFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNDQvRm9udEJCb3hbIC0xMDExIC0yMTAgMjI2 MCA3MjhdIC9Gb250RmlsZTIgNTEwIDAgUj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0Zv bnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFuL0VuY29kaW5nL0lk ZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDE0IDAgUi9Ub1VuaWNvZGUgNTExIDAgUj4+DQplbmRv YmoNCjE0IDAgb2JqDQpbIDE1IDAgUl0gDQplbmRvYmoNCjE1IDAgb2JqDQo8PC9CYXNlRm9udC9U aW1lcyMyME5ldyMyMFJvbWFuL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJ RE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gMTYgMCBSL0ZvbnREZXNjcmlwdG9y IDE3IDAgUi9XIDUxMyAwIFI+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRp dHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjE3IDAgb2JqDQo8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIwUm9tYW4vRmxhZ3Mg MzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2 Z1dpZHRoIDQwMS9NYXhXaWR0aCAyNTY4L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRp bmcgNDIvU3RlbVYgNDAvRm9udEJCb3hbIC01NjggLTIxNiAyMDAwIDY5M10gL0ZvbnRGaWxlMiA1 MTIgMCBSPj4NCmVuZG9iag0KMTggMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA3OC4wNzYg MjExLjYzIDI4OC4zNiAyMjEuOThdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9V UkkvVVJJKGh0dHA6Ly9zdGFuZGFyZHMuaWVlZS5vcmcvZ3VpZGVzL2J5bGF3cy9zYi1ieWxhd3Mu cGRmKSA+Pi9TdHJ1Y3RQYXJlbnQgMz4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PC9TdWJ0eXBlL0xp bmsvUmVjdFsgMTE1LjggMTU5Ljg5IDE3NS42NiAxNzAuMjRdIC9CUzw8L1cgMD4+L0YgNC9BPDwv VHlwZS9BY3Rpb24vUy9VUkkvVVJJKG1haWx0bzphcHVydmEubW9keUBiYWVzeXN0ZW1zLmNvbSkg Pj4vU3RydWN0UGFyZW50IDQ+Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1Jl Y3RbIDM0Ni42IDEzOS4xOSA0MTcuNjkgMTQ5LjU0XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUv QWN0aW9uL1MvVVJJL1VSSShtYWlsdG86cGF0Y29tQGllZWUub3JnKSA+Pi9TdHJ1Y3RQYXJlbnQg NT4+DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl czw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAgUi9GNSAyMyAwIFIvRjYgMjcgMCBSL0Y3IDI5IDAg Ui9GOCAzMSAwIFIvRjkgMzMgMCBSL0Y0IDEzIDAgUi9GMTAgNDAgMCBSPj4vWE9iamVjdDw8L0lt YWdlMjUgMjUgMCBSL0ltYWdlMzggMzggMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0lt YWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDIyIDAgUi9H cm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0 cnVjdFBhcmVudHMgNj4+DQplbmRvYmoNCjIyIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDY3NjY+Pg0Kc3RyZWFtDQp4nMU9W3PbuM7vnel/4KN9plFE6t7ZszNpk3bzTdvT3c2Z 85Dug2wrjs/6krXlttlf/wEgKZGSKMlpZs7uuNEFBEAQBEkApM4v9uXqLp+X7Kefzi/KMp/fFwt2 e36ze/jj/ObxoTj/nC9X27xc7bY//8zeXL5lb25evjh/xxkPPT9kN3cvX3Dmw/+cRSFLosQLBLvZ vHzhsyX+8/7li9vJv+blbnoWTmbTbFLsmZjGE38aTvj0LIB//mA3//fyxRXgRdwaGw9Cz8Z4O2EO WJGmnh+Ngw2SzOMN2MUOOZl7r9k0mFwDZ1dXV3iZwiUyKvC1h2wLB9YwTbxQ2FjPXLAZ97LUhuVa HOeKJN0IuEjwYj9NnYKKIu7xhqBiJ2zqcbec/sIWO/M9P4t9P2UxFx6HSmXwh+2Lly/+8w+2VS0b CS+KARPHP5EfY418LxEEd/ePly9+ffmCXX18y84dKvZmV5a7Tb+WCQbkGyomQC1Q8Yj531E4x9lm hX8PB/qz27o0ikPNYhuBU6MS4Qluwz7k0BzLAv5xlsoSL0nsUi6NCfzAS7Nx3IS+8OIG3ouH434a Tb4iU+yTxz7uFtMznk4ep8KfvGLTs2zyZppMLq4YCIn78vmBLstic+hVECdTJytIEHtBGpoK4vtB S0fY+WfUjo9vry+Zf/4h3y7ZpNievX8zbRodWx0CQIv9XgD2eKjf+1kvbIsRbtGOGGgPVKhp8MAM SmwkljBlN/PbyW/FX8fVvtgU25IE7pI2FwGIx0TiU/levoTBl8kJ6EjQ1WYtBEE3gjjNsI2adbn0 2GVe5kq//EmxZlQ9utkX9Acrenjt6hTY7SIL/Yhahg4mE+hho2oZORDEEYpcIrh19YLMS2IT1BTI xcerT5dXl64m9X3oCxaVP1wqyTn3YmHRkZK5nJ7FEw96N4ffa/gx+N3A7x5+Bd0DwCVc5HhR0oWE +gi/HfwWCnJtPP83Av+uUOHDA/yO8HtQvx0CoFUp8UJDPChUc/it4HcHv0d1vYXfUgOXFoeObghD dZbZAnqneF4jorXm45tFQjL8WdV0r/5uiJoSQaFeOG2bD2YttUnnikCpEW3pAVzkjUpIo6ZRJDiS hGQRfLQn2qI1tS0KcGyu5kOmHt0Xq+V9yR7yfa46UQlzo90d3TBpOO4LdjjO/lvMyxYniDz0Uhgi YULjZ8SG7/NOTkQQIEiLmxH9MFbdCCx/BkaK8AmsMQyQvgAmgsSLYzYHnOfXm3xZiIhd7liXZU8s gxp3GNQkhgohTjAVrjHx/F3SUTLzFTdVSavLbsti65wWCNmmRlEpl7yldEotNkrZbKVz6zzPwJ4E drW+TFzm0o+8MLOBP2rKhwZV50QkjLysQfE/AI+d/1JV65+I9GfnjNr3Yt7fEjUsDPKJDbtQMtOm aaZt1UF3tC9Tl4UIUi9M3KRbepW6VFQrBTRwOE5Fs0EVzUKpojCN6ByH3CrKYcKHelaXNFX0F2kN PlvWwGXJhM9xnmmiGtGVuW/VLu3kERZSMCLBhKQykbtW7brkwmURq+RIuUAtbJqmXDb5dpGXu/0j uyC5vP/AVlu2KdREVs5CDq/Zv7eH1XIr7xfs+tPNK+cIhOulzKIH5GDlguSEs1QsvDSwS1GJN6jM j1W/dI16EY16pnRcjRvA8jCJ+iVZwyZexF2y+zLx202QdTRBCOWTrF25n3yeJD+PacRQwKORTIfQ 4AF3NEAcuUrBQJNFHQ3wylUgDLzEKZsocBWLIk90NbSTsdhvta2z6jH02EYvmbtgYYTFUb5TTBun +QxTgO9gv9808Ma6O+vsotKCSbavvsPCE2xVCsMhLDsfaO5WvO4n07V24dCzwIpZyFPE5uM/Ataw 3vRM0IWQM80+Cl2LGw5LjzS2KRC/+xXwHk9WJfoNVl8bHbiNvGtRIoQgW2wif92LJbJk3dWbhAAd zGycrWrDcMcDXGxEMM5FLEu9ANbsgCwMjbW4RTnuWluPw+NQjCDCFUyUCVRr5ZiYcjWFhkkXev3U dBrdJtCO93iHTpTVkpYLNHmvq/YrORmezhAUSRsMMRv9r7X8hEjRByPpwGw6i/vllzjkNwJPN7si gKkJt9m9VrJborMU5LRvSefp5GBhm0ajpYOWJFBkwgzmUAPqlbrEMwKRg2EY36imBsNcGgFQpZkc egVNBFpCejLRQKCDa6yUAmhCkSg6QmTohOmVUlYLZkxZB48wO06yH+54DMEQYgbWlVbdX+Gi0EWW cLOnx0e5Nk5gYq+lvy6+Kg1dE5rVFgcDekUjAr6hOWwIBrzZOk+vOS7B+ajGsZxmeu5LC18OBNHx 4vu4xACyqfxHr50H35N5Uq+VfbIAsIeG3I1A9WD1XnZhGyANsKcaCHBt3wAhBVcgSsMtiACW/UnW i0S1gwJRDWFBRHFgyyLJsvRkECVR2d70pm7txnuYaFQCMx0aY0CqYQMgjHYxYVTTODkx3rvIGPYX QOrWs2BkA9Zk8GWDUg2iKOnmsRFVdgygjGY2gVRL91EzQHqoGf0SoAx9MIFUe1fUqLltagaIpFap hANRD1S7M/OOeVgW02I/Sn0MxHV63G4/7UqYoT7s9tK7ls/WBVsdmFw0yrXj3WpbLFh+YNyj+8gd 6xHo9TDoqYn2xlkg9XhgFugLVlBwyILVrsqF9v82fCq1S7c0nC8r5Vvd0jvlqNVuVbx+q4C3GttC XzDl880N6JlBSpNgcoCQjmLtB971eKd0U8UgkI6Vme+zDfvl4uJGNsy3+9X8ns13dHNcqxX+rIBH m4e1dgSsH+F+K2/29Gc1O5bQlLPH2peab2lkhJut9LK412kRTSNrDmF4ff/BCZ6muMAwK+SrFbiS l6ec2Pj3VXMV0yUb9O22A0ub3XGLldptpWxyNtvv8sVc3qjoHit334p9a+EPCw3uRaIxIUy8OLOo KcZdy0sRhxjNMUrcTjyG66ebbxR9pevZNJ080qqqgCvoYTAP2dMtvS7h4X2hA9vFHRXcA5B8vcWH cwI/wMNDTpCPFITvj6lbbP3hhE09IWzY/oibGFyx6WYLRZezQRmepietWrSEGD81y8pGOFZeXsP9 q2M2G9XhZCcHgJ2OXOgefjC6473VX/UzmhDKB8MOW4TSMZn1tI4szVVv1wwdzXhMOywUTX5BgAu4 uMALHYuqbVJ/H6uldOtwxCte79QDzdtQj8O5Q9svW4LZcIbvMowCmQXrwMHWYGtrmlcnNjA5wsJ2 S0J6D78PhsWVQ0APIgHdPMxsREsd2Nsp7akHkjpMiH+/To2Yojl2tAx+S4NcocKVetbLdOiTd89i eq3Iz6fN4UzF6dzWG9ovcLXol8k6L1+x9W67dFq5SAToe2s37ZAS8QR9t02Su1mZ07ziTg5Nuw3L wUo/yJuldGLnDzDQsUVeyqFplh8KHLykTb+XsXd6TW9kXkGx/1rsnTYRukrELZ5kJZyGMYQpc2YW GDKMwUDoJcKkhMwIvUDXdYReRDg29oIrwDg5MfZCcQ2jpNk876FxKPJShRWckRcOPMSxhWhMykY0 NvIS4qySPyXyYpU8KfJilGwHTXO2WEmlLeaYn5XLCdhKzqke2Wp7t9tv8lLmg8C8BES5eEM3r5nK EYH+tvpasHKnQttgUje5LKDmMevdzG1mFZdJhhZCGf78+2pz3LBlhQa4YMVXyehe8eYykBEt3yyE EVsUy32h+lX+N2Av7+XNXNZ4N//z2wo63kH1z3252i7rDl1XbaAacYJRCRUlXe2lVJkUzZ2SDd18 l1XDauayKSSNJWpr8Z1uHlTTHA5gXODxcatah+3uYB1FNyKS5RZv2A6sxRB/UeQFWirIzT7fLluV 6g4j8ZSWcwYKdmIYCT31kYXAUEhYLIJZUsrFYGpNVd/OdwuovP/dp3v/yxQUDZDJdUIF7H9/984d M8HcsKDN+MSV04QBs4zbwhoSbBh4vN3L3t6D3Zlj5sfvavECauUc2VN0BZiY+kclIUL0ZBoFbmlE veudP4Q0f7AKJTIUU68B64Bnf+qDyGAgTWxk/aYyHm0qYXCuhqnTTKVZ8jRTWZfsMpVgN1SfBeOx 2lqOBbQuh1dsvt7J1Zq0Jk37sT8W7NNuD+O9KwoqMHht8jGgqQEIK+mvch369BuwZiUFmznnW0lL rI9l4RpDw4y8Gu06OPmC2RVPXXxdf7pxzeI4xc/GE4oELsScsmora2dAqDeGGnJj1HHGUM/EQAgU 7pwRzNCpDCquaPHgjiuiLxAMgfKjpoImX91BDeEK/YzCZFlLGVFEi8w1iwOBDRl4uJvyQCUwkjDx dSkTwuV6oTvGeAJrmMiK8waTtcHYosIvncT9Msz6o4v9mOx0P4oqWoy+hRVERELZ4z9zGZxhLak8 lVgAEqzmNZSWDyOZdOaA9JfPQCeiLDOLzmDsUqFXXvNe8QedieejUTUHvSyw5a9GUOq8uLozQpeH tnBOJhnASM+TsbqpvPwKv/Ly90uHO6QzDpWd30ehy1N6OLkOcK48jas+ndQwa3pUPmK377YIMLoG k26zoM0p3VIRusUVd6oioTiI6+ApxkdX82Iam5RqJt+0e9STJWSp+p4CrbiQUjZecrmryJsM6xAs VtbgcE3QM10VG+47VgzkFMpHR7jM5CVOY2KKBTfwGQJm0tcbVvFjKfJHuCPQqJJzJUkKLuNFc0fN j4otJS+GDpqEk7+Ra6tmsZIWMYSmUEoGr/4Err6hNsLsTMsIl3whLvgMe5YosZAMMEZuSKvVGD36 S9rVo3vPJ5aEJoK147Sn0Z+BaBJj77aIPktlAGEY2HixIm7b0aG3haq5nEHh3eGgetWCJGB1bYw6 VaYCJlpZp73w5ZYNXG/jVVS1rTYLupmrDvKcbRsbHruG7u0r8Syr1I6nEz5/FzYzUZIIvUcmCz/5 /hv+83M0dualiV27GCoRVLJOumUN1f5CVaV6Y7fe6dQV1ciqALUaqoJfzba/TFWIinPZYDWgYean XIn3S43jHZajf75MnRkvJ1Q/woSH2K5+o+3ae7vEc4/TAW4W1aPQF3PEoaF3XQ2lZDWdYyeNu/lM 5xsdqhF0PpVP1vMjvsQhjkiMso6q/L2msK06ap2XlKtRiYwAsSsTnrA3061cPNFk7Dn7ZBhjWnDD RNXpU6RgVU6WORZD7XoH427JG4oNEFfXv31WpgwkqKu/PmrRHVheMqq3zcJej8yrAywPVsZg93yC CWIv1vpcD7yD67UnEIxTzNk3CDLaAYwuAJ79kBUULG5YwYRIhbRtRicqPkMVUr9RhUZs/umIgxbi EXl0QdCRRxdyMhE6V4qSeBpZW70gtBBXEHXWlgWjsrL60KgVpQKpsrJsGJlyZaBRSVANKFp+Kag6 5coCUvlUA6hUwyioOp/KAlJpUDUqnQb1BCglb6UJJChDDwxR9kFIKRkQWLUGkKp/P5DiuQYiXhtA Da+TII9xnfUdCNeaNOx3OvUi6vA5BSLCbXpV6tjgsrRnceFwNo1nKYNW7uBo2N8kSVRZ4W7pRQPu pj5EXQ6gFq+jE9nHk5L56yeJRblSJIk6D9wtF9cmiVGYbDdQjNGXNrfC6fAZjTvwfbTbg5J4Gm6B 7qs27nFOq/F0BJetP7419TgnadR54+7WdG3ZGIWpa/byjEbirHZXRS3niGuIH80wbrPzkw6GK6fL 4RUtdZoOED2jrDwgbjfH/mjNxT/RKT/7Dvt3MvcRzKQAZLRyWI2udwQbg6Ffzxo6UsYVRH/KeB8a w53t8/6UcANNT763gurP9x5AZcwKfT6QzF2j6szB1pKU7edO4EcAP+tN4O8FqYZJPxtqDScrBoCL jjHw+NlAc9V0nCn8Bqm+JpVQA03aR86A6SFn9DU/G2r2ipw7ib8m15fEPwDV7qSd4a7BFK6ABziV dBiE9jEyvitDTZ1fobLyx2SohXwwQ00dYIGjc3haLpZKmDNKWgcKvWMf88OfmKQmE5Tk8QAywWDo KAkTp4x/P/U8CateTzlPolcwNayM9JmwP36ehJN0u53F2BQUde7cE1JQrJInpaAYJe0jp5bHtTwo gZTicrfBPDGVJRXIhxe/v72+Zh+Ksjo44cv0FbtUeXOruUoyxSPZoCSgVHsuDLxv12qvgfuUnQTt jclmf4YKZmnwfoHUoJQD7hBB4bGlKxc2CumYmjZXrtMDoogygEexpVsmiXAzRZOtd6vvxeIV+4xJ pTJHMl87E7wETY8MRJLL8/6MMKPALR1Xs5uq42pK3U9mRpL3q6l9VtTMyOp3nmCByQ+RTcklu4DH 2NktWOdOJ0HbqByyK0rX6Qg4HY+7ROXSgABMWNgQFdgMlc3utKHq3A+rGNdbDJqZcO7s9gBHZAvJ NcB/msqzuIiPVxrrR2Xj0LT9qZrqk95YsSGyKu1+r95eGxn9+Py7eu6sle4OJkOugwp1TxjTmron wJQgbHfQ2WPpTo+Vh1mZJWV7tuSkKnYmTwjTG0v203qDyUdzcPhTi/XTtN44M5tGDgEqyWoJ6s0t +4qEQvtQb7mRcjd32+yMDRNMA+tzy/Q2hrniZ625rbb6/AYX76y62MogUzh7zptSrRBxnJE1WyHf Mjy/72GjtsKVrLzPSyYzF9WU4gAGX2YUV3vnaOeBuc8Mt9MtZFkJkx/YA44L9HIxNiFawPCcagu7 b4xi8wIPD1UDUy55We227t1pCQ3yBs4BqyBgxiYym4n+yUFwcsqfEAlOnv6nKX8WD90pf7EHs44Y x+JU0AoFLB9PXQlBodv5OozI3vzGaUznCc7DJYOXGB20Mm2gwjePlcDapz2cTBXH9QbVHiciz9Db JtGHIe6i7BeO07c6AlEzgTvlNpsj3KqnUol8T0SjhRGHNfYYBtUBWTj9qcN4mquCJpNjjwI5jVIA k/twtDiCwK+Ri0DQsXm9AnG7JEdgsudAESaIWYzetMPK7eiv9Dou9K1UKIq9kp9vVRyqBDM72F6a fTC0EmHaHr8TaxPCnCTJesX+JLQyqd1C68rmoxg0JQ30p2CdygKeYtMwNjoZZ/fj6CNOZx5Z6Hvi 6o2tH08kqnXPj9FAGTmKreSBHyeVhHgim0VqKA8mdCWkP7WiPCOnhKTekTZE+vNP3SfegW1efZ82 szJmOjJQp7/I3EIzKfDH1U2kKC+L40F5uZLPnyyvNK4Xzra8+Gh5vcU0q880+l89g1x8gWcUWpwN ySVyZYU/WS5JFdBoykU05AJzXVl3GuUPGJKpuzAZ9HMQm1qI4MQQJ+gpzCYZTBDVcU6L2lQ/iyUF A23VYFB+7rzxJ8rPPL3Zll/w9Cp2pDVGlB9jknOlNZ5akShFZ0B3ReocQkMRfqBa3G/WC7Q/i2zq v9F4T1r2dapTJH9cXWAW2pDgmOBdJKwMI5jXC6FXMY70oVEgiYZQy4NW0g+wy5NeNGperXdR0cS6 BROHDTSdGUZyRqrPeYy6MKHAhzGpZtHLPNkuXalDIrZRdachDUMpcUs9IDEZWmABCAwL9TXZEEii IfqbzM1KBeCmU62VCKS3TWs62BBNUhqmItXT7gqqt917qVUwvdSqLktQ/bphkgub5CoYg5xTfwag 2h0+GBv742CTfeNsrx4/JA/weECjwNDXIhzfm+Ch333OYBuD44MTHKPR43iwtz47vjjCeVyfSdX/ AQsD9NQPWFhUhj5gYdJpfMAC94w7P2BRnTRmfsBiM/3ffcDCPOkMXcI6tKmWuNbJN/aRa0flVP6v QarUQjArbx7MdI0Alz2OXGxuPAlOtNrw2+64XriKpakXpVbR28nMdItQ76mgwAqpo8HkNyTqbzh1 6EWN0/yEhHaTb83WHDrRiYewQLG5rEWrWsQQken3bh8qtdClvhrudf3yqIReaK1zH1cQY5CjwVND cBUQCi7CjtYnN8ymC6O24MzjgVi7dapiSARTK8J+KoJC/Y7m6ToB7N7MATCP9pMnVrkCWT4eKWTJ xx30inEfngU7141gBkLsQ6LsMyaqo8/woY7xLKeNyElpdv3HRvv+wFfI/hr1uSvt/Ic+1P4iHky3 o7D6UMTI/1wdBmYPMJS4Udqza/2dGDw4TeBQFspTNqEufmhpUTf3PKNR1yDnyrgZJydrrEsakZMY J2fNj2th5pKuaGM3RRVxoa95meUSDyqbhDBsu7/PAbVq1jb2iWez3MVUcG3SzlD1ODd2GOVqlRYE an8nwkgVdY2sgj7UZ5KYy71mmSxt7GqGx2t6nEnij1MhqDeIyTdki+ARYi03JIYpBvwzyeSD7gt0 d6CtuDX3ZVWCMCtnMbyVD3MDsK51Ylca4OTGSs6JR72POkTvcCLBSs07odhPIxOqUQhhm4zcS89G QkWpvn/LTXmJwV4lKU0c42lwW9fCwNggugBMb9Dbq+WnWL2bGjzXUl2Y7KrW6pHjUstBUtWwWEpN JYijs0gWx8hrmEw2OXng8YnBKdYIC86cbaWZCwKN03WWClmB3v5Rw+IAbYGuDFZz+dFF9DXJ1IQC WTcYUWKp1OEsare2cB9ERJ+48vy4/qYQKSDUWLU8XM0qpTwAdeohSaKu6fOIciNdJDuallySdHei RNXExGW3UBLTDvGtVk1Cs66UfKH3yxmUjAaHu7aqwMOqxE6rLxaay72KWnS2hWjhjkUH7li4JFSi ezHvtj6yYC53u9dHvrsoLKp7p7Rrva26oNpCnySGZVprVoC9s9DudUTdNdOgfcKWsqjOGQtDjIie 7o6WlahtlG6irNVCVP5vWQGA3hzJtim47nZuIxkhKLfxVe96OksUeVk1XOIBe3VzBt0WJCCGtYll 0liR5Ukaltswidocqr3VBv9BS9bw3JB1Q5NhQENCB2Zz2pJcIBHZOhyY8g66tBwuMU+iHiUaip5I INOEqkdvUfk+T8PJldzmrQadh4op+fnBjo5JWRtyVjD51xSztbiqGup9c5oAmIbGf1bV3G4Te0A+ sAOa3nurqLJpQbPJLbPt6FCRoNNYLYUyrXvVHAyF3bIKuttWo2lu9TqCb2bkdE/meIDJpBYjrdnn /wMwvxXTDQplbmRzdHJlYW0NCmVuZG9iag0KMjMgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBl L1RydWVUeXBlL05hbWUvRjUvQmFzZUZvbnQvQUJDREVFK0NvbnNvbGFzLEJvbGQvRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI0IDAgUi9GaXJzdENoYXIgMzIvTGFzdENo YXIgMTIyL1dpZHRocyA1MTQgMCBSPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NvbnNvbGFzLEJvbGQvRmxhZ3MgMzIvSXRhbGljQW5n bGUgMC9Bc2NlbnQgNzQzL0Rlc2NlbnQgLTI1Ny9DYXBIZWlnaHQgNzQzL0F2Z1dpZHRoIDU1MC9N YXhXaWR0aCA3NjMvRm9udFdlaWdodCA3MDAvWEhlaWdodCAyNTAvU3RlbVYgNTUvRm9udEJCb3hb IC0xMzMgLTI1NyA2MzAgNzQzXSAvRm9udEZpbGUyIDUxNSAwIFI+Pg0KZW5kb2JqDQoyNSAwIG9i ag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMi9IZWlnaHQgMi9Db2xvclNw YWNlWy9JbmRleGVkL0RldmljZVJHQiAxIDwwMDAwMDBGRkZGRkY+XSAvQml0c1BlckNvbXBvbmVu dCAxL0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDI2IDAgUi9MZW5ndGggMj4+DQpzdHJlYW0NCgAA DQplbmRzdHJlYW0NCmVuZG9iag0KMjYgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt YWdlL1dpZHRoIDgwL0hlaWdodCAxMDgvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L0JpdHNQZXJDb21w b25lbnQgMS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDg4Pj4NCnN0cmVhbQ0KeJxjYBgFwxow /oex2P8fgLLk/3+Asuz//4Cy6v//gbL+//8H0/ofqpkZyGpAY7EDWQfQWPxA1gOasLDZhs1VCDcj /IHkN4R/EWGACBdEWI0CAgAAyhhfWQ0KZW5kc3RyZWFtDQplbmRvYmoNCjI3IDAgb2JqDQo8PC9U eXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y2L0Jhc2VGb250L0FyaWFsL0VuY29kaW5n L1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAyOCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RD aGFyIDMyL1dpZHRocyA1MTYgMCBSPj4NCmVuZG9iag0KMjggMCBvYmoNCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvQXJpYWwvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1 L0Rlc2NlbnQgLTIxMC9DYXBIZWlnaHQgNzI4L0F2Z1dpZHRoIDQ0MS9NYXhXaWR0aCAyNjY1L0Zv bnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgMzMvU3RlbVYgNDQvRm9udEJCb3hbIC02 NjUgLTIxMCAyMDAwIDcyOF0gPj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0 eXBlL1RydWVUeXBlL05hbWUvRjcvQmFzZUZvbnQvQUJDREVFK0NvbnNvbGFzL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAzMCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFy IDEyMi9XaWR0aHMgNTE3IDAgUj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDb25zb2xhcy9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0Fz Y2VudCA3NDMvRGVzY2VudCAtMjU3L0NhcEhlaWdodCA3NDMvQXZnV2lkdGggNTUwL01heFdpZHRo IDc0MS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA1NS9Gb250QkJveFsgLTEyMiAt MjU3IDYxOSA3NDNdIC9Gb250RmlsZTIgNTE4IDAgUj4+DQplbmRvYmoNCjMxIDAgb2JqDQo8PC9U eXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y4L0Jhc2VGb250L0FCQ0RFRStDb3VyaWVy IzIwTmV3L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAzMiAwIFIvRmly c3RDaGFyIDExMS9MYXN0Q2hhciAxMTEvV2lkdGhzIDUxOSAwIFI+Pg0KZW5kb2JqDQozMiAwIG9i ag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ291cmllciMyME5ldy9G bGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4MzMvRGVzY2VudCAtMTg4L0NhcEhlaWdodCA2 MTMvQXZnV2lkdGggNjAwL01heFdpZHRoIDY1OS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9T dGVtViA2MC9Gb250QkJveFsgLTIxIC0xODggNjM4IDYxM10gL0ZvbnRGaWxlMiA1MjAgMCBSPj4N CmVuZG9iag0KMzMgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FC Q0RFRStDb25zb2xhcy9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAzNCAwIFIv VG9Vbmljb2RlIDUyMSAwIFI+Pg0KZW5kb2JqDQozNCAwIG9iag0KWyAzNSAwIFJdIA0KZW5kb2Jq DQozNSAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK0NvbnNvbGFzL1N1YnR5cGUvQ0lERm9udFR5 cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g MzYgMCBSL0ZvbnREZXNjcmlwdG9yIDM3IDAgUi9XIDUyMyAwIFI+Pg0KZW5kb2JqDQozNiAwIG9i ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+ DQplbmRvYmoNCjM3IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF RStDb25zb2xhcy9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NDMvRGVzY2VudCAtMjU3 L0NhcEhlaWdodCA3NDMvQXZnV2lkdGggNTUwL01heFdpZHRoIDc0MS9Gb250V2VpZ2h0IDQwMC9Y SGVpZ2h0IDI1MC9TdGVtViA1NS9Gb250QkJveFsgLTEyMiAtMjU3IDYxOSA3NDNdIC9Gb250Rmls ZTIgNTIyIDAgUj4+DQplbmRvYmoNCjM4IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9J bWFnZS9XaWR0aCAyL0hlaWdodCAyL0NvbG9yU3BhY2VbL0luZGV4ZWQvRGV2aWNlUkdCIDEgPDAw MDAwMEZGRkZGRj5dIC9CaXRzUGVyQ29tcG9uZW50IDEvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sg MzkgMCBSL0xlbmd0aCAyPj4NCnN0cmVhbQ0KAAANCmVuZHN0cmVhbQ0KZW5kb2JqDQozOSAwIG9i ag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggODAvSGVpZ2h0IDEwOC9Db2xv clNwYWNlL0RldmljZUdyYXkvQml0c1BlckNvbXBvbmVudCAxL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggODg+Pg0Kc3RyZWFtDQp4nGNgGAXDGjD+h7HY/x+AsuT/f4Cy7P//gLLq//+Bsv7//wfT +h+qmRnIakBjsQNZB9BY/EDWA5qwsNmGzVUINyP8geQ3hH8RYYAIF0RYjQICAADKGF9ZDQplbmRz dHJlYW0NCmVuZG9iag0KNDAgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05h bWUvRjEwL0Jhc2VGb250L1RpbWVzIzIwTmV3IzIwUm9tYW4sSXRhbGljL0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA0MSAwIFIvRmlyc3RDaGFyIDgyL0xhc3RDaGFyIDEx OC9XaWR0aHMgNTI0IDAgUj4+DQplbmRvYmoNCjQxIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIwUm9tYW4sSXRhbGljL0ZsYWdzIDMyL0l0YWxpY0Fu Z2xlIC0xNi40L0FzY2VudCA4OTEvRGVzY2VudCAtMjE2L0NhcEhlaWdodCA2OTQvQXZnV2lkdGgg NDAyL01heFdpZHRoIDE2MTgvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyA0Mi9T dGVtViA0MC9Gb250QkJveFsgLTQ5OCAtMjE2IDExMjAgNjk0XSA+Pg0KZW5kb2JqDQo0MiAwIG9i ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIv RjIgNyAwIFIvRjUgMjMgMCBSL0YxMCA0MCAwIFIvRjcgMjkgMCBSL0Y5IDMzIDAgUj4+L1Byb2NT ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3 OTJdIC9Db250ZW50cyA0MyAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NT L0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDc+Pg0KZW5kb2JqDQo0MyAwIG9iag0K PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3MTEwPj4NCnN0cmVhbQ0KeJzNPWtv3EiO3wPk Pwi4PaC1iGWV3hrMDuDETjaHJJvZeG8+JPNB7pZt3fTD0y074/v1R9ZDqmqJVXK3B3sInFa3WCSL xWKxKLJ0erZtm+tq3no//nh61rbV/LZeeF9PLzd3v55ePt7Vp5+rm2Zdtc1m/dNP3uvzN97ry5cv Tt8yjyVBmHiX1y9fMC+Ef8xLEy9P8yCOvMvVyxehd4P/vXv54uvsH/N2458ksyu/nNVbL/KzWegn M+afxPDfr97lf718cQF4EbfCxuIkMDF+nXkEbFQUQZhOg43zMmB7sIsNcjIPfvD8ePYeOLu4uMDL Ai6R0QhvB8h2RGBNijxIIhPrCQVbsqAsTFimxHEqSfIvEVzkeLH1C1JQacoCtieojIQtAkbL6Xcc sZMwCMssDAsvY1HAoFMlfHjb+uWLX/7qreXIplGQZoCJ4UcaZtijMMgjDnf915cvfn75wrv4+MY7 JVTs9aZtNyu7lkUekN9TsQjUAhWPM/8FhXN/tWrwc7fjH5s1pVEMepaZCEiNyqMgYibsXQXDcVPD f2SrMg/y3GwVU3oYxkFRTuMmCaMg28N7dne/9dPZAzLlfQq8j5uFf8KK2aMfhbNXnn9Szl77+ezs wgMhsVD8vuOXbb3aWRWEZOrJChJnQVwkuoKEYTzQEe/0M2rHxzfvz73Q0IDUg0EDPPt2JioCwR/n Jim8y/nX2dVm8ehdb7aUGFmYBkWmNw55u0qD57wrwBhwF14a5BmwXmYd36ZWsSCLNKQcgyk2gVQC KqRFYUOaB+k+Tr2rTbsje5mEgSki0UvUlhr+buDv3j/JZku4qPCihYsN/CHEI/x58LeQv604UDpr 4I+aWFFcBIXOrmVeJUmQMQMUse8k1e+SxyX/A9Y8xaOAoKZSgZN1XCmqtdcs6nXbcNW/bubczPAv 3kb85rW3NTXzkiwo4qEwyZmKal8a/Wtln+bwd8ulCN3ZyE5u5IAosbccCAAq/kVKoOlERMxaGG6W BSwbTom6Wd9497t6EYgue6TawHqbFwYe0dVvM4ei9S2+zj5Kddkp9muuV7wfBJaC4ZI0zv4vX869 v/3kLaqWc19dVbv6m0/a7DhI45Ee6KQH9oadfqhARLN6ffLutb+3/JSG4WFRFoQwg8E6RGp0L/4A +wsaWsBMAet7xydWDY7ESQTuwwk6OifoNuSzAH/Ci0iIA75x6G0DLTOY0bh4NQ9cW5LZ7geql6Ba sMYYTAw6CHaagektIi8rEhAvyBjNMCuwTW+odTlEY3KYiEf5hCXaM0NiWYoSy4oyyBWznyq+Tq38 CLWjZ/xnvrwcRw7owDJjkPNMEj/3EooAbxlLUkmByGwCigkBTUBDMhzFUZCUJsOXMPqP/kk6uxtK 5yhaaYJWcqpwsgINtaCUJTAmdvVJNIFMaEpzWaRBlppcfgCJ1OsblAmfJLdDuRxDMgaDEaVTBROD nQzVEEQRbCasckkJrZmAhmQ4ieIg39Oa83o33zZ3wojwzdZ6IKWjaIJxjbJJQtK7n8keCw8I5jaY enBm40RsFuC/JOk8oCn3i0gBSONgguAEiWw45AySAGIK7UFkOTrmFhRC2SQAaFse7rMRx3EQ29iQ QyEBxFiYEGkW821djwI956fDCKGKMeeM9EOuCYy+L6RB3pc9Je9LFvv7yKEJsr9isQQGVg1vVhIT K3esVzSWbnEfLB8JQ7c/y3lTzZc/rx98mFbz2kMbdAnrF3psYrlPLYvYITyUMM+iER7c65igJlSa FFvhWMVIJCTHEVijMh/h+D3aorUP+4saXdx6Sy5nBxAFPzsqnyYmuUYIYnKRIOVUUnJyYqF5Lgr0 T4c8M9Qi7hBe4RXXrHZk8T+cdMxivsQ9QVxqsRDUhIUipcVCxzJHYqFZjssgHFMrMf1uQa9wOiaz B7iqlveoYfx7s8D/6zU4DWLX0Fz75ayp4TqCfUksJN3egicuGrQyPpLJ6cx/3ODltV8I6AW/8QAo lRGoWg/VW7TtmbnBqw258j5dDCnYV1hwh2I4eUYiStZZhPZPI7LknsS84l1tNmpCc5ls8RvMbJDJ DmUN8xulzwWyRhHdPCOHCfhosK8ecrinwMPt3ej+7lmklTJcdTVeQuz1Hzy4DRdhN6v/xlXjbfMH hr9BlXJtssOGln9BxWyr1uW6HSA5WNRKNsKtU3LUjvB4ycFHaZEcc0nuDejbZ4xwXjyrioEnk44w 5xQUtTM8XlAYRopoQUV7guIyqX2YgHxyok5xO7bmJvKUmzf+A7/dVlciWsEt2cpnpbiJcWRuG59R tuBFYhxg0B+nbJM/TbZgUUpatPFzmtcUYNmQ4rOacLCMqL1kr96+5Q8uhK4cSJeFI4RL2XSP8D+R VL3DZZeBvsWzhxrVbPGcWhWHQTEykhP2pSyVqqS2RzESVxu1yNg98XBUrHnyBkS3gSIwdCGbuPdx TQC1w6IQqNhGLN0+ud3sIbo9GIGh2/fHvYQNgG6T1iGQ+0hTEJ3vye/IMdJlQNyVHRy/q5gfv6s4 6+8iZxrA3uYxLUN8yCIHCnYmIRWYYZl9A2nH5NxDhkmQZaN7SGq3eCjBPAxYMUJwaF2OJRSj8R4S 4vu886FReRZBpiVXAI3cB/QFwKoIVxQdbuWE/ymCHTLg3IlLgmKuW3WQCmJMQeTckI8P1JQN+YF0 5Z58QNe5J5f05JbWKjEyfjEFk2VrnnEbO2A9Gt2a76i9+YHkY5YGbGzEnNtzSVDYdKvgqIDGFERO X2rAOD1J5e7R3F+fI6zYyo9ZyKN4TMKSr34TDORxdBioPzntzrmTfc3D8/Vy0anVtxn+9B/ie7kn lvktPlzc8n3inLvsYpONjr3xGPQZ2E8Zw+e/k3XQeHYYmt4U7KSyrHNEWFmWA4dKgPQOlQHU+RM0 ni50yEE6t8qEUY6HBY2KqXGQ3rkygDoXhcbTObEcpHOxDJjOl+nQSC9rIKDOkHBa/RBqsrEAiF7T ALI7NIBkVANARk2Yfb8ry3C1nuB3RVRAZhImp7tQhOZewO12HUhPegf79Giv61A63Ovao+NhikQc 8+yG9+fPTZI/qxn0zO32CHJutyeiIktTELncngHfGCzCZWfEjg591mfhICv3YrVf2m3D036GIdHj CAJ8ko4QdHtcgt4Ejysi8x6mYLJ4XHGQx8PR+u+KZws1KjZFelqHkY1B3GxESdyOlqDndrQiR8TK isjlaA34fm+E5P/15ZV4ooEPN0QkvnvgwYP0/OotRgnfYDD1DelCHMQkekDZyJjSjtaBZFIM+zzN JB5HMcqCNJ2sNYY6mIGmFDOU6DiTuG0JM1HtlRnht+kgE9lcTip+2xJiotor6fLbdICpb07El+Tw WNweGkD2kARQXSABFJM9gNvtSeI+Tc1qFVzRJhsip9OT5nshii81j/A31ZLP+E8833cFRoHvYuut 2G5QbsNRvCQpOo1HxWsOoy8dsgF9t9/C6U1wW1zRGgsep88wGMLpwZqDyIpYzZCs23Pg5KY4Dq5Q jQ2RK1IzZPypkZqDqMtAzVPEpkwjpzfBfXDFaSx4nN7DgO0nhWlYMtGuwB1sIuIcLB8JdAwCQAdG Og4RRhoVmGE1eQyNHGAz0IFLBUssy7m4b1vPKQzavoAlthWdRND7ySyxrukUBs1lYoltVe8RUMs6 HyfLqk7el52k7qsuUPcVh91994rOyiCJu9UnCsqETAh3RTLsqJwraRzvbyNds49aUA9kBKTFt5cD RtxLqqAoFyWrEF2xACsm57I6YP2gaMBxPEQMS4ieFg44kKKMBwwould1QVCth9YRcwUE7KicEYHB kE0OCRxIWMUEnqDmyjQKinIBsgrNFRWwYnIu7FNZN1ja25kmkTUFQt63rWUUhs5RjewpEDQC5bNF jhQIEkPnMET2FAgNAbWWwUjF2mKT7afap9DblNrjO25zY83v2+RMc9BBEDQ688LvW0bCQkJBUCTU ZOT3bWNF0+ggCBrdpOH3LaPZk1ALfzZ0DnoqgyGfADKcV6rmRczafKSCuQyDMMKqaBgAPYSlVT5+ 2rT1D97lbe0tuEdeP5jPMMwSSlBaHZsn6h6pAwgYHpeQ6Q1wu5nOzo2K27WsAsYfvsga1q0sRq1k +Sre+4TA97JU+EoD9GTR60YB8IpehVJBehIar+8k2oq3lNWjegNVJlvxT4mWL6XI1YNGfLfHZSMx 1aprrfzxmn9SdbUZJs3qktWGqCYLzeX4JmUW5KkU8Kpa1N7m2tusa1l8vPVW1fpRfLkT9a1buqw7 SkJcpTSccpQDskGKc11voDFP1gFHsC8CH2JI51LWL9dKS1Rp+E5Ksx93APiFaw1cnMsBWPGy8x6a Pp8jxrltyE4N5E5pE31QAgvK1Gy8k4qlarDVoD8ioleKX70K/U52bNuxKgq1rxVwI2/YarKVDhRJ EA91Z1vfNLt2KxK+MWHeu9tu5rU4n2Hn8Y/vTXuLpeneohLHNvDy51fiZnsrzILX1vPb9Wa5uRFV DNCgaj0R+28F6P2u3nnfZnVwE7wS2vaen29i5zuP8JgUIcIijGDL/ArbcQQXHv7CmFDaa/7xyqvb efDNB0q7WvJGHtcC0yrXSXjmEQW/S11pVPF4zRVIXqy1YfkHpUUZC1JmkNCkH+TffGrawKqLZ20M mbNWkce5ZvS1svwkLbFUkyjTNjAUBIYkx2cPUzCUU47OSOIU10SB7ytl+Eo888IAPSNAszRIIx1U F/THi0/nF+fUMgTbS2YS+ZU8JUAcnqGTEaPC16zAx4TtdPaD1IreVMkJe+5rR11UEuqjnNYLvz90 Qv3+LwT+IlF5cqrfS9twp8yQMBDSHNJ2hl5gYnDBYHANGaB63yikrdGT/syIuXFGRCN/XQ+M1T4G 6vQiFpiqoQ/i7v7qf+p5u3+eSdcow8URVqcYvbQy1ZNZDJ2KeFhDIyKf24mTHpTAz3uzTB52keAO aTit0Vber+f1thUGs1m3j16zFlZwVcuzb7Y7r1ovvLk0vNd4OshcrsmNMsb1dl6v20oYVcrvikH3 cbXRuLGfDhLnLMiZ3kCsbbqr1fk+c1+e07Ltfu0doH6E90alI5Hgo9gyCtD5xtN6otFBScBBZwZH cgN57aszYUY1kRgasDhxYvZvisbSA80wPWow0IsahnHFT4ziA0Qf+QRbA+i5jsbuNMlTULQG9GjK 808MWMthKbDmmbD9WSnSMNVqtOmzUkSWyLhUusNSNG/BclhKiQ+AhpKxLjHJaJ2n9bSUuNRWwH/X aSkGE5bTUuK8wMUfLVvoOO/CEfy1Y3IdmIJOSLcgTDow5VB64sQUg54tulviOXuSVlIGhV1GdGzX icdyZArsD0qTY/uRKUfQSpOgYJOlk5VBmitKMvJhlU+sB08nNLacmsKfihqMTjk15RiaMcsx1jRR OBiyAcdA0sJpyRzCsUVMnZgsZ6ckmKVtcD317JQjqOa8inuKrAwZqBCtdnxKDHvbkpHhRetttBPi vrQTg+BgHNMY1EwS9/lMGkT+itTSXqqbuD8eGRSDQ2FQgyDuy0EYC9hpGKiYng1EilKMdTh+aApK igaQoiABVE9JAMVlD+A8OCUGa9UPrS3JIHFkI9kxuR5cxtB505n8oCobxk8SOK9a/juZkXQkPxjR oh7ASRb0RAh+dIEzS+lQnsoc05SGPLlXXUGQzzvr4NJpSk48lmeZCV91B0M7JU3pCLIpbGDYCFn3 KizISStjlRedpzQBk+VxZs5bD1ifnqh0DHk81IzFT5Kcsq6CoLSuVsnZcpWcmGjWYV8VjrH+1Gwl p9nhUG3FS7OGNkHkMPFjY5YLkSDwZ+QxHS6oNOVV0ZPH2DiXzsxkivMccdBug7hvcxsoDJ0DnovQ POU2kO2Vl8rv29wGCkPnu/H7Nrehx0D5BGKkiFQmFAMNIPtJAqhukACKyx7Amc4Ug/DzWI0bEEgy ajanrh2tHZVzFU546uRzegVHMgQbySwl3ILnJpnxB4lDku5VX1Dk08Y+fK7Ntg2Rc90fDN4T86ie gYWnDNdxBDEonz9tsKSNEvSkjbIPF51FNQUVzXzOn/oOB+zTR5xUF/jfmc+YmGP9cUuFOPRmtC7g WJaKCM+9G8rzaTp0LBMlj5BEER6EN1GLjiMZM6G4A5JuF0xQlCuVXY9cYRI7KqcTNtCjZz9+zzxj DmvTujOrRhwsraE6lO8kF6fyUc7VkRIYqK3wAJdV27T3wJZg41XnIC5lBEluIzFSXc7u/UwCghcI H8GR3IbDuBbjzQfcRuFzC0Y+3plsHw11NZMO0ZVhlmQ4ed/mdlIYtG0n3KfdTrJ9v/1iVB5b56+N YtCce1Za3c4eA+V2iqHid7SBMgFCS1TQdlv6NaE9KkhzoEGM0tAW49AWN7RQ6CHGKfSGOrRHFmka GsQoDW3ShPbYY08j5BbUIKMBhY4ApQVkOK8mJx3GYYkhFUvSIfksNQnSQm+PTsXFGQmfxkFqgoes iL2/2LMStQbyieQ7WFs+4wqNF+/w4szyjDQC61SUBhqth5ut95d3n999+CCe95MJSiF3FnTeuZ9w Qz7ZB/MbpiPMz30tnVJlRKrkMv2FKyLvkcAOYxfv8dM9Rm9lZsrC79NERFJBl20pX/aiHrjfyOyU YUtrShi+3SgcZl006+vNdiXeqmLTBK3511lAao14AKrTEoJ8r+W39LkIMjnhu3qnCkr0N2cWDAAj ugvtD4EKH09tTcUj50BdRPLuL35qkGg0aXpKM7cSSKUKvfL79NPW4LZPOCRycnJ+YCsh9Gq3u1/V C6ItnuWDx9AMhEgnbuSYykAQ4ymFDt0o+JNSqZq3tVct0T2SucuY90rptpz2GgIHr3hCOixZBsUb lRu4EZ582iXN3MmBb+TUU/mdG/6blgusXj+kRm/JJ4YcsSuBn5idcREkuckQaScSWGVio7dGXsu2 eagXZGNhBoai6lLbxlLGFr6R+wYXV36fuKug9n/rDIcwGoTaYHpNNq3naZzsDdt+6pZDw/II85Jl UhF3vhegZuJNTgtvuVnfNGLDoWsd4l2KTK+5zURJ06oRcWihrAQ2uOLK1yUJ74+DyIjGBDdr4rOB kU4kKzCfxYCFbYkaPjkZxrRhrSZJl3CkJ+Cr5PvW0IJUviHMknidRnFg8K4P7t/Pzi5do5uFmEwg etKsvXNwWqurzYMcSXyp23eR8dzMRczfu9lu7tcLr17K+gg+vJ5M/BMv9lLrkvddpIndLxfeuq6l yog0qY13VXu/rTffRRsyYUr2UOeTXMSUruvA79cuESQ5Orl6xjUw20rWt7/tXnld0jf/ePP5YudV 89/vm63KBb+tm624eSN6uXHYLJ3mcmOfIjBz01Rv4poi0lzpNAaVJa1mq9e+TIZbKeM8tGlUAis/ F17nTfdQtlSzUpw5PLlLKaYs7w1VP2dIh8w+7nGKzuZghV8ro3Yv9BWGd7OnAZjh5+1arYoAFmp8 mR13bmX4ZSWW391OmsGGD3JgdYCTpMDsd5014Aw2ILwQ5JZqJZLdiQ7VnmJXTDw+W+2SiWIVOfs6 +85nb3V/IxN5aWezxBcVaW3lmFLr41KtclqGajpIqVbenpEXu/LTkQb2FUbvk2tx0WEXyqpfKz1b 7xnpxrd4yJ98kdiOvu6Z3+e0t8pr7Zwh5c/2PU2NjnYebKPRcY0kOKThUCVksjbmaQt1/DZbffMx PVt8ncvsXpmj7SlTXy8B8j9JUy03YzpRh6WKMnRKtAZf9bdO2tLwVZXZ3kJ64/deZGccjHxqJdJH v/c9lRHsVVW2coiXlYUKxZnu5HWzrr2mpaaKeBCmt1bZ0dKH2S+m6D1Gq2+uYfwqctjXvlbRp+qq +veKiu96dZ+2e1VVhP0EFMV8XTmQTJa3MRYnJUZvCEE9VMv7eqd7CVe1sYyu623VgmNetar6yuWu Yqp2t1cf2mn8hdq9KSH2GOSwvCIb8IiTQZIMbYQpvnHQgL3Wd8+elOQfciBQT1VdJrX8YnyuzE2k FLNRnuDaOY1ZEYfRJaHHcsj1A/exRTkiwUEYoPOC+7ezpuTLWUX5oqUstXt7a4e/d/pTw5hsNFVH 0r+rYtZGMyIuFQNJju7W0Qm8qTdT9j1y962jGjUBcKHbv3spKTXtzBmt7aqVZNQM3isDlgtuX9s5 rA3uCzHlkqMMgKqxUgg42keFVtmVuSbP4f7WMLF9F36bOAAZPzJ5GBADR62az2F7Issw0VzsRKnK /6rqX7E3rbbiewVXuJ2xemVymdLJDl9gbXr5EVZ3aA2Gc+30bTkSLJb7g/Ee/hiG7Az+sjAMc/iL w7Asw7CA3wr4XibiM4x/gt4AcMlC8cJwDQAbCSQSCDCxrFAtUok27Fvz7xJ1idfwWbxWDfDGa9Gg KDnt/W5aYuIMVodUvdWSzxz7pOHxTK2RK2IlXFKDCt+to44F0sjgZ1eNLEoT5TRRM+G93wd08LcH bSLUurdidQS7ykb0AmkXSq6XOsukWqYpVlvr8tBmg/DbyX1omeGjL4POHV9sqT1GHO4Ts1d0YX1i FtM9GT5KIUp5Wcwzd6dgIEp58QlKOY2HSaW8jEX4REbgs5fyaqD64JxNKNA1qLgKdHU6ewW6if// ukBXBfO7IzB6T1+9fr1V3IonCxrkg997s8rlv/KV0yRbKRdDeflq/7YcWOQxUyXLZ43RGNryUU2J ciw+MVp2mxb9mZClEBNVIR6Z3OqIgpXY1P/RrO5X3sV7/uWfn9WmbvEat3X4GEHu66p152FXYpM3 36xWmwU62aSV4bUzOiOOTV0WctMyzvmy2RnPNETxrGoS8WdQBX9STRfPxgU/F0SjoFc094W9XQWt 9EtWmlHXtzZKx7ZqMgitpGJXMffceuLo3lKwBd9R6LBqsRgp9DWcPVIlijwoi6Fg57fVeg0bdBCw 9H6qh6pZCv24Ek7QsmkfyWNLwgRjHzp2+zhHYYkZb1oDubqe+33Qgnzu8Tf4+8nSUXwfOXjGBvaP CuHw5BPKceObLkJiv3w5t6zDoqzTKo3hW7efXqab4+KmOvjvKtM1mBgv0835yUUZP8iJMf74CY9v i4j0uIxOap6AyVI2y180z3iiiUyFGMkZPopEyYLYJFHx01TJOuBjqOEkCkuTnCXdFagUqaKVgXLb B4FMTXbjoTnGyrg9jq11wEfQgt0GBhImSgcTPvlrIDgl2CvkhUM+Wh3wpMY0o3GCx94YjLrrgI+k CbJk04UDczzpaDGwrpljBpMJrlMw0RW5STqQ1KQ64OOolgmW20+RlSGDQR0wLON5wo2lylRjJQyh ntbnBOH2QoJIe7EPhJOGxVY8cl5JED6v9kFkBrQNi1RBCSJVcACU82O9rHjE8KheieHZB5IJdhqe /kVMT4WSkpb6oAp5WTQASOF/+2jZQYR1FyD20aJ5UQAWQspMChDbcNJkFICFjDI5AsQ+3hZCEsBG SM5XKTirQmiEZLE1G2RlarQsSuOA4hP8/wBLnLwPDQplbmRzdHJlYW0NCmVuZG9iag0KNDQgMCBv YmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBS L0YyIDcgMCBSL0Y0IDEzIDAgUi9GNyAyOSAwIFIvRjUgMjMgMCBSL0Y5IDMzIDAgUj4+L1Byb2NT ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3 OTJdIC9Db250ZW50cyA0NSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NT L0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDg+Pg0KZW5kb2JqDQo0NSAwIG9iag0K PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NDM0Pj4NCnN0cmVhbQ0KeJy9PWtz20aS313l /4AP94HYWBAGwOCRy6rKspSUttbebKxcqk7e2oJISOItXyZB2aqt++/XPd0DzAAYkLblS0KRIHp6 erp7+jUN5vT1tp7fldPa++mn09d1XU4fqpl3c3q93vzj9PppU53+Wt7PV2U9X6/Ozrzzizfe+fXL F6c/C08kQZh413cvXwgvhH+FJxMvk1kQR9718uWL0LvHP7+8fHEz+du0XvsnyeTWLybV1ov8dBL6 yUT4JzH8+Yd3/ZeXLy4BL+LW2EScBDbGm4nngI3yPAjlcbBxVgSiAztbIyXT4EfPjydXQNnl5SV+ zOEjEhrh7QDJjhxYkzwLksjGeuKCLURQ5Das0Ow45SnVRQQfMvyw9XMno6QUgegwKnXC5oFw8+kj SuwkDMIiDcPcS0UUCFhUAW/etnr54o8/eSuWrIwCmQImgW8yTHFFYZBFCu7uTy9f/P3lC+/y7Rvv 1KFi5+u6Xi/HtSzyYPqOikWgFqh4ivj3yJz97XKO77udeluvXBolYGWpjcCpUVkURMKG3ZQgjvsK /jhHFVmQZfaoxKWHYRzkxXHUJGEUpB28rzf7rS8nj0iU9y7w3q5n/onIJ09+FE5eef5JMTn3s8nr Sw+YJEL6fqc+1tVyN6ogTqK+WEHiNIjzxFSQMIx7OgJoRZyhcDIwK1ECoiqUqGK0MS1i7/RX1KK3 b64uvPD0r+Xq3ptUq5Nfzn1Wm2MRafUqgiK1FEwkuJQsyoMo5/W/2/sn6WTpiwLs14kEA4Z/gcHR ZI2f7mBvwpVIJm9AFA9gJEq4iicrvLmCy2qxM3n4d8XGZyFTpEGWan14BG0o54sSiMwmi+q5Z8xD ZbTMKTurMqQZyTTIpZ4rlUEyKkvhkOURaJwER6nA/WWJ8grtA4qkru59Jckuk75pxiJEm2HN6GZR HEVBkemZZBxk+TiTIgeTjkLkJDoGrZAdokWj4Erhn3wwK3Vfob5x4hQsbHw0tzLwr81cIpdBOm4e Yhe3jkHkJjqPetxyEG0Sk/D8yjAKtIngr4HxEftMy3Eevk/7mO7zPrYgUIlF7MaglZzuKyW37qNg I+kerwVP91nwNkQGZmIMA0uB10BSsCBkGquopsWAjuNLQTQvSdrqVitrk1VOAM0LNwAv1QmgyWwB kEwbpuMFU7AkSWra6NSl53LcDR7AdMjBhBAIGOH8zeTfHsbxyo6i3/swwU/KVHxXN/lty0ghPily cxldZ+nhMs7U2kKk54P/7JQUBe6ZPikHnSjP2Pgipyqk4150FM9BN9rThIOejecz/IKT8mzctR3A 5LbWSRHk2ZfRToZJS7l1D07a83FHcwDTQU/To73Ze2pr1Q8Q46P6ilRtoj1q7xK+G9uD0WT6AHtw YP9BAiUEZAm8p6uPuD32uFcXaotQGq/uqX3yCj+1hMx3neSIA4VnYUV/6+A6q5JiOiCmIbtWWY4y MTWRrbmUTGaKL2rljwAwn+LXcjJt0SAvFLdqb43L37ScLOsqeO7VyTjCysHRhsHUvYLVrXFzMSqL O2Sg+2MhgwtDExer++6QwTW+iRXV/bGQwYlBB260hpGQocXgigdYVo2zTnsBwQgEL3UMgpYyAsGk GhA6JkjdQUFYBFEjPUjHZORKpw7kxuOYSFMTpzMF+CwxFPWnMITMJ5TR2UkMn6Wk9zA+O4nw/Zyu kzcAB5ciOTtJ4VpcIgx9X8B30hgTC8CTE5wMz0SB4yXBJDnNYcLj3OpecZbT1y7vfcTK3WFEqgYb W3QskkFD2g0z/lOZp/kPP6CxgRhDx07/dkYbX0dvJEFG8QDBHZvSMyjClYk/C/9kFmQtNaD2oPPX U6AK/3lmFgiZwGSdKQ2JrVAiJKx/YuCqw9fWcz6zSCKJpcEeQQcl4kr7n0UiCRi7/P9ZJJ05byZv le/9DLL4J7L+tQ87Z7EA3yvk5BNeVDMUlrp5idtFhUC/gSR/xSrns5NJrImBWItMynVU/HCO9KhU ZyRR+MrZ0zyI0oHpDyqKq+LxLNwA1xSl7gxqvpjX+P4EQlQWDWOxqbKKuNtIgCo2dRcmv3pjQVwg Byg8yLDkezJMCNtLTv732dU0DYqBeQ7nkzSfiuFGowhXaeEIPIfSyV4QMfmvatomGNvGMxppi6NU +01k9BxkhPOhKXqnEgdQbpHpAuhAeeI5aOh6BHBNnKYoDpQqbXHndt+DpJ6JtrNHlRGV8y0S1iRd 31lSPXv47i3OqvyB8hhtUqrK1zn+ib8fi3rm5j9wrv/2i8kF6IxJE3Ko3qrAT+WlKky8B3nunpWw WKRBOmSpDxdqaDpOykZNgqvEdBSmkTMISPAHjUK5xahsjk4mHXId3zhvmmG805/3cH2IbTZloaMs c9a2jsF0sCbSI/2voIHzHbpbLl80u7Z8bGo+5LalLnxa1aCUo2JPxV9KWYcMT7PvTXPlKo182xp7 RnqqFralxgj4U+026uBf51+KmvkKCL6neEQkFK3RGtG801ZcPjPFCZA65FX2yo0oEohnig4V48Zm iOs1Ju1QiPs8nO26nuozzKisO/N1h6ekLWmKp+qTDoNhRe2ylACwqmbUHdtaHNXfFGLKvu7py29Y 2kCRQgqq8HSW9lMYnoteVeDbuCgjEcR5n4spLj5pONDJGL6XLHs+m/KVCrcnbRgqfbbSDHWsoz7o c4+TpogqeEupyx9SHBcDdICX0lheqlfHeMcn/j6r74UHzeJ+/hnoMNZVqtpMxNtusTA2ZFtAbuvF ZVMqNpMd/yRnzVax4UjKkyoj+30W3XP1xHkVcJQqOqu9Urc8tBGluq/i7I2tpGVdndZ0BKBUtUK2 MQC6kXVjGeh0QC22VHH7g078hnwJWbvvxYVeBtRaqd+VpJGG+SNKdKvsMK6fzzP0stUZQCfwRk6w deMDlh2K/cnnD3WlsCsA96nA15qW8EuSOyvgyO1DgTQvEInzUIDvjxwKODHocJXuOw8FnON19Eb3 Rw4F3BiYy7wG96GAgcF5KECiUrdaQZl8cALohboBeB1OAE1mC4Bk2jCd8wBZqJ46FhyoijsGLcYr HeOYDlQ6ZFEE8qhCx1dPg4WO3jQH6xw8nVLLMe5ErtOSI/AcShO/gGreDDwbb4ZRul21+qMwHTo0 /xLKaRNq8dImHKXc2cp2DKZDDuFYyi2K4o7RDHPA4baZ6vaYyXSMbxJ8vO02mI7RTbaLt8fMpWu8 9kmK+hFj2Yx32UqWkLrVyqcDEKXu7raR+42tiNIxFrtJMAAGpzD2dZS6peCewAAYnMDYgFE6JqiR KVqA4SnanRKlY7I0pkBh2rMYMFE6LPAjQPq7KbG6+DNPhNgL3mnkl3mKRDs2ah+pNJCaaLIkiAda MfsIUosq6aAqjVDjEJ9qdE9ydR52EcgfveuHyrsoqYW+xIb7aqEuvLfq7ff3195uv9mst7VBBzXD I+KYYpQElQ/CuzQMRcND6ymCOFf62VLCh3N0MtfF3YAr/BLbs0exJwnWCbvYbyaY628w34fXFF5z H+u52P6LJThf1YLSCfZNe/Cq4fXA0Hi9xOMgH1MuGrlE4D3fQIC1L9V1zdOo89Za3YQPG4b4xCi3 xqg7Xw6sWi9DrToSRTDO1CQDYUYDyx7XmcyhdOAks56S1KAfu/3t/1RTyg2DITWQVDSAOC9NBike 3jCCkr12YpdOWE+8RIVadDNIpYhy8p65rIV3gSIIfFW1SNU3KMpb5v8jQwYM/RpeCx9LgCfYKeV4 FIblY0z9ygUqwyDOLNDugk5/LgZ4og19O/CnMCzkGbaCFJF6yzN6oy/zc+opyXOC0ZfndBkSUHHG vSXqy5S+fG2io3siJcj8Z3qLCVvxWs9l3Cwy80rjFvoeDUw15XSZmQToIZE1sjCpKhKi6rU5QC+Z 2aLRhBaaZoou112mG5x00jeSu/3d3Xw6r1bYdQf6v5uvppU3dymnzII8snCRNteuAbjXTfgRxYf9 pTpGDVhlkUpl0Frbou2MNl/63op0W7KFkmwAyTIutPmaqZ3BW6ZrEUseUfN3K422ZIB7BtKoA20M 3ysTeZIOmOIW2jbEDIxfXMLrCl6/wevXhvqTVBl4F8NQqJHUZWtTqKuqmlWzwDGuAOeb2GMPmKQw xKSxhQffymuXmpM75qR2GcjvmWbOrcnzGfN2we+a1zNe906vXYuu8ltx1n3msCfa8uTaK+0stI7n +RIImqW9slqNZ1pvjemnlmkFgK3+MPNtfSPzLNk6y4lLEHT0YM1u9abYvlBitdQCHneDucMNiijI jwu+iqOCL1AOWTC+G5eqFhjiGKCmtr5+e/nu4vJiXPnMWf7hVFQIldPImoc0u3GWKbx+ZBFdW5sf AC7U5uYQR+/4tyx2U23197/rnX9t6O6elXCjFWmr9NbYJ8MRm2kmGHjKFGqztGpoaFw+fHg0bNLC b+MAfa33zZMepee581uDujTXPteWdDVufpI8x+fBugK9W297scCQV8ogrAptLMOGaFj5sky13hrD b9h4tNZWGxlPG/HVAZMgkjCQHaRLw6bVOrJWxr5FT3fXLLSSWT7n71baXLlMAcdT1rTOJ5YphLJg bV3GJfJ6a/3hlsnaGVCkw9JQYQZeMODab/3iQisexfxG0Gk6453fWvStSQx+8cgsMa26ZW+VBk59 befdigfWsOhbknLnld5mu/78RMEMKKK3hghfXWzpuz/eOy1NEaH1MHGTOroevBZFjnmBMWBEaGES iMyGtfVRTj76HKNo5plRz6rhFwCQqFkTNZu1s9IWY8FbPBjhZZyCdS1ssiDdcAEDlLSB3zrlDtT9 oXSLLSuS+Gd4nY2QkyQpOidrhgtjP7WKzPsJp3P7TJBPHh0nHxlio6sTtOcc4/CYekkC4W96lLON xbC7TjD37Gv61cqblrvKW9+5fWEG6bUx/GaShxEGD+OxvTmhVn9g9pPPyaMW8lJ9Mb4xzMkPbQwT 9hNrsbYVD6Zt2vaMB33eaF+71k5x7rdumyAIWjsIV9ISS4iQhU2S64dB9AYaFlPtSrVj8H2ZGGC2 cx4qHlo02X6J3XYTdrSrbM2DDpJL5kyzl0wzVDLXtZXeHZGIJHGh2tC72WW1fcTHtTZbbt4pt/PF k0elljUZ5O1+Wy68cluVLnXiapkxx83klYeVG+cvgcRBIiyiiLvn2iB1nI3r5z5y/HEAa14XjbGI sX5swTqNrijwUQ8LVttQ06dSWsMe93PjDxxI8xjDAQupGeAZvp0DFzOnMqfe+a3zn2pN0hbYzNTe +JitAsCl1pIxDYnSIBtw2auZa5CO74yBJMWPrPfa18xNRXXX1VQxzsB200v/Z81Cm6CJP5hRk81V +r7UvHowUPVDHs5ClCyufF0mbSXeXdmTBp4bMjKNnpVZ37cWsE1DTIHZ1RNe2szpPfHRNpthZiq+ amg/IHiRBEnfNNyW9fTBW65n1SsqyJeLhadjNY/bbiGAW6qfGGJTUS3KuprRBbbDIGhVAp5ZBXZG XVfe7qFULUJwccvoICZ8nM9gpLY8aDzO6Ud2xkgHhynasGgeVK74PYekOrIGsK66CqgQvMu8M4OL Ei7YWLC26nIRoh8mac1tMr/GlJMAzXKZ7UyNIkc3TxwoYXX8jdZfvW10SE/5EPubob3UMVAcb+iF mruwv8GYGNOUHcr2QMZxXuh6iKmei/VUKd7ug++SOUVY5vh+9tqP86LhOA/9uzwu8owdGCA6j+VR hRgD1Fzzu3Vd/XhcGZ9V0kSkFo8PiWZW9Z3r9JJK2p0qemTV68+te6EucFO9v1OwP7cK5km/0t/U 4qV1qJBbpf1Lm6rUJEAfGGTWFA0kUSX1WvFSpPmRxxBhnnbQGVc5P22rb8qhxVlrbA8TOsyhy8g4 atCryy2s+gDGOnDgJcMcxxRzMHVKU1sL69bu2FX51gQ1JftxJxLLaCjhny6qcut9eqjqBzL+W7Ds 8x0Z/0/kIPaLmQfB5WLBRYH5aoqxJnsG7nWuvFlZl169paPi1e4OUFV3VEUgZ4SHJNOnwLtiZ4Qu ZNrgobmc2RguIVEP+DJnYLBOx1RV4rfX77zdk/6tNwqWdxTk3pY77dlqtElEIa9xDq4Oy/2NZyun H/f4mI8aoN7YsXrzFa1H+9RD3i+OcqxJcXx6u97XCg1x6FG11i549eR6H8rVCp+jxvpf65rXdzan IWt98+vlzsPGV6QOAkAVypODV2/k5Zfl5/mSRHiUTcLfc4xNqhuTZB/hhbxL36g3QToveLfn5tGb yEPbQMiOgTjy7A2f8xF9H1M/lMTS9Ya1F+SyuidWTB+YPcBSTzFJa+ptOf3XXl1sNCgz/sNEa8Gn hzmwnvWUlUHp2LRacAMEqw7dnLGM1mP6EMb4ODTnnutH0Ki7NmKb7rfbalWbu2GjF2SthWOyKcEs 7Uf0BtIkY1p2sHv27CW7/7b4bdQ6qTQ7mitZC3LnVTlaHgu2jZQ45mjqu3vfLlDowL7m70sTeMNf 6AFttu6UQVSIQPY1iTUAwulHkudRG4ZTIhMn7xhUfNMTSMtbhR0vQd4qs5yOdnDWgbh16N24dPsk PzP9Y4Ptcsh3xdqJG28d36f9vfaMYuhIf8xPW5GF3v+paRWaCMFax+CKdRTUdjiYTQRD8U83pBBm FNPS/wUO2pD2TRvBm5G1ferEwXqlg/IDhaAIf6q332aDlXgrwSt3u/V0Xpr+bqb8QuB512QuwI8r G8VOjDzD+pPy1K1P/LivtnNCsDOq/itw92zcPpG/IR+1XnIQcD+2iDQNCs0jSD5v1+V25mmvdlvh aMKj95sriRZ5GuSpifBAXsiHEBYFzpIGlVkt2O6Zgj61boyOaYnMlG3X9kRwTNY9ANdFQ515Ncf7 3ZOvBb+a6kVTUxnquRg6mGoqzf2DNNkl8hhLhzKVSSB7iqk2I/b/0HsuMd4N6adyM/qxG/VZ3T8D Uatth3se9yvu0ha4SGiHKyDCxhcKAqGFGgGbmlFHPErQ1M0UhaSXnh8B2gEaSCg7yReZRtGlmq8z Gt0MyOOW8jwloPyS6TQJR1PazqcpF4xOrfs4+yNzzAxMOdBWsGXM9kbr0Rdk8lESBfFQoQnCpY2H LpIiZ4yUIPQi0+NpUwOhz23l1VuOVHbLed3YJa43KQuGtoTsANqZLecIHLjuHsA0ONs9IIfJhEXm MQWDZDjdjyL144THFAwcXbiRyNqEZBzDUW24USiD5LhOEAPU6ti9ev/6l98uL52tIFIZU3OekV4Q rM5YsBdBphqCSXwXJGndFdxpCOZMiZVkt6mm87unOWnQvUfxFnkk9k+UENGPquAzhs4jziLGhz5N DhyjBY6mVoHY+jo/byunra6WnDOWnB2WXrld7yGzoK3Ai5xbCYEug3V1eniL88GZSdR4ZxmfnjlW 8WFyYbl69fbnMydnY9mZHX+naFdDJj/SVIVPq/To/UM39uDh8+j5cpHYE45L0dGThT/UnR9X/Csc GNJ8KC+4WnnrPURDG9ZckOQrz9mrKVWftYmKuEFHsQcOAQXwMnYSMgXlu3WlY1FYYADTn9h5vidA boU54EY5Bx0hVGPVJO5ytgbrmMQ8PLn3ucLd6bqwi+dt71Trrz7qPvpuH0fbp8gnj5Xm6hhntV4P c3Z+N95LcTxX0T/JDlf7B1N8JqCXZB4adM4EnI5ayFQ/BG2uhON6rKpxiQsc8owtWKXrXfWDN9sv l1zMU+c+lXelLi6cB8hFqvTFmHc8Co/DCH+gyhgwYsPolNixKDS81edySQ5lUSlLzBe8zBWmE5v9 dkMVkV3lWgb3sxy/DGxqkflxy5BgzuPEhm0Dr/HqrEjioO/NH6rVtHrlfYI1kwgrzP/K2ioHQuQF /63WtS4AqkIty5zjr2oWeFd3Xul9pGpgtX3ydJF3xuXQCgM4rKXNtFtXqsRKw4WwsSXEQj/ZBJqo FMw8U7y6wFqsqYlKW8d7WiycWCl2QEdCKVsLfcj8RZnSOBP9Tu+9fgO2edLH5myrd+m93xbku217 baJmNFtpdPj5k9/r7+NzwLZ1ZCiCNzLSNk2UVhf3o3Y5Rru+W3aiCIaqq5W3mO/qpgDNIRpvRK5a cuk0IKFCcLjFA2SK/qjIulD1aQj017qqDmap7Kgoat98Vq1qUrW7J+tQ4lClXYSZfsKJ6J6vpov9 TOMmI0dI2NKh/pfqWIMLrrAB1tzhuKItUbvyEG2w2kmPiUCTcDjyKJIgG/z/zvQxiGOyiBwsb5r0 pHnz7vIPZ6zPh+nmUN33Te2Pua/bvkGTur2ydoMh75C3ei91+76HH3Qwurvt/m9ptn+7vBNEf8Kk /qbdoDYWs7nZ9UhDhO0aFrIDjz9YsFY77tf1x9Co0RjDmrJfd+QaQNvubje/PHRqSs59lUF2EfZ1 CXfYkhMD3CkjLcH0GzUmngOPylD7uDHgpqmlNo+rNC0Zun1ct0eYvTqltehO9KkfdNHm2u7cNx81 cj9CcLAp2MG9kY4tPlfps6vXrdI0HiJ9/zJ2jZvmpv482q5kcd6dg6tAyrHADxCCOVsL1dPLQd5u 1AqPW6tlc/T1tyBzJoz4sxixOZ7Z4+wwgd0icnvCnon9P1jOOJQNCmVuZHN0cmVhbQ0KZW5kb2Jq DQo0NiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwv RjEgNSAwIFIvRjIgNyAwIFIvRjcgMjkgMCBSL0Y1IDIzIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0 L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50 cyA0NyAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+ L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDk+Pg0KZW5kb2JqDQo0NyAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCA1MDg1Pj4NCnN0cmVhbQ0KeJztPNmO20iS7wb8D/mygDhjs3gfxmAA H9WDXsBtb9uDxqLcDyyJpeKYEmWKqprar9+8gowkGUnWDPpt0FCLKkdGZkbGHZG8ett21V2x7dhf /nL1tuuK7X25YzdXX5vT71dfn07l1ediXx2LrmqOf/0re/fhPXv39eWLq5985keuF7Gvdy9f+Mzj //ksjlgap24YsK+Hly88thf/+9vLFzebT9uucV5Hm1sn35QtC5xk4znRxndeh/x/v7Ov//3yxTXH K3ADNj+MXBPjzYYRsEGWuV68DjZMc9cfwe4asZKt+4Y54eZnvrLr62vxmPFHsdBA/LMrlh0QWKMs daPAxPqags19N89MWB/IcaWnlD8C/pCKh9bJSELFse/6I0IlJGzm+jSdfogTe+25Xp54XsYSP3B9 vqmcf7G2fPnitz+xoz7ZOHDjhGPyxVfsJWJHnpsGEu7uTy9f/M/LF+z643t2RbDYu6brmoOdywLG px+xWMDZQjCeXPwXQZzL7aES3+ez/GqOFEf5fGeJiYDkqDRwA9+EPRX8OPYl/x85Kk/dNDVHxRQf eqGb5etWE3mBm4zwvj1dWifePIhFsV9c9rHZOa/9bPPkBN7mFXNe55t3Trp5e804kXxP/f0sH7vy cLYyCLmoZzNImLhhFmEG8bxwwiPs6rPgjo/vf/7APIMDUsYPjeMZ65kgc+fWN8HmI2x4vJ+4frIG QWAsJyaWI85SYpPEifjz9mbz2WWf26Zrtk0tyc5+LX9cqraUPw7q69id31DsmmdujFF7Eqt1teH8 dhOuceJV9IoIBEJpZhrBDcU7uZsmGBQT4+3ffr2+JgZy7R1no0l+p2TB9zzObHgWRZfPXBhc/uGK M9m84Q+Mf77yzz3/lPr3iX9aAdDwhw4etvwjvmsN9ZF//s4/XzQGNZIDtxrwgX8q/tkh1IUAEA8H 8VBqtPfyX+LNUY84SwA14k5i02iZXJC5WgF8EQC3/OEfGG2HRjT6eYem2MLWHjQ6NQVxbpyno8Qk v5VJYoJJEi7k0eTku/uS/faFfSi6QrL8bXEuWdUx+eNe/e3MuoZd+N+LTolKwfbVQ0kqZ77S1JhP 8cARzqDGR1toQlWaWEfJKSbqeU0TRoGb5ngii18RZUJHk7ATKiYEFWOufFcdQ7pGNSV8C2G0TnIH 0OdKLp5kSXLRLKbkBn+M5J4F8EWjOOkBLRKiFiRrD5A14hqAfkJi1oCYF5qtjnYZ1PgBzTrmiyLf 9VKTtqSDEHGui2nYCe9kBPMFubDTKxDkq5jP5/7QSuYbQJ/LfGikYqjfiQF5xKkzWtUCs2JQ4NPw 3+fTWz1CMNijfi4FMDDS2BQcwMKcAe2g1Qc7BHZpO7ZLRw00h/o3AfBF/uAPHxDrF3qlheZoGKGk TI/6arEsEXdhcgvBp+6aR/ClF3M/csId58vp1LTdwnGjsVMXaubMB/gbRCxpWYhxQegGiTkQaFfp U680TZ+siJJcWmKM6A54qKUGZYmbjQaRE3BPPQkocgpLTZlcP3aTfIaWO4NftK9iMgyBMUndJCaX 0tCxfixi/elKhORdQETuyagrE3EdMWt13KNxMozpB6QiduSMHIgwJo/zPO/DGGOCIHYjg1ASzQLn haHvBrF5hmCyBgprqT9bqBqmqRul9P4m2wN4tT0eJgT27XGlm6/ankIP4BJ9LBS9FTsX2TSeYL/R bptFciIRiY4IKA0wdsCPmiVBCxdaZSorzoHB7j9bcLmKivNQpGHGJN/eF8d9Kf1b5eleSCWSu16A 0dxsbv9RbjsqVPeT0E2NadUhjL2LkXIxJiD1RBoLR4KEnSpuf03YHmeem65yL/xVcXecZENca/cv EOgz/Qs8cpV/YazKbmsMUPAvov/4F8/zL0iCT9mKSJDEceKGlHvBDhcVlV6KmhWX7l7+KI8ql1Zt Zd6SFer3TkI0rfxR/Z/8kgArI05lCNB6lgxHKvTeAL9EgGiVXEXhEMQuyNUA+ly5QiPXyRVe1YJc YVCQq/g/cvVMuaIIPmUrIiUUc3ZOSbmqjkquyn1bdU9MpYKOO5UB2jbHu2pXHrtKyVAtQE5Krhoy /+65mY9nVYzVEx5yZ/9CKogLmhci1LZMUODmPgk6JR6RCYr93A39VRhWpYJi4YWl66R6AH2uVKOR 66QarwpENeGfN5DMmxdVnTvt4GFdKkiHCFQq6BajvYcFXJActZprCi3c4m9Xjs4Pg8CdtXoA9DuQ UuWJ8gcQakgY7Z3B0yz6XRDSyZ0z7kUZhLOzB5HtiYS77U9d1lJU7IRdK3VyVqRsd8p/LS7K7N0L yZSmT0ntOikKYs8NU2Niu30LuGHj9hANWNrrqsRUlAUi7FkjCggUE+mX69+IYamIdUZTkDlRLTV4 EjMpmkpJ0OxDS4Jhs/SDTRJajeUHpDwr9EfT2uCyBjB4h6RB2SKF/kM/Wq6B0I9JLJKVBoHoeNYX B2/AHpzYSLz2qYfKiYcSAOiDAcIsnTw6OuiDnU5tLBnrRSl3MqaCsyu6QlY3ClVnZedTueWSpIyc tmu3T0zkWepmq+0aj4T3l1o7isq8tSQ5fG6RUzz/zaY4s8eyrqkRcSSMCF7xgkeZcMic2mIhI9nz SW1JbaG6e6Lz0jKHba73uONbtui2JJlZLtlMkcnSJrFcTtrq3JXKa2DqILqz7WTj1M2A0ZpT2XIN d9z3rgnXhNvvSgOelD4U8f2xrKkgPQh8N4ox2iWFF6Qi32SsY5ZVC8TLNQiqkk8NSZUUseliYA1B msEzAsO0BcGSIv1EnUIQikKZsWoqDxEFuRvHJqy9BL+qJSCKYjdeZSICf5WJCEM3mOr9Ty77pNhC Gz4uwKKuryRBMVp5KC11fZFK5U4qxr+ish8EhA0PPOFsrtk2EftGnixcrrKFA6jhFn68/uXD9Qdr RGbMQpcIfV/kp/E8ijafBPep8n7cx3BvnX83yPoogMe28YejXD6FRHK9FpRpCBbrCCweBWCziXAo +Wu0vaHEKM2cZGykJGvYGh23haKEb9DazhNEv0eYJ240TYiAsusNXHPXlUcGNXz51aomF64qnxSM sHZcD6sMSj0kRNi3DWUFdN0dr8Ke2xTFd65T0ICbzd5uEQ1YEq8yhgQ5XrGf3lMDMy7d4cwO3hsO GD9PxW1ayYIHdtZQ4MAMPGsNCYw92Q+eCNjDLJoL/LjGY7vi6ZvDOqX22EPZSruvggF9qvKshdWE U+amc6v/UaXHLKYy5OFuGhorUCR7RQ1QpRY0YLHAYsBCWQBisVuwoILa37USOOl/VM08OITD1QQ4 L9wLMPGgoRcFK4RGKgV7ZUH4wNmU+05t81DtBIntyhQPR+mQ1hkKI2e90QIz5hHUE/gNj84Qoypy WGuFaF7afdP+kQE79C3JZRIDo8hNfHMgxSg66jRgbQGnH5qw41CiAvJcBoVs9mKBHJuhiqYlreJ1 CapUxs7qapGbmYp6ssZ9CrmFn43GpvhWJZvCKBUKcI1XgUCf61UYsyx5FXiekVcROH+4VwEDuoGz dVANSgOGg4yBUqk1Y21B/YwzmKTSU+VUg0ijWKJ3Q+KJF7LVn4vedQFZNhwEqCovzJMJVzTP3NCL RJ038bxgts4r/BTPOHhd5y3QdsXO9o72vGZCIFpfhpGbxdPiNw/8LkeR3FL+SkX2iatKLELDVSYZ 4vqRKL3gORVvfdtoerpi2Xt4eKUp/BP/vNcfMyET63yMZhHsDvzZEclGqikydCPfXDWpdVUDpQG7 0G9hwMZ8HZ5YoJCRb46NBVXCgjgSkQoQeX51HruSnw5THmL5oL5q0uMJY+nF4WVxh9Ldu69YLsfG /8XdFYpLPNlkOT010yfQwt+bw90C4wWBsElTxqPGcB0uRAWNs3W+6FwhngXsuSm9O6wo5otBemfN WAHgrMIYrdECjXMG9CUKxZJ4eypk0gWrPvvQ6MWB6jO1Wzw4XbYT0LlCY7pbLU53+tPHdAuNJAaS HWhpSH0ClyilTyCKuR4cISInTSKRvTJgwRdrIENL1wJphuSmOZiK3a58qLikbYuj8t9vS1bsdpCg 1DlIdii+l+x80fcVuGsv/XsllmrcY9OeO47mrH+fq+4yJEZoCmeikobWdjMfNNL7CriN8fx+7P5S q4iStP+pG5uDzNhTWh+AyoXz2ndCkTZMWwmEFXdCuRPsAC7RQycUjZ1rJh7QjbGbUa1CDJArEUee a1JQI56uGCDXIhZ2cIp3MHicj5XFm0ykRsp5BJnszoPuTZrONOk+6yFX7iDzxd2n8YEa6WTJpmf2 Z8mlV5MJNQY5XxLKS1S2GXUQQ/DQ6zH6HnzdfnTYs4JQPeRaxDJGmiLmrsAEswZdiTnx5aU465Jn ukgN2QZNzYaysLbfYGJ2zmC8SqRWjTBtalWht1+7oX2HBvb9IcivncF7rgF4bNrAr+uxfXdQdLm3 K3fhmCVT5X6qi624R0M3yMSiXRiPVux2C57OkKQ0K439NrbTVapNm5nT4c5EX5uciiisJnXDkOsQ 7pZZO0SBU4fVT4RUmI4P7+ze7HT3VLgtWkryEA9YCo+zNeG2do3W4FtV0BaC48H67OE2An1uuG3M shRu43kW+u6V5Z1f1yc3fMPesoPKIsIF1pZpJ0Y5IvfV9n6UaRRNtyLk6wut0kPYqUJNq0qBx70E wRnL5viKlLlA3tu272t6JZO40hDwaDmbBgsf//7lK/txKds+t6puz+H6sCoy3zWtzrw/FFVd3Nba UVPuV1+67KkiE/cKplAkuWdddSD9LOHARqmxzjXbJW7cBmHixtPEMo+NDlSfQBa4WWCOVAuAS42g Pg+g4+caGMBXRwUclLTDF7amnj2KlCDe2eoBd/q7HKISXfN5cubDJ1jc3tGJQ3zLbBzwfNuoVVqD FEQZS7lVudsGLFUa0blF4qxcKr+qY/HpQS20BRhrGidEBqL3FgdTfTh9eeHXc0RGgpDbMBeXAozZ aLsai453ggIHS0aBDwoiUbpXE9y1zUE3eqg+AaV/dAvCqmYp3bCP0C7pUe3vogFo8c12ezlVPMZ6 hAZmNs1MzBsYba2mK+m7ZlUqVIfJjTP0zNVIIiAbvoNjnROTwYfQAk32HGjGxlSf+Bc9UCz8ykX/ EwRgwDlxL8TBTmaBYXIW/mMp/8kjniycTjPvihDXQ+NAZDvI7U81M9FBEHBzna/K/IfhGlfEF76+ v8oVQaDPdUWMWZZcETzPKPMfOTHRE84B+mTVtMBPdVjPZP5xl14vI7tx6cjeBKATercONPvgqiQK RY6AFpr/4AqTMnDWVJVB0oVUlQE7JE0JmQbB/yfs/gBJLfUuBFKl+iIumOrh659//UxmSZXXgEeq I4cqXuvgOjtKQEKCDeoxffFBVfasOhdNZ9HPMj1A7KnkThkxTFRUspkdQSvY+EUTIyawFjqNhT+i c+t9plGnwmB8oQkUoucJG4jGU1FN+18EUAPVG8Bvisf0xRrgHh2wxOCSLKylBSnpY9OhikZzGD8/ b6qC7ugeTN3fiwZObs5Kbd7DJTKvtWgUtF4b0GKbUDpQlNP9QvRdZJlnNFY35Q99olTTqPY8DCQL TgdBx+poS+XqTgE8dijDkDczBwVoLTsYq68BUV/MJasIXiA6Eoj9iIrVofhndVBx5IE1l+6kr4cx 1RXbPJbtmBd6pJIX/DATVsnuIUgPmeAG22sguF9hsqYztCXMNHUPNszs6aYFJgnmXtSgwnEqCMkj zk/m2DWxZLQmleKLlNCqS6VhvMp/4afjr7v8hkCf7b/gWRb9FzTPyH8Rpdg/rHPBbjnwDuj8rEzo GrC3DvZ0dNRcj/2hcbpwpvPLwDqfe1xs2uwrpcjDGrw6u5itIYBw0+PRUnGClTmosQFcSaGt7pDR PIO8PmLLbrPugo+DGC5bjzr4hXGr6DZ4lY5Dw5Xaq45bVZu/7HQRsBurORiZCuvBlZC/UEJTb6NA M+lsP7cYP71/z36W83xgzZ0wIvpKhfyqi4epwe3Ryen9MBCZZdv8wEaj+ZENgstccBe0wpX1wfeh ekDlyw8MQg7Cpz3hrTXPo+JK4iTPTPVPHJTdqepyoWzq++FwT1r38rLiQbfD1MVtVVedflmg3TEY EK1LSeABaAffpvZUuvZqEfrI27K5++awc8OGPtNCbFuNgGoz7MfSIZs8Z+X6YgmxclE7v7XS2vOH t6mdy7rcduWOS57aknzXGdS6Ff3rWpzeWWR7FdvbGx8Rfr0R8gqKKpkYC1oKCjAsdiCMV9YdcEMj c4YmNrgdDTruOyUgqhPbmG2hE3vVLvQFMwP2J3vTCCYnOuZLy8+EakGNvMQN85mTmOSjFxKnqzYF HiGGhSjo4EASHMVt814/isBI7g1Dd0S9/vLfk93mCI0XTaWlqM9U/KyjJDzQLpc6vidmOpbioqrV mZpONVuenAmq0EjTixns9mu4Z64t+pKN0LG9gRk3kRdohgo67nDTMPgQj+BM2U4oyGX8QdCua7hK 43qVVGtaXqcE/Jc7561iYRCF0m5aLAzYhfDIgMXaDfIT/dsjHw21txga8egu9eZ4snts2u/CQilb JczU+VGXAvpSnOivemz0DZmdsC5dqwcop+dUtOWxE/cvwT4KM0JrJ0/ch8NrstsJrc7QgLl8ugbK 1Gt9F/PpqlCFcGoPr0/R2EsA4MprQwMyN+1QmKT91bxqmb7HozXrOuWLMuXrCGZz/kVdN4+imNr3 v52VByqPSrkpshptNm+q9yCLF6Ny7SGiX19In7X/JfBF3WmyFiJY/n+GMWarDQplbmRzdHJlYW0N CmVuZG9iag0KNDggMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDUgMCBSL0YyIDcgMCBSL0Y1IDIzIDAgUi9GNyAyOSAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAv Q29udGVudHMgNDkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZp Y2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxMD4+DQplbmRvYmoNCjQ5IDAgb2JqDQo8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI4Nzg+Pg0Kc3RyZWFtDQp4nJVa3W/bOBJ/D5D/gY/W ImFEfatYLJA2uUMPSLt3SZEHtw+yLNvaypIryc7l/vobkkOZtEwli0KVZI2Gw5nffCo3t21frrK8 J7//fnPb91m+KZZkfvPU7H7cPL3uips/s3VZZ33Z1H/8QT7efSIfny4vbv7BCAuoG5Cn1eUFIy78 YyQMSBzG1PfI0/bywiVr/t8/Ly/ms6953zjXwWzhpLOiJZ4TzVwnmDHn2of/fpCnf11e3ANfzltx Y35ATY7zGbHQeklC3fB9tH6cUnZCu2y4JDn9QBx/9hkku7+/55cJXHJBPf6YcrE9C9cgiWngmVyv bbQpo2li0jKljhtcUtx4cBHzi9ZJrIoKQ0bZiaIiK21CmV1Pv7jFrl3qppHrJiRiHmWwqRROpC0u L55/IzVaNvRoGAEnxk+hG/EduTT2BN3qt8uLf19ekPuHT+TGArGPTd8322mUeQSWP4GYB7DgwBPC P3Ll7Bfbkp+7Tpya2oYoBjuLTAZWRMUe9ZhJu8vAHOsC/rO+lcY0js23bKbwXZ8m6fukCVyPRid8 b3f71glnBy4U+ULJQ7N0rlkye3U8d3ZFnOt09tGJZ7f3BJTEXPl7Jy77YttNAsQq1N8GiB9RPwl0 gLiuP8IIufmTo+Ph0+c74hoICAkYDficxhkvoVI+IU2QkKd8Ptt3Bek3BclAKXyfZZUtqoLk4mYj f6vroqLajqSswNEHPglhoUu9FARNo0FKw8JuwJ8f1xfvwyO+vq6p0b6Ysa/Ysi8WURadUfyInfcu NXGMIbe5zeIpjSONUlfo7cP9l7v7O5s/uS4PJtoaP2wAZozRyNNXkRr76lxHMwowjuD4AAeB4xbP WzgyTtDBRc8vCrho8ekSDn5/gKOEI8d7/uyBE3+Di0c4nvDHhUaQc4IMLnbqgj+tBgqLy3ohDVKL rvqGnMJqoIcTQAuCLjgVh5brsrPo8gOPxvoCgs181qysIkVgg3Ss2IOVPqRpaNlCVpXLrLfGIEAY G69UnO56IBS7DmmSTO45gNDgn9kzt2nNrbO2CeT5prIm4qeX0tC2ax4xluW67EV8yCorkzShaTBW wKSb+pqbao4ZQQkQjgNYXvBcWeZZXwhhCBieiydunmUcJ3dZny2yrrDlIC/mmUtfYSyn8YLv0TTW X5hLt6vRy7jDvMCxQffoxfXgjnBB0Ad7pN4Izw2F4+quVyi2BB1ZOXADx09FINeEi0Zz9xqprPDk +SY1d0GttBC9T3Y8acXgPbE74oXlOSSO2IXvid1RFHG4nULkK40/kFuyzTqJVyinl8WhlDkOkfLw 7fGJLCDxZTuJaZ4FeXziN/lGkuY/BbQOWSVz5bLsXwFvEmOSNzx+fhxFNSFbwsO5D3k/8e3Jktsk ZvpO3p0tI4vfhFCZjF1YuQTJpd8oL9KVktVL8rIpYM+t3GPZk03WyYcL+V5Rwz4OzU8oUMV905K6 6c+VC1EYUQ/KmyDise5cfDuPEwyO2j50lcw56v+j/GCHDpJNwT5g1I11fvPZFbpMN3idvNeSrS3C +bxANpj9mI6GBu2kRWOLRSHl+e9ywuRdXgORPh0DZP7l/tlanEDzGCbGq+hm1mImpqFJ/sRzCIBQ gkmeAI7bfddzR5SOl+2EI0pkoaP9LIpdWa9JL0GZgVfaMnfiU883NihBw6PiCk0sqiQZpy1mY9Ap +6bw9qwpEqxFpfkm47V0Z307DmkUnZF3kDEbMoalMnUFtizrZ21hfRGMCTaKFazyvYUQiqHQ02lR xNZCHzNRwukvaBK1Rd1Xr2+UwOPFFiqVlpjm1mjMPeqn5ASVuvgferTKzDy3vg7mP2ZpkUG3WiLu 8cGxgMZ1D/xCL6FtzaHPoFfwTd2+USsbtBlucGmIi1IQTcQc9yGTPu6+kcXgeLdHHOkaAGJFuNeC Ib//PlMUVKgbL66msAhWh4LWH+PwM58VJdCge55w4SsifxE3rvyNMpatrkjR51Tcf3dOS5Pz2cKD btSPjZXfqOV4Wgr1F94Iqun5qBxCJmDvisrMtXBIoNk/o60VySBN/toXOIogK0iy/cbI1IfspHPn gYaUMqpKmm22LMjilWR1I/lAWudFkbyxBj+Pj/500VQPAxBQfvGMfeMd3q/QZ3ic3SrHMj1NwitD gkKVxJliq7L4BLpCKKnOdAS8aoFCpeyITBjNHn7ocZbRE7V3UhcvXK3iHnTb85yCipJq61WhiJ1F X+SbupG1X7OWEyIoGGuod0jeWKecomLWZZUKtI46E2h6bXsr/lt2NlOFfBByZqEr0wAYO+o3dAte 4Z/p+zLYqgCX2H5Fuk2zr5ZSPwtEZFtsmwPUg1L9bbM9NmTZQZ4UWLUJU0cqhKusQcm6EVm+UZU1 GJSbbELmwFdF83wmDUcJ+VZLUYuu43Igb1nAH6B65W2Bqm+fH+/IKpNiVB1avYEN2SK2z3js0BZ+ w7i+H/NawpD0F4bboTVUMfjFObaImyHZ2UYNYiRgMLaWGejTOq1WBR29U1XTOS6+wrPWcsqHDQKq R6fNFdymrAW6i0cI2xVt2SyvjpZayj5FD3YSc2C4n8oxJSyxZ5GIguiHQRHNb+ts/Tjmna0mznS+ wKLySD8X07d8UAUGsKUqEVR9UmEeVr3GqPLYaVGzx7PSbiUDpF2bUGf4bKROVNWubQ7YslorQBa4 1GQk5jw26jCmiWcsO602FkFlbHI/GVaapZaeUroJJOEoxmD8olSvVEyGZKKlG1laieVtnxs8GoQm aysq3ISPkCxmEDGkKgYYg17LFruaHc4kMpGA9IjIe295I0l5nplAgBvztlaKWRfFsljaIJ8GNIiM N94zX2DsfNkSALv4nH7GHDwLh8TjLniqtS9NX0jffpHg7QHNPcl0nWR5D1Fc5KTB77dZLWnWUn1b aDLIthA0kyNhTY75rOy25PusoDJV0CsZamTVSrqdZJ337X47YZQgBsYD3kGuddF+d66wMBNFyr7G adJPCQRoh8Sep2eVGmO03UZ5k5ru632RUePbP8W5NGGmzEvlKSq0L5xje2RPiyLLGYysjiPn9wbt X0MDMqQRW0LCdFmqKanasBq+qh5NRYFc1UCqsaqRZeUcZ69aEToddQMeBcfAHapx61egkCaR8fYb wVM2wtoLmLEblPg0dRRmEtYyUY663TrHGbNK3UTpXAXi0w9Fk4E4CfkfFBgyNirE6gHYgyNwjlPv BiVq1erKTq94fusbEw4IjZWHFFCpXvj0e1aHy66cY2GTq7dOtaLSMVHQGdg2CLYplAQhl+8UJdDF Tc9M9Pem8QEljBsZL8wNSCi/adUWTn9UHl46WMHUOuVqYn8s9QQ0z+9xu6/6cmd1BM9PaBL+jY16 QUAjZlsNynfrbM2LfRqwM0sNH80Gz1dfWzIn1FrRyQ7A0Lw11GFY1GnNGh/1LadYk+Xq+xaUpapB q+JAr8Jbq+JooW1XRYpJtwsT6oc2Wyys49QopemUHVQIz9EE+ihq+VZA9mHHZwLytuGt5Ib/EYdM soeis1VHLPT4SF9n9UZ0lrWw9gJA8ViCYmN1NOxEDHUDymKTk4lCLUjburNcuW6uTKzsrTy9QsrT ueiIrXpJJQxtQIpsObs1vrG1BM4h36ofl7h+65xkqu4t83ouTcdY4xOfv/brdYUTMuzpjW/Adzi3 qLB+7LpyXUNlKAsxfO9Qtv0+q/hEWpRkdddnNX6iwJFHs++q16vjRKMtOohxqkKtcCwysQVoFCJl 20VByrpYrcq8xI9pPeF/kWN873jelNbYm/CZpcaSqO8F0/jSZVD58BFTwtC/2yYBEhRAIFEhJsGT DZSx3KhB+D/NY9QkDQplbmRzdHJlYW0NCmVuZG9iag0KNTAgMCBvYmoNCjw8L1RpdGxlKGRvYy46 IElFRUUgODAyLjIyLTExLzAxMjdyMSkvQXV0aG9yKEFwdXJ2YSBNb2R5KS9TdWJqZWN0KFN1Ym1p c3Npb24pL0tleXdvcmRzKE9jdG9iZXIgMjAxMSkvQ3JlYXRvcij+/wBNAGkAYwByAG8AcwBvAGYA dACuACAATwBmAGYAaQBjAGUAIABXAG8AcgBkACAAMgAwADAANykvQ3JlYXRpb25EYXRlKEQ6MjAx MTEwMjgxNTIzMzcpIC9Nb2REYXRlKEQ6MjAxMTEwMjgxNTIzMzcpIC9Qcm9kdWNlcij+/wBNAGkA YwByAG8AcwBvAGYAdACuACAATwBmAGYAaQBjAGUAIABXAG8AcgBkACAAMgAwADAANyk+Pg0KZW5k b2JqDQo1NiAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiA0NTUvRmlyc3QgNDI0Mi9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDU4MjQ+Pg0Kc3RyZWFtDQp4nO1czc7lyG3dG/A7aJmsWlXF+gMMAzGC AM4M7MF4doYXY6cRJHGmjUkPMPNkea08QZJz6pL3uyWJ6uosgiyy+HD1SRSLRfKQFFWlLNu+lX1L ect9qzgOWwhhy20LUrYiW+iylbTF2LeSt0iSuKU9b6XhrrSVuqXWttI3IUnZBDfVuOUQtwpGUrcq 4Ne2CuKYtgq2JAGHjiFxXvatggoX2r61gMO+NbBuYWsYHUP2hAuQZd9Bk/ArcWsFv/inZUqMOyBy wFRaxW8vW9+3EFMFC/xibHAKKcjWQZ+kgyd+cTNIg2D+PeIXEndoIIe2dfDJUErD+cybdjAsJADD uuPqjisVnMKOW+qQB2O0CEF2MG+FN+FsH8SZquQccLkP4rrFPXI2HQcg7m2LgxdUFwPHhSVixNwC 5I6x8MwwBc+ULSbhGVglVZ7B7RJ5Bowlc9rgkyklRok5YeAIhhmqDxEMCyWNOw4oKYaJNfASzUwH CLhUOXPQxQYTQY9b7IGKxKWeeQZ39aFaegXUDR3joPKMbImyhJRwkHmm4IB6hboTpMcBvCcOzrhE 6wQ4Q0q0SepbEtwaMMkklVYC5xx4BpxzHnbDAQ0JX00l8Qw4l8ozcM8aeAZD1MwzYFgHZ1xq4Az5 U+eM877JDvWFHHFASUEv+/AE2YTzh0vggHrCuNAyz1QcjDNtk7QPN8EB5KYbSqLIgJMIRQaERDI9 KOOAPkqoZJofYJBchnMBPIMYfAqJ4fpS6CsAm1QSw/+ESAmYozQSQ9XS6IUAnTQSw77Shxg400mc Ae+98FIBMMtwVxzQFPAcSEF33XGAkQNglwlwemBOUDo8GQe0EuTOQrsBN5lgCUBlxm10chxA3gCt 5RJJDM5EegAyc6UXw09yhSYCTJZbJDGGaIMGZwZOAILcqVUIV3bgKO6MUMJLiC87RgZqEKfoeQBL odoigFci0bIzyAgvIb5EugYsXuBaOMAZGaBjYMvkjCEEgvPOkuncQF7JHAK+Xxit4s6gVolM3F6J KHhpqZA5wrdL23kJDFsmH4zOkBV3RkQhHx5g5Ig76w6QAM84gKIiIFgfwEZQpOsB4TiAvBEQrMQH /axGjo7Z1kTMQ8qa4JUREETk5BkeCM+ATyaeMUzN8MoInNUCbZEXROYl3F4aiTHWmA4cBQ7FaIKx GhQZGY+b8HaISo9iCAJyIuMLYjTFgFs0IiUK4zTNBAs1ojfizkYzRoCycRwEIxx0hh7clSAUohIO KuMUAqwwKmECjakjQhEtUy0AWsuZd+H2DG+KmFKDLRnCcAD3iyPeMwIyUBPlDJKtwnci/Kw1jgWm rVVeAp9OJ8FsYSUwLMwwjcQV+YJpDlPqjMEIlzighIBep4mIjc4BmQN75BBMBolmAvR6ojwAYx8+ Bpsh2uMusOgCbEX89cywC8T1jJEj8NUL/DQCcb1AtRGG6cR7BBw68R6ZoCo9HMjtwzpAU2+DITh3 xnp4cO+DITh3ap65bGeSpNZxVBmlmXtGJhjJjFEgMhruxBWng3yWyI3pCwlgG+jZEzMOE86eaIJH loMTjoC3Z1g+MWXBFxj3OQbxk5gAdwIoMQMi9tRRNCDp7bzKMZg600iNtfFqH/mcXHYeQd0pcAzi CImER42ZRJiZKAGjX2DiJDCQK3feMaoBxnzG88BolJiDAhGURiplMZCAb+RScE0jYyZKEJl6JTI3 cQyhBIy5yA+8yjHojylyDDpkiqPmYH5jwBvVQYocgz6ZGOACnTIljtEoAQMR4in4MYwGumNi9A30 x8QMBnPwDqbdndoYaXuHPRKza2QFMHJMZAJKiVUOQ1scWZ0umWRUPrzK4A2AI12yUgBWeTXxiNUb qxEgEZyFY+RHouVRY0VILoilG4slHLHsy+RSYVHkYR6NREwuCBOjGkSqZCbPo2gAThJiACL1zqsc ozfewQpgh94Ts15iYkosVxLrp8QqJ430zTyVmHxSGQUG5pqYPRIxmZgjEj0ksRJIlDfhPMoOSlA4 BuNJYk7CRd7BMTJLhcoxkG9YIrAsiSwWRoGCK4nlAy7wKseomVJxjNqpIZ5rlKCOKoVSMTeiaGGl wcJ55zxYkslOVECbOKqsOljgsGJLrGKFZUZqo7LpLKMzix3WRqxlhYGCfokqJ7BSIRfqhDjEETCZ iG5hmEmsFlFX8CrP5VHbkF8hQol9YfxPfRT2tAIRj5oC9QTxhgIL4xLnCFasgsgPAZmFEY8aC6JR RBF5o+TqLFyI7rwLC6hRSEETso9yaXBmDT3qI+Itx8G58wgeLER3ZqgTojsTL6NWymlwZhnG0YXo RrUBzmHU5NCfjGots0wjplGng454Q+lBzqNOYz1FdOcKDTHJ4KiRjpwbUCxEN+oPXuUYLECIfxwJ r3K03shPWNPhfyHeCvMdn3ZwBPsK0V1YEhFfKLrAdRRJhWlllLCFsU+I7kI08XEDR41XWQnyPmEs KSPmMHqXTAmI/VI431HOFdanRHcplIrohsPCRkR3qaPG5GgNFmVFgCPwF3psaawTicbCmCPEOSqU xmKUR5R+FJHEpTxqT5azxHnd+6hVWX1iNiydcMTalNivLKOEiK9M4kI0VqY0IeIrfXc8jFTGByHi Kz1YRhVKbUsZz1EslcuoZ3sdD5EMnbyDnPMoiUcBS00S3ahneAfHYH1GzSFfU1dEfK3UFdFdK0cj 4itjkxDdddiciK+duiLOa6euRmndqatR7+7UFTGN1MsSnOUxS1BmdBTK1BXx1kbpTww21m9CdDfW Y9LGEyF1RXQ35jsh4huj73gOaESsEPGNXi1Ed6M+WZniqLOI5xiZnk3faJnPDn08YtITiXNMiFfJ uYz6f1TrlJ6Ih/ExLtHdKittIr5BVByRcxvPB+TcWL2Ph1fiPI/n2V54ByvyHfflxxMtdEU36HzS o4/0Ph4kWK3DATKLdD5ajAoKAZ5VU2KdzRzICjcwnwiiFMrXMQcWu6xHfvGLd1+R9b59/e537756 98Xvt/0P27uv/nEb5375y5//7EHSX0nCJUlTkm/+ljQQAv/eEv7uL99+97z87ostvpFU4/U1eT1G Z7fEYVmmGaRLkjiLJy6v6IgnnniP0dmw8VjWV/HyJUmZxWsur+KIV1zx6kO87rGs4VW8ekmyT+LV 6PKaLNFWeLmWqPmVV1/hVVxekwnCpZMfmbk2qDMaLuFwYNZcODwJjwYNLh4eBlNdq5p0hiobu3nO eG2yULgES5vB0lwTtclEQVaYuTZqs40ucXJk5tqozTYqC8y6Y6NvfvrL+3e//dXff/3ut3/85+3B 98SrJ8+M9Y3Gxvvyn777lzHiUCybpM4suheMQnujmeD7kIN9Vk8xh0m7UG7u2N1zzIdvqVeoPdUS KiYbvd5cJ4vFS4j2OcmwS+xwY1vhld0lSE/sXGWwCH1lF5fYubhhg/qV3SUKT+xcm7K7/cruEocn di52upuhs2f5h/FM66Yum6cJOLrv3hzCbLBLxLJLPk0i+BYLs8Uu89qZn2+yMJvsMred+fk2C7PN LvPbmZ9jtDlG6V1ndjE4lk37C5GNaWGKlfewXkzubKKXxlJ4mc0clKM6S7xR+mH+0Qd8cCVwE6n6 nPmK2dhsYwKPtzTuxCczpksk84XLPA0Xe6zZX/ldQvnEL/lqSROs0mVWPfPzYZXmWvsapid+voXT BKt0DdMTPx9W0SuQU3PdIKq5o5o7qVskdYukbpHc5MUXaK/TuEZzOoRg8c0mk9nkMhue+flmk8ls cpkOz/x8s8lkNrnMh2d+vtlkgpFcw+jEz4dR8nKYuM9xakPTvenM5moyjnebzrDPR+lvvv3jn9+P p70hhz5V6tOb1vxaYWm6tQBmHmxTuB3moaxrTGcv1ku5IHpwukbfgegy873N/P2PH//44cdHCa95 I6sis+9POXvS9guix4P0NSgORNeefiC6dt8D0bVPHoiu47XbVMhWUR0S+MN7LxiJx6hcjPZM4EU9 uPgA9EWs1yI6D0KheMjL7VZEBV/1Y6IvYr8UMXplUPUYlf1ORH3gDn7LwhexBM9lgvaP1LZjZcLj V+OCPu6r1GPFwSfDzysINZxkZasRKWhXLRQNO0WHKW4SuWwUPoo4hyYs0MQFmrRAIws0+ZImtCn4 /M2fPv7w7Z+pwr/6z//6j3//69FEW7nxSQB71xciw+yXv/rwDz8NtTS1SXspKE68TfIvf/24J9/Q 9k9NoK3c+DqBl7Db2mkCXZ2mh8+YQPdpn+2TtyH4PnfjWyu+/nq2g043xnmQLisCPUiTS5pnyqbI bAqd16bJSaC5i+U4Tj8UtL3dcJyfmuoSRy7k8TjGuTcSHN84cfRnHef2SOiLHG+M1Y91/NMz40uQ 7gZALeG6BjntR+hMTb6xUOmTNn/WbuG1i3Yfw5YC3XWki/OD6xV443X8i6dH3jcdyYttzH+e2Ir6 3BvDnUmfqP/1454bhwqnEBev8RpDOnD1DRJDOXG9htOZqx9XX+b1IBVVxYKtH3fs6lthIX5Mvaej JHGCYbyGYYxzCyTGG5vFedxrGJ45+jCMcX48v076Z46+MuOhYXKNnCOVA53TuI8AHaOfauKpU/UE TUovHmWgeQQWtZVp2PRico4Fgu6IKU5zuS5U4rNRo3NJvnvFJBNHB2snjjdYS2Xi6ODsxPEGZ88n 8Kmx80mON5Z70p4t13zLPbRvOrOZmnxjAeZ6SlDvMVmu5Zx7N/l65k/ef/fhw8fvPnx8sBcf3IeK 2MG2TGnzKpmIg2FxE66EFyqLB28xWdsiUfwaJsozQTwCtNwEiLwfhxAH/tJnrvnOKE8JHqQLVn9Q avcniu+ZhwcRJ1vPj33ihIFsciog8p2m5qaZEwZOHG/sNC/0ECcMHDmWm+BXLjtMn6ByUuGByoHA TJUddz9QOWnoNFMNJvrMHvWZPWqDJZY7ax17N0+A5fhC9Yw5j/CVlbM+vquFTP6xmPozwlf2U/3h SXnlkTsvPXNfu+WB6NrTLjsOjxh533E40MR5/Ud0iA6PJ68rQE60c79/jeHrKpAjbZt9e5FhvGF4 1fn4JEO5mfIxQTwIprVHsc4PZKp405dN06QbS+79GUxGqw7RcQY3RpsXhbQ1hv3GaIe1F4sMb4zW Z2e+9vgjlePzByrH6Q9UjicfqBz3PM1Uo2PXGNa19NKn9NjvbOV6W8i+u+maE7W0GcjkH3srvBHT oStSHKr5kSPtvjXToSty7cFnjj4G07xuJFy78JljueE496uuffjM0bfcG+3Jci+dm6PlVPumM5up yTd2rLgjHpaOXOMhHdYSpHBjucPikWvsnDneWO6wfOQaZ2eON5Y7LCC5xuSZ443lTv2kN8v5mFPt m85spibf2AfkjnhogTiYOzzmp3hjuXjZevkkxxvLzS2Q6GDuxPHGcnNzIzqYO3G8sdypqfG0XLrB nDY1VGc2U5Nv7K5yRzysK3Ewlw5zSDeWO6wscTB34nhjucPaEgdzJ443lktzW8rB3InjjeWSb7kb zOkKFdWZzdTkG3vWvBEvngqq5mV9LaUR3OKBeZfJulCFp2sgH4iusXkguobbdTPklkiui6l0WHni OLLMpU2SG5PK/BDtOPKRY/aVmw4rMBxHPnG8AdtBN44jnzjegO3UP3o6suQXqoMja/NIdWYzNfnG 5kZ/DrPlnOSRj3O4sdyh/eEkjyPHcmO568bGJzneWG7e7CJO8jhxvLFcdi2Xd99y2pBQndlMTb6x ZdSfw7wjxsFcOc7hxnJlslx2MHfkWG8sN2+LyQ7mThxvLFcvmyef5HhjudNuoDfL3WBOF5iozmym Jt/YiLuePBT35kUm00JAzitJIq8kibySJPJKkihOkpibKcVx2MPeinTTTUnz1pniOOyJ401tMrdL iuOwJ443oJr7JcVx2CPHm4ZJOm0qeeshvTjssxemDqvNItWZzdTkGzuzP8Nhb5pmqU8v1swZ5ECU DhN+xcuRdn68XmTYbhjO22SWGHLTucdQ5rZHWmQYbyQ02qeNRW0sL0RPp3mYWFtFqi+bpkk3tsP7 M5iXYDpEcphBuWE4I2mRoW802Sej1TWG4cZoc8ejLTL0jfZGezJad42mijd92TRNuvF9AX8Gcyfr GmpHqmv8HKmuQXGkuvb0I5U4VEfVFp2xauLRZRnfSxi/8caWcw8kOP57HDHeGHPugQTHgU8c5Ybj rBXHg08cbzAWXId72dt48jjtLanObKYm3yax3sxhXkfXHap5j4GkG8vNPZDo+PCJ443l5h5IdPz9 xPHGcnMPJDrYOHG8sVw8LvB+Wi4m33K6t0Z1ZjM1+ca3ObwRL3K49vM1bJk3mWz3XOZ26S3RNRYP RNfwul4Cdk90HccPRNd+e2iIXLvigejauw5E1w5zILqOpQeiFY2nFY2nFY2nFY2nFY2nFY3LisZl RePGqNzQhAWauECTFmhkgSYv0JQFmrpA0xZo+ooOlxS9oumwouqwouuwouywou2wou6wou+wovCw ovG4ovG45NsrGo8rGo8rGo8rGo8rGo8rGo8rGo8rGk8rGk8rGk9L4WRF42lF42lF4za5thAp72ji Ak1aoJEFmrxAUxZo6gJNW6DpKzpcUvSKpoOj6ufC3vd/+vjojfLE9tyypruN9OWAbqAbH9h9/NpO Od3S1pReFxsF3WirG4Bs18j4Nu3jV1eN7LokONivriLRDcFRNwTrWtLx9dTHr60G1Pu0sRp1n2/U BmvUHXyx6v366Z4k+n5Nx0mPrtT4euTjV5sjuhQ16byTLq5KOv+k8086f+2jWS0+vnD3+NVaXMcV HVd0XNFxRccVHVe01Sv60kZE+enLG1E7idpJVD+i+hE1q6j9RFvGolsSRV8liG5JFH2lILrqUvTV guiqS9FVl6LbqkUb26J2ELWDqB1E7SBqB9GGt6g9RO0hql9R/YrqV1S/ovoV1a+of4n6l+h+MdF+ peh7VdG+peg+MtH+pehuOtHVSmL2sqcc9VfR9VOiTTLRneOizTJ+ae7xG/Q36m/SX4WV9m2y9cAU iGP37O8+fv/Dnz5+8/37919/+PDx3Vfffv/+u/HvlrVV+3sFNaH8vPqb9z9+/OL9TwgDyuw3P/zr vyFEb4ZV+zJRfH73Iz23vMpzs2t+bnMt43N2PKrjc3Y8auNzdjzq43N2g/E+vmf3nMczeKgTqQ/p SOoxOpr6h46oXqDGV5urqdXSali1p5pRradGMgFNOg1Fagr9JpB9zMe+wmMfxrEP2tiHaOwDMvbh F/sEi30zxb5MYl8UsS+B2Bc87Msb9sUM+4SFfXrCPhlhn3qwTzTYpxXsWwcvIVjp5y39/4Ndxnq/ Qve56Vmh+rbpWfnbOyka+PPj/rTd9rh71TaNfsavxnk1ru6MtP2MtsvwnF/mbXe2+c22q73lHf3e jm7Msu1Ux+1NtunItgrZBh/blmObaWyLy0v+mnZs2L6Jl3ym42XLZ3r/2up3W5P+6Xxou11o1HNy 1JvVqLrW2ZYo28phW/Br63Rtee3q4lNbEmoLOW35pS2atKWOtgDRlg3aYj9bomcL62y5my1Ss6Vl tiDMlnHZ4ipbEmULmWz5kS0asqU8n1Ek6H2KWF0FYms3bEWFrYOw1Qu25sBWCtj7e3vrbu/K7Q23 vZe2t8WfUZTofbbYSO2nrw3fXubRKfTVmr0RsxdZ9v7JXgvZ2xx7CWPvTuyVh72JWO3TW3fdeuLW ybb+snWFrZdrHVjrm1o38/9axfVQ6v+XXbdllyrpf6v2+vnP/hsRt3sEDQplbmRzdHJlYW0NCmVu ZG9iag0KNTA3IDAgb2JqDQpbIDI1MCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMg MjUwIDI3OCA1MDAgNTAwIDUwMCAwIDAgMCA1MDAgNTAwIDUwMCAwIDMzMyAwIDU3MCAwIDU3MCAw IDkzMCA3MjIgMCA3MjIgNzIyIDY2NyA2MTEgMCAwIDM4OSAwIDAgNjY3IDk0NCA3MjIgNzc4IDYx MSAwIDcyMiA1NTYgNjY3IDAgMCAxMDAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1 NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDAgNTU2IDI3OCA4MzMgNTU2IDUwMCA1NTYgNTU2IDQ0NCAz ODkgMzMzIDU1NiA1MDAgNzIyIDAgNTAwXSANCmVuZG9iag0KNTA4IDAgb2JqDQpbIDI1MCAwIDQw OCA1MDAgNTAwIDAgMCAwIDMzMyAzMzMgMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2NCA1NjQgNTY0IDAgOTIxIDcy MiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDM4OSA3MjIgNjExIDg4OSA3MjIgNzIy IDU1NiAwIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDAgMCA2MTEgMCAwIDAgMCA1MDAgMCA0NDQg NTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1 MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAwIDQ4MF0gDQpl bmRvYmoNCjUwOSAwIG9iag0KWyAyNzhdIA0KZW5kb2JqDQo1MTAgMCBvYmoNCjw8L0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggNjg4NDQvTGVuZ3RoMSA2NjA1MDA+Pg0Kc3RyZWFtDQp4nOzZe3xV 1Z338bVvh9xIThICCQfIOblw8QABROAglnNMgpcUiVxmEtEhaFCEimlBe0FHtFI1eMGirYqtN2xt merhHNoJpVxeLXY60/ZVO2P79Jl2ZqjivJ7WOqVWW1uVPN+1s8W2z/T1/Omr8/q89bd++7L23muv vfblBOMYY8ao8E22Y8UF513zN6cuM6W/u92Y8Xee19G55MGezzxlSp79P8bEW87rXrbiqfKemabk hxXGNJ5/3opV58a+2XrYlLy+0jj+3PevXHG+6zz7T8bZcdSYY99dtqJtzsCJQ28b43xLR/mrK65Z O2AqzUoTe6VP89OvuH5L8pzl45eYUQ15Yyo+cuXAVdfsnbtpj9bfacyoDVet3TxgGk2pjv8j1Y9f 9YGPXjl4ybP3mlGTp2p+aH3/NR+5an36n43bvdP4Dz+3ft3a/m9WNjbqeO/X+nnrtaDm7rK45m/V fMv6a7Z8pHKv87QxbtI4d3z2A9desXb1I6t/pP0d1/x916z9yMAPLmk5qfpPqX5y09pr1h14efUY U5LfYkxdx8C1m7cMzzNXqj1Ddv3Ah9YN/OzFh9aY2GtvaPdfNrYvFUPx3Y+vqVr0ukmUGOvxFyd+ 3eYDp75yxW9/9vZlNXUlj2q2JKxvRrYpuevtHxhTU/vbn/0+VVN3es07YnbJsX80ZcYN510TN21m hTolreOG+/Bud3aawJQEDwVnav7TI9ktM1e6HykJ3PKY71r+sPxMoTqL7YZLl120zGRN0qSCfzm1 3KksuctN9y12RmqcbqSbOR1PGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3nPH/tGx 3utmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP8zxIw59p3y8nLjed573RYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgL15FRYXx PO+9bgYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADwF2/06NHG9/33uhkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAX7zKykrj+/57 3QwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADgL15VVZXxff+9bgYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwFy8ejxvf99/rZgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/EzjGUxhTYXyTVPb1n51PDQ+rTA4PD78YzptsdvkF559z9sLMgvnzzpp7 5pzZs9pmzpiePmPa1CmTW1uam1LJxkkTJyTGN9SPG1s3pramOl5VObqivKy0ZFQs8D3XMdOd+nx9 e0/nhnxDe19+SXNHczyZX3LRyaVteVOTSDVXJ89s650R1coH6byp7cqP6e7ZZ7ILevOx9J9WuSjv tcZfTWnjpYlkZ95v1f/NF67tz09d3pNqjv8wcXp9r7bJj2/vSaUSebdV/1+gVfr/wrXJ/ny8W8tT iZElF+RNd4+NoeEXFmihWZDqVbm8Jz/pndne3v+ukQeMGT56uplnqspFzmB835KG9o68GbPPLHkh b+pspZMLTN4syk9NqxlxTYX7Mm15Z8yreac279QtVYP/+AB2s+ML/pse6Ozf0NzZf7X6s7/v3R49 OdKfqeRgcnB5T/WZmgyb3JX/1sU9+8rL2pvb15VpgQkXmH1l5VpSbhdoFwP7nCXvc8IJd0nnwn2u KRmtzquxze20sSGf3dGnieYO9ZrW1L67Zmj46J1/uMpos3emakemRhqRj7XnR400Inl1Prs2b3Yk 900/OnjnUNxc3peu6G/uX3tpT95bqwr7jNfauX5lfkJX9yVapEMp+tYn7cXuCAt76ZKd65ODmrd1 +1Q2d9hL/kfL+9ev67ODxOlr7tC60vae21JHE/ka5c58dTp/nqqd97ETCW+ws/7qpJ0dHLwtmX9U zf2DtSlbagjUq+mDnc06mnbWueFce0naTl+2cCxe0B9enOyOtcn8tss3jIy8tXe+M/pTg/H8kt+k dHV0fbRluGHUlf19G2yTN6y1p9m5ITm4Y114qneGp6bRmuzc0GHDbqixb1Zp60t6Otc3d757QJ24 JrzWP902lco3pO2Gg4Odtolr+9X6kSZrxbvtt3dEIu2oPe357MowmZXhNdARs2s7eqNFUYVL7GZ2 TV9Hb29q5Lqran5U623BzObkoN3jqNb8mHQ8dUzrjs6Y3rW8p7MjEZ593m3vOeeV+sQrmu7qPr3Y qVedwbZXEiN91LWiuevikVGw/p2ib+XI7euevvKqGtUP9/rd+sR3Nb2keUnf4OCS5uSSwb7BtUPD 2y5vTsabB/d1dQ0OdPYlw/ve0fKv7kjkl9zZm4/3rXcW6iLb8bZkub0yS5Lr1448JRY3pxYkUtW9 76zu/nOro1tMg11D3t5ig/FfqFkVehQlkkvsc2VID4REPr7A3qFqxKoe3QJXhMM1LHRrrNDOE/Ym 8XpbO69eEfWNBmI0VuwD7+JoqXaSStnbZ8dQ1lyumfy2i3tG5pPm8kTBZNvSumx9ds3Rd9bUrbJr tr2z5vTmfc26TPVdK/4/w/kPh/JgdXNNMtMWdn34nO3PH12pc3xjQb5kQXSla9t7vIQbTbkJz06V pfXkWpQflw43tH2iB+RgvDn5XHM+ns4H7T1HE4t6k/FqPdmc0+Mg2qMdofHnmv/Rsc9PMyaedxbl nbF2udHzNHyoe+MWaOXpDZOdg33RCLOnp2sXdmT+JT1M9r1kOnpTf3Lm0cuhf/3/e/oVOn3ViTfn K36TGKlfXdNsO+E74S3wpwPjT1vftfL01PKeGxMf652hd22ZY5xJzhLHlDpf84t6K3/dZJ3txZpE JjvkbM+uKCnN/MfxseMmPP8DFVtvGJtYs/XarTdt9RZvXbbV3XpDw/f/Wcuv/7CKawZUfOBaFRs3 jU0s27Rm07WbHtnkm403bdy2Mb/R/95GZ+Ommz40flku4c60b3qVcUVScVxxUhFoLm2yCtfMcuaq KXNNt8Jz5jpnFcbUTTjgzHHOzM7T1JbrVFy1QcWVV6tYt35M4qb196z/3vr/WO/PWuc0rnPWrd/+ wfENm8d+rL0h9VGFe2D4eKypOLoqM2solipW12bm5WbGJqgpq2MLzfMK15RrfnQspWgzE5UnKs9Q pGPzzI7YdPOA4lnVKTOZ2CxtOT021TwZm2L2am6/8kHlbytisQWxhoKbzg7FEoWKqsyhWCJWp2+b dGxGrKbgpZNDsbGFMfVaPj82TsdNx+pj4wp+emWuVPOOuUPlg+GaZGxcceasjDYYV5yYHMk1YzJp VTzLnK1wVbnWOLEx2rGb/qtcQ6xGcxNjk2KNpiJWGauKxZWnxc6IpXVazbGWWKsZbTpinhrs2QME /1WoacjkamJucErfZOlYafAzfaulg19G+fdRfjN4SUdIDgUvFccmMhccDF5SS5PBcGFcQ+ZQcDI4 EdZ6LTgxUutEYcasTG5sLBYcD8+wRNn2wChlW/FtZR0ueGtk/fDx4IViRaXOMDhebJ4ykmvGZcpz k4Kfm1sVrlkW/JtZo3CDl4NfBK+YiuAnwb8F/65vyrbgJ8YJfhu8EfzOjA5+Fbwa/Fr5K8H+QpA+ lqsN9pvnFa45I3jUtAR/Z+YquoNHTJ9iQBEz2eBAsW58JpErCx4yi4PPmv3BXvO6wjezgoeKdQ0a NsGewvysuirIB/fbNgd7ovxglB+I8v3BTl1lbbCrUJfIaOAFu4rVY+wePl2Mj8l0HA4+rb77aPBF NfqLwafUYV258uBTZrVio8Izu1U6w88F9xWrqjVQy4OCNviELYOng51hBz4ZHkT9tLM4P5MJc7LJ HuPego5hD3qvHe3lufHBl+0ot2WwO3g4+Iw67s7gruBudVx5sFtLPx88FXxBHfZY8HjwhBk9fDS4 pTglnQlyFcEt2vT1sCwLtph1Cje4OrigMCmVyI0LrjaXKTYqtip2KAIzObjKnB1cY7oU6zR9vyJQ //YVy+syWw8GG3TA64LukVHSW5wzz7a9t6DRfSj4QNAddmB3cOFIB64pVFZr+Zrgb7SPdLAsWK7b ZPehYLnZq7DDd2Mx1Wr3sLFYM9bm/sLMOZkDwbrgIu3hEwe1oR2lf1OYOFlLLwyW6rj1Q0pztmZy C4JNwbWmMhgIPmiqjObMg4ovhDGgK2/LIc255gaVWzS3Q/mhqE6gAblJA3KTOmCTuSLcokpTjYq0 4myFXXKe+VywXvvIBucV1Mbc0mBV8FfBX+sqLAnOC87XVYgFq9RKP1ii7Wys0rFWmScVgfm2yh9q 6cvKnva26nSdLsVqTfcpb1XeG8YqUxqsDS4PrtD1XB1cGlym2z0RrNbQX20yivMVvm6HrI7YEZyj W+scc5/CUy+1FzTODwSLgmbdN+rLM4qTkhn1VrqYTGXOPxJM1aWbFrSEl2JK0DpSaU4h2aqNWjQf DsfWYuZseyFaC8nmjG6n2UHKzDGpYNbpPFvXsPxQMFv9NlvDqSk8XG9udtBsrla4wYxgZtCm/pkU NAZJ5UywMDhb53NmMDc4S+dTFsxQ60v9k+Zj/mtmUPGfQan5jSIwZ2muU/GQ4guq8RUt/V0wRrd4 0n+9OH5CJjjs/0Zbd/qvhyOjrjhzdqY0tzCoNQ0K11wfVJk7gjpNLfRf0UWsUkdX6cLX6v6r0wAp 081Za0YFlf4vwrE6OsoVyva+LIlyLMqBsn3QeSP1/F+OLPd/4f+nOuz6XF0QD5vzllmlcIO4/5+a Twe+st3OVbb1f676Rt00OVx/R1g+pPKLCtf/lf+q/2tT4b/gv+if0JC6wH/B9Cpc/23/lD9sRvu/ 9d/wf2c7z/+e+Yr/HeMOH/e/U2hptY8KTUyYGE1UxDO5M/yf+D+2j2v/x/43w/yv/vfD/L/8L4f5 n/19tnX+96P8D34hPLtD/rNh/nvfPrHS/re03ra+4H+5UJIuy03wf2Qc/0dqwygt/d/+sXDtD/1/ CvfyT6qtweV/M9rqazqazYfDrZNDSrrbc5X+EVWIacVXosMfiPKQv0+Da0GuWvOOX/T3m0pTpS+b RsX5Cs//uv8N3etxv7TYPDnj52r9x8wYxbcVP1a8rHhTETO+ypUKd/io/1ixpj4Tz9X5j5tuxTbF boVvjqp8TvGawvMf9R8xDTrWI96bhcrGm3Lj/c+aexSPKJ5RHFF8TxFTnYe19GF1VYv/GXOr4nmF N/yc/0CxtDKzWps+oMUPqD0PmJMK35T7D5mEQg89/1Mmq+hTDCi2KQL/fn9UoSs1Jtfs32OaFP0K Tyd6j+rfY2ZFSz6k2KbYqXhUkVeU6mR2mb0K13zOv08dt9NvKpzRWJ5r9D+pY35SHftJc7Zit2Kv IvZHSw8qfC25Q0vu0D5W+4Paxw6/sjCx8bWD/p32PvPvKo6bmBmtS3e3at6tmndr27vNjYodiph6 +fZiWU3G5Kr82+3T0L/NdChWKu5TnFAE/hf8pwotjQO5Gv8p1dkZlnP9W1TrFrNFcZ9ivyLQCd9Y OP/izCH/Rr/J1KvDb/SvKExr7M/F/RtU9Qa181aV94VT9/k3qzduDvv21kL9BG12q18ZbvZxnca0 xqrcFP96bXa9jnm9rvj15rgi0Ni6Tq28Tmuu0/X/nP/h8Po/GeWtypOUPxblj0b5I/6HC5MaOzT4 PqyWfzhsyod1Ji/716osV5lQpBWebsmBYunozMZcj/8hs1Xhmi5/s/pss3lF8abC1wjerB1t1nls 1jVf7X/AbFS4GtWbNKrtC8z4GzUWNmqq379Kw/UqTT2v8kQ4tdq/UltcqeVXavs1/tX2g8Ffb77q 2xfXMv8T5lrFIwq9glS2KXYqjij+QxGoA67QNrtV7lXYZ8vlxarxmXNyU/01ukJ9avQa9VSfYq0O tUanskYnsUabrNEA9P1LdRKX6m641OzxL9M1vEyNv1SNv1S9cqkp0UC/JBxHvcXSiszuI36vDtSr oderPjrqTy1MnZbRo3GSLnaTerhRuVE5qdymnFLerNyqfIZys/I05cnKFcpTlO0VmzqS1fymgr4+ D/lNGgbdWnDUHxMdokxL7CHKle0hKpRnKY+OcpXy55XjyguVq5XtoWqU7aFqle2hxmhg1TWWH9Ss o+PNtN/1esJVFvSoOeD9zntDQ6Qqt8n7tanyfqt4wzRqui2M3yh+q3hDHfV5XcPP6ydJ0vu9cbzX vddMnfeG1taZcq13zD2efVMsVrlMsUZxrWK3Yq9CjyJvSOvHevvMFoVrPqHy2+HUg953tccXvS/Z Z7D3gvevYf5pNP/vUf6B97R94nvPR/l7Uf6q9/Uwfzma/6Z3LMwHRuaHj3tPF2pqM4e8p7WjWLjg ROGsjH0LaaJpiiZ+4p0oVtWqV7x/Lc481+ZvFyc0ZfpzZd5Lau1LxvWe9b5hW6FtvlFITAo3PlZI z9DEc1pSUa2XhffjqKU/UrYt+Jcof9/7UvgVqqSGHPae8fJhrz1jHHdVoX1yKlfqXuR22xeL2+Ve FObzi+2TUtlcuXu+/X5SuVJxn0KjUCtLyzMv5yrcJdpDt9th33HaQ4d9pw0/53YU6htsw9xcoVQn 7ubcs+27VAuyhdYp4ZpsYezEzJBS+5TUkLu4qJS0WY+kg2rNYh10v/s+c0zhqvr7CmPrw+3eV9Bd cchd6M7XrZJ2M+58vS9nDbnzi3My+i3vrStOmjSSdaZhLi/PzDrkTjN9Cn2bOi8VSqszQ85LxWe8 dDZX6rxgh46zS+UaW7pfD098yP1qsawyU3XQtb8psu7+gs74wPBRZ0axYVKmLVftzDDbFMcVwwrf JFXmFScVnkonO9nJDjt9px499dyp46dOngpmvd339s63j77tm7dmvdX31s63/LfOnZoq1+n+tUko 9ij2K3x3ebF9Riqdq3GX2+eTyo2u/RGw3z1P8yvdFWaLYq/Cc5faquqApcWqmkxXbpy71H6OuBeq bAmrH1T5ssJ1L3Y77fhzlyn74eXotBfqkDvPnRv25lnuXPVmua7rXDVoro48V0eeqyPNNYF7jrtI 32VvHnQXqZfOdOcUWtKJ3Ex3jo5xNCznquxSbFFsU+QVgXk0mjqheFOhh7jKpKJfMRAuedOdre37 VW5R7Fd4Juv1R9eyP7qW/QVdyyFvdfGwq0am3Ilq5ET7KnPrFQ26SvWKBtOt3K3cp9ynPKA8oFxm XnNO6DiPOC8ax3nR+WmhpvGRg85PNfMl52l9o95z2HkgHAcqdakfKJaU67juwWJp3I6EA+FIGMou 1FDIvto0OfPq/W7avOBk/yFek3lyj5/e9oTzxB4vve1x5/HHgvRjdvJR51Elsye+p2/PwB4/N889 5f4+vEJvK+tmdd9Stjfcm1H+vXsyzKfcX4Y37yJvnq3vna1s5xcqa72XifICZV1Vb36Uz4ryXG+e TsnNjfcmeBPDmglvYriHWq86fEzUKNvl8ShXRcsrvWo9LtzcJDfvPhO25Rn36XDkPO1+KZz/krs3 zH+nbJd/McpfiPJT7t6ijm1yo93tJq5IKmYpsopuRcy9rbjLT5tc1r3FLFa4Ju6tMLMUfQpPY2SS uVWxR+GptH+/GqOyQ9GvuFXhO79wXrGPHO9ib2l4Zt3K9gyWRfmiKL8/yl3eheGZXhDNn+/Zn8nu kPPVwr1+esgZKuyy6XDh467SocJ2mw4WbgqUDhRuDNK5Mucu52aNpLRzp7MtzLc7t+lLfM1B5zaN o9ucG7XDNYcd+2Gx2JYaRxsKiYn6gehc6ay3t5mz3rnUttZZ5izS78HGQ469WbNOp7Y/p7B9TqN9 zJxdmNiUGZmoGRNOLCic2xlOzH9nYl5RE9kj7le04TRnij0jZ6ozRa3JDjlTinPOtH/cnFKY1KTH 3ZRsvQbrs8fc9Ld1ivcpsp88Y3rmk7u89NDw0eK9/Vdnwtx72Uheusrmv783d0Hm3l1ltk525q6z 5mV23e+k774/SD/8YJDO7p7YmMk+qGK3ljyo+LTiAcWnFHaThvtntmWy98+cpSLZpELnsmyXs+xB R2+2z3gPhxdht7K9KA95D4cDttK739sVXs77lO2aT0b5Xm+XvVyH3Feje+RX7kmdrV4cJwsp/QZv cv9LN41d8Tn3MbsH90llO78nyk8oa8C4j0f50Sg/EtX/rPuYHbja42OF+ZlMbpI3x5se3n6zlW2b ZinbtrRFeWaUZyjboZiO8hnedHs2B4ZPaqLavv7rvYaw5jivYeRt3FAcPynj5mq8Um9U2BMlyrZG LMpBtNz3RoXD1P14cXuZLq67zr5/rz3s9pt7FHmF5/UVDmm0emtG0vLiIftHCuffCs1T7YvT+WGx qi7TcsT5oVmpOKHwnO+7rXqit+QmuK26qVp1m7WGt15L+PJo0uu+KXzrJPUeTto/G6tsUdyq8Jwf u6nwb1fOT4plFZnyXNz5F/t2cr5r+hWu+bHzHb0ojHPKzDeNzsvOzzXYt33N+bnZqXA1q7sr1+Sd 5y0JO2yJ1x6ebGeUO5RtJ5yrbDs+F+VslBdH+X1ee8HRsClzbnbCPxg625Tth9dR54ZCqiW8VW4o 1I7NHHDudeyfEo+q7k41dcCWzt86N9rjODcWtwfp9iFnc2FWSulDI+mDNn3NGdAXb2r4uPPB4pix GXPI+aCJK/T17wwUqu2er3OuUCt0418e3viXhzf+FUXd+LoH+4pT05k1uUqnL3z7qHT69QywR70s ehZcWtgePl0udpbbjynnfc4i028/x52Fhfd3h+ewsJBrjyZmzwknFhWWrogm2i8YmSieMdse8dzC uHHhglwhszCamJaOJhrGRxP6lLITiwuLF0cTmbOjCT08RiZmtEUTyaZowvaknSiWlmWyh92CzqbJ abbX0Gkubo+ljxz0Pmd/wXhPFEaPDj9Un7A/Zfpybd7jZkCxTbFT8agirziqeE5RonfAk9ruSb0H njRHFL9UDCtiWrNH+4x7T9j9av0T+j54Qm+ABmei+ZbtJx1tzllhwxLFOfMzOzUc7TvDOAldqoS+ zhIadwn1+UmV9uIkChNaovrV9fo1viCqqZ+QTq2mavV9V6ttas2jirziqGKUHtS1plvRpxj4k1qj dHXrzTOKIwrPLFO5RnGt4ibFPYphRUx7qS9Oa7OXqr4wZ1HYjrJCd3c0MadDj+yy4m1l6XiuyikN z8OWSWeUyiNOTGWjE6jn/cJNejo7brZru5d+86de+pFfO8/d1N34jGZ/qhts+Jjz9W946ePfcF7U kp9td9LfVM4eyh7OHvGOHCpLH1Yc0lPlrh1l6TsUO7aPCt8I2xZ3hG+CbepVm2/R4zDM7Utszg7c MnVm5pab/fTNasA2xd8qblRkb1qxKnOT9nK7Dn+bxsOt2/30x+1za7sG1bbtTmJ+Xf28urqz6mrm 1lWdWVcxp650dl1sVp3XVmdm1k2eUjl1StUZ6crp6aqm5sqW5qpJjZXJxqqq3GjnuE7a/iOKp7LO ucMZNC3hLTJYHNuQyeama0GfYptipyKvCJxLnNWm0lnprLJ/IXOPqOdsWafysHYSd6q1vM2J61rF da3i6t24xlWlU2XrO3Zd5X7X+32dd9h5VRucdH6lxf/l/PLLldnaaSN9Ep82LeyTNn/ajExVvLqi YnRlRWlZeUVsVEmF5wcVeg5WXNviJJuea3KzTd1NR5uON51sCuw2k5v0TpzsTUnHFIurnCrvl56b cCaOrh81fnRdfNzoGn/M6O4znXxNl+laeW6+1lFecW7+zHTXkJdcnp+T7sqXdK/u2ec4d/dqad69 fUhP4bx/+5CrVNN+yeqeIafBrt6e0BesY/Jdfdvv6t3nmnPzzu355hU9NmUv7sknbx+Km5U9+1zn 3ETev6u3tzc/v6u7x9bsTU/M99t/v902sTc/x07snNhr0rJ5sy222PJdm9Ph0vQ7ydo3dXJn/ozO tfnpnX0df1jZ+eNt37XlD/ekA23evGVkuQ6nJVuuu04z14VLNXvdn9lLuHrL6WZoszC19xzQ7XSz /ac3vYrbi00tmU8c0CvFtkb9lNSimvAXeXshmcyk071/1K7NtgG2RZuj/W6O9uiNKp413242qjh5 2kiuG5/ZfUBv8vA8EyN1asZmfhAu2xLtuL0nkZvsTfOawo+NqVGe4rWG77jJUW6NljdHuSXKqSgn o9zoNe1z/qAPet8547g3vdg2OxMfUtYZh1mnaXOhpDRjqyW+am6z3zxb3j3j9p6v6efbY/YBpO+j qW0Z+31UTDSH2f5Tjx7ymohXhzu4zp6jrTd9pN6kxqhebSb9R/0YNkmvh12FmW2ZkYlkKhP10a5C TV3mdMO18uHw37vsRDHZYnv24UJdvd1jIhc39+kbco9if/hNactjiufDuaRq6p2lC2/3ZrZs+TMD JRKNo3Bc24HzbvX2nkPehV74+1rNWFqYlArbs7SQnjkyUdSv6U8cVI1P2d8j4Q4SudL/y76XgFdV XW2vffYZ7mUSECHhnCRXmacwh1GGCBGZRIaAiEAgNyRIBnNvwiAiIqWO1BGpUkSKEQGRwVKkiEMV R/isn1K1lmprKfazPLa16mc1+d+9z7nJTQjVfv37/c/zP+u+7r3WWWcPa6+919p7HyLZuHUIXdMI amIK/Jr6eKKYNqm+7erME6yuS2Y9A9vv1B9hduoZ2Ln/Im35nQnL71SWV8zefW3dIf4ad/Xz/vba 9jv3d+/pU38udgZzUTcZysSf4tqnt1DFdOg0RC+Ft3AnrFsKfrEsf8CKSY+A+QRMihtIWrXxV5Ea Vta+3v6UZanjuc+0SjlrFSjviSu3iid8Xtk9pi2QsEQcblvra3Hf+5RI+HYKHFzHodpwkhyUYj38 4EGxHiJJqEX1VRGx+FPySbl3bOFB+fjYorwxmhyU+/y/BNszav5Bub/DGHRJOhD0EAfNFihstugw pn4UqtcwOkbTKkf4EjFwilH/CSgaRLYgmpJ+VEKhA0yceughxpVyPZ4yN5gbVIeZYxfnqb6ho2oO heOB6eLoO9aj3kKPJWsjAoEuXuHbtO69NqzqO/6U+XfzU9XVKW0IRQ6af6gzhPlVhzGkrRivNTv5 k6hUp4pgmoLVHA96DuxRa3E17JhWOpj7QI0epAedPIvKIEGxetsGJQwv/IFWwGiqQDwh10aP60CL xbcnZU8f7KIQV8QSltd91T5psjesttcpU7Oxx07V++ye9h3w8DIesvDQTD3kT91jddAbMuSz9toi e69D2XubgDalbFfsJWrbcm8Ole2lnBEHzUNj6aD5s7F7mvbY0wTVmnbIppEjU3q0HC4qew9OsZvt sSF1OmRfWfsnxdYhSkVepfLkn9nJl9T8ob68ulBJVP5VDqWaf6DmxnM1f0Urzf/5P2cOBelf/t1C 46h9zdKagzWnaBvNp+Y1c2q21PxVvGQMSS5mxswYzanZRq/QM/Q8HaQnaQdyAiV6jDYk8bcTGUvx dgvtxvM9VKXf3YO0mx7xWxNzxWKxWZSKXDG6gT6rkY4BhTRRXNiIvtuBLbQc3O10I60EXhepNA/4 AT1jlNF1MoS+DgalZ9Y8pmkxTUVSv1yka2t+gBLH6HWAaA20r8ABPvn3fZpL30NPP6CCWlk32mU8 bqwwSsR6mmuspk3iaXrd2EVfGTuoxLicHvSLWcWUanyPQpjfJ+kuWkV3oOeN1KnmUzqE5770c0rD NeM+vN2OfnJpvOY2+7z4FW2iJtSW2lN+zSbqV3OcJmvcC+yDBZXttwI30A1yizFL3mDkfPO27IT5 ya0J6X/QNWhDdS8qojjlmsXUxG5jb6v5vHq+LBY9MBc/0UpWQac/UQzj/yE9QGW0Xj8dqx3rxZA+ gLyAltB4eT5tF+9q+YO0S8/yDFyC1a8UuAWz+pS5xdyXJM+j65H/EmleLdeOLqReNISm0AK6ju7E aqv/G0o5NBsW/3Ejs/4gHcCsH8Cq2gpbbQAa/31IJ+l2WUBT5Nc0UAyDbl2NHeJGWGOGHINrYRVN oGVKP7GcPhNtqQf9Z1Ifd0HX5TUf1pzBFaQ1cBwrqYReREr+bYL299DdeiylmL1+GHVjvwXAOBqH K0sL0U10g2X6yW3yHmCbVUELRAadlC+YqRjzPPUOY0twJN4V/yH3ycfEG+I98RENpN5YN0ONI8ZR 4zDm6iuMYaLxMmbnRiqz99n7xJ3WMlv5WAHeV9BVtAItbTPn0lPGXLoJF9vdYl6gVS1nHqQJskwc kr82jxmLhO8x/Wg4LJSPtaBmbcs5ZCetZyjH9OhjqpSvwQKvYE4rRZbWvkSX+z5s+SA90pgsoFvA PUFPwRuO0dJGZJU0lv4mwmJQLT2G9TgU+BrjHgj8u35rEV1y6XKa06gsBx7h/8poIdZV8sieaFSW A+vMhhUSdAZs0rCMGvPZNqBGZY3VbUz2oNxv3mbeJvdjVXSnl+larIapsN8dwD7xAo2iwWaumfud 7bICKKVZmM0JGMl89LcG9hgPSf3f1Y1o01Cifvmou5imiCjWdgmpqK12tB/RevMktRb7qRPdLC4g 9acY94vf0B6UyXa60m+xr56kSyFfJZoA7bG6FyFaf4OaV8Ijt8KPKjBTd0DDVXQ/3UQzMSd3I2Vi TU2klvQQWqqCFw1Dj7+kXxo54Bv52Qfse6mN3dpaQC3Nh8x75GL0/PeaP9f81zdn6hVU/pGYW7XS V8IutyNCbYEmTyKWNxd3iR105Kxyy+qV+6OYAa22o72DjWnzP/xl1byKkc+uqaJq6zLqgBkYhJ6r KF+MhV9t+eZt6id+gL7nG899fVf1u7AZkQvtrsEOdLURlmQ+Jz+Bdlu0pu+LQ3QrtSCLRspm8iTi 21O02Bom7qIT9iGxCPUm00ViE+7PKzHuL2DfWXSJ2Rz8X2mp8ThZRopYivWxmm6jD+UWaitmYv85 bkySMblGflinNtbBXsTwXGgxlZ6Gv79CP6Wp8hu0tw0W3GNtVqVq/ohTwvcx71dBqk4cK4WFEd1u 9DHGIGofofHGOGMZVsR0YxbWwXG1tuAFO/2dx2kR9PQA7HIdIul92A3upmrM0f1ikflraE2iFWLt dejpcxRdCu+rRvv+by4scaPejW6jLqCLERdGon4p9oePAP+kMk3Vrv+zBgb9boDG4xFVbkIqAjcX 8a2nPADrkpgnRmHvopralRb0+7B4xGhHMbGd3sQKX4a5JNvETqTaawNv7IiT5wxo1gbtbYI2i803 MJ/qdzUNoJdrfg/uZ7Do+uofaenF8OVKYyxtFT3FYdgyjU4hMlg12TV/R6sPYL9si3E/gJHlYuVM wGxE0XZnGgzp2rOXm9mSumtdZsFu47GS38Jq3wZ+LvbBVPkKpWBsP5bDjRUY22lUmII3i4KxPSh/ jb3uGNbQjRjDGtSOiYNyl3jJ8eg58USj54J/8mcfU7trSJ0yB2Juu2JcZaIFTis59KAYZr5P6sRZ iQgxNLD9mCTb3wudtsHqu1BiquHRXszRMlhwI+y2nh6Fz0xSxZzJwfyWYewFiMPXoeatmn/a6G4d VjagR0U7xKjABrKfkR70MRht3ytsnA3WQqsYouPd8m/oZTqtNtT51VD/i6JD2OsliDuqqSNMQZYM mxRqefIY/qPe/Y/1Pta3z4WtLmzVCZlA4a9WW/R3RQkMzoc4l4s7cO+wKEw5P3GE6GyKgzVfj8pI vzDLlEZoj9NaGKZlm/YTlzrifudRxyDHadqkVeshveddfe2fXmj5QqshQ2jkN8dH9u0jeoh5c68W soNs1V92GNhf3NG/YtBvmhw7ZlZ8/aUMibFf5ahd66IAcxgMBoPBYDAYDAaDwWAwGAwGg8FgMBgM BoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwG g8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaD wWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPB YDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8Fg MBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAw GAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPB+H8Koj5GDgnyf4eQfF5QS3ox4A1y6O2A l+SilM+bSWUsakbvB7xNLeh0wDu0kGYGfA1KfI4WhCnRZjPxpuYt8C3FbzVva/lfNO8oufGs5kOa /0TzYSgXN74OeEERc13AG9TCrAp4SVlmWcCbSWUsSjGfDHibPPP1gHfoqNwR8CHqJ8cHfJjOmKcD vgmdEdUB35SyrBMB34zKavnmTU/bOQHfggpaZ2q+SdJ4m6qxtL5X882S5C0U33qb5luqsbT29Twf fOvWz2u+TVL5C7TdfL5tkjxV131L867uy28zLalMRhLfUZf37d9L858qPpSkcyip/WZJ8maB/mOK FhXFi1ZE8yP5efG8yMLSsuXlRYsK45Gul3SL9B0ypH+vfn369ImMXlSQF5lUWlIaX14WjVxSWl5W Wp4XLyotyYyMXrIkoqvEIuXRWLS8MpoPYXlR3pLtkaJYJC8SL8/LjxbnlV8TKS2ITC+MNtpOZGlh 0cLCSHHe8siCKBpaVBSLR8uhVlFJZGG0PJ4HuriivCiWX7RQlY9l1rbSy+8tMqOkaGFpPpqfNjW6 qGJJXnlutDymmu6b2aevLhKUmDRteiE0KygqiUbKykvzKxbGIwvKSyvUsOOlkeWlFZEFyyPxQowm UhwtXoBmlOqJDrugamlJPFFV9RCP5hUPjWSjjxJlj2hJz8jYSmgdyV5SGi2OFef1jIyPQh7JLtUP l6JIfl4Eyl5asaI4D8XHl8YKK/Ii4/Lyl0SX94zMzFuyJG9hNDKutGdkQl4xRjcpryRWWlHeMzIt Hq3EIPPi8WisFDWnF5YW58UiU4sWXlMSLc9sTpOplMqpmPJoCZXQcjwtoOWiOUVpMZ4/Rqp7P50K qYhiFMHbZRRHXkL5yPMhqQQtx7silC/BcykVIJ+kn0pRdjmVoUQXXXs0ShbpFiOIGqpEHE9FoOrt IshV6UL9VKD7j+jSifKqzwhKlOo6cV1uKfi41k/1rjRVZWbgqSipzjTdk9I6D63mU0/Ichto3o8y qS9lygfkXvm0fAbpKXlI7qIxKLFI91JEK4JRq3ZUi75eZdC7XJcqhDRCXekS6gbal4YA/akX2u6j oWywCGPLa8RGEdRSYy7TeZ7uT5XI1LV8K9T1EtNPUVA1ikqtV2Y9G+/Gkz9rqre4blNZo1jb4Jra uUrY7Lvqo2xeqK1bCF61thx0ga6hNFqke41rvXxr+XOzUEsSMx7BOqvQusZQRrWWaD+GcZytS68G 66fhDE/CHE/VvVfgvRphw/nF3GIG+ia1Ur8N1cLlgYWVhn4/+drGSlZCQ/E8VXuKP4LJgRVKdY8x vaqmaEuV6zdF2vLTkFcEHlOuRxehsWf5UfLqH9robEyv5cbo+ViqtViE58sxjwW6x6jW4Vx1S1Fa 1VS9LIceah3F8TSUegNLNTLx3l+hxQ1aydSWKkZJVa8Y+vauZx01uoRkntYtX8eLzNryzbHDToa2 0+kyykG6BHOh+MshVaPIQT5Ry8dCMg25mvNLYfOxwCQtna5bUakuKiU0VFov1ONNyAuDiFGuvdRf f8vPGaUat1MkiBwRHQNUuxXa69SaV29V7Kyo7VPZqDJp7dfNfJ0+vm8U6/K+JmqdLAlmsCRoPU9r EdUeG9XxTq2cK4PeCvG+UpdT6zHhVX6f8X9gmZjuMY6ZztOtq5heFGhWrtd7kZYrf1yix1egrVfc qL1Kg3Epi0WTWklE5cb6yw/ig/KRBRhLPNB6QTAzJUHLjcxQJFWPqr6lotqnzl4VZ/dcFw0rtXdX IF8A6ls7pluLn3N1ZAZRZ4nuMZY083Vz4c9T/cinrOP3GtPtqLjge+t3mfNIsBZLdHz0/T3Rr4rn +cHOVFobsZL3iJ61pcuT1q0/vvi3WkppV6zbT6yr0nrtLdXzf42ezeT9IbF315UsRdkS7YkV2uKq /cLa8fh6Ja/uxK7i279ul02suMbW0D8aUd36uEyP/eyZy9OnoAhdC3lUt50YjX9S8XevkgZzUH7W npxoOab3BbUX5Qf7YiXKRaFRXRz4LrOfaM/3SeWrlcFs1PlYor2z59G3Vt1Za6Fu82w/rjtt1bd1 wT+lbZ2Vz+5hobZw4pxQXyN/PGoFDa1tYQbi/2hIB9MAGoTdfxB27sGgffDsn6R8zKAJyAcAXSHt hlKDcOIaBNkgyqKBOH+plGg1Jxhnw7EkR+REtFerMk/HtbN9qkxHgbygdqVedUVB7Ej4RhRjjQTy aL3xJXba77LDJt71bqBz/V1VpYnB+bQE+QJtU3+tVug8qq1fEYxtsvaZFcG7WLC6CgNNC2p3b1Vn ml63EX2KKQjaiAUxTo10ph5pLNhHov/WMU6ptW+Zjt8xHQu6aH0Lam8sdSfJht6bF3iVH8NV3XJ9 m4jXtlSha/sRKjmmRevVaxgl6nryz9lqVasSS4IaPcm/KVXotpVsRW2NmI4S8UDm26o88Of/DYvm aY0T54hocJKLNLCp2rX+qi2RF1hzoa6VH8SG0uC88bEuX6Q1jCW9T2iROBUvT6qVH6wm/yxdV6tC R7Se9Twsqm2UsH653pFitXtgJFizUb0Tzgx8MKrP7v9OG0aDqFIX2/K1N/qro6jB6ojr1ZGn243U nhQSZ68i/b6odj2ebYO8wA5FepS+pevbojQpAvk36C6BT/s9rABK/202+Uf3ikXf8Wbx7T3VfcHw LZl4/lB/0YjW+8IRrfcFQH8DMNPNvuYE81LzYuRDUDpPnwrztWbqjliuI52qJf2PpzX9oX/jP0nq C2YKiZoa9d0MkmayMvi2epe51XyFhPmq+QuS5pvmb8B/YH4A/kPzd+A/Mj8C/3vzNBnmx1ZPElYv qxcZVqaVCb631Rt8H2sE+JHWSPCjrNHgs60cktal1qXgx1nTwc+wZoDPta4EP9taCD7fioIvsG4F f5t1G+rebt0N/h7rHvD3WveB32BtAH+/9SD4TdYmlN9sbQH/sLUd/GPWLvCPW4+Df8Lah3y/dQjl f2Ydhvxp6whJu5PdCXlnewIJe6I9kQx7kj0J/GR7MvjL7Sngr7CvQJmp9nTwM+yrwM+x5+PtNfYS 8MV2CeRl9rXgy+2HwW+1t4LfZleBf9RG7/Zuew/4vfZe8Pvt/SScB5zXkR9z3iXpvOe8B/5Xzvvg f+3AwhcMvWAoyQuGXTCKRNuX2rUn0c5t55HRLq1dZ/Bd2nUF363dSPCj2l0Bfmo7WK9dbrv94J9s 9xTJdodSYKWUe1NgpZQNqe3ISJ2aOpVk6rTUaeCnp+aCn5k6E/ys1Fngr0y9Evzs1Nngr0q9Cvyc 1Dngr069Gvzc1Lng56XOAz8/9S0SqW+nvk+GG3bTyHTT3THgx7pjSbo57kRIJrm/hORdrz0Znuu5 JD3P60ym18UrhOQarxR5mXcd5Cu974O/2bsZ/C3eLShza5okI81MM8lMs9Is8HZaiGRaOA29p81P Wwg+P20NibSb0n4Myba0RyHZnvYM+GfTjoJ/Ke1z8F+kfQH+y7T/Rjtfpb9ERvrL6e+Smf5exgAy MgZlDEY+JGMEyYxRGaPBZ2eMAT8241Lwl2WMRz4hYxIkkzOmgL8iA2sgIzfjBvAvZfwJ+ZlIcxKR FpG+ZET6RfqRGekfKQcfi8RJRioi14FfGVkJ+fWRVeBviNyA8qsjN4FfG1kL/nuRm8HfEllPMnxc XG9US0PasolsIVvLtrK9TJcXyc6yu8yU/WSWHCpHyGyZI8fLyXKqzJWz5Vy5QBbKEhmXK+RquU7e Lu+WG+VmuU3ukHvkAXlIHpHPy6PyVXlcvilPyPfkSfmRPC0/kX+Rn8uvZLVpmLbZxGxptjFTTM+M mJ3N7mamOcAcbA43s80cc7w5xcw1Z5tzzQVmgbnYLDHLzUpzhbnKXGOuM28115v3mg+YW8xt5nZz l7nHfNI8aB42nzVfMF82XzdPIFL80fzMrLZCVmvLsyJWR6ur1RPxYIA12BqOKDDOmmhNgdfPsebD 3wutJVaZFbeWWSut1dZa62Z4/J3w8U3WVmu7tdt60jpkPWsdtV633rTesd63fmudts5Yn1lf2WTb djO7tZ1ie3bE7mh3tXvafewB9mB7uD3KHmOPg29Psafbs5Tn2vl2ob0EHhu3l9kr7dX2Wvtm+3b7 Tvtee6O9yd4Cz91u77L32E/aB+3D9rP2C/bL9uv2G/Zb9jv2+/YH9kf2afsT+1P7M/tL+2uHHNMJ Oc2clk4bJ8XxnIjT0enq9HT6OAOcwc5wZ5QzxhnnTHSmONOdWc4cZ76T7xQ6S5wyJ+4sc1Y6q521 zs3O7c6dzr3ORmeTs8XZ5mx3djl7nCedg85h51nnBedV5w3nhPO+81vntPOJ86nzmfOl83XICIVC LUJtQu1D6aGOoe6hPqGs0PBQdmhcaGJoSig3NCc0P1QQWhIqDy0LrQytDq0L3R66O7QxtCm0JVQV 2hHaHdoXOhA6FDoSej50NPR66I3QW6F3Qu+HPgh9FDod+iT0aeiz0FdhCpvhULhZuHU4JeyFLwp3 DncPZ4b7hbPCQ8MjwtnhnPD48OTw1HBueHZ4bnhBuCC8OFwSLg9XhleEV4XXhNeFbw2vD98d3hB+ ILw5vDVcFd4R3h3eFz4QPhQ+En4+fDT8KvactkjNkFKRQurfzQJqIqUH9CKklIBvg3RBwA8MUiek QUjYbehipCykDrXJwA0LuxF11/k43KUNak/q36A6oqYBaR/kPXBaMXDeQIRF6oLcJa82H4JTQSIf oPtMCXRpjXRhQJWseTAm9W+VIuhb6NQjaFnQ5UiTkfojjdb/pimoM952g44Ct0UBzh+9+heudMoA 1w9J6dYBWvvv1Qgium8lycRTph5hpu7NRWoa6HgekhfwnQP7Khv1CezeLOhNWaA/xpcYKekSfZHa J424U1CjWdLspetZMqkV3rZGHyb660NpqKtkXSHromX9Iet3Ttn5kLXRsnTIMhqZ4Q5Uf2br5tTX sWPtHPqzdD5S99p3iXkQehYalxvQpa9ueZBu+Qq9Wjro1dJLr5bBerUMqO2pO2ZDWSwb+UDY1W9B 0PB/qRVfp8b0Hvgt71ICWXIa1yC1b5A6NkgN6/dokIY0SP/b/eHUBksJGoY0sZFnNbf9g/V5YZCU B3TVq1xgrfkrPy3Qp3OQzg9smLzOGj6fPWYVJTrqXM3kSBqFPIfGIs+lGXqelT6XII0P9BqpUyL2 DEZ7BiJBtq7RUeczdQ2DpuIOoFaEWikTUN/QX4gMjFR56HBQVV/5hvp7CbWqJqKcgdudijI420GD 6bUtjNFtDtLra6C2mYpJ3XSuVn1PvTp76neDtT1VacWp+Ka8X3m6TXURKp2S45KKOpGAuoG9lVz1 VxeFkqOMHykv0HZJ2KCHjjuJZ38FDP2W1DaYyU7BTDZ8Vj2bSanhc2IPon+QIsGMDwxmM+F1owOq oscKs8p8lMh8zHwMNyP/9qTuTU31jamZvt00t4qscjrPWmotpVTrOus6am9db11PrnWjtZY8nH9u poh1h3UHXWjdjVvPRdZ9uO90tB7EfaezvuN00beb3rjdPEF9cLvZT32tn1pPUT/ccY7QQH27GYKT UB8aitPQABpmZ9lZNBznopF0sT3aHk1j7UvsSyjHHmuPpUttgMbZE3ADukzfdCba83DTmaZvNzPs 5fZymonT0lqaZa+zb6Yr7Ydx35mj7zhX69tNvr7dRPX9pUDfERa5EbcLlbq93F601O3t9qZlbj+3 Py13B7mD6Do3282mlfrucL17hXsFrXJnurPpBneuO5ducivcClrrXueuou+5a9w1dIt7j3sP3ere 795Pt7k/dH9It7s/crfQHe42dxvd5W53t9Pd7m53N93j7nf3073uAfendJ97yD1E97uH3cO00X3W /Tn90H3JfYl+5L7mvkab3V+4v6CH3BPuCdri/sr9FT3sfuh+RFvd0+5pqnK/cL+gR91qt5q2e6bn 0GNeU68pPe61x71mt77R7NF3mb/oW0y1d6t3B9V4d3v3Cek94G0Rjvdjr0q08HZ4u0Rrb6+3V1zg 7ff2i7beT7wDop130DsoUr1D3mHR3jviHRFp3vPeL0S69zvvdyLT+713WvT2PvHOiP64B4VFVlrT tKZiaNp5aeeJYWmt0s4Xw9PaprUVI9NS0lLEqLSMtAwxWt2JRHbaz9NeFDlp76b9SlymbkNiYnpO +jgxKb0o/RoxJf1k+odiWvpX6d+ImRluRndxFW5Dw8Q16h4kStTdR1yrbj0inrEyY6WoyFiVsUpU qtuKWKr9oAmtFi3JzivPW0Cd86OVedR9UcXicspcVFFeQf2uKcnPo6x4XvES+GUKyntIHZF6IvVD ytJfJWrQVhNNpfYtI+AtRBdH8waeTLxTp5WwlhA1zVtQWUxjFixZWkzj84ticZqiJblaMkfzCzRf qN+WlEevraC45leov9OhtUl/SyYSPeuYpnJH5yGdh3XeROct9NeS8/QZRf2F2QWIL+0wulQa0OT1 80a1XNNyY8vdLV9obZ6/p+2CdrPafZJipKSkZKZMTnk25VTqqtTD7Zu17+l+5J1K+1SPyT+DNUMU FGKXsQM62DoykPUIvNvQfm1r73D0GgvpNaYi5wgdO0jHjiY6djTVsaOZjh3NdexopWNHax07ztex 4wIdO9rpSJGiI0Wq/hriaS9N117aWXtpF+2lXbWXdtde2kP7Z0/tn720f/bV/tlP+2d/7Z+DtH8O 1v45RPvnUO2fw7R/jtT+OUr752jtn9nwzwN0ifbPMdo/x2r/zNH+OV775wTtnxO1f07S/jlZ++fl 2j+naf+crv1zhvbPXO2fs+Gf7ekq7Z9ztE9uVj5JW5VPUpXySfgwPJD2Kg+k/fDAn9GTygPpADzw Nfqpd8x7g55THkgveme8M/QK5puwJxPNRVJf00qQ1JeyVUjrkNYjbUDajFSFtBvpANIRpKNIx5FO IJ1EOoV0BulzMqr/yzyJtn1qBrR1QFMC2jygbQOKFVv9Mej5DeQXNqBeQLsGtGdAWwU0NaBpAW0f 0M5J1O/nVbFBbBZVYrc4II6Io+K4OCFOilPijPhcVBu20cJoa6QbnY1MI8sYYeQYk41cY65RYJQY lcYqY52x3thgbDaqjN3GAeOIcdQ4bpwwThqnjDPG50a1tGUL2Vamy84yU2bJETJHTpa5cq4skCWy Uq6S6+R6uUFullVytzwgj8ij8rg8IU/KU/KM/FxWm7bZwmxrppudzUwzyxxh5piTzVxzrllglpiV 5ipznbne3GBuxr682zxgHjGPmsfNE+ZJ85R5xvzcrLZsq4XV1kq3OluZVpY1wsqxJlu51lyrwCqx Kq1V1jprvbXB2mxVWbutA9YR66h13DphnbROWWesz61q27Zb2G3tdLuznYlddoSdY0+2c+25doFd Ylfaq7Bjrrc32JvtKnu3fcA+Yh+1j9sn7JP2KfuM/bld7dhOC6etk+50djKdLGeEk+NMdnKduU6B U+JUOqucdc56Z4Oz2alydjsHnCPOUee4c8I5SYbxEWZnYBL9CWingOLeId8AHYFTSAboxXg+Doqz ozwG2qER6oHiPCovA+2OehWg49De2/7qMJaC4nQqN4Li1CtbgeJWK0eC4uwjx/qrzbge1K2j5kWg Q+qoXAg6IKm/hu0F7Wj9Lw/0n/wdxnuucSXot40rMY6EfkH57zz+f7a8Gn+/f8HeC4N6Cbt+7Nvl 39buLX55be/kdgK5DDdo5/9SvXPRxLjORWv7OxcN9DgX/bb+a/U+B2247s/yg//fx6fW0YSAZgfz OiygE7/9vfFg4E+K9q/z+3P597e9b1S/3mfThvFL+9PIgOYENBftlPl20H7VO6C4gRvfAx2Nclv9 crW0M+hU0Gm+nuakYPxqfIMCOiygwwOK9qwPamzVr/UAqHqe4NtH0ylo5wzoDJSfHoxf0TEBVe2+ bvrxNJn2rKPW5bpc8rlU3XRfFepLSQj3za3Wj61tuHE+bR3x1K1+Gk6f1+HUeaO1xrpJf6+/Q501 1UkT58z91lM4T/bGCTIbp8L7cRr8kbvZfcjdgrPgdpwB96u7GU5+h3Hie8593v05znyv4ax3wnvI 24Lz2TbvEa8Kt6ad3i7cmvarsxpOajileYdxSnve+7n3gveid9R7yXvVe817Hae1495/eG94v8DN 6ffeKe8P3mncm/6Ec5s6x1+E1D24eQxFykYajzQVabY66YCmBLRNQFsH9MKAUkD7B3R0bb1ptJ32 0EF6ll6mN+gd+oBO06f0Ja4WIdFSpIiI6Cr6iMFilBgnpohZYr4oFGVimVgtbhZ3io1ii9gu9oiD 4lnxsnhDvCM+EKfFp+JLg4yQ0dJIMSJGV6OPMdgYZYwzphizjPlGoVFmLDNWGzcbdxobjS3GdmOP cdB41njZeMN4x/jAOG18anwpSYZkS5kiI7Kr7CMHqzULfdUa/U+fygdBL8PzTlC11h8GxV4qz9Nf fRFD9I3NkDFQtWbGgnYJynl11LxI27WWGs9Uj/D3oKCfRL0G/SbarVe+L57/Xj1Hr9lBoFeoeqDK t38N2gvy0aBqPBbogCT9FoJ2A/0b5NmqnW/O6LNO0K6pTuHDz92+bu9/0L6xHM8dA9o16G+UojU9 1BdATWeoWKHXoWF98c1n6hucc371NvU1z7ym+iq1rqwe1a+oGJOgxs5v3tbzcAvoEGUnUBUjTdCO uv+3aSbK/85vz/gJnqcp/Ws2Kb3NYaCq/Suqn1V6gm5U8yNvrZmoY4yig1T96u4qBqGd99RZy3kL MeZKlH8f76ej3OLquLZD6Te/Uf3Iwupc1Z51SfV+HcMWVq/V9vizbx9t377Bc6/gGeWsH1S317Fr PSj6t+ZVv4jnUBBzDGqJe8yX+i8P1LVcqL8DAN/JWmwtRulSqxR5mVUGeTnuv9KKWTFI4lYckgqr ApJKqxL8Fv13AI9Yj+BtlVUF/lHrUbzdjnu1sB6zHoN8h7UD/E5rJ+S71N8KuBe68HW3owvLup3c TpB0wb1Yul1dzKnbze0GSXe3OyQ93B7g1c3c8Eq8EuTXetcij3tx5Eu9pchXeCuQX+9dj3y1txr5 Td5NyNd565D/2fszCe+/vf/G+NQo1XcI9ZcY7fWXaf+rhKG/N6j/f019n0hIzEAia79JJrhQYMWv AsvVk4q5jUgFIpYvTY776nvtKHoTLZn6GyLZM+3ZJPS/tVvquxKp/7etiT3AHoabziX2BHtiWlP1 NSotBbXPFWWJFiAtRipHWoG0BulWMmrGmQ9h5n16XkC9gLYJaOeAugHtGtCOAc06Z/0mWFPpqJ/5 f6g7Fzibqvf/r7XPPueMS0LM2HPOPuc0uV8nIsb9Nu5CSGjcJ9fB2kKSOyFJkiQJCQnlkiRJkiRJ kqSSJOkmldRXpd+znrPnM3tO+n77fv/f/+v1+83rNWu/9/M8a+29116XZ6299j5k04B60PbUC2dR GU4nbQV3GxF6nPE4twF6P0bb07St6tn+c3tv/ulZ5c5iqZ5PCnShUWAPO2AHba1L5efStQK1A3UC GZR79QL1KQcbBhpTLjYPtNA5GWinZ13tAvbVdnHK0WQ7yrNSqVfsxega9XyYuy3hbpPcbfEEeYRS 8eZBtsgRo8UEMUPMFQvpfFeJDWKr2Cn2ioPiqDghzohz4qK4TNfYjWLTHfBtirdfvpHxeu2r7raH TTl1w1eTtsm01e9uRmk7hM+Wxhhu+6m32ufMduMtivc7vE91z1ff1eutzvOX3P4idzvCY6/b9Tvj /ZRPtzMBz3kkHi/3OPH43nulnzEMZh+nqJ7nDjwdWBdYb/8crRPNiNaNNok2jTaLtom2jbaL6qd3 BXgWXPD8t+TZblPPsAq/nlsVSXpuVRTSc6uiiJ5bFcX13CrlSNG/XRuEmE//i+l/Bf2vpX+d59vJ 1/CZH/NszSO0LfwX22R3WzJBnhtP/IfbGN39f6vMyIAsIpNlRJaVVWUt2UBmyvayq8yS2TJHjqY7 kUqp6ju1nrY1eDTzsTsa4qP+S32ufDVtG7vySv9CnvGfb/194rnLWxpV+cvQtoy7Lfs39WF3a7py 7/af670lNpWfpFGPJ/yB1YE1gacCawMbtSYwjcrlPYGZgeVUJo9HWkRaRgZHx0cnUG+ha6WuGboW 65rFtefyI9Q2prrbUu62hLst424L8xHTqNZXp3xoQiW4E5XevlRyFfXr5ciC/EPjHdpqf6MYbXWu zaKt9ls+pO31f9abRWjbJM8ud5/80ILsn+ptzQS/oLXb/3XSPVZgBHFS4I7AWGEExgUmkmQVr7h7 Wq+1s9+wDwjDfss+TMwrwaKNoy10P0nx8nra8vl62kL0Xxg9rWRJbi+r9Ve5em+fWtk9l3x9qjSv IHX730Qp978Bur/6qYJNdyiNpEm46rLcauijd9NPQqL7okepYT0W/VRcHf0s+rWu18Ik6bdCxu6O TaJwSmw6hffEZvKVxGNIjiE5hnSfdEpcZdH8Z/RH7b84UhB3owj50D63xTJEMLg5uFmI4MHgQSGD R4JHyH/8QK9s5NVxZmxybLIoH5sRm8FPmAuxtXStDwff1d4mxZEcR/K1GBxTxsbwKrr4+jmdiuRU 4ldguM9siuc7e/PyiH/zjLxXFeGrymBJIDaR8nJqbBrnpc7lb/jM4uv4pvAKvngue8+mRP6zid/d fCn5OUa8JlcV+vn6OQqvNvebb5pvmQfNQ+Y75knzdMmM2KzY7Ni9sTmx+2Jzdfr8PFUIPTJrQP+Z 9N9e/LvPIwxZw7+dS2MH2sbcfdPdj7jbNDreO7Qt5dFL2pZgvaX1tC2uRwKkj+n2lfZf1yM82qbq dpfkteL75ue0TaL7VIrSL03tSDq1PfV4TZQuaRn8rL+ZnsngHsagkt6bQt3CGPxugcH9jWGcoDMo ptf0BM7wfK/eD7v76R79TbRf3qPX+zW88Wnr1ev9RP01CfpIvvsWXwGh10MY5gHzbc/d0WWgYNzz kjX+6M05rbfmfyMHfE0oJUpZvE3bsu6+7e5fn6Avl6CvnqeXxS4v9+p5v3pC/BIJ8aNuq5FXcmuJ b/5GydV5pNdC/N8stwZ/L8QQv1MZ0qvwPg+Ooas3E8pCqn6C65YF0ug1H39ZDuKtxeeU46W4rSgo x5lzRBI/R6/Oz9Gb8HP0TH6O3npgn5xBov2QPjl9xGB+pj6Kn6mP1aP6zMadYqJ7l07N9BtF41zP UXuM24TZunH7mNjb5iayONi95c0xcax7y84xcUocEpJ1x/hJ5Fn618/U/SL+DJyftdN+kmc/71l8 QY80SehvjhTS4z3SFKLesQjd46JUg4pT7SnhPhuP6/TaRb1GMY3XB5WhsqtXu2ldgJ+ep/L6Spsl Jq8Hqkv1I746oJ67CqAWqDboxgSr3G0Sr37U78tX5zVGNd1r1CsrK/HqpvqDnOFD5YhBOYNGydHD BvQfJMdnD8rpI6cMHXR7HzmTtfNZsmjo8H5D5VKWrGT7tWz/LGu3snZHzh1DRsndfYYMzJH71IiB 2fJg36FjsuWRgX2GZsvjo/uMukOeHKEGOPJsn76jHXmBtI4hRjijHKMg2eQYRXUKRrKOZYR1LCON tNlGebasqmMZtdimgT6K0UwfxWjN9h3Yvqs+itFTH8Xoz/aK407go0zjo8zmuPPYfiHbLGHtStau Y+0mTnkbp7yTLfdwOvvZ/hDbH2X7U/rajbMcnuPwgtNn6Cjjkv4cik84w0YM9QX0N0J8hcWVV1vo 3ja3hP2zdReFOIyncpXIXYkhuU2RPLbSa/l0WJzDa7glLsHP6013jUYqs+2WRX1cXQYrsn1lDqty WI3DdA6v57A6p6bfyxTuKj0trcthPQ7rc9iAw4Zs1YjaEj1L04TammbU5rXko7cWbaiV78h2nTns wmFXDm/hsBvHv5VHiIbowV9Bikslt5dS9OKwN4d9OOzLYT8+Rja/RzzYox3K4TAOc/5Cot+aPUU3 Z5UxzTfB95E/yb/Vv99/wn8xUDAQCVQPdA5MSDpXIFagUYHehQ8UrX3NouQOKUVSTll9UzNTu6fm pM4Nz7FX2GciZiQt0iiSFRkdWXZt+Wu3XXsgrURa1bQNaYeu213mcNkiFVIrZFQ4WHF0xQUVN1Q8 WOm3ytMqL616ulpytVrVulbfUSu5zuA6pzPMjM4Z0zLO1zXr7q57tO7F+scblmpYvWHbhtkNJzX8 plGgUXrTbU1/aR5oXj6ze+ahFgVbbm95oVVSq4xW3duUb5faTrUv3H5Gx/4dd3Q83El0GtXpYKfz vY8vXPNHpuvzak+vsPCl2Ckhy+G5t6r+dLdkxrUdRBlriDXSGmPdZU20plr3WA9aD1uPWo9bT1ir raetZ6zN1vPWi9bL1qvW69ab1rvWu8mfJL+d/GPyZyUbpARTClmvp1yXEk3pTJohlGYZc625ztxg PmM+a240N5nPm9vMF8zt5ovmDvMlc6e5y3zF3G2+au4xXzP3mvvMN8wv9ZoEfwl/Sb/lj/I7E1X9 dfwN/A09ZzlU1LD6Wv2tbGugNdTKsZQ11hpvTbKmWTOt2dYca641z1pgLbKWWMusldYaa531rLXF 2mbtsHZZe6x91gHroHXEOpK8L/lk8qHkCykixUwxkk+XbJiSlFLY2pdSOiWW0oUshtLxauge3Fxj PkVX8nS+a9lsbjGfM7f+i2t6na/q0/h1mb/4JZWvf35140QGrm4wXd0Ia5Q12hpnTbCmWDNwffOt hdZia6m1wlplrbU2WJusrdZ2a6e129pr7afrO2Qdpus7kXww+YcUUbI+X+Gpko1SAikFU5JT0lLC KTenlE0pT7ZHrWPWcUt/Iywj4VrX/z9frfjT9VaJX6+/MXmN71sfWB9SvS3gehTt6er1mNqkUI96 w9Z7wqC8eJ/C/tYHFA4ke8PK8VgcZYtjbHGcLT5iC2pnqZTuyvNXZBE6TikqO6PFJLGDPICT4ivx G7W7nA71z+nUirXU746RV7eawtPmKmH4O1hFRECnRD7eScqt3L2T5iHeM/Uek19TbK6l3+kwzTU6 Baa1TCbPM5QV6f9BenrEXkSUKDVfn5vVX6dn9dXnptO3snOPZA1m0n5bYZ1nZPUeW8Ulx1hy1I1X gO7w6+Yb1jAqYQetw9aHlG95vt1CCpOpr6hIHgTliugk5ugjlNTzF4c0xWaBZoPuBc0B3ceUl8vl qa+5gdPZz2m8yfEPcNy3ON5BjvO2HvmZJzmNuZyGwXfmEDX0ejVxEDWGRpnFm7LvuTufrNmfZUKP ZqV51DzmafX+wrb4rSzbm0/WPUGmR86mP51qVcRfje/2eqoNe/1VPBbFRaBkXX+vkvVK1jWPlayn 06EzeN/8wJ/l7+3vkze/ZWRSGcxmf3YajQMWiRVindgqdon94og4Qf7qD+I3GZBFZaosLavK2rKJ bCu7yt5ysBwlJ8iZcr5cIlfJZ+V2uUcelMfkKfmNvEjZVtAoYUSM8kZ1Qx/dDNGYwb+EKQqKga4F pYGuA5UGlQGVBZUDlQdVAFUEVcol/2bQFtBzsKsMqgKqCqqGGFshSwddD6oOqoEYz4O2QXsDqCao FuhGUG3EvReyOpC9AFkGqC6oHuy2gx6Etj5kCyFrAGoIagRqDGrCZAi//3Y/eTn+4f7ZIsBvDqfx O8MV+G3hSp751DRub5M5dlPh86/3P8LcjHmSbkP9Y/wTPDGKu1tTP/3zr9dlnNK/kj7zSnpfe/IH 54slNLJ9VmwXe8RBGoudorH0RTIsKEvIiCwvq8t6MlN2kN1lf5kjx8opco5cKJfJtXKL3Cn3ycPy I3lGnpeXDNMoYpQy0ozKRi2jkdHa6GxkGQMNZYw3ZhjzjMXGSmODsc3YbRwwjhonja+MC8ZlX5Kv uC/sK+tL92X4mvGZtnPP1Ay1B90E6gDqCOoEuhnUGdQF1BV0C6gb6FZQd1APUE/QbaAsUC9Qb9A0 UB9QX1A/UH/QAFA26HbQvaCBoEGg+0CDQUNAQ0HDQDmgkSAFckBjQXeDJoBmgGaDRoHuAI0GjQHd CRoHugs0HjQRNAk0GTQFNBU0HXQPaCZoFmgOaC7oftA80AOg+aDhoBFMBtXSMVSjBb/bXyZUmept lf/ldY1aulAm0wLQQ6CFoIdBi0CPgBaDHgUtAT0GWgp6HLQMtBy0AvQEaCXoSdAq0Bug1aA1oKdA a0FPg9blUhhnFc47q/WgDaB3QM+AngVtBG0CbQZtBT0P2gZ6CbQb9CroTdDboBdA20EvgnaAdoJe Bu0CvQLaA3oNtBf0OmgfaD/oAOgt0EHQIdBh0LugI6D3QEdBW0DPMf1frGvv4xqOgT4AHQd9CPoI 9DHoBOgT0EnQp6BToM9Ap0Gfg86AvgCdBX0J+gr0Negb0Legc6DvQOdRr/Lq+PegH0A/gi6AfgJd BP0M+gX0D9Al0K+g30C/gy6D/sD5CZAEGSAfyAT5QQFQEJQEKgAqCCoEKgy6ClQEdDWoKKgYqDjo GhBa0HAJUElQMigFVApkgVLduiZD7ULzhfCMjMaLVJEherqjozk0Pl0m1vIo/izVrzCNhrbKXXJ/ vAYZhlHayDS6GSpvniCsV8ONCesR/YwwtfL+2WFq4f0P83FX632mNaCnmHjkHKZW3D8vTC24/wHW UQvuH8+0ATJqmclTjttv1PrwZpa4Y/ewHtNMDutxypTw8xwrbruNJS+wJO9sqUX1Tw3rEcK08A4+ +kueODtZ/rJHMoSvaxefc9HcUTblWCNql9rS6L0bVq+MF1PC1Ob67wxTO+8fF6b20j8zTO2nf1Z4 N+cLtb7+uWFqZf33h9/hYx/WRwq/rvMr/LbwhbJoe4C2/Um6j7aDaatb74fCus1dGdb9xlrOlSPI z6Oe/PyAz/YYdB+CPvJYfcxncyIhZz7hvD3NOmpp/AvCn/J9zLP4nHP6C85X3do8Ftbty1I31S85 pm5TVuDeUBvinx7+hq/1W9zRN9z8TaLS2FmIUFfy05NCPckzvyqURT52kVA/8qqLhwaQH31NaDD5 tyX4vTzLMx5ayqtMStPdaCS68zeqxoopYgGnr3v6Tky6L+/snp/uwzuFt7Ak9/zImw71dEPdc/bm WLovy2Z6D7L3Qbp97+mmeZLT1C30YNZ95VoVDHUKdabr6knX0yvUO9QnNIT8db/IWxXQnZ9T7GRJ aV6X/ndWpe8Lv3GFlelnsCrdEEX9y/26/ul3uA3+HpWhUxdSvytM4UaqQ1K/K0yhflNR8puKUr8r TKF+U1Hqd4Up/IxKgaS0z1B4lu601G8Mi/wrEyz3mYueBaxMd0N/jbi76E01YqhQdEcmiGlitphH rcoSsUKsERvEFurFd/G6riPiOK9pPycuiN+kIZNkEerPU2VMlqVcbOd/mEMaY4Q6+udx+IDObWof jFBXN6R2IXSLfzKHNHoIdePwVv80DqdyqON2Z0mWrgEUjuPwTh2yj5zln8vhw7oG6jpHe2c5zPLf z1ZrWdPflc3icCbLsvg8s9irzeJjDfFrD3woe8tD2VPOYXkOx87xT/+v3vG8MqXrqK4fu3OfifnJ CxZhfpvX0O9TkKc1TecDv8dr8Hu8Br/H6/M/TraS3+A1/Nv0PAu/qevjN3UNfv/W0G9akGQZ+/kr +XrXsGe+lT3hXeR5+kKvso/7OnuX+j1bQ793IXzhJ3QvweXNx+XNxyXNoCulllFfl56DpBpVFCUr xKTriF73mlvrAykd3Svzyjq4sivMloT1lQ7Q+lDzPL3cTSW3tmhCLXhXKq2DxSgqqTOphOp+7zz1 e6VlA9lNKjlezpDz5GK5Um6Q2zi92W56Zvhe0BzQfaC5oPtB80APMOW2QnokP0Cv9w4156+YzYRm BGtGskbl0zisGcWaO/JpRrNmDGvG5tPcyZpxrLkrn2Y8a+5mzYR8momsmcSayfk0U1gzlTXT8mmm s2YGa/hLbHzN83H1D4IWgB4CLQQ9DFoEeoSJ+g5eva/n4uLr9kdTKV7mX0byJ/3rRAFedV8sVDpU hvqRcqFKooSnppQQEX42nCly/6SuA+HvwudF/G35/rQ/QB8nXjN4Tb7J78n72Ury7F5F0YA8gP7U 988Ui6h12yb8XHaFiK/ZuZZKXFmPTJe/tASZPqvrWGa6snhMn0cSj+eVxGNpiY8l8TgG9nW9Ke3Z j6eQtx+Pb/CZ5PVJpTheeU5Phi+G4+9MGJwfBu/HW/+8Y5bhNCTSKEw1+4fwj+ELnhzNr70Y/pnT ubL2UvjX8G9/qb0c/sMWV9Dq5w+F8p1zrly3iEWoVdHffsq716b+HgKVzZkeP7g7fzdKe8ITyAPe LU7LAI0sW8uhcq58lkaQF4xko7bb6+uZvOX6q4P+FR7vqBdL9azhirCeJ3wirOcIV3os+rFFf7YY wBbZCRbl2aIcW1Rgi4oJFpXZohJbVGGLqgkW6WxRjS2uZ4vqCRY3sEUNtqjJFrUSLGqzxY1sUYct MhIs6rFFXbaozxYNEiwasUVDtmjMFk0SLJqxRVO2aM4WmQkWLdmiBVu0YovWCRZt2aINW7Rji/YJ Fh3Y4ia26MgWnRIsOrPFzWzRhS26Jlh0Y4tb2OJWtuieYNGTLXqwxW1skcUWUhSjPvbRUJN8bytu yPeO4jvuSpXcXjzHLcOjuV9brusmf5VU+rf4qRfyb/dvpzapcqgKhfq7GpJ7axmqGWpC4YIQecHU K79A4WvUE8vQG6EDFB4MHaLwcOgwhUdCR9y0pfjz2t0K3pqVPM619LYUydxSVGeJEdqs53eoVsU9 T/Y5+Usckr+vkd9jrOSp0zR+Dg8KD0Ya3lwI8/oVHYM9cf+y8LBwju4dRQH2aCT7L3GfRfpf8Our 1X6KZK9Eslci2QeR/F0OyS2Z7iEkpTT8ClddxXNmRai1/z78U/gf4d/zHT3Pw9jL66jTqcVoRl5v N/6Gv37+PZvGIEupL9hEvoTurx4T7txyeGku6Xkhlz4FnQJ9BjqNuIsh+xl0GVoT5AcFQEHQo6BU l4q6JTOvXG6mkolySfckz2f6gcrFla9zrzhEvvxp8uR/IT++sEwmH76ivIF8qJayk+wps+UIOU5O o5Z0kVwh17kzCkfkCal/M820yYsMdGR6CrQW9DRoHWg9aAPoGdCzoI2gArkU6Am6DdqCoEKgwqCr ECMLsiKgq0FFQcUQoxdkxUHXgEqASoKSQSmgUiALKfeGLBUUAoVBNiiCuG0hi0LWHrIYk+F+w1jw 14vL8neLy3lqQEVqAwrzWgYdh8pboAdTEijoki/QmtLo4Oltz5HnNAWzTVtoHLxPHBYfiTPivLgk TRoJlpJpsrKsJRtRH9xZZsmBid643C0PyKPypPxKXpCXjSSjuBE2yhrpRobRzGhvdDP6GkON0cYk Y7axwFhqrDE2GTuMvcYh47jBazrsxjjPJqCmoGag5qBMUAtQS1ArUGtQG1BbUDtQe9BNoA6gjqBO oJtBnUFdQF1Bt4C6gW4FdQf1APUE1QfdBmoIygL1Al0HKg2qAKoKuhGUBioDKgsqByoPqgiqBKoM qgKqBkoHXQ+qDqoBugFUE1QLVBtUB5QBqguqB2oAasSk61E6lX7BX/i+1i5gx9iT/9NYVX+XmmPK QCtPb1tcVOW9vhhZmPnS09+zLsup6pXlSazT3xTvQnZdA13p6D0oVZOtJVtL/vq1wXEk+7TJ7NMb 3KvrVec1ibTExL7B31nMPadpoqHd3x5gZ9u32wPtQfZge4g91B5m59jD7RH2SFvZjj3KvsMebY+x x9p32uPsu+zx9t32BHuiPdueZE+zJ9tT7Bn2PfZMe7o9y55q32vPse+z59r32/PsB+z59oP2Avsh e6H9sL3IfsRebD9qL7Efs5faj9vL7OX2in+aC/lGDXZvu6/dR/sffNVC5PM/7FfsfjoP+MuEV7on 1+pvhfM9Sff0hQXFNaIy5Ugj0Vp0FllioFBivJhLrdmm/M+oOI1NlH4Zps2gLaDnQFtBz4O2gZ5g 4hGIvVKz/ar+XrwreZIlezySVSx5zSNZzZK9LNEpvoC0t4NeBO0AvQTaCXrZPRszUCFQje5C50Bn EeQ3upPsp6nfLezx5oqLVH7jTJeutoJXEPJ37umsKLauu1UpDclpGJyGQWlQf24/a2/kvB/CpTNe VvW7EXleW4bwvlun98w/6b33e7e9C8fP64+qUh37L3s28gf5mxEwihqpRmnOsdfpqCuY9oHeAO0H vQk6AHob9BboIOgw6BDoHdC7oCOg90BHQe+DjoE+AB0HfQj6CPQx6AToE9BJ0KegU6DPQKdBn4PO gL4AnQV9CfoK9DXoG9C3oHOg70DnQd+DfgD9CLrARCUx4ATGUpkfF1jOb1leYdWX/RO1uxsDjzNf ZJ7F5W5S4J4rtjPk1wfiZX3xFfW/XEn/v/HpuH3JPVPT/hX0G+h30GXQH7kUESAJMkA+kAnygwKg ICgJVABUEFQIVBh0FagI6GpQUVAxUHHQNaASoJKgZFAKqBTIAqWCQqAIKAqKga4FpYGuA5UGlQGV BZUDlQdVAFUEVQJVBlUBVQVVA6WDrgdVB9UA3QCqCaoFuhFUG1QHlAGqC6oHqg9qAGoICoNsJoNr 53Ih7HepxqZ5alktGuP/f1o1bGQaHYzuRn8jxxhrTDHmGAuNZcZaY4ux09hnHDY+Ms4Y541LPtNX xFfKl+arzOdLfqX9C1NjUBNQU1AzUHNQJqgFqCWoFag1qA2oLagdqD3oJlAHUEdQJ9DNoM6gLqCu oFtA3UC3grqDeoB6gm4DZYF6gXqD+oH6gwaAskG3gwaCBoEGg4aAhoKGgXJAw0EjQCNBCuSARoHu AI0GjQGNBd0JGge6CzQedDdoAmgiaBJoMmgKaCqoD6gvk/YMJwUeoV7yUapTqVSnviEv/RzVrLr/ i2vWNFzFdNAM0D2gmaBZoNmge0FzQPeB5oLuB80DPQCaD3oQtAD0EGgh6GHQItAjoMWgR0FLQI+B loIeBy0DLQetAD0BWgl6ErQKtBq0BvQUaC3oadA60HrQBtAzoGdBG0GbQJtBW0DPgbaCngdtA70A 2g56EbQD9BJoJ+hl0C7QK6DdoFdBe0CvgfaCXndrls++RL6GiJSk3jE1Uof6tPoenzGbn3mVEtVp ZEqxotReBO7PfTYbpZYi8ECU2obAoqj+yskjec8wotQmBGZHqRUI3BulViHSWv8ylW7/9egxOo7j 3MVx9NkUiBSKWJHQlbzVKLVMEf3umaTwz08Y49/C8EXHRO/WR+Avzuj5Xv21f4OkY4Qkzd0UTiR9 /ucHzT1P9yI8A6m/gGBECgWo5tD5tOawjSd971MFwV/twvdeyP/if047KTA9MJ386wcDD1L4aOBR Ch8LPCak/Qd5qDJyFfmGkvK8JIUp5MPFzyv3bSc9ymwhPM9NZE/3CN7rL8HXvyYeK0B1RJSiVpLa WP4FBMr9wH36/uhrCTwUoDoeWEz+vhF4kmwltaE0lrPf1yM1+2M9qrJP6zGTfVaPiOxv9Sgn0kh7 B5Fmuu+PtNb9dKSj7oUjXXQfG+mne7zI7bo/iwzTfU9klO5ZImN1v8E5b+TL7VbeKyo1zz3rK91x PVs5UutpJJM3T7JdhEQ9GqN08KzRis/6bqeW/pxMkmk0OrlCy85p9nXTNKP9QP1BA0DdQF1Bt4B6 gG4FdWfKrRPasxypf6/N/pl/o60jNHVZ04w17fJp6rCmCWva5NNksKYpa9rm0zRgTQvWdMinqcea 5qxpn09TnzWZrLmJNfr8s3Elt4MGggaBeoJuA2WBeoF6g/ow6Tp5hzvGnUg9uf4KUkH+ClIh+w37 sCiWbzVFmOtYM88Tdiqx0Zo8vzMiMILSGqnTdEtx/MtJNUkv+RfwTP4WVFXRRHQVgzGLtlscppFs /vUU7cj2Zo9M16X2CTJd9m5KkOlz7cAy7xqLdhQ/TxJPyyuJp+SVxNPRkrwVEFQqsB9PI28/nkLe fjy+3s83JxWtFb0ReZZf0zDa6C80LaOt/kLTKdoZmj8/sy0bvz+csh7x6PuTexxd5sI82+zN9U5/ yrlOCXnQ6QrXdHO0i+c4/2I9hv5GHpXvjh7PsDWv0NKtxgz2D/eIM9RaVCQ/MEfOk5vkEfL3ShkZ Rk9jAvl1u43TvoCvvKcv02Pn1VE9xlsT1eO7p6J6DM1rZ6N6/P2Ux7YS21Zm2ypsW41t4/1eKdbq 8fkajp2aEDvK+hjHvpZjp3HsPIt0trieLaqzxQ35LSJ6dm11RM+srYnoWbWnIh8nWJxgi0/Y4iRb fJpgcYotPmOL02zxeYLFGbb4gi3OssWXCRZfscXXbPENW3ybYHGOLb5ji/Ns8X3C1V7HV1uar7YM X23ZhDR+4DR+5DQucBo/JaQxmNMYwmkM5TRyEtK4yGn8zGn8wmn8I8HiElv8yha/scXvCRaX2eIP Porgo8iE8zD4PHxsYbKFP8EiwBZBtkhiiwIJFgXZohBbFGaLqxIsyrFFebaowBYVEyyKsMXVbFGU LYolWAxnixFsMZItHLe8W4G55FE8RJ7EcvtT+yz5BpnkGbSJtI20i7Qn76AL+QODyBvIiQyPjIiM JI9grKeHr85bv+tnRUTpqJ7vWhnVc12roiWohteOlqSwcTSZwtbsIXhnOPVvjuS9697zL9/C1jUL s0jRvNmhmaDZoLmg+0HzQA+AHkJ6wyB7GrQetBG0CbQZtAW0Dekpl4oHHkrI0cT8zJ+bJeAvTRK+ YL2g/uKVDHp8aJkqUv5GbnnGyJwajX+C/AZ6dCNoE2gzaAvoOdBW0POgbaAXQNtBL4J2gF4C7QS9 DNoFegW0G/QqaA/oNdBeJqqJwVAwXYjoJMq7ZE+e9hRBXtFZnspq3NfUsaaSfQ2me0ELQY+CngBt AD1D96Y8c5B/e7VMsFywYrAand2fffnScV8+WJ7PsDxtZbBGsEaCH32b5w7P52eHDeg89a/L5z4z PEp39JIsLCMyXbaWPamXm+n2P5Mp3RuiUyis6UqmsWS6RzKDJfd4JDNZMoslub4k1aBg9egc1tzn sZ3Lkvs9knksecAjmc+SBz2SBSx5yCN5mCWLPJJHWLLYI1nCksc8kqUsedwjWcaS5fnOfQWf+0rW POmxXcWS1R7JGpY8lS/2Wn1vo0+zZh1r9H1er9PU42kqWbYQwWiwCnG1YDVqs/7ena7O8fPfae+q 1AJuDJP39b/nGVFsIh1tv/6dbuJpxJuZjeDa4MYrjrFo/M8WMrjHU5628nsX/5WVWXyUfe5RzOgb oP2gN0EHQG+BDoLeBh0CvQM6DHoXdAT0Hugo6H3QMdAHoOOgD0EfgT4GnQB9AjoJ+hR0CvQZ6DTo c9AZ0Begs6AvQV+BvmYy+C4foDL3cfBjXv9tunfzIHnof7Pl/zuzo1y2iuQePXY1qCioGKg46BpQ CVBJUDIoBVQKZIFSQSFQGGSDIqAoKAa6FpQGug5UGlQGVBZUDlQeVAFUEVQJVBlUBVQVVA2UDroe NBk0w73Lpvcu81deS/PvtJfx1O8m1NYUdd9lq82x7yJP6hTTnaAxoLGgcS75o4ej70bfj35EJc77 PlBtPspYd9wWoHNZT+fyTHATndcWakOSgnvp7Cw+rxifl36HoCDbSbaTbCfZTgbfCuqarr9/6+Pv 3/r4+7e5X6/l358X+d/i6S9y3+IZIPLGh61FWvRc9Lvo+ej30R+iP0YvRH+KXoz+HP0l+o/opeiv 0d+iv0cvR/+IiZiMGTFfzIz5Y4FYMJYUKxArGCsUKxy7KjYpNv1vX1PeOo8N1P62ptqVQ+3kfLGS atU+ah+/EZepNqVRu5gpu1EtGk/t4TIaY+6RR+VZeckobESMdKOJ0dnINsYas40l8Z4mVkPnRuxm Co+4khtY0tkjqcmSLh5JLZZ09UhuZMktHkltlnTzSOqw5FaPJIMl3T2Suizp4ZHUY0lPj6Q+S27z SBqwJMsjaciSXh5JI5b09kgas6SPR9KEJX09kqYs6eeRNGNJf4+kOUsGeCSZLMn2SFqw5HaPpCVL BnokrVgyyCNpzZLBHkkblgzxSNqyZKhH0o4lwzyS9izJ8UhuYslwj6QDS0Z4JB1ZMtIj6cQS5ZFM YclUj+QelszMlfyt0u2d3y5FY4f4nEwD9iQOBd/hVmhn8GWqv/uC+6ieDqC8lbGcWA57Eoe4hsbn snPnsfX/7V4/ptQTSC2v3YqwJ1OCW6I7SPsO02iXjNggyvuA6/fEV/Q3cM+te7xHj56KjdEtHLVf 8W+NOzGHwolX+OK4tn5fyOgp3d5RrDEU3klx/3zeQxLeIijtHrNRvmNKfaR/O+V87wfoL3fzV8Tz pZtrEfjBN1rVVLXUjaq2qqMyVF1VT9VXDVRD1Ug1Vk1UU9VMNVeZqoVqqVqp1qqNaqvaqfbqJtVB dVSd1M2qs+qiuqpbVDd1q+queqie6jaVpXqp3qqP6qv6qf5qgMpWt6uBapAarIaooWqYylHD1Qg1 UinlqFHqDjVajVFj1Z1qnLpLjVd3qwlqopqkJqspaqqapqarGeoeNVPNUrPVvWqOuk/NVfereeoB NV89qBaoh9RC9bBapB5Ri9Wjaol6TC1Vj6tlarlaoZ5QK9WTapVardaop9Ra9bRap9arDeoZ9aza qDapzWqLek5tVc+rbeoFtV29qHaol9RO9bLapV5Ru9Wrao96Te1Vr6t96g21X72pDqi31EH1tjqk 3lGH1bvqiHpPHVXvq2PqA3Vcfag+Uh+rE+oTdVJ9qk6pz9Rp9bk6o75QZ9WX6iv1tfpGfavOqe/U efW9+kH9qC6on9RF9bP6Rf1DXVK/qt/U7+qy+sMRjnQMx+eYjt8JOEEnySngFHQKOYWdq5wiztVO UaeYU9y5xinhlHSSnRSnlGM5qU7ICTu2E3GiVEivddKc65zSThmnrFPOKe9UcCo6lZzKThWnqlPN SXeud6o7NZwbnJpOLedGp7ZTx8lw6jr1nPpOA6eh08hp7DRxmjrNnOZOptPCaem0clo7bZy2Tjun vXOT08Hp6HRybnY6O12crs4tTjfnVqe708Pp6dzmZDm9nN5OH6ev08/p7wxwsp3bnYHOIGewM8QZ 6gxzcpzhzghnpKMcxxnl3OGMdsY4dzrjnLuc8c7dzgRnojPJmexMcaY605zpzgznHmemM8uZ7dzr zHHuc+Y69zvznAec+c6DzoL/Ydqe3/ruHzaOz7atuGy3XMstt2qtT62Fqd4vc7Zt27Zt27btfY/r uH+5/4zn4zxOY4ox1ZhmTDdmGDONWcZsY44x15hnzDcWGAuNRcZiY4mx1FhmLDdWGCuNVcZqY42x 1lhnrDc2GBuNTcZmY4ux1dhmbDd2GDuNXcZuY4+x19hn7DcOGAeNQ8Zh44hx1DhmHDdOGCeNU8Zp 44xx1jhnnDcuGBeNS8Zl44px1bhmXDduGDeNW8Zt445x17hn3DceGA+NR8Zj44nx1HhmPDdeGC+N V8Zr443x1nhnvDc+GB+NT8Zn44vx1fhmfDd+GD+NX8Zv44/x1/gHyoHyoAKoCCqByqAKqAqqgeqg BqgJaoHaoA6oC+qB+qABaAgagcagCWgKmoHmoAVoCVqB1qANaAvagfagAzAD5sACWAIrYA06Ahtg C+yAPXAAjsAJOAMX4ArcgDvwAJ7AC3gDH+AL/IA/6AQCQCAIAsEgBISCMBAOIkBnEAmiQDSIAbEg DsSDBNAFJIIkkAxSQCpIA+kgA3QFmSALZINuIAd0B7nABPJAPugBCkBPUAiKQDEoAb1Ab9AH9AX9 QCkoAwYAAAIEMCCAAgY4EEACBTToDwaAgWAQGAyGgKFgGBgORoCRYBQYDcaAsWAcGA8mgIlgEpgM poCpYBqYDmaAmWAWmA3mgLlgHpgPFoCFYBFYDJaApWAZWA5WgJVgFVgN1oC1YB1YDzaAjWAT2Ay2 gK1gG9gOdoCdYBfYDfaAvWAf2A8OgIPgEDgMjoCj4Bg4Dk6Ak+AUOA3OgLPgHDgPLoCL4BK4DK6A q+AauA5ugJvgFrgN7oC74B64Dx6Ah+AReAyegKfgGXgOXoCX4BV4Dd6At+AdeA8+gI/gE/gMvoCv 4Bv4Dn6An+AX+A3+gL/gHywHy8MKsCKsBCvDKrAqrAarwxqwJqwFa8M6sC6sB+vDBrAhbAQbwyaw KWwGm8MWsCVsBVvDNrAtbAfbww7QDJpDC2gJraA17AhtoC20g/bQATpCJ+gMXaArdIPu0AN6Qi/o DX2gL/SD/rATDICBMAgGwxAYCsNgOIyAnWEkjILRMAbGwjgYDxNgF5gIk2AyTIGpMA2mwwzYFWbC LJgNu8Ec2B3mQhPMg/mwByyAPWEhLILFsAT2gr1hH9gX9oOlsAwaEEAIEcSQQAoZ5FBACRXUsD8c AAfCQXAwHAKHwmFwOBwBR8JRcDQcA8fCcXA8nAAnwklwMpwCp8JpcDqcAWfCWXA2nAPnwnlwPlwA F8JFcDFcApfCZXA5XAFXwlXlyldE7S60t2/v2d6nfVj7gvYzOvh3CO2wpcNdM2szX7NkswyzbmbI TJgdMDtqdtPsttkdswdmr8w+mH0z+2Vexbymubn5aPOJ5lPMN5kfMz9ufsP8tvl38x8W7SxSLXpZ lFoYFiMsJlvcsHhhWcfSzTLNMt0yw7LYcoDlastjlqcsr1mVs/K08rXCVvOsLlldsXpobW3d0drO 2sd6ivUh628dK3b071jUsW/HBTb1bVxsJtsctrlv88zmhW1tW1tbB1tP22DbVFuTrbLdbnvX9p7t fdsXtu9sP9j+souyw3Zj7VbZnbf7Ym9jn2DfxT7T/p79fftH9o/tn9o/s39h/8r+tf1b+4/2n+y/ 2/+0/+dQyaGqQ3WHUIcwh3iHRIdUhxyHXIdSB8MBOhCHqQ4zHGY6zHHY5nDc4b7DO4dPjtUc2zq2 c/Rx9HUMd4xwjHSMdSx07OuIHZWjdhzpONpxjuN8x0WOSxyXOi533O540/GW4z3H745/nZo4tXCy c3J2inCKdIp2inHKcurnNMBpqNNop4/OFZz9nNOdM5xznPs493UudR7iPNR5hPNI5xnO+52fOD91 /unSxMXfJcYly2WdywWXBy6vXT64fHQ1c7VwdXENdk12TXUd7jredZrrdNcPrl9dv7m1dvNxG+A2 1m2W2xy3PW5n3c65XXV75l7OvY57c/dA90z3HPdc94HuQ91PuH/zKO/RwMPGo9hjlccJj3ce3z2r e7p5BngmexZ5lnoO8Fztec3zjuddzzdelbyqeDXwcvPy8ArwSvYa6TXda7HXEa9LXp+8vnhX9G7m 3dq7nbeFt5W3nbezd5J3uncP70LvEm/oPdR7rPds70Xei72Xeq/03uJ9xPu090PvJ95vfCr4VPGp 7RPsE+GT5JPjQ3yUT3+fkT4LfZb43PO57/PQt5FvG19L306++b4FvkW+A3xf+L7z/eD7x/evXyW/ an42fv5+iX5d/TL9Tvid9nvvX+w/yX+9/xn/O52qdqrRKbIT7zSt08KAuICkgH4BOEAHrAk4HHAk 4ExglcCqga0DQwO7BeJAFrg8cEXgpsC9gTcCvwb+CbILcg7qFBQZNCZoftDGoLNBj4JeBvcNVsFj gmcGLw5eGbw6eE3ws+B/IVVDaob4hviF9A+ZHrIi5HrInZDPIV9C/oTWCnUIDQxNCM0JhaFjQ3eH Hg49Enoi9FzoldBboc9Cn4c5h2WH9QvbEXYk7GjY5bCn4RnhInxi+NTwDeGHw4+Enw//EP43IiCi LGJSxPyIFRFbIh51rtO5ced2nSM6R3c+2flBZM3I1pEdIlMi0yIzIosjyyIHRY6JXBN5NPJ9VLWo FlFuUQVRJOpA1OvoltE4WkWfiT4ffTX6WvT16HvRT6JfR7+J/hzTKqZ1TJuY+BgjZmbM0ph1Mftj TsWcjjkXcyW2Yqx5bFJsaiyNvRX7IPZXXKW4NnERcfFxKXGpcSTubHyz+OD42Pge8b3jZ8TPjl8U vyJ+Zfzl+G8JjgnOCb4JOIEkDEqYkbAyYWfCxS4tu9h0eZRYPjEiMSYxITE5MTMxNzEvsW8iS9SJ oxLHJU5OXJb4JPFF4t+kZkkWSV5JxUm9k6YlbUy6k1wuuU5y8+SOyXbJKFkkj0welTwmeWXy8ZRW Ke1T3FMCU6JSeqdsS9mZWpKqUnXqgNRBqcdSn6a+TKuUZp0WlcbTZNqotPlpp9M+pn1Lb5jeJN0m 3Su9U3p6elZ6fnpJ+tD0Kem70++k30t/lP4q/U3614yWGR0yXDO8MvpkTMt43PVI1ytdH3Z9nmmf mZDZK3Ne5o7Mk5nnM39kNciyyPLKmpG1Mmt11tqsk1kfsv5kt8o2z7bKds2Oy+6aXZzdL1tk988e mj0se0T2+OxJ2XOyF2Uvz16RvTJ7V/bx7PPZd7ud7/ai2/tuP7r9zKmW45HjkxOVk5FjyhE5o3Km 5SzMWdLdpXuv3Mq5TXJb5frmLsg9mHvMFGjqYko2ZZu6m/JM0ERNzCRM2jTUNNo0zjTeNNE02TTF NNc0z7TItNy0wrTatMa01rTOtN60wbTRtMe033TAdMx0ynTGdN50wXTVdMN003TbdMd0z/TQ9Mj0 2PTK9M703vTR9N302/TH9DevUl6VvKp51fNq5tXKq5NXN69BXsM8lzzPPO+83nkib3De6LzdeTfz K+X75Ifmp+aX5A/On52/Jv9lj849RvVYVlCpoGWBRUHHAr+CgJ51CjsUWhW6FLoW+hWmFmYUlhQ1 LmpeZF3kUpRalFlUVkSLdNHwoidF74t+F/sVdy0eUjyyeGzxrOIFxQuLrxS/Kf5a/LOkpKS0RJUM KhlVMrpkTMmMklklC0u2ldwvedrLr1dCr3293vb60ftu70d9fPr06LO5z9O+0/u+K+1QalnqUOpW GlWaVZpdmlc6tXRa6c3St6XvS3+U/iqrUvb/XuwtHtfuC1fDNXAtXAfXww1wI9wEN8MtcCvcBrfD HXAn3AV3wz1wL9wH98MD8CA8BA/DI/AoPAaPwxPwJDwFT8Mz8Cw8B8/DC/AivAQvwyvwKrwGr8Mb 8Ca8BW/DO/AuvFfmD+/DB/AhfAQfwyfwKXwGn8MX8CV8BV/DN/AtfAffww/wI/wEP8Mv8Cv8Br/D H/BnWQD8BX/DP/Av/IfKofKoAqqIKqHKqAqqiqqh6qgGqvlfk6JaqDaqg+qieqg+aoAaokaoMWqC mqJmqDlqgVqiVqg1aoPaonb/lSpqjzogM2Re1gVZIEtkhaxRR2SDbJEdskcOyBE5IWfkglyRG3JH HsgTeSFv5IN8kR/yR51QQFk2CkRBKBiFoFAUhsJRBOqMIlEUikYxKBbFoXiUgLqgRJSEklEKSkVp KB1loK4oE2WhbNQN5aDuKBeZUB7KRz1QAeqJClERKkYlqBfqjfqgvqgfKkVlyEAAQYQQRgRRxBBH AkmkykqRRv3RADSwzECD0GA0BA1Fw8ogGo5GoJFoFBqNxqCxaBwajyagiWgSmoymoKloGpqOZqCZ aBaaXSbQHDQXzSuTaD5agBaiRWhxmUJL0FK0DC1HK9BKtAqtRmvK+qO1aB1ajzagjWgT2oy2oK1o G9qOdqCdZYPQrrLBaDfag/aifWg/OoAOokPoMDqCjqJj6Dg6gU6iU+g0OoPOonPoPLqALqJL6DK6 gq6ia+g6uoFuolvoNrqD7qJ76D56gB6iR+gxeoKeomdl49Fz9AK9RK/Qa/QGvS2bhN6h9+gD+og+ oc9lk9EX9BV9Q9/LpqAf6Cf6hX6jP+hv2XT0D5fD5XEFXBFXwpVxFVwVV8PVcQ1cE9fCtXGdsjm4 Lq6H6+MGZXNxQ9wIN8ZNcFPcDDfHLXBL3KpsAW5dthC3wW1xO9wed8Bm2BxbYEtsha1xR2yDbbEd tscO2BE7YWfsgl2xG3bHHtgTe2Fv7IN9sR/2x51wAA7EQTgYh+BQHIbDcQTujCNxFI7GMTgWx+F4 nIC74ESchJNxCk7FaTgdZ+CuOBNn4WzcDefg7jgXm3Aezsc9cAHuiQtxES7GJbgX7l12GPcpO4r7 4n64FJdhAwMMMcIYE0wxwxwLLLHCGvfHA/BAPAgPLruEh+CheBgejkfgkXgUHo3H4LF4HB6PJ+CJ eBKejKfgqXgano5n4Jl4Fp6N5+C5eB6ejxfghXgRXoyX4KV4GV6OV+CVeBVejdfgtXgdXo83/CcW eCPehDfjLXgr3oa34x14J96Fd+M9eC/eh/fjA/ggPoQP4yP4KD6Gj+MT+CQ+hU/jM/gsPofP4wv4 Ir6EL+Mr+Cq+hq/jG/gmvoVv4zv4Lr6H7+MH+CF+hB/jJ/gpfoaf4xf4JX6FX+M3+C1+Z5TH7/EH /BF/wp/xF/wVf8Pf8Q/8E//Cv/Ef/Bf/I+VIeVKBVCSVSGVShVQl1Uh1UoPUJLVIbVLHqEbqknqk PmlAGpJGpDFpQpqSZqQ5aUFaklakNWlD2pJ2pD3pQMyIuVGbWBh1iaVRj1gRa9KR2BBbYkfsiQNx JE7EmbgQV+JG3IkH8SRexJv4GM2JL/Ej/qQTCSCBJIgEkxASSsJIOIkgnUkkiTJakWgSQ2JJHIkn CaQLSSRJJJmkkFSSRtJJBulKMkkWySbdSA7pTnKJieSRfNKDFJCepJAUkWJSQnqR3qTPf75D+pJ+ pJSUEYMAAgkimBBCCTM6Ek4EkUQRTfqTAWQgGWTYk8FkCBlKhpHhZIThREaSUWQ0GUPGknFkPJlA JpJJZDKZQqYabmQamU5mGB5kJplFZpM5ZC6ZR+aTBWQhWUQWkyVkKVlGlpMVZCVZRVaTNWQtWUfW kw1kI9lENpMtZCvZRraTHYYv2Ul2kd1kD9lL9pH95AA5SA6Rw+SIEUCOkmPkODlBTpJT5DQ5Q86S c+Q8uUAukkvkMrlCrpJr5Dq5QW6SW+Q2uUPuknvkPnlAHpJH5DF5Qp6SZ+Q5eUFeklfkNXlD3pJ3 5D35QD6ST+Qz+UK+km/kO/lBfpJf5LcRS/6Qv+QfLUfL0wq0Iq1EK9MqtCqtRqvTGrQmrUVr0zq0 Lq1H69MGtCFtRBvTJrSpkUib0ea0BW1JW9HWtA1tS9vR9kYK7UDNqDm1oJbUilob6bQjtTGyqC21 o/bUgTpSJ+pMXagrdftPw6g79aCe1It6Ux/qS/2ov1FAO9EAGkiDaDANMfrQUBpmlNJwGkE700ga RaNpDI01EI2j8QamCbQLTaRJNNngNIWm0jRD0XSaQbvSTJpFs2k3mkO701xqonk0n/agBbQnLaRF xhBaTEtoL9rbGEr70L60Hy2lZdSggEKKKKaEUsoop4JKqqim/ekAOpAOooPpEDqUDqPD6Qg60hhH Rxnj6WhjAh1Dx9JxdDydQCfSSXQynUKn0ml0Op1BZ9JZdDadQ+fSeXQ+XUAX0kV0MV1Cl9JldDld QVfSVXQ1XUPX0nV0Pd1AN9JNdDPdQrfSbXQ73UF30l10N91D99J9dL8xix6gB+khepgeoUfpMXrc mEtP0JP0FD1Nz9Czxnx6jp6nF+hFeoleplfoVXqNXqc36E16i96md+hdeo/epw/oQ/qIPqZP6FP6 jD6nL+hL+oq+pm/oW/qOvqcf6Ef6iX6mX+hX+o1+pz/oT/qL/qZ/6F/6j5Vj5VkFYxmryCqxyqwK q8qqseqshrGK1WS1WG1Wh9Vl9Vh91oA1ZI2Mdawxa8KasmasOWvBWrJWrDVrw9qydqw968DMmDmz YJbMilmzjsyG2TI7Zs8cmCNzYs7MhbkyN+bOPJgn8zK2M2/mw3yZH/NnnVgAC2RBxi4WzEJYKAtj 4SyCdWaRLIpFsxgWy+JYPEtgXVgiS2LJLIWlsjSWzjJYV5bJslg268ZyWHeWy0wsj+Ubh1gPVsB6 skJWxIpZCevFerM+rC/rx0pZGTMYYJAhhhlhlDHGmWCSKaZZfzaADWSD2GA2hA1lw9hwNoKNZKPY aDaGjWXjjNNsPJvAJrJJbDKbwqayaWy6cZ7NYDPZLDabzTGusLlsnnGVzWcL2EK2yLjGFrMlbClb xpazFWwlW8VWszVsLVvH1rMNbCPbxDazLcYDtpVtY9vZDraT7WK72R62l+0znrL97MD/qSo7yA6x w+wIO8qOsePGa3bCeMNOslPsNDvDzrJz7Dy7wC6yS+wyu8KusmvsOrvBbrJb7Da7w+6ye+w+e8Ae skfsMXvCnrJn7Lnxlb0wvrGX7BV7zd6wt+wde88+sI/sE/vMvrCv7Bv7zn6wn+wX+83+sL/sHy/H y/MKvCKvxCvzKrwqr8ar8xq8Jq/Fa/M6vC6vx+vzBrwhb8Qbg3K8CW/Km/HmvAVvyVuBirw1b8Pb 8na8Pe/Azbg5t+CW3ApU4da8I7fhttyO23MH7siduDN34a7cjbtzD+7Jvbg39+G+3I/78048gAfy IB7MQ3goD+PhPIJ35pE8ikfzGB7L43g8T+BdeCJP4sk8hafyNJ7OM3hXnsmzeDbvxnN4d57LTTyP 5/MevID35IW8iBfzEt6L9+Z9eF/ej5eCOryMGxxw+J9Cc8QxJ5xyxjkXXILGXHHN+/MBfCAfxAfz IXwoH8aH8xF8JB/FR/MxfCwfx8fzCXwin8Qn8yl8Kp/Gp/MZfCafxWfzOaANn8vn8fl8AV/IF/HF fAlfypfx5XwFX8lX8dV8DV/L1/H1fAPfyDfxzXwL38q38e18B9/Jd/HdfA/fy/fx/fwAP8gP8cP8 CD/Kj/Hj/AQ/yU/x0/wMP8vP8fP8Ar/IL/HL/Aq/yq/x6/wGv8lv8dvAid/hd/k9fp8/4A/5I+DK H/Mn/Cl/xp/zF/wlf8Vf8zf8LX/H3/MP/CP/xD/zL/wr/8a/8x/8J//Ff/M//C//J8qJ8qKCqCgq icqiiqgqqonqooaoKWqJ2qKOqCvqifqigWgoGonGooloKpqJ5qKFaClaidaijWgr2on2ooMwE+bC QlgKKxAhrEVHYSNshR3oLOyFg3AUTsJZuAhX4SbchYfwFF7CW/gIX+En/EGU6CQCRKAIEsEiBESL UBEmwkWE6AziRKSIEtEiRsSKOBEvEkQXkSiSRLJIEakiTaSLDNFVZIoskS26iRzRXeQKk8gT+aKH KBA9RaEoEsWiRPQSvUUf0Vf0E6WiTBgCCCiQwIIIKpjgQggplNCivxggBopBYrAYIoaKYWK4GCFG ilFitBgjxopxYryYICaKSWKymCKmimliupghZopZYraYI+aKeWK+WCAWikVisVgiloplYrlYIVaK VWK1WCPWinVivdggNopNYrPYIraKbWK72CF2il1it9gj9op9Yr84IA6KQ+KwOCKOimPiuDghTopT 4rQ4I86Kc+K8uCAuikvisrgiropr4rq4IW6KW+K2uCPuinvivnggHopH4rF4Ip6KZ+K5eCFeilfi tXgj3op34r34ID6KT+Kz+CK+im/iu/ghfopf4rf4I/6Kf7KcLC8ryIqykqwsq8iqspqsLmvImrKW rC3ryLqynqwvG8iGspFsLJvIprKZbC5byJayFSiTrWUb2Va2k+1lB2kmzaWFtJRW0lp2lDbSVtpJ e+kgHaWTdJYuAEtX6SbdpYf0lF7SW/pIX+kn/WUnGSADZZAMliEyVIbJcBkhO8tIGSWjZYyMlXEy XibILjIRcJkkk2WKTJVpMl1myK4yU2bJbNlN5sjuMleaZJ7Mlz1kgewpC2WRLJYlspfsLfvIvrKf LJVl0pBAQokklkRSySSXQkqppJb95QA5UA6Sg+UQOVQOk8PlCDlSjpKjwSA5Ro6V4+R4OUFOlJPk ZDlFTpXT5HQ5Q86Us+RsOUfOlfPkfLlALpSL5GK5RC6Vy+RyuUKulKvkarlGrpXr5Hq5QW6Um+Rm uUVuldvkdrlD7pS75G65R+6V++R+eUAelIfkYXlEHpXH5HF5Qp6Up+RpeUaelefkeXlBXpSX5GV5 RV6V1+R1eUPelLfkbXlH3pX35H35QD6Uj+Rj+UQ+lc/kc/lCvpSv5Gv5Rr6V7+R7+UF+lJ/kZ/lF fpXf5Hf5Q/6Uv+Rv+Uf+lf9UOVVeVVAVVSVVWVVRVVU1VV3VUDVVLVVb1VF1VT1VXzVQDVUj1Vg1 UU1VM9VctVAtVSvVWrVRbVU71V51UGbKXFkoS2WlrFVHZaNslZ2yVw7KUTkpZ+WiXJWbclceylN5 KW/lo3yVn/JXnVSAClRBKliFqFAVpsJVhOqsIlWUilYxKlbFqXiVoLqoRJWkklWKSlVpKl1lqK4q U2WpbNVN5ajuKleZVJ7KVz1UgeqpClWRKlYlqpfqrfqovqqfKlVlylBAQYUUVkRRxRRXQkmllFb9 1QA1UA1Sg9UQNVQNU8PVCDVSjVKj1Rg1Vo1T49UENVFNUpPVFDVVTVPT1Qw1U81Ss9UcNVfNU/PV ArVQLVKL1RK1VC1Ty9UKtVKtUqvVGrVWrVPr1Qa1UW1Sm9UWtVVtU9vVDrVT7VK71R61V+1T+9UB dVAdUofVEXVUHQPr1HF1Qp1Up8AmdVqdUWfVOXX+v0VQXVAXwTZ1SV1WV9RVdU1dVzfUTXVL3VZ3 1F11T91XD9RD9Ug9Vk/UU/VMPVcv1Ev1Sr1Wb9Rb9U69Vx/UR/VJfVZf1Ff1TX1XP9RP9Uv9Vn/U X7BP/dPldHldQVfUlXRlXUVX1dV0dV1D19S1dG1dR9fV9XR93UA31I10Y91EN9XNdHPdQrfUrXRr 3Ua31e10e91Bm2lzbaEttZW21h21jbbVdtpeO2hH7aSdtYt21W7aXXtoT+2lvbWP9tV+2l930gE6 UAfpYB2iQ3WYDtcRurOO1FE6WseA4zpWx+l4naC76ESdpJN1ik7VaTpdZ+iuOlNn6WzdTefo7jpX m3Seztc9dIHuqQt1kS7WJbqX7q376L66ny7VZdrQQEONNNZEU80010JLrbTW/fUAPVAP0oP1ED1U D9PD9Qg9Uo/So/UYPVaP0+P1BD1RT9KT9RQ9VU/T0/UMPVPP0rP1HD1Xz9Pz9QK9UC/Si/USvVQv 08v1Cr1Sr9Kr9Rq9Vq/T6/UGvVFv0v+j2y7c08oaBwE3lbRTd5cAIUZKQiC4JwESIFzgXiCBmwSJ ACEJadN22mk55zB1m7pO3b2durtN3S2Vqbu77VO+/ma/3X32/3jf9aENoY2hTaHNoS2hraFtoe2h HaGdoV2h3aE9ob2hfaH9oQOhg6FDocOhI6Gjob9Dx0LHQydCJ0OnQqdDZ0JnQ+dC50MXQhdDl0KX Q1dCV0PXQrWh66EboZuhW6F/QrdDd0J3Q/dC90MPQg9Dj0KPQ09CT0PPQs9DL0IvQ69Cr0NvQm9D 70LvQx9CH0OfQp9DX0JfQ99C30Gd3i9AFKgL6oH6oEHv1yAaNASNwC+gMWgCmoJmoDloAVqCVqA1 aNP7A2gL2oH2oAPoCDqBzqBL78+gK+gGuoMeIAZQABXQQCyggzgQDxJAIkgCDJAMegImSAGpgAXS ABtwQDrgAl5NHcAHAiAEIiAGEiAFMiAHCqAEGSATZAEVUAMNyAY5QAt0QA9ygQFgwAhMwAxwQAAL sAIbyAP5wA4cgAQFoBAUASdwATfwgGJQAkpBGfACH/CDchAAFaASVIEgqAa9QG9QA/qAvqAf+BX0 BwPAb2AgGARCAAAIEAiD38FgMAQMBcPAcDACjASjwGgwBowFf4BxYDyYACaCSWAymAKmgmlgOpgB ZoI/wSwwG8wBc8E8MB8sAAvBIrAYLAFLwTKwHKwAK8EqsBqsAWvBOvAXWA82gI1gE9gMtoCtYBvY DnaAnWAX2A32gL1gH9gPDoCD4BA4DI6Ao+BvcAwcByfASXAKnAZnwFlwDpwHF8BFcAlcBlfAVXAN 1ILr4Aa4CW6Bf8BtcAfcBffAffAAPASPaozgMXgCnoJn4Dl4UYODl+AVeA3egLfgHXgPPoCP4BP4 DL6Ar+Ab+A7rwChYF9aD9WEDGA0bwkbwF9gYNoFNYTPYHLaALWEr2Bq2gW1hO9gedoAda/JgJ9gZ doFdYTfYHfaAMZACqZAGYyEdxsF4mAATYRJkwGTYEzJhCkyFLJgG2ZAD0yEX8iAfCqAQiqAYSqAU yqAcKqASZsBMmAVVUA01MBvmQC3UQT3MhQaIQSM0QTPEIQEt0AptMA/mQ3tNGXRAEhbAQlgEndAF 3dADi2EJLIVl0At90A/LYQBWwEpYBYOwGvaCvWEN7AP7wn7wV9gfDoC/wYFwEAxBUFMFIUQwDH+H g+EQOBQOg8PhCDgSjoKj4Rg4Fv4Bx8HxcAKcCCfByXAKnAqnwek1NXAGnAn/hLPgbDgHzoXz4Hy4 AC6Ei+BiuAQurRkAl8HlcAVcCVfB1XANXAvX1QyCf8H1cAPcCDfBzXAL3Aq3we1wB9wJd8HdcA/c C/fB/fAAPAgPwcPwCDwK/4bH4HF4Ap6Ep+BpeAaehefgeXgBXoSX4GV4BV6F12AtvA5vwJvwFvwH 3oZ34F14D96HD+BD+Ag+rhkLn8Cn8Bl8Dl/Al/AVfA3fwLfwHXwPP8CP8BP8DL/Ar/Ab/I7qoChU F9VD9VEDFI0aokboF9QYNUFNUTPUHLVALVEr1Bq1QW1RO9QedUAdUSfUGXVBXVE31B31QDGIgqiI hmIRHcWheJSAElESYqBk1BMxUQpKRSyUhtiIg9IRF/EQHwmQEImQGEmQFMmQHCmQEmWgTJSFVEiN NCgb5SAt0iE9ykUGhCEjMiEzwhGBLMiKbCgP5SM7ciASFaBCVIScyIXcyIOKUQkqRWXIi3zIj8pR AFWgSlSFgqga9UK9UQ3qg/qifuhX1B8NQL+hgWgQCiGAIEIojH5Hg9EQNBQNQ8PRCDQSjUKj0Rg0 Fv2BxqHxaAKaiCahyWgKmoqm1YlqVhkzPubPmNkxC2N2x5yOORNzJeZ6zF1KK0oMhUJhUlIpLAqb wqGkR/SHiCKmSChKShbFQSmhBCi9KCHKCMpYylTKdMoKygHKBco1Si3lLuUe5RG1CbUZtQ2VQqVR 46mJ1OSIGTFS86gOaim1glpFHUT9nTqUOpw6kTqTOos6l7qQupy6krqOup66gbqRupl6knqGep56 kXqJep16h/qY+p3WgNaC1pbWlRZDo9ESaIk0EU1MU9AyaHqa8adCqY44lIG0EbQxtHG0CbRJtAW0 pRGXcoR2inaOdoF2lXbtp035RPtM+0L7Ghsd2z02JpYSy4rlxApi5bFZsapYItYe648tjw1E5Mrk 2BWxf8Xuit0beyj2aOyZ2Luxj2KfxH6kR9Hb0zvQO9Jj6EK6nm6gW+g2uoNeTC+ll9MrIrLld/pQ +gj6aPpE+hT6LPpS+gr6avoa+jr6FvpO+m76YfoJ+kn6Tfot+kP6U/o3+ve4unH146LjGsc1j1PE 5cSZflqYirj+cb/FheJWxG2O2x63I25v3KG4k3EX497H14lnxXMiPkYZb4g3xveO7xs/Kn5M/KT4 yfGz43fE74zfG384/nhEztyLfxr/KqFxQpOEFgltfioabgIvQZAgTHAn9EoYkjAsYXTCpIT5CYsS liVsTtiZcCjhdMLVhH8S3id8SmyY2C5RlChJ1CZiiaZEa2JeoiOxKNGV6E30JVYmDkuckjg1cWbi 3MTliRcSLyfeTGqS1CqJmpSSxE4yJTmTqpPCSUOShiVNSpqSNDVpSdKWpF1Ju5OOJV1OupV0O+l+ 0oOkh0lPkz4x6jOaMVozOjKoDAajZ8Tv8BlCRjZDz8AYeETyeBhljACjgtGLMYAxiDGfsZCxnLGW sZlxkHGIcZZx6afyucO4x7j/0/q8Y3xkfE1undwmuVNycnJaMi9ZkZyTrE8mkvOT3cl9k39NHpA8 MHlq8uLkZcnLk1cnb07en3wq+VLy2+SPyZ8jMsjWM79nSc+qntU9J/Zc2HNLzzM97/V82PPJvzKo LrM+szWzLbM9swOzI7MzswuzOzOWGceMZyYwE5lJTAaTxUxjspkcZjpTxJQwZUwlMyMiidRMDTOX aWAamWYmziR+qiIX080sZQaYFcyqiDDqzaxh9mH2ZfZj9mcOYA5kDmKGmL8zB/+rjnYzTzHPM68w a5l3mC+Zr5mfmV+Z31IapXRJ6ZGSnsKLKKTMlKyIRCpL6Zvya8pvKaGUcMQhTU6ZnjLzp0ZalLI0 ZVnK2pSNKVdSaiMe6XPKt9RWqe1Tk1NTUlmpglRRqiRV9a9NsqU6Up2pgdSq1D6pfSNGaVzqnNQV qdtT96YeSD2Yeiz1TOrZ1NrU26l3Up+lvkh9yWrIasxqwmrKasZqw2rP6sTqzopl0VlxrEQWg5XC SmdxWUKWmJXJymKpWGqWnoWxjCxrxDy5WMUsL8vHKo/YpypWkFXN6svqxxrAAiz0U0L9wZrHms9a wFrEWsxaxlrF2sDayNrM2s7azdrPOsg6xPqbdZF1mXWVVRvRUk9YH1mfWN/T6qRFpzVKa57WPq1D Wpe01DRJWmaaJk0bcVSlaWVp5WmBtNlpy9NWp61JW5+2IW1r2s60U2mn026kPUl79kNYpb1P+8xu w27L7sjuwqaxk9gydgY7k61m69gWtotdyq5gD4nIq/HsmexZ7AXspeyN7E3sC+yL7MvsK+yr7Fr2 HfZ99hP2S/abHy6L/ZVTl1OPU5/TgBPN6cTpxunBoXG4HD5HyBFxJBwFJ4uTzbFwbJw8jp3j4EDO EM5QzkjOKM5ozhjOWM5kztSI6FrD2cLZwdnD2RuRXac4FzgXOZc41zj3Oc/T66Q3Sm+d3jE9Jj02 PS5dlC5Pz0zPSTemW9Jt6fZ0Z3pJuj8iv6akT03flL4z/Uj60fRj6ffS36W/T//AjeI24Lbm0rlM bgo3lcvicrhcLo/L5wq5eq6ZS3ALuMVcH7eK24/7O3cwdxZ3EXc5dy13A3cTdxt3O3cf9zi3lnuf +5z7jvuB+43XkNeIl8zryWPzODwhT8yT8GS8HB7GM/NwnoWXxyN5Tp6bV8rz8ip5QV41r4Y3gDeI B3lh3nDeKN5Y3gTeYt5y3greOt5fvK28A7yDvMO847yLvOu8O7y7vPu8B7wnvKe8V7y3vM/8qIhP a8VvzW/P78LvwY/hM/mpfC5fyJfxVXwNX8vX8TG+iW/m43yCn8+38wv4Tn4J38ev4gf5I/gj+aP4 4/iT+FP50/iz+Av4f/HX83fz9/H38w/wL/Gv8x/wn/Jf89/w3/Lf87/xvwuiBW0EHQU9BHGCeEGC IFmQIpAIFAKNIEegF5gFloh/8wr8gkpBjaCfAAmGCEYKRgvGCMb+VHAbBTsExwTXfzg4wRfBd2Fd YTNhe2FnYRehTKgWGoSY0CwkhE5hUNgnIuNCQiQcI5wnXCPcLNwq3CPcJzwkPCw8KTwvvCi8JqwV fhHVE7UUtRa1FVFFcaJkEVOUKhKLpCKlKFNkFllFDpFT5BZ5RFWigSIoGi6aIJoomiKaLpohmin6 UzRXtE90WHRMdEL0j+ip6KXoU0TZ1RPXF0eLG4lbiWPENHGsOEnMEKeIuWK5OEOcI8bEJnGhuEwc FPcVjxGPE88RzxMvEi8TrxSvEq8R74+ovPPi++Jn4hfit5IWkjaSjpKukm6SHpI4SYpEJJFIlBK1 xCgxSXySgKRC0lcyQTJNMldySHJYcl5yQXJJclVSK7khuS15IHkheSONkjaWNpe2k3aVxkrpUqlU Kc2UqqTZUq00V2qQ4lJCmi91SAukTqlL6pYWS0ukpdL+0kHSKdJZ0jnSedLH0m+yKFkDWTtZe1kX WVcZRUaTyWVqWY4sV2aUmWW4zCXzyMpkXplPViWrlvWXDZQNkoVkq2SbZXsidvCw7LjslOyh7JXs teyD7GNEEnaUd5V3k8fKRXKpXCHPlGvlBrld7pR75KXyMnlA3iuiDAfIB8qBHMqRfIh8mHyEfIl8 hXyVfLV8jXydfL18o3yHfKd8j/yA/JD8sPyI/Iz8svxRxCNGKeoquivoingFQ8FUsBQchUAhV2Qp shU6Ra7CqMhX2BUuhVvhUQxQDFJARVgxVDFaMVUxTzFfsVqxVrFOsVWxR3FCcUpxU3FbcU9xX/FQ 8UjZUNlE2UzZQtlK2UHZQ8lWCpRypVKpURqURqVJmaf0KEuVPmWFslLZS9lPOUgJlKOVfygnKScr pyqnK2cpFygXK5dGNOQq5UblQeVV5U3lfeUT5auIjBRGZKQqY1jG1IwZGUsylmYsz1iZsSZjQ8al jBsZdzMe/7CSmU0zO2XSMpmZokx5pj4Ty7RlFma6Mz2ZlZk1mX0yB2QOzByTOTNzduamzO2ZuzL3 Zx7JPJp54n8cZeazzJdZ9bKaZrXIomSxsrhZZFZhljOrMqsqq1/WyKzlWSuy1keM5Ymss1m1WTey bmV9V0Wp6quiVY1VbVTtVO1VTJVYpVBpVOWq3hGDOVE1WTVVtUy1VrVetUm1VbVNtUO1U7VfdUR1 UnVWdUV1T/VI9Vj1UvVK9U31Xd1a3V7dUd1ZHa9mqlPVaWqOmqvmqWVqhbpAXar2qv3qSnVQXa0e qB6iHq+eoJ6hnqmeo56nXqBeql6u3qDeqb6gvqK+rn6gfqx+on6p/qj+FpGe3TUxGpomUZOsSdNw NEKNQqPUZGrUGo1Gq9Fp9BqjBtdYNHkah8apcWs8mlJNmcanCWiCmmpNSAM1SBPWDNeM1IzWjNGM 1fyhmaqZrpmpWaJZpVmtWaNZq/lLs0GzUbNLs09zXnNBc1FzVXNLc1dzX/NY80LzUvNa80HzUfNZ 8z07KrthdpPsVtntIt6Uns3ITs/O+OlOHdm9sntn98mG2eHsEdmjsydkr8penb05+2D2oey/s89n P8p+kf024lG75cTk9MwR5ShzcnJycyw5jpySHG9OdU6fnH45A3Nm5MzNWZ+zLWdPzidte20XbTdt jJaqjdMmatO0Am22Nker12JaXEtqC7VubV/tAO0g7R/aJdoN2i3ardrj2pP/pVv/0d7R3tXe0z7U PtI+jkjX59o3ul90zXUtdZ1+mleaLkmXruPqBDqJTqaT65Q6jS5bp9MZdJjOo6vRDdBN1E3XzdQt 0i3RLdUt163S7dYd1B2N+NgTupO6Wt0H3Sfdd309fQN9I/0v+ub6lvo2+g56ij5WT9fH6eP1TD1f L9BL9FJ9lj5bn6s363G9RZ+nz9cX6cv0FfpKfbW+t75G31//m36QfrB+in6lfrV+m367/or+hv6m /nlu/dyuud1zGbmpP92tLTc/155bmVuT2y8X5Q7JnZw7M3dO7pbcrbkHc4/nnsg9mXst90bu7dzn uZ8NdQ0dDRQD08AycAxcg9ygNGgMOoPTUGzwGwKGSkPQAA1hw2DDUMMIw2jDWMM4wwTDRMMkw2TD FMM0w3TDTMNsw3zDAsMiw2LDkojuXW5YbVhjWGvYathm2GHYadhl2GPYa9hvOGw4YjhhOG04Yzhr OGc4b6g1XDfcMNw1PDI8Njw1vDC8NLwyvDW8N3w0fMXqYFFYXawR1hRrjnXDumNUjIExI2Y4DRNh YkyCSTEZJscUWAaWiakwNZaN5WA6TI/lYhYsD8vHnFgp5sXKsQBWiVVh1RFpPAAbhEEsjI3ApmLT sOnYXGwBtgxbga3EVmFrsLXYOmwrtgPbie3G9mD7sYPYYewIdhQ7hh3HTmFnsPPYBewWdhu7g93F HmAPsafYC+wD9hH7hH3BvhsbGRsbmxibGlsZOxg7GbsYuxupRpqRbow3JhkZxkPGI8ZzxhvG28Y7 xufG98avxu+maFMjU2tTW1M7U6Ip2ZRqkpoUpiyTOiKf80x2E2lymzymClOlqcpUY+pnQqZhprGm 8aYJpkmm6aYFpkWmxaZNpjOm86bLprum+6aHpqemb+Yoc7S5kbmZuY25rbmdub25s7mLmWqONyea k8zJ5lQzy8wx880Cs9gsNcvNCnOGOdtsMpvNdjNpLjaXmb1mn7ncHDD3Mvc2DzIDc9g81DzSPMo8 zjzRPMk8xTzNvNi8zLzOvNW803zYfNx83nzFXGu+Yb5p/sd823zH/Mb81vzJ/NX8Ha+D18Mb4o3w X/DmeAu8Fd4a74B3wrvjsXgizsCT8RQ8DefhfFyGK/FMPBvX4Xo8FzfgRpzAbbgDL8JL8TLci1fg lXg13jsiuxEexofjI/DR+Dh8Mj4Vn4bPwGfjy/Dl+Ep8Fb4G34Jvxbfhe/H9+AH8IH4IP4yfxM/h F/D7+AP8If4Mf42/xd/jn/Cv+DeiDtGQaEZ0JroS3QgKkUAkEskEk+AQfEJIiAgxISGkhJxQEipC TWiIHEJL6Igiwkm4CDfhIUqIMsJH+IkAUUFUEdVEb6KG6EP0JwCBiDAxjBhOjCBGE38Q44jxxARi IjGJmEosJBYRy384dGInsZvYQ+wj9hMHiEPEYeIkcY64QFwiLhPXiRvETeKWpa6lviXa0tjSxNLc 0t7S0dLJ0s1CtdAt8ZZES09LioVl4Vn4FoFFaNFZMAtusVhsljyL3UJaii2lFr+lwlJp6WfpH/Hu ICLeB1uGWUZYRlnGWyZYJlumWaZbZlhmWv60zLNstmyz7Lbstxyy/G05ZjlvuWSp/aHjLS8sryxv LR8snyyfLV8sXy3frPWt0dZG1l+sraw9rDRrgpVhZVpTrQprhlVt1VhzrFprrtVgxaxGq9lKWG3W PGu+1WEttBZZiyPKPmwdaR1jHWudZJ1jnWedb11gXWRdbF1qXWldZV1jXWddb91g3Wbdbt1pPWY9 aT1lPWO9aL1kvWyttf5jvWO9Z71vffDD6Fs/WD9aP1m/2KJtzWwtImK/g62Trbuthy3GRrMl2JJs DBvblm7j2fg2gU1qk9k0tuyI5ydtBbbCiOovt/Wy9bb1s/1qG2IbZhtuG2EbbRtjm2SbbJtmm25b ZFtqW2vbbjthu/ZT/t+J2P9ntnd5dfIa53WKHIDYvLTIA7Dk2fIq8vrl/ZY3Im983pS8qXlz8ubm Lc87mHc070Rebd4/eXfyHuS9ynuf3yqfmS/Nz87PyTfkm/OJ/Px8Z/7o/In5M/MX5q/KX5O/Nn9d /oH8o/m3foyC/Ef5L/Nf5b/P/5T/3R5lr2+Ptje1N7M3t7e0t7J3sHe2d7VT7HR7nD3B3tPOsrPt QrvcrrJjdqO9wO62e+yl9jK7315ur7BX2fvaoR3Zw/ah9mH2kfZR9tH2cfbJ9mn2GfbZ9rn2efbF 9iX2lfb19i32rfYD9kORw3DWftV+1/7U/sz+3P7a/tb+0f7F/s0R5ajnaO5o7ejgoDrojnSHwKFz 5DoMDq/D7yh3jHWMc4x3THFMc8xw/OmY7ZjrmOdY6FjkWPzzQaxzrHdscWx37HbscxxwHHEcdfzt OOU477jouOG46bjluO2443jkeOp47njpeOV46/jg+OT47Pji+Or4TtYho8i6ZH2yEdmEbEW2IduS 7ckuZFcyhqRGXkUi2ZNMIVPJNJJNcsh0kkvySAEpIxWkhtSSejKXNJJm0kLmkw6ygHSSxaSP9JMB soKsJKvIINmLrCH7kP3J38iBJCAROfjnzRhNjiX/IMeRE8jJ5J/kbHI+uZBc9HNqrCBXkxvITeRW chu5lzxMHidPkZfIWvI6+Q95l7xPPiQfk8/It+Qn8jP5jfxeUK8guqBpQfOCFgWdCroUdCugFFAL 6AUJBYkFJwpOFVwtuBMZHy9/nI+Cz4W0wvhCbqG0MKtQV5hbaCrMKywqdBVWFoYKhxeOKBxVOKFw YuHkwimF0wpnFs76MUIK3xV+KapbFF3UqSihiCgqL6ooqirqWzS1aFfRvqKzRReKLhZdLrpadKPo TtFzZ5SznrONs72zs7OrM8ZJc6Y6BU6R0+Ac75zmnOtc4Vzp3Os87jztPOs85zzvvOZ84XzpfO1K cjFcTFeaK93Fc4ldEpfUJXPJXQpXrsvoMv97T4Ku3v/1T8KuIa6hruE/F8q4nw9lumtm5KLMcc13 LXAtdC36/56U/a4D/8dLufTvTLnuuuG66br186fcdz1wPXY9cT11PXe9cr1zvf93qkS567sb/F9b paW7VWSstHd3cHdyd3cnuNPdArfMrXbnuUm3z93L3TeyWMa5l7i3u3e5L7kvu6+4r7qvuWvdt9x3 3ffdL92v3G/cH9wf3Z89UZ66nvqeaE9DTytPe09HT2dPV08PD8XD8LA8Ao/QI/JIPFKP3JPhyfRk ewwezGPz5Hv8noGe3z2TPDM9cz2LPCs9+zwXPZc8Dz2PPE89bzzvihsWNytuUdy6OLZYWawq1hQX FlcW9yseVjy8eEzxuOIJxbOLFxcvLV5RvLJ4dfH64k3F+4uvFF8rvl18t/he8aPi75FjQyuhl8SV JJaklbBLuCWiEkmJrMRUYi0pLCkqKS4pLSkvCZRUlQwumVeyuGRryYGSQyVPS56XvCz5WFq/NLq0 SWnT0malzUtblkWX0crkZZqynDJtmaXMXuYoc5f5y4Jlvcv2lJ0su1J2rexG2aOyZ2Uvyz6WfS77 7o3y1vc28EZ7G3rbett5O3g7ebt547zx3gQvw8v18rwyr9yb4VV7Nd4cr9Zr8GJesxf3El6L1+bN 99q9Di/p9XiLvWVen9fvDXqrvf28v3oHeUNe6B3sneCd5J3snen907vE+5d3i/ew95j3tPeM96z3 vPeS9673sfep94Wvja+rr7uP5xP6xD6lz+QjfPk+l8/vQz8H0VjfeN8M3yzfnMgkWuz7y3fYd9R3 zVfru+575Hvqe/NjFvm++b776/jr+uv5eX6pX+7P8pv9hN/nr/AH/f38/f2/+Qf54b/zaLx/on9q 5B/N9s/1z/PP9y/2r/Sv8f/l3+jf5N/m3+E/5j/uP+e/5L/iv+q/4b/pv+W/7b/jv1eeUM4rx8qL ykvLfeXl5b+VDywfWj6m/I/yieVLyreW7yo/UH68/GT56fJz5bXlD8sflT8rf1n+uvxD+ceALKAO FARcgdKAP1ARqA7UBPoHfgsMDAwKgMCQwIjApMDiwNLAqsDawLrAxsDuwJ7A0cDfgVOB04EzgbOB c4FrgdrA9cDNwO3A/Yp6FfUrhBWaCkOFr6JXRd+KUMWkivkVayr+qlhfsb1iT8XRivMVFysuVdyq uFfZsLJf5aTKyZVTK+dWLqhcVbmu8njlicpTlY8rn1dFVXWsSqxSVGVUqauyq7AqY1VBlauqpKqs qqYKVg2rGl41qmpZ1cpg82CHYOdgl2BMkBL5WMmRkcUPZgRzgtqgPjKzCoKFwd7BQcFwcHBwSHBY cERwZHBUcHJwQXB1cFvwaPBy8EqwNng9eDv4LPg8+CL4Kvg2+C5yuKKqG1RHV3et7lEd+9+bi6Pr TEPTf2wuNKNmNZqJ/kSz0Oz/vC40B81F89B8tAAtRItqNqLFaMmP44WWomX/7/JCy9EKtLLmAFqF VqM1NQfR2ppDaB36C61HG9BGtKnmKNqMtqCtaNuP+4W2ox01J9FOtOvHAEO7/zPA0B60F+1D+9GB movoYM1ldOh/bzB0uOYGOoKO1txEf//PCEPH0PGae+hEzX108scMQ6fQ6ZpH6Aw6W/MYnat5is6j CzXP0MUfSwxdQpf/88TQFXQVXUO1/9li6Dq6gW6iW+gfdLvmM7qD7tZ8QffQffQAPUSP0GP0BD3t E4We9amHnv84ZOgFeole/Zhk6DV6g96id+h9n8boQ7USfUSf0Gf0BX1F39D3cJ1wVJ/m4brheuH6 fVqGG4Sjww3DjX48s/AvP6ZZuHG4Sbhpn/bhZuHm4RbhluFW4dbhNn06htv+uGfhduH2fbqGO4Q7 hjv16RHuHO4S7hruFu4e7hGOCVOqc8PUMC0cG6aH48Lx4YRwYh9aOKnaGGaE/xcb98Al55YoADS2 bdu2bds2uzrl7k5y7C+2bdu2bdt28ta5tXrlzsz7IXsXcecHRUExd0F3YVDcXQSUACVBKXcxUBqU AWVBOVAeVAAV3SVAJVAZVAFVQTVQPawtqBESa6CmuwKo5a4IarsrgTpWroG6oB6oH/JroAFoCBqF dQWNQRPQFDQDzUEL0BK0Aq1BG6vaQFt3HdAOtAcd3HVBR9AJdAZdrHIDXcO6h5wb6Aa6u5uCHmE9 3S1AT9AL9AZ9QF/r3UC/kHgD/cEAMNDdAQyKlm9gMBgChrq7g2FgOBgBRoIw4ALhYBRwAw/wWgsH fGH9gB8EQDAk4kCENXEgEkS5h4LRYAwYCwCAAAEMCKCAAe4eDkTIygEJFNDAAAeMA+NDag5MABPB JDDZ7QVTwFQwDUx3+8EMdxDMBLOsowOzwRwwF8xzjwbzwQKwECxyjwGL3WPBEqvqwFLr6sAysBys ACvBKqvrwGqwBqwF68B6twQbwEawCWy21g5sAVvBNrcDtoMdYR6wE+wCu8Ee90SwF+xzTwL7wQFw 0Po7cMg9DRwGR8BRcAwcByfcM8DJsCA4BU6DM+5Z4Cw4554DzoML4CK4BC6DK+AquAaugxvgpnsu uAVugzvgLrjnngfugwfgIXjkXggegydhkeApeAaegxfgJXgFXoM34K17OXgH3oMP4CP45F4JPoMv 4Cv4Br6DH9b0gZ/gF/gN/sAYMCaMBWPDODAujAfjwwQwIUwEE8MkMClMBpNb9wdTwJQwlXsDTA3T wLQwHUzv3gIzuLfCjO5tMJNVgDBzGIRZYFaYDWaHOWBOmMuaQJgb5oF53ftgPpgfFoAFYSFYGBaB Rd0HYDFY3H0QloAlYSn3IVgalnEfgWVhOWsGYXlYAVZ0H4eVYGVYBVZ1n4DVYHX3SVgD1oS13Kdg bVjHekJYF9azphDWhw1gQ9gINoZNYFNrC2Ez9xXYHLaALd3XYCsrDGFr923YBraF7dx3YHvYwX0X dnTfg51gZ/d92AV2dT+w5hB2g91hD+sOYU/YC/aGfaw9hH3dr2E/2B8OgAPhIPcbOBgOgUPhMCsR 4XA4wv0BjgybCMOgC4bDUdANPdALfdDv/gwD7i9/dSIMwggYGa0TYRQcDcfAsZ44EEAIUdhMiCHx JIQUMsihgNKTGCqoofEkgY4nqTWLcJwnJRwPJ1i3CCdauQgnwclwiicdnAqn/WMYM3kyw+lwBpwJ Z8HZnqxwDpwL58H5cAFcCBfBxXAJXAqXweVwBVwJV8HVcI0nhxWOcC1cB9fDDdY5wo1wE9wMt8Ct cBvcDnd4CsCdcBfcDffAvZ6CcB/cDw/Ag55C8BA8DI/8oyH/ZSHhUXgMHv9PEQlPWBMJT/5bRcJT 8PR/y0h45j9lJDwLz1kbCc972sMLng7woqcjvOTpDC/DK54u8Cq8Bq97usEbnu7wpqcnvGWlJLwN 73j6w7uegfCeZzC8Dx9YLQkfwkfwMXwCn8JnYQfhc/gCvoSv4Gv4Br6F7+B7+AF+hJ/gZ/gFfoXf 4Hf4A/70jIS/4G+PyzMK/kExUEyrK1EsjxfFRnFQXBTPE0DxUQKU0EpLlAglRklQUpQMJY9WlygF SolShewlSo3SoLQoHUqPMqCMKBPKHC0xURYPR1lRNpQd5UA5PRLl8qhok4lyeyagPCgvyueZjPKj AqggKoQKoyKoqGcqKoaKoxKoJCqFSqMyqKxnBiqHyqMKqCKqhCqjKqgqqoaqe2ajGqgmqoVqozqo rmcuqofqW82JGoQ8J2qIGqHGqAlqipp5lqDmqIW1naglaoVaozaoLWqH2qMOqCPqhDqjLqgr6uZZ i7qjHmEfUc+wT6gX6u3ZgPqgvqifZyPqjwaggf/4z62ebWiQZwca7NmJhnj2ePahoWgYGo5GoJEo DLk8+1G4taBolOcwciMP8loRinzIb1UoCvxVoShoXSiK8FxAkZ6LKAqNtj4UjYn2oWgsAiEjiiBC CCOCqOcOYogjgaTnHlJ/zSjSyHieIweN87xE49GEsD+eN2iiHbXQJM9bNBlNQVPRNDQdzUAz0ayQ JkWzrSdFc6woRXPRPDQ/5ErRArTQ8xMtCtlStNgbAy1BS9EytBytQCu9MdGqkDVFq9EatNYbF61D 69EGtBFtQptD6hRt8SZFW9E2bzK0He0I+VO0E+1Cu9EetBftQ/vRAXQQHUKHQx7VlRgdsSIVHbUm FR1Dx9EJdBKdQqfRGW8WdPYfofqPT0XnXEnReXQBXUSXXCnQZXTFWwBd9RZC19B1b1F0w1sM3US3 0G10x1sC3UX30H0rVtED9BA9Qo9DahU98VZAT70V0TP0PFquohfoJXqFXntrojfoLXqH3qMP6GO0 ZEWfvPXRZ29D9AV9Rd/Qd/QD/fQ2R7+8LdFv9AfHwDFxLBzb2wbH8bbFcXE8bwccHyewphUnxIlw YpwEJ8XJvN1wcpwCp8SpcGqcBqfF6axyxelxBpwRZ8KZcRacFWfD2XEOnDMkX3EunBvn8Q7BeXG+ aP2K8+MCuCAuhAvjIriodwQuhovjErgkLoVL4zK4LC7nHYXL4wq4Iq6EK+MquCqu5vXj6riGN4Br 4lq4Nq6D63qDuB6u743ADXBD3Ag3tmIWNwmZWdzUVRQ3w82j3Sxu4WW4pas4boVbezlu4xW4LW6H 23sl7oA74k64s9fgLrgr7uZ1cHfvONzDOx739E7EvXBv3Af3xf28k3B/K2zxAO9UPBAPwoPxEDwU D/NOx8ND1haP8M7BI621xWHYhcO9C/EoK26xG3uwF/uwHwdw0MpbHOFdiSNxFB6Nx+CxGHjXYIgR xt71mGCKGeZYYIkV1thgB4/D4/EEPBFP8m7Dk/EUPNVVGU/zbsfT8QzvTjwTz8Kz8Rw8F8/D8/EC vBAvwout2MVLvAfwUrwML3dVxyvwSu8RvCqkdvFqvAavxeu8Z/B6vAFv9J7Dm/Bm7wW8xXsRb8Xb 8HZrePEOvNN7De/yXse7vTfwHrwX78P78QF80HsLH8KH8RF8FB/Dx63txSfwSXwKnw4JX3zGGl98 Fp/D5630xRe8L/BFK33xJe9bfNlKX3wFX8XX8HV8w/sJ38S3vF/wbXzH+xXfxfe83/F9/AA/xI+s /sWP8RP89P/zv/hZSADj5/gFfolf4df4DX6L31kLjN/jD77U+KMvDf5kRTD+jL/40uOv+JurFf6O f+Cf+NdfH4x/4z+uNlYJkxgkZrQTJrFCUpjEJnGsFXZ1JHFJvL9emMQnCUhCkogk9hUnSUhSX0mS jCT3lSIprB4mKV09SSqSmqQhaa0gJul8lUh6X2WSwVeVZCSZSGaSxVedZCXZSHaSg+QkuUhua4pJ HrvtkbzWFZN8JD8p4KtHCpJCpDApQoqSYtYYk+KkBClJSpHSpAwpa70xKUfKW3NMKvhakIqkEqlM qlh3TKqSaq6AlcekOqlBapJavg6kNqljDTKpGzLIpF60QSb1SQPSkDTy9SGNfX1JE9KUNLMimTR3 QdLCumTS0jeYtPINIa1JG9KWtHNh0t43jHQgHUkn3wjS2TeSdPGFka6kG+ke8sqkh89NepJepDfp Q/qSfqS/z0cGkIFkEBlMhljFTIZax0yGWcdMhpMRZCQJIy4STkYRt28s8RAv8VnZTPwkQIIkgkSS KDKajCFjfYQAAn2cIJ8g2EpnQgglzFpnwokgkqiQeSaaGOKQcWQ8mUAmkklksm8SmeKbTKaSaWQ6 meGbSmaSWWQ2mUPmknlkvm8GWUAWkkVkMVnim0WWkmVkOVlBVpJVZDVZQ9aSdb45ZD3ZQDb65pNN ZDPZ4ltEtpJtZDvZQXb6lpBdZLdvOdlD9pJ9ZD85QA6SQ+SwbyU5Qo761pBjvrXkODlBTvrWk1Pk NDlDzpJz5LxvE7lALpJL5DK5Qq6Sa1ZYk+vkhm87uUlukdu+neQOuUvukfvkgW8XeWjVNXlEHpMn 5Cl5Rp6TF+QleUVeu2aQN+QteefbT96TD+Qj+UQ+ky/kq5XZ5Bv5Tn5Yn01++o6QX+S3azb5Q2PQ mDSW7wSNTePQuDQejU8T+E7ThDQRTew7S5P4ztGkNJl12zQ5TUFT0lTWb9PUVnDTNDRtyHDTdL6b ND3NQDP6btNM/225aWaahWal2XxPaHaag+akuWhu3zOah+b1Paf5rPCm+WkBWpAWooVpEVqUFqPF aQla0qpvWoqW9r2lZXzvaFlajpanFawApxVpJd9nWplWoVV9X2g1a8Fp9ZAFpzVozZAHp7VobVrn 3yKc1qX1aH3rwmkD2pA2cq2gjUM2nDahTa0Op82sDqfNaQva0rWWtvJnoK1pG9qWtqPtaQd/RtrR n5l2op39WWkXfzbalXbzZ6fdaQ/ak/aybpz2pn1oX39e2s+fj/b3F6AD/AXpQDqIDqZDog05HUqH 0eF0BB1Jw6wmpy5/GRpOR/nLUbe/PPVYUU69VpRTH/XTAA36q9EIGkmj6Gg6ho51bafAX4tCiiim hFLK/HUop8Jfn0p/A6qopoY61pvTcVac0/F0gjXndCKdRCfTKf5WdCqdRqfTGXSmNeh0Fp1N59C5 dB6dTxfQhVaj00V0sb8zXUKX0mV0OV1BV9JV/q50NV1D19J1/u50Pd3g70k30k10M93i70O3ug7Q bXQ73UF30l10t78f3UP30n10Pz1AD9JDVq7Tw/QIPeofSY/5w+hxeoKepKfoab+LnqFn6Tl63j+K XqAX6SV6mV4JiXZ6lV7zB+h1eoPetLad3rK2nd72j6F36F16j96nD/yQPqSP6GP6hD6lz/yEPqcv 6Ev6ir72C/qGvqXv6Hu/ph/oR/qJfvaPo1/oV/qNfqc/6E/6i/6mf1gMFpPFYrH9E1kcFtd6eBaP xfdPYQlYQuviWSKWmCVhSVkyltw/jaWwRp6lZKlYapaGpWXp/LNYepbBdYllZJlYZuvmWZaQnGdZ WTb/Apad5WA5XVdYLpbbv4jlYXn9i1k+lt+/lBVgBVkh6+lZYVbEv5IVZcVYcVaClWSlWGlWxnWb lWXlWHlWgVVklVhlVoVV9a9j1Vh1VoPVZLVYbVaH1fVvZfVYfdaANWSNWGP/dtaENWXNWHPWwgp8 1tK/h7X6x+A/Ya1dT1kb1zPW1lp81s5qfNaedWAdWSfW2X+YdbEun3Vl3Vh310vWw3+M9WS9WG/W h/Vl/Vh/1ys2gA30n2CDQmKfDfafYUPYUDaMDWcjrN5nI/3nWRhzsXA2irmZh3mZj/n9l1jAf5kF WQSLtKqfRbHRbAwbywCD/usMMcwIo4wxzgSTTDHtv8OM1f7M8d9n49h4NoFN9D9gk/yP2GTXRzbF /5hNdX1i09h0/zM2w/+czWSz2Gw2h81l80ILAJtvHwC2gC1ki9hi13f/R7bE/5ktZcvYcv9X/3e2 gq20KwBbxVazNWyt/xdbx9azDWwj28Q2sy1sK9sWiMG2sx1sZyAW28V2sz1sbyAO28f2B+IFErAD 7GAgETvEDrMj7Cg7xo6zE+xkIBk7xU6zM+wsO8fOswvsYiAVu8QusyvsKrvGrrMb7Ca7xW6zO+wu u8fuswfsIXvEHrMn7Cl7xp6zF+wle8VeszfsLXvH3rMP7CP7xD6zL+wr+8a+sx/sJ/vFfrM/PEZ4 bB4zkJXH4rF5HB7370rA4/H4PAFPyBPxxIH8PEl4PJ40UMDuBDwZT253Ap7i70/AU0YPBTyVPQp4 ansU8DSho4CnDdTi6QK1eXo7FfAMPGOgHs/EM//9CngW+xXwrDxboAXPznMEWvGcPBfPzfPwvDwf z88L8IK8EC8c6MCL8KK8GC8e6MxLBLrwkrxU6DLgpXmZQE9eNtCLl+PleYVAH16RVwr055V5FV6V V7OzAa8eug14jcCwwAhek9cKjOS17W/A6wTCeV1ej9cPT8Eb8IYBD2/EG/MmvClvxpvzFrwlb2XH A96at+FtebtAJG/PO/CO4ensfsA7BcbwzqEBgXcJIN6Vdwtg3p334D15L947wHgf3pf34/35gADn A/mggOSD+RA+lA/jw/kIPpKHcRcPDxg+irsD47iHe7mP+3mAB3kEjwxM4lF8tJ0T+Bg+lgMOOQpM 5zgwgxNOA7M44zw8GxdccsU1N4HZ3OHj+Hg+gU/kk/hkPoVPDczh0/j0v8sCnxFYzGfyWXw2nxO9 LfC5gZV8Hp/PF/CFgVV8EV/Ml/ClfBlfzlfYf4Gv5Kv46sAGvoav5ev4er6Bb+SbAlv4Zr6Fb/3P k4FvsycD3/7vk4HvCBzjO/kuvpvv4XsDx/k+vp8f4Af5IX6YH+FH7dPAjwXO8eOB8/wEP8lP2a+B nw6NDfxM4Bo/y8/x8/Zs4Bf4RX6JX+ZXArf51cAdfo1f5zf4TX6L3+Z3+N3AA36P3w9tDvwBf8gf 8cf8CX8aeMr/WR34c7s68Bf8JX/FX/M3/C1/x9/zD/wj/8Q/8y+B9/wr/8a/8x/8J//Ff/M/IoaI KWKJ2CKOiCviifgigUgoEonEIolIKpKJ5CKFSClSidQijUgr0on0IoPIKDKJzCKLyCqyiewih8gp concIo/IK/KJ/KKAKCgKicKiiCgqioniooQoKUqJ0qKMKCvKifLBJKKCqBhMKiqJyqKKqBpMJqqJ 6qKGnSRETVFL1LabhKgj6op6dpQQ9YPpRQPRMJhBNBKNRZPQLiGaimbh1YPZRHPRQrQMrylaidai jWgr2gVzifbB3KKD6Cg6ic6ii+gazCu6ie6ih90nRE/RS/QWfURf0U/0twOFGCAGikFisBgihoph YrgYIUaKMOES4cHiYlSwpHALj/AKn/CLgAiKCBEZLBveMFheRInRYowYG6wogIACCSxIsLKgggku hJBCCS2McMQ4MT5YTUwI1hATxSS7WIjJYkp4YzE1WEdMC9YV08UMMTNYT8wK1hezxRwxV8wT88UC sVAsEovFkmAzsTR0W4hlf3cLsVyssL+FWClWidV2uBBrQsOFWBvsLdaJ9aHlQmyIXi7Exn8/F2LT 3+lCbBZbxNbQdyG2Bf1iu9gRjBA7//e8ELvEbrEnSMVesU/sFwfEwdB+IQ6Jw+KIOBrU4pg4Lk6I k8Hx4pSdMMRpcSY0YYizoQlDnAtdGOJ8cL64EFwgLgYXikvisrgSXCyuimv2xRDXxY3oGUPcFLfE bbtjiDvirrgX3CDuBzeKB+KheCQeiyfiqXgmnosX4mVwm3glXv/9MsQb8Va8E+/Fh+g1Q3wUn8Tn 4FHxRXy1b4b4Fjwtvosf4qf4JX6LPzJG8JyMGTwvYwUvytgyjowbvCzjyfjBKzKBTCgTycQyiR01 ZNLgLZlMJg/elimCd2TK4D2ZSqYO3pdpgg9kWpku+EimlxlkRplJZg49GzJL8LnMKrPJ7DKHzClz ydwyj8wr88n8soAsKAvJwrKILCqLyeKyhCwZfCdLydJ24pBl7MUhy8pywa+yvKxgPw5ZUVaSlWUV WVVWk9WDv2WN0M0ha8pasrasI+tGxJH1ZP2IuLKBbCgbycZ26pBNZFPZTDaXLWRL2SoiqWwt28i2 sp1sLzvIjhHJZSfZOSKF7CK7ym6yu+whe8pesrfsI/vKfrK/HCAHykFysBwih8phcrgcIUfKMOmS 4XKUdEuP9Eqf9MuADMoIGSmj5Gg5Ro6VQEKJJJZE0ojskkkuhZRSSS2NdOS4iJxyvJwgJ8pJcrKc IqfKaRH55XQ5Q86Us+RsOUfOlfPkfLlALpSL5GK5RC6Vy+RyuUKulKvkarlGrpXr5Hq5QW6Um+Rm uUVuldvkdrlD7pS7wr1yt9wT7pN75b6IOnK/PCAPykPysDwij8pj8rg8IU/KU/K0PCPPynPyvLwg L8pL8rK8Iq/Ka/J6eEDekDflLXlb3pF35T15Xz6QD+Uj+Vg+kU/lM/lcvpAv5Sv5Wr6Rb+U7+V5+ kB/lJ/lZfpFf5Tf5Xf6QP+Uv+Vv+CY9QMVRMFUvFVnFUXBVPxVcJVEKVSCUOj1JJVFKVLGK4Sq5S qJQqlUqt0qi0Kp1KrzKojCqTyqyyqKwqm8qucqicKpfKrfKovCqfyq8KqIKqkCqsiqiiqpgqrkqo kqqUKq3KqLKqnCqvKqiKqpKqrKpEMFXVHiXhY1W1/11KVHVVQ9VUtVRtVUfVVfVUfdVANYyYoRqp xqqJaqqaqeaqhWqpWqnWqo1qq9qp9qqD6qg6qc6qi+qquqnuqofqqXqp3qqP6qv6qf5qgBqoBqnB aogaqoap4WqEGqnClEuFq1HKrTzKq3zKrwIqqCJUpIpSo9UYNVaB0HyioEIKK6KoYooroaRSSiuj HDVOjVcT1EQ1SU1WU9RUNU1NVzPUTDVLzVZz1Fw1T81XC9RCtShcqsVqiVqqlqnlaoVaqVap1WqN WqvWqfVqg9qoNqnNaovaqrap7WqH2ql2qd1qj9qr9qn96oA6qA6pw+qIOqqOqePqhDqpTqnT6ow6 q86p8+qCuqguqcvqirqqrqnr6oa6qW6p2+qOuqvuqfvqgXqoHqnH6ol6qp6p5+qFeqleqdfqjXqr 3qn36oP6qD6pz+qL+qq+qe/qh/qpfqnf6o+OoWPqWDq2jqPj6ng6vk6gE+pEOrFOopPqZDq5TqFT 6lQ6tU6j0+p0Or3OoDPqTDqzzqKz6mw6u86hc+pcOrfOo/PqfDq/LqAL6kK6sC6ii+piurguoUvq Urq0LqPL6nK6vK6gK+pKurKuoqvqarq6rqFr6lq6tq6j6+p6ur5uoBvqRrqxbqKb6ma6uW6hW+pW urVuo9vqdrq97qA76k66s+6iu+puurvuoXvqXrq37qP76n66vx6gB+pBerAeoofqYXq4HqFH6jDt 0uF6lHZrj/Zqn/brgA7qCB2po/RoPUaP1UBDjTTWRFPNNNdCS6201kY7epweryfoiXqSnqyn6Kl6 Wvg0PV3P0DP1LD1bz9Fz9Tw9Xy/QC/UivVgv0Uv1Mr1cr9Ar9Sq9Wq/Ra/U6vV5v0Bv1Jr1Zb9Fb 9Ta9Xe/QO/UuvVvv0Xv1Pr1fH9AH9SF9WB/RR/UxfVyf0Cf1KX1an9Fn9Tl9Xl/QF/UlfVlf0Vf1 NX1d39A39S19W9/Rd/U9fV8/0A/1I/1YP9FP9TP9XL/QL/Ur/Vq/0W/1O/1ef9Af9Sf9WX/RX/U3 /V3/0D/1L/1b/zExTEwTy8Q2cUxcE8/ENwlMQpPIJDZJTFKTzCQ3KUxKk8qkNmlMWpPOpDcZTEaT yWQ2WUxWk81kNzlMTpPL5DZ5TF6Tz+Q3BUxBU8gUNkVMUVPMFDclTElTypQ2ZUxZU86UNxVMRVPJ VDZVTFVTzVQ3NUxNU8vUNnVMXVPP1DcNTEPTyDQ2TUxT08w0Ny1MS9PKtDZtTFvTzrQ3HUxH08l0 Nl1MV9PNdDc9TE/Ty/Q2fUxf08/0NwPMQDPIDDZDzFAzzAw3I8xIE2ZcJtyMMm7jMV7jM34TCF9u gibCRJooM9qMMWMNMNAggw0x1DDDjTDSKKONMY4ZZ8abCWaimWQmmylmqplmppsZZqaZZWabOWau mWfmmwVmoVlkFpslZqlZZpabFWalWWVWmzVmrVln1psNZqPZZDabLeGrzVazzWw3O8xOs8vsNnvM XrPP7DcHzEFzyBw2R8xRc8wcNyfMSXPKnDZnzFlzzpw3F8xFc8lcNlfMVXPNXDc3zE1zy9w2d8xd c8/ctwuPeWAXHvPQPDKPzZPIC+apeWaeR140L8xL8yrysnkdedW8MW/NO/PefDAfI2+aT+az+WK+ Rt4x38x388P8NL9CT4/5bf7Yq8eJ4cR0YkU+cWI7cSKfOnGdeE58J4GT0EnkJI585iRxkjrJnORO Cielk8pJHfncSeOkddI56Z0MTsbIl5GvnUyRb5zMThYnq5PNye7kcHI6uZzcTh4nr5PPye8UcAo6 hZzCTpHIT05Rp5hT3CnhlHRK2fvHKe2Ucco65ZzyTgWnolPJqexUcapG/nSqOdWdGk5Np5ZT26kT +cupG77HqRd9Azn1o+I4DewO5DR0GjmNnSb//oGcpqEhyGnmNHdahJYgp6XTKiqD09pp47SNyui0 s2OQ097p4HR0Ojmdo7I4XaKyOV1Dd5DTzelu9yCnh9PT6RWV3+nt9HH62kXI6Rd6hJz+UcWcAVHF nYHOoOhNyBnsDIkq5wx1hjnDnRHOSCcsqoLjcsKdUY7b8Thex+f4nYATdCKcSCfKPkPOaGeMM9YB DnRQaBxycFQ9h0Q1cKgdhxzm/B9jd8He5LkwABh3Z7imadq4tGnSxpqkSd801jTBpcBwKE5xiOD+ PgYMd3dnuLsM9wFjuDvDvisP73rKzs51fX/kvsex44NudkJUHmInRu0hdhI7mWVZwEIWsZgl7JRg gJ3KTmN/YaezM9iZ7Cx2NjuHncvOY+ezC9iF7CJ2MbuEXcouY5ezK9iV7Cp2NbuGXcuuY9ezG9iN 7CZ2M7uF3cpuY39lt7M7/mkZsTuDbdhdwZ/Z3cF27B52L7sv2Indzx4IdmEPBruyh4I57OGoasQe YY/+LRuxx9jjwb7sif/oRuxJ9lR+4Yg9zZ6JCkfsb/8Rjtiz7LmoccSejxpH7IUgy16MKkfspfzK EXuZvfK3csReZa9FpSP2elQ6Ym98l47Ym8Hl7O/sLfY2eye4iv2DvRtczf7J3ou6R+z9qHvEPvjb PWIffpeP2Efs4+BO9gn7lH0W3MM+Z1/8rR+xL4OH2Vfsa/YN+5Z9FzzKvmc/sB/Zv6IWEvspeJr9 zH5hv7LfgmdBAVAQFAqeB4VBEVAUFAPFQQlQMngJlAKlQRlQFpQD5YNXQQVQMXgdVAreAJWDv4Of grdAleBtUDV4B1QD1UGN4J+gZtRMArVAbVAH1AX1go9A/eATwAMxgP/dTwKxQBB8CeKCr0A8EAbf ABEQAwmQAhmQB98CBVACVVRVAgkgEahBUvAT0AQ/A23wK0gGKUAH9MAAjMAU/AZSgRlYgBWkAVuo ILCHCoP0UJG+rwETNZeAA2QAZ1ReAi7gDpUKlQGeUFng/a4vgUzgA1lRfwn4owITCISqgQagIWgE GoMmoRqgKWgGmoMWoCXIBq1Aa9AmVAv8DNqCdlGfCbQP1QUdQEfQCXQGXUBXkAO6heqB7qAH6Al6 gd6gD+gbqg9yQT/Q/7vhBAaEBGAgGBSKB4PBEDA0JALDQBCEQBhEwHAwAowMScEoMBqMCcnBWDAO jAcTwEQwCUwGLAAAAgQwIGAKmAqmgV/AdDADzASzwGwwB8wF88B8sAAsBIvAYrAELAXLwHKwAqwE q8BqsAasDWnAupAWrAcbwEawCWwGW6JSFNgKtoV04FewPSpGgR1gZ9SMArvAbrAnZAZ7wT6wn/pR tpAdHPjuR4GD4NDfghQ4HMoER8BRcAwcByfASXAKnAZnwG/gLDgHzoML4CK4BC6DK+AquAaugxvg Jvgd3AK3wR3wB7gL/gT3wH3wADwEj8Bj8AQ8Bc/Ac/ACvASvwGvwBrwF78B78AF8BH+BT+Az+AK+ gm+wACwIC8HCsAgsCovB4rAELAlLwdKwDCwLy8HysAKsCCvByvAnWAVWhdVgdVgD1oS1YG1YB9aF 9WB9yIMxkA9joQDGwXgohCIohhIohTIohwqohCqYABOhGiZBDdTCZJgCdVAPDdAITTAVmqEFWmFa aB20QTtMD22EDHRE7SmYAZ2hrdAF3dADvVGHCmaGtkMfzIJ+GIANYEPYKLQTNoZNYFPYDDaHLWBL mA1bwdawDfwZtoXtYHvYAXaEnWBn2AV2hTmwG+wOe8CesBfsDfvAvjAX9oP94QA4EA6Cg+EQOBQO g0EYgmEYgcPhCDgSjoKj4Rg4Fo6D4+EEOBFOgpMhCwGEEEEMCZwCp8Jp8Bc4Hc6AM+EsOBvOgXPh PDgfLoAL4SK4GC6BS+EyuByugCvhKrgaroFr4Tq4Hm6AG+EmuDk3C26BW6P+FdwGf4XbQ8/gDrgT 7go9h7vhHrgX7oP74QF4EB6Ch+GR7y4WPBp6B4+FPsDj8EToIzwZ1bHgqdBneBqegb/Bs/Bc6As8 Dy/Ai/BS1MuCl+EVeBVeCxeE1+ENeDNcCP4Ob8Hb8A78I6powbvhYvBPeC9cEt6HD+BD+Oi7pQUf h8vDJ/ApfAafwxfwJXwVrgxfwzfwLXwH30dtLfgBfoR/wU9RYwt+hl/gV/gNFUAFUSFUGBVBRVEx VByVQCVRKVQalUFlUTlUHlVAFVElVBn9lNsyHIOqoKqoGqoejkU1UE1UC9VGdVDdcDyqFxah+mEJ 4oWlKAbxUSwShGUoDsUjIRIhMZIgKZIhOVKEFUiJVCghrEKJ4QSkRklIg7QoGaUgHdIjAzKG1ciE UpEZWZAVpSHbd80L2VE6YsIm5EAZyIlcyI08yIsykQ9lIX/U90IB1CBsQw1Ro6jzhRqjJlHrCzUN Z6BmqDlqgVqGXSg7qn6hVlH1C7VGbdDPYT9qGw6gdqg96oA6ok5R/Qt1jtpfqEtU/0JdUQ7qltsl /DPqjnqgnqgX6o36hNujvigX9Qt3DHdG/dEANDDcDQ2KWmBoMBoS7o2GomFRCwwFUSg8AIXDA1Ek PAgNRyPQSDQKjaYuWCgcRmPQ2KgJhsZFVTA0Hk1AE9Gk8Fg0GbEIIIhQeDzC4QmIRJUwNCUM0FQ0 Df2Cpke1MDQDzUSz0Gw0J7cvmovmofloQXgKWhieihahxWgJWvpdEUPL0HK0Aq1Eq9BqtAatRevQ erQBbUSb0Ga0BW1F29CvaDvagXaiXWg32oP2on1oPzqADobno0PhBehweCE6El6MjkbVMXQsvBwd RyfQSXQqvBKdDq9CZ9Bv6Cw6h85/V8jQBXQxvB5dyh2GLqMr6Gp4A7qGroc3oRvoJvod3UK30R30 B7qL/kT30H30AD1Ej9Bj9AQ9Rc/Qc/QCvUSv0Gv0Br1F79B79AF9RH+hT+gz+oK+om+4AC6IC+HC uAguiovh4rgELolL4dK4DC6Ly+HyuAKuiCvhyvgnXAVXxdVwdVwD18S1cG1cB9fF9XB9zMMxmI9j sQDH4XgsxCIsxhIsxTIsxwqsxCqcgBOxGidhDdbiZJyCdViPDdiITTgVm7EFW3EatmE7TscMduAM 7MQu7MYe7MWZ2IezsB8HcAPcEDfCjXET3DR3Mm6Gm+MW4Se45XcpDWfjVlEtDbfGbfDPuC1uF36D 24ff4g64I+6EO+MuuCvOwd1w9/B73AP3xL1w7/BH3Af3xbnhv3C/8GfcHw/AA/EgPBgPwUMjBfCw SGEcxKFIURzGETwcj8Aj8Sg8Go/BY/E4PB5PwBPxJDwZsxhgiBHGmOApeCqehn/B0/EMPBPPwrPx nKjHhudGyuB5kbJ4fqQcXhB12fDCqMuGF0VlNrwYL8FL8TK8/LvPhldEauOVeFWkDl6N1+C1eB1e jzfgjXgT3oy34K14G/4Vb8c78E68C+/Ge/BevA/vxwfwQXwIH8ZH8FF8DB/HJ/BJfAqfjkjxGfwb PovP4fMROb4QUeCL+FJEiS/jK/gqvoav4xv4ZiQB/45vRRLxbXwH/4Hv4j/xPXwfP8API0n4EX6M n0Q0+GlEi59FknOn4uf4BX6JX+HX+A1+i9/h9/gD/oj/ihjxJ/wZf8Ff8TdSgBQkhUhhUoQUJcVI cVKClIykkVKkNClDypJyEVsknZQnFUjFiINUijhJZfITqUKqRlykWsRDqpMapCapRWqTOqRuxEvq kfqEF/GRGMInsURA4kh8xE+ERETEREKkREbkRBFpQJSRhkRFEkgiUZMkoiFakkxSiC7qzhF9pAUx ECMxkVRiJhZiJWnERuwknTCRbOIgGd9FOuIkLuImHuIlmcRHsoifBEiDSDvSMKrUkUbflTrSmDSJ dCVNSTPSPNKdtCAtSTZpRVqTNuRn0pa0I+1JB9KRdCKdSRfSleSQbqQ76UF6kl5Ry470Jn1I38gA kkv6RQaS/mRAVLUjA8kgMpgMIUPJMBIkIRLOXUAiZDgZQUaSUWQ0GUPGknFkPJlAJpJJZDJhCSCQ IIIJIVPIVDKN/EKmkxlkJplFZpM5ZC6ZR+ZHRpIFZGHUxyOLokIeWUyWRI08spQsi0wiyyOTyYqo k0dWklVkNVkT1fLIWrKOrP9u5pENZGOBgjX59adTNW9u/UX1F9dfVX9t/d35/Ly79V/yivKK8crx KvIq8epxlp7iXzW9VOrpNeQ15jXlteBl8zrwOvE68/rw+vKG8IbygrwQbwJvMg9TY28Jbxl19o7n l/Z4L3gvea9572JKcuZe7Xzqni7GGJMR4/xB3usTMzRmWEwkZkTMSCrwTYoBMTiGxEzjJL4FMQvz NL4NeR7frpjdMcdifstT+a7EXIu5GfN7zK2YuzF/xtyLeRzzIuZ1zDd+cX5Jfnl+RX5VTuoTUKtP wpfyZVTsM1Gzz8538j18H78BvyG/Eb8xvxk/m9+W35HfjZ/L78cfyB9MHb9h/CA/xB9JPT+WE/1+ 4U/nL+Qv4i/mr+Gv4+/g7+Tv5u/lH6DG33FO+btCnb8b/Af8R/zH/Cf8p/xn/Bf8l/xX/Nf8N/x3 /A/8j/n8v59i68byYoVUADTHplEB0BEbiG0Y2yS2WWzz2FaxbWPbx3aJ7RrbLXZE7MjYsbETYifG wljEyYCbY3fH7ondF3uA/pZRIfBG7M3Yu5wT+Cz2Zezr2I+xn2O/CAoICgqKCIoJSgvKCyoIKlI9 sKagvoAviBckCHQCk8AmcAicVBPMyucJdhLkCHpQUbCfYJAgJBjOuYKTOVlwrmCeYJFgmWBFnjC4 gTMG9wkOCQ4LjgiOCo4JjgtOCE7mmYP3qDr4QvCekwcLc/Zg6bhycXXieHGCOEmcLC45Th+XGmeN S4uzxznjsjiTsEVcy7i2ce3jusTlxPXidMJRcWPj5sWtiFsZtzpua9y2uF85q/BA3EHqFZ6Jexb3 Ou5dfIH4yvF14iXxynhVfGKeXuiifmGD+JbxPeL7xPeliiGMx1QynBE/J35e/LL4TfHbOdNwf/xh 6hqeobLhtfjb8Xfi78U/jn8S/zT+WfyL+JfUOSwnLC+sIKwkrCWsI6wr5HHmoUyoFCZR+TCZ2ocG YarQJrQLs4QNhc2F2cJWwjbCtsL2whxhd2FPYS9hH+FIaiOOF04UThKyQiKcKZwjnCdcIFwuXCnc LNwu3C88LDwvvCC8JLwsvELFxAfCh8JHwufCl9ROLCAqJCoqKi4qKSorKieqIKooqiSqLKoi4ouE IqlIIVKJkkQakY76ilZRmsgmcok81FlsSKXF5qIWopZ52mJ3UQ9RP9FQUVAUEY0SjRFN5uzF2aJF ohWiVaJNokOiw6LfROdFF0WXRVdEV0XXRLdEX8SFxaXEpcVlqMvIF8uozZgqdoh9Yr+4obixOFvc StxG3E7cXtxbPEA8RBwSDxePEI+kbuME8WTObpwlXiBeKV4v3soZjofFJ8SXxFfE18S3xXfzJMcX 4lfiN+K/xJ/F3yRFJKUkZSXlJBUklSRVJNUk1TnbUSlJ4nxHi4TJZzw2kTSVNJdkS9pQ67GzpKsk h4qPvSS9JX0k/STDJBMlkyRQMk3yi2S6ZIZkHlUgl0tW/E8F8pHkseQJtSBfST5IPko+Sb5Iy0or S+tJedI4qVAqlkqlMqlCqpImSJOkWmpDNpY2k7aRtqc+5CAqRI6WTpSy0mnS2dK51IqMSpG7pAek B6WHpJekl6XXpHekD6WvpZ9kpWSlZbVkaplGZpbZZYwsQ+aUeWWZMh8nSXaW5ci6U09yoGyQbIgs IhspGy0bQ3XJlbJVsnWyDbKNsm2ynbL9ssOyk7KzsouyS7LrVJ3Mb06WlpeRl/+HPFmb2pOCH/RJ qVz+/xAo/XkGZRN5K3lrzqFsL+8g7yjvIs+hHmWPf4iUA/OJlGF5hKqUY+UT5ZPkUI7khAqVM+Rz 5HPli+RL5avla+Tr5BvkG+Vb5Nvk2+U75Lvle+T75IeoX3lJflV+V/5I/lj+hCqW7znHsoCikKKE opSirKIGFS3rK3gKvkKhUCoS83RLg8KssHLGZYbCqXApPIoGiqb03O2ZJ16GFMMVIxQjFWMUY6l9 SRRT8uzLhYrFiiV5/uV+xSHFGcVZxUXFFWph3lbcUdxVPFY8VbxUvKEu5mfFV2UhZVFlCWVJZWll GWUF6mTWVNZWxiqFSolSqpQp5VTN1HJupkmZqjQrLco0pU3JKB2coZmpzFI2VDZSNlE2UzZXtlBm K1sp2yjbKzsqu1NVc6hylHIclTWnK+cqFyuXKJcpVypXKzcot1Bn829l86ryhvKB8pnypfKV8rXy vfKj8rOqiKqYqriqZJ65WU5VQVWJypvVVNX/S99MpP6mVqVT6VUGlVFl/ofD6Vc15CzOZqqWqmxV K1Ub1c+qtqp2qvaqDv/D5gxSnXM49TlH06t4vIpVARVUYdVU1TTVTNVc1TxO7VxE3c5lVO5cq9qg 2pjnd+5S7VHt5wzPo6rjqpOqM6qzqnOq86oLqkuqy5zpeVN1S/UHlT0fqR6rnqjeqj5yumfxhBIJ ZRLKJpRLqJzwE+d8xieIE+QJKQm6BEOCMcGakJZgS0jPcz9bU/mzK7U/ByZEEoYnjEgYlTA6YVKe BPrdAT2Q8FvC2YSreRLom4T3CV+oBVozsVZiHaqBShITE5MTUxPNiZZEK5VB0xM9iYHEhpwO2imx e2L/xFGJ4xMn5gmhixJXJK6kSujOxF2JexP3J55JPP+DGPpH4v3E15wX+lFdMJ8YWlpdRl1eXUFd Q10rzw7VcnaoSZ2qNqstaqs6jSqiLnWWuoG6kbpxnibaSt1R3U3dW91fPUA9RB1Sh9Uj1CP/IYyy apSnjM5XL1OvUa9Vr1OvV2+m4ugeao4eVR9Tn1Cf5OzR39Rn1Rc4gfSK+rr6tvqu+rn6jfq9+rP6 i/pbUoGkgkmFkkoklUmqkFQpqTKVSWM4m9RAdVImzydtltQ8qSW9qdsmdUjqlNQ1KSepZ1IwKZI0 PGlUEkvN0vlJi5I2J21J2pq0K2kvp5eeSTqXdC3pVtIfSfeS7ueTTItrSmmqaupqeBqBJv5fTFOj JlXj0WRR2bSRpp2mg6aTposmR9ODCqcRapyO1UzXzNcs0CzSLNas02zQbNRs0mzWbNH8qtmu2a3Z pzmoOaI5qjmhOak5pbmquaG5o7mveaB5pHmmea55QR3UL5qvmm/aQtoi2pLaStq62npagTZOK8wn o+rzbFRPPh01m+qo7bUdtZ20nbVdtD20PamS2lebq+2vHaQdwlmpo7VjteO0E7STtJO1rBZqkXam dpZ2jnaJdql2OfVT12jXcobqdu0O7T5OUj1BLdUr2uv09/4uqj6moupL7VvtN05ULZ5cIrlkcjkq q1ZOrppcLbl6cq3kOlRY5SWLk+XJKqqsGv6ns9qCk1Y7JXdJ7pbcg3qrvZNHcObq5GSQjJJJ8lQq r05Pnpk8O3lO8tzkhckrk1clr/vBYT2V/FvyOaqx3svnsb7LE1krUZO1Tkq9FH4+l1WZok1JSTGl mFMsKVYqtLpS3CmeFB9VWptzTms3TmodmhJJGZEyKmVcysSUySmzUmanLEpZnLIkZXnKqpQ1KWtT 1nF26z76mJ+hfuuLlFcpH1M+64rqSuhK6crqyukqcZZrbR1fF69T6ZJ0ydR1deo81Hb16xrqmui6 6nrp+lLfdYhuqG4YFV6BboFulW6Nbq1uo27T/7BeH+ie6N7p/tJ91n3VF9YX05fWV6TyaxV9XT0v z39V6JX6BH2iXkcdWIveqk/TZ+hd+oC+kb6xvqm+hb6lvpW+NefCdtD31Ofq++uD+pA+oh+lH60f qx+nH6+foJ+sZ6kWS37wYufrF+rX6jfpt+h36/fq9+sP6o/oj1FB9rT+N/05/WX9Nf0t/R/6+/pH +qf65/oX+i+GAnmibAVDRUMNasoKDHGGeIOQs2UTDImGJIPGoDUkG3QGg8FkMBushjSDzeAwOA0e as42NDQytDC0NLQydDR0MuQYuhl6GfoY+hr6GwYaBhuGGEKGsGG4YZRhtGGMYaIBGIhhimEelWlX Upt2jWGjYbNhq2G34YDhoOGc4YLhouGy4abhtuGO4a7hvuFhVKw1FjKWN1YyVjZWNVY31uLcWp4x xhhrFBjjjCKj2CgzKoyJRi0n2aYZ7UbG6DT6qGjb0NjMmG3sZOxs7GLsSnXbXsY+xv7GgcZBxsHG kHGkcYwRGJFxqnEaNW8XGRcblxlXGlcbNxv3UAH3uPGM8Tx1cC8ZLxuvchbuLeMd6uE+j4q4xg/G z8avpoKmoqbiVMataaptqmviUx9XbJKbVCYNdXLTOCnXyVm5PqrlNjE1NTUzNf8vM7ezqbuptynX NMgUNkVMk02sCZmmmqaZpptmm+ZQSXepablppWmX6azpgum66a7poemD6TPVdQulFk4tmlqWGrvV U2uk1qTSbh1q7QpTlamGVHNq+g/mbnZqG87d7ZLaNbXHD/LuotQlqcuov7srdXfqnnwG73lO4X1H Fd5S5urmGuY6Zr451iwwx5mFZrE5xazjTF4rVXm95kyz39zY3Nzcwtza/DPn83Y251Cjt6+5v3mA ebB5iHmoeZg5+IPVO8EMzVPN08yL86m966jbuylP7j3Ayb3HzMfNp6nfe9V8x/zI/ML8xvzOUoA6 vsUtZS3lLdUttanoK7ZILDKL3KKwKC0qSxJ1fS2c7Ouhtq/fErA0sDSkxm8LSytLa0sbzvrtaMmx dLMMsgy2DLEMpervCMtIy2jLGMs4y0TLJMtkC7RMsUyz/GKZa5lHLeAllmWWdZaNlk2WHZadlr2W Y5ZTltOWM5azlvOWm5bfLbcst6kP/Mjy0vLVWpgTgstRIbi6tZ6Vb421Cqwyq8KaaFVbU6w6q4ma wTarw+q2ejg5OGBtbG1qbWZtYc3OZwj3svax5loHWAdZh1BLOGIdYR1lnWidxJnCv1inW2daZ1ln W+dSWXgptYVXWNda11k3W7dYt1q3WXdZ91kPWY9aT1nPWM9ZL1ivUHP4rvVP6g4/t76wvrK+sX6k /nDFtEppldOqp/HSkvMs4kZpLdN6pvVK65MWShuTNi4NUJt4dtp86hMv54TidWnr0zal7U7bk3Ym 7XLalbTbaX+mPUh7mPY47WnULE77aCvOucVxNpFNblPYlDaVLdGmtiXb9LZUm9lmsVltNhtjc9u8 Np+tga2RrYkt29bK1t7W3dbD1oeTjUfYJtlYG7BNsc2wzbSttq2zbbJtsW2l0vHePOv4tO2c7YLt ku2a7U9qHj+Mqse2V/bC9mL2EvZS9jL2ctQ/jrPH25V2lT3BrrFr7cl2o91sd9jddj9VkVvb29jb czLyOPt4+yT7ZPsU+wz7bKokr7dvtG+yb7bvtO+2H7AftB+1H7eftJ+yn7afs1+2X7Ff4/Tk+/aH 9if2t/ZP1FEuRCXlkuml0sumV0ivmF4pvXL6T1RVjk+XpyvTVemJ6RrOV26S3jS9ZXpOep/0Iekj 0idzzvKM9PnUWt6Qpy3voN7ynvS96fvTD6QfTD+afpa6y9fTb6bfS3+c/iz9OdWXX6e/SX+X/p4q zAWZQkwRpihTginHVGKqMFWZakx1pgZTk4ll4hkRI2HkjIL6zBommTEwqYyZsTBOxsdkMc2YDlRq 7sJ0ZXKYbkx3pgfTk5rNfZi+TC7Tj+nPDGAGM0OZIBNiwsxwZgQzkhnFjGbGMROYicwkZjLDMoDq zpiZwkxlplPleRYzm5nDzGXmMfOZBcxCZhGzmFnGrGTWM5uYncwu5hhzgbnIXMqnPz9jXjMfmK+O wo4ijnKOyo4qjuqOuj8o0OZ8DnRGngTt/xcLurOjiyPH0c3Rg4rQ/RwDHEFH6F9caOiY6pjm+IXq 0HMd8x0LHEsdyx0r85zo9Y4Njo3Uit7q2O3Y59jvOOY4nmdG33DcdtyhbvQDx8M8O/qN453jPSdI f+EM6RIZpTOqZFTLqJFRJ6MedaQTqSTtzGiQ0TijCdWkW2a0zeickZPRm7rSuRmDqSw9KmNcxvgM NgNl4IwpGTMyVlFlekvG1oxdnDR9OuNCxp8ZD6g3/SrjbcaHjM/OEs6KzkrOys6qzmrOms7aVKAW OiVOqVPmVDk1Tr0z1Wl2WpxWp40zqZs7WzhbOrOdbZ0dnJ2cnZ1dnd04oTrkHOsEzmnOGc7ZVKre 4tzu3OHc49zr3Oc85bzpfOp84/zL+dn5xfnNVdhVwlXSVdZVzlXeVdVV/QfNWuVKcCW61K4UV1qe au13NXA1dDV2NXO14HzrHFd3V09Xf9cA6lyPco11jXexrimu5a5VrrWu9a4Nrk2uX127XUdcx/8f 9vVL1xvXB9dH1zd3QXcx6mCXd1d0V3b/5K7hrsl52PXdfHesW+yWuhVuFXWxDZyMbXFb3YzbydnY DdyN3S3cLd1t3O3cPd257oHuQe7B7qB7pHusG7mxe6Z7rntBPjV7jXuTe4t7V56efZLq2Wfdl9yX 3VfcV91/uB+5n7lfud9TT/sTFbWLeIp6ilNVu5SnjKesp5ynvKeCp5KnsucnTxVPVU81T3VPDU9N Ty1PXU89D88T4+HnqdtCj8wj9yg8Kk+CR0sFbp1HTxXuVI/ZY/FYPWkem8fuSfcwngyPx+P1ZHp8 Hj+nczemPncLT7antaeN52dPO08HTydPZ09XTw4Vu3t6enFqdz/PQE7uDnpGekZ5RnumeqZ5pnvm 5SneRzzXPL97nniee954PnmLeIt6S3rLeKt4a3vreOt6eV6xV+KVeeVehVfpTfHqvTZO+W7mbelt 4+3s7cZJ3wO9g7xDvCFv2BvxDveO9I7yTvBO9GIv8U7xTvPO9c7zzvcu8C71rvFu9m7zHvIe4yzw s95L3ivem1QEv+994H3ofeZ97n3n/eD96P3k/ZpZNrNiZqXMypnVMutl8jL5marMhMxEqoUbMy2Z 1kxbpiPTlenOzMpsntkqs01m28z2mR0zO2V2zeyR2T9zaGaI+uGjMkdnjuUMcfYHRXwadcRn/Ksk vjJz9X9p4nt+8MRP5xPFL2VezbzGueK382TxZ/9qixfxFeV88Qq+n3zVOWVc4BP6RD6xT+KT5Xnj uv8hjjvymeMNfI18Tag7nu1r7Wvja+drT/3xrvkE8j6+fvkU8ohvuG+sb5yP9SEf5jzyGb5ZvtlU JV/0D5d8k2+b71ffjh908sP/8MnPUaH8iu+q75rvuu+27w5nld/z3ade+WPfE2qWv/W9873PJ5cX zCqeVSKrJOeXl80ql1Uxq1JWtazq1DGvk1U3q15W/Swe55nHcaL5wazDWUeyjmadyDqZdSrrbNa5 rPNZF7MuZV3Jupp1Let61o2sm5x3/oiK5x8587y4v4S/tL8idc+r+2v6a/l51D+X+ZV+TZ6B7vJ7 /T5/lr+Bv6G/EaehZ/vbUBG9i78rp6L38vf25/r7+wf4B/oH+Qf7h/qH+SP+4f5R/jH+8dRKn+af 7p/nX+Bf5F/iX+pf7l/hX+Vf7V/r3+Df5N/i3+rf5t/u3+Hf7d/vP+A/6D/iP+Y/4T/pP0VV9Yv+ S/4r/pv+3/23/Lc5Yf2x/4n/qf+F/6X/tf+d/73/k/+r/1ugQKBgoHCgSKBooFigeKBEoEygLLXX awTqBuoFeIGYQGxAGJAElIEEaq/rAoaAkerrtgATyAo0CDQKNA40CbQItAxkB1oFWgfaBtoF2gc6 BDpSj70rFdl7BHoH+gRyA0MCwwLBQDgQCYwIjA6MCYwNjAtMCEymNvvCwKL/q+7O42Jq+8eBz7Qv SClaiUSl5UwJ7SmVUGHO1pmZmjNnZpp95lRKcaNkz50tO5WtskUlESIRKltkya7sFNnX33TM3Y3b 831+f32/z1OvXs1Zu865rutzXefw+ryZhcwiZjFzJ3MXczdzD3Mvs5RZxixnVjArmQeZVcxDzGpm DfMU8zSzgdnIvMhsYjYzrzGvM1uYN5i3qDzud6k87k+YT5nPmS+Y7cwO5ktmJ/Mt8z3zK0gD6aAW qA3qgnqarO4WYF+wH2gJWoHWoA1oC/YHh4BDQSfQBXQD3UEPkAF6gl6gN+gL+oEBYDA4GgwFx4Dh YAQ4FowEx4HjwQmarO+TQSYIghAIgwgYC7JANhgHxoM4yAeFYAIoAWWgHFSCpCYXfOpvs8Hngfng ZnALuA0spLLC76TywpeAe8C9YDm4H6zUZIg/DB4Bj4E14PEfMsWfBuvBBvAseA68ADZRWeOvgtfB m+At8DZ4B7wL3gNbwTbwgSaX/BPwKfgMfA6+ADvAl+ArTWb59+AH8CP4CfzcnWHeGOoB9YR6QSaQ GdQHMoesIDuoPzQAsocGQoOgoZAz5AK5Qm6QO+QBARAD8oS8IG9oBDQSGgX5QQFQEJWDPhQaA4VB EVCkJg99FBQDTYIma3LRCyARpICUVB76JCgFSoXSoGnQdGgGNBPKgDKhLGgOlZE+G8qBlkC50Epo FbQOWg9tgIqg7dAOaBdUAu2FSqEyqBzaB1VAldAB6CBUBR2CjkE10AnoJHQaOgPVQ2eh89AF6CLU BF2BrkMt0A3oZleueugedB9qgx5CL2FtWAfWhfVhQ7gH3BPuBfeGzWBz2ALuB1vC1rANbAvbwf3h AfBAeBDsAA+Gh8BDYSfYGXaF3WB32AP2hL3g4bA3PILKbh8AB8JB8AQ4Go6BJ8KT4MkwEwZhCEZg FMZgDhwHc2EeTMB8WAgnwCJYAstgOayAVTAJJ8JJcDKcAqfCU+E0OB2eBv+hyYSfCc+Gs+A58Fx4 HrwAXgRnw4vhP+ElVF78XHglvBpeD2+E8+B8uADeBG+HS+C9cCl8ED4EH4Gr4aPwMbgGPg7Xwifg k3AdfAo+DZ+B6+Gz8Dn4AnwRboIvwc3wFfg63ALfgG/Dd+C78H24DX4EP4afwM/g5/ALuB1+Cb+G 38Bv4Xfw+668+vA3RAvRRnQQXUQfMUB6ID0RU8QCsUZsETukPzIAsUcckCHIUMQJcUZcEFfEDXFH PBAAYSBeyAhkJDIK8UF8ET/EHwlAApEgJBgJRcKQsUjkLzn5QQRCYE1efhbCQeKo3Pw4wkMIRIAI ETEiQVKQVGQqkoakIzOQmcgsJAPJROYgc5H5yAJkIbIIyUYWUzn8lyK5yEpkFbIaWYOsRdYh65EN yEakANmMbKWy+hchO5CdVGb/EqQUKUPKkQpkP1KJHEAOUjn+DyPVyFGkFjmDNCJnkfNIE3IJuYw0 I1eRG8gd5B5yH2lF2pDHyBPkGfIcaUc6kJfIK6QTeY28Qd5S+f8/IV9QGqqD6qL6qAFqiBqhxmhv 1BQ1Q/ug5qgFpQJYotaoDWqL2nXrAINRR3Qo6oQ6U0qAK+qGuqMeKIAyUE/KDBhBmQEBaDAagoai Y9AwNByNoPyACWgUGo3GoBPRSehklImCKITCKIKiKKaRBbgojvJRIZqAilAxZQzIUQWqQkk0kdIG pqCpaBqajk5Dp6Mz0JnoLDQDnYPORedpBIJsyiDIQZegy9EV6GpKIliH5qNb0W1oIVqEbkd3oLvQ 3WgJugfdi5aiZWg5ug+tQCvRA2gVegg9jFajR9FjaA16HK1FT6B16Cn0NHoGrUcb0bPoOfQiehlt Rq+g19EWSjW4i95D76Nt6CP0CWUbdKAv0VdoJ/oafYu+Q9+jH9CvsdqUdmBNaQdOsYBGPAiJDY+d RLkHrFhBrCI2LXZ67B+xcyn/YHm3gFAUWxy7I7Y0tiK2MrYqtlrjIVyIvaoxER5SKkJn7NvYd7Gf MD1MHzPADDEjrDdmiplhlpgt1h9zwBwxF8wVc8d8MH8sAAvERmNhWCQWg03GmBiK4RgPk2FyTIUl Y6nYdCwTm4PNxxZhi7Gl2DJsBZaLrcc2Ypuwrdg2bHu3sVCGlWP7sP3YAewwdgyrxU5gddgZrB5r wC5gTdhl7Ap27R8Gw9dfFAaTnxyGwRqJwZnl0q0xBLCCWMGsUNYYVhgrnBVNyQyTWUwWyIplcX4x GuQapWEaa4ZGashizaG0hoUar2EJaylrOWsla/UPasM2ym3YwdrJ2sXazdrD2ssqZ1WwKinF4Sir hlWrsRzqWedZFynP4QbrNusOq431mPX0t7KDHtuQbczuxTalhAcrynjwYnuzR7BHsX3YIexw9liN 94CzeWyCzWcL2CK2mC2h9AcFW8lWsUl2IjuJncyewk5hp7KnstPZ09jT2TPZs9gZ7Ez2bPYc9lz2 PPYC9kL2IvZi9p+/NSO2/EONqGAfYFexD7Gr2UfZNZQecZJ9qluQuEQZEjd/UCQesh/9W0lC9ydL wvL/Q5Pw4/j/RpRAOBiHRakSXA7OITh8joAj5Ih/60ukdQsTGZxMTtZvlIlczkrOGs5azjrOBs5G Th6ngLOZs+UXc2IPZy9nH6eCs59zgLInjnCqOUc5NZxazknOKU49p4HTyDnHOc+5xLnKaaE8itsa keIR5zHnCecp5xnlUnygZIrPlE1Bi6NTPoWhRqgwjTOLs9A4FQMoqcIhzjFuKKVVuMWdjjsTVx/X ENdIyRUX4i5SekVb3OO4F5Rg8UZjWNDiteKN43vEm8T3jh9EiRZO8cPiR8aPivfRyBZR8dHxsfFs yrbgx4viZZRwMTt+fvyC+Oz4nB+Ui7XdzkURJV3QuFpcfa4B14jbg2vJteLacQdxPbnDuT5cf24A N5AbyoW4GFescTBSuKncWdwsbjZ3MfdP7lLucm4udzV3PXcbt4i7nbuDW8E9wK3m1nEbuOc1VsZV 7jXudY2X8YT7jNvOfcV9zX2P03EtXBvXx03xPrgF3he3xK1xG9wWH0A5GkNwJ9wZ98AB3Asfjo/C fXBf3A8PxIPwYHw0HolPwKPwGHwSDuIQjuAoTuAJuBRX4iqcxFPwVHwWPgefiy/DV+Jr8HV4Ab4V L8SL8O2UyFGBV+I1+HH8BCVzXNTYHM34dbwFv4Hfx1vx511OB6V0uGmcjhG/SB3hvPG8aB7Ig3go D+OxeRwezuPxCB6fJ+AJeWKekqfikbxEXhIvmZfKm8r7gzeDl8GbzcvizeHN483nLeAt5C3iLeb9 yVvKW05JHqt4a3nreOt5G3gbefm8Td2ax3beDt4u3h5eGa+Cd4h3hHeMd1xjeZziNfAaeWd5TZTl 8aPk0cproxyPJxrJo4P3kvdaY3l87LI8eN8IOqFFaHeLHgaEEdGD6PmT6WFOWFCuhyVhRVgTtkR/ YgDhRHgQIynhI0xjfBBEAiEhpIScUBIk5X2kEdOJmUQGkUXMJRYRi4kcYimxnFhBrCXyiS1EEVFM 7CTKiP1EJVFFHCGqiRqijjhFnCbOEueJJuIS0UxcJa4Tt4jbxD2ilXhAPCQeEy+IdqKD6CTeEV+I r5QTos3X5xvwDfkm/N58M34fvjnfgjJDrPj9+fb8QXwnvjPfhT+M78p347vzPfgA35PvxR/OH8Ef qbFE/ClNJIgfzB/ND6FMkXB+BH8sfzx/Aj+K0kUm8SfzQY0xIuerKGdkET+Xv5q/nr+Bn8fP5xfw N/O38LdS7kgl/xj/OL+Of+kXf4QmoAv0BYaUQmIqMBP0FVgJrAV2gkGCwYJRAj/BGEEY5ZJMFEAC RIAJ4gVcQYJAIVAKVIKpghmCTMFcSitZ2O2VbBJs/cEsKRWUCw4JjgmOC2oFpwVNlF5yU3BLcLvb MHkleC34IPhCWSYmwn5CS6GV0E7YX2gvHCh0EA4WDhEOFToLXYSuQjchIGQIvYTDhd7CkcJRQh+h n9BfGCAMFAYJxwonUeZJrJAl5Ajjuu0TsVAuVAhVwmRhinCaMEs4RzhfuFCYLVwuzBWuE64XbhBu FG4RFgorhQcoG+WksE54StggPC+8KrwmvCO8K3wifKbxUr4k0BK0E3QSdH9QU0woN8VYZCayEtmL HESOIicRQ+QvChdFUo5KtChGBIsQEUp5KlwRTpkqchEpShIliw6IDomOiU7/oKs8E70QdYheit6I Pog+/qKsdBkrlpSy4tDtrLiJAbEnpa2MoryV0eIQcegP4sqk35grXEpdSRCLxGJKXpGJFWKVxl+Z 8YO9spbSVzaKC8Ql4r3iMnGF+ID4oPiwuFZ8Snxa3CA+262xXBffEN8St2pUlnZxh/id+KP4s4Qm oUu0JQaSPhILia1kgMRBMkTirNFaQiVhknDJZAlTAklQCSZhSdgSjiROEi/hSQgJXyKQCCUJEpFE KpFJ5BKFRCVJlCRLMiRZkjmSBZKFkuzf6C7Fku2SXZIyyUlKeWmQNEkuSa5otJe7kvuSJ5JnkueS F5KXkleU/PJeY790yS+jpH5Sf2kA5b+MloZII6SR0nHS8dIJ0ihptDRGOlE6SQpJUSkmZVEyjEpK ShOlydIU6VRpGmXE/KFRYuZI50sXaKyYHOlSyotZKV3Vbcbka9SYLdKt0m3SQmmxdLt0p3SXdLe0 hFJkyilHplJ6QHpQWiU9JD0sPSKtlh6VHpPWSGulp6X1lC9zVnpeekF6UXpJ2iy9orFmbkhvaryZ e5Q40yZ9IH0ofSR9In0qfS59Ie2QAbIRspEyX9lo2XjZRNkkGSSLk3FlAo1IM1U2TaPSzJctki2m bJrlshWyXNkqWb6sSLZLViqrkFXKDsgOyqpkh2TVsmOyE7KTsjpZg6xRdp6Say7Lrsiuyq7JWmQ3 KcGmU/aOEmxGyn3l/vJAeZA8WB4iD5WHyyPkY+Xj5OPlUfJoeYx8onySnCmH5LA8Vs6Wx8nj5Vw5 LufJCTlfLqDcG7lcISflifJk+RR52g/+zWyNgJMn3yLf9pODc1B+mLJwauS18pPy05SJ0yg/+4OL c1l+RX5Nfl3e0i3k3JXfl7fK2+QP5Y/k7fJO+Rv5JwWdMnN0FWYKF4W7wlcxRjFWMU4RrYhRMBWI IlbBUwgVcoVKkaRIVkxRpCrSFOmKmYpZigxFliJHsVyxQpGrWKtYp8hTbFZsUexRlFLWzn5FpaJK cURRrTiqOKY4qTitqFecU5xXXFY0K64qrimuK1oUtxV3FfcVDxQPFW+UNKW2UldpoJyqnKacqZyv XKhcrsxVrlZuUBYoN2t0nnLlAeVRZY2yUXlOeV55UdmkvKK8q7yvbFM+Vj5Vdiq/qWgqukpLZajq p7JRDVA5qJxVw1RuKneVh8pTNULlR3k+4ZToM44yfSarmCpIhahiVVi37yNWSVUyFalKVk1Rpaqm qtJV01R/qGaoMlRzVfM08s8SVa5qoypPtUVVpCpWbVftVO0iDcleZO+fNCAHcjA5hHTRmEAjyFGk D+lPBpBBZCg5hgwjw8kIciwZqZGCoskYchKJkKxuM4ggpWQymU7+Qc4gM8ksjR60QOMH/UnmkEvI XHIluYpcTa4hN5AbyTyygNxCFpPbyR1kCbmXLCXLyHJyP1lJHiAPklXkIfIweYSsJo+Sx8ga8jhZ S54gT5J15BnyAtlMOUQ3KInobrdF9JJ8RXZ2e0S0RHqidqIOpRLpJxok9vzLJkp0pdFpPb7rRDR3 mrnVQKtBVgOsHKwGW/W3srOytRpm5WrlbOVi5WblbuVhBVgNtXKycrQaoj7CnGasPjKEFkfj9tjW o7BHpWmn6WvTN6ZvTd+Zvjf9YPrR9JPpZ9NvZjRKP6JrFCSadar6tzmN+rJWApnWUj1Dl7lj577r SdfXys+0ZqtXoVp0OqMX0EPP4PsWLV1dGsDVMxqmR9ehZ47UouvkTwYmAq4/rLHd1H+WLc2f+o6h 8WhJNCVNRhPQktU/gV3fgP3P59PpvV2nV/M6R+HA0VMTF2GlNi/zM80PAZlaXT+OWr3HWV0clZ0Z a7uVkxRvwbmxGejZXU66jro4GRsZAwA7PW1Ix6hPX1iQqB7TEhT2YOKUpGT7aEFyqjJRyugHWHTt YNyn1187uNpHKgh3hivg8n2Dw99HiuUCe2YyLleJFQn2TEFiipgQ2E9WKpMZwwHP73sPi46xnxA5 OiRyQiQYaz86NDRsIhg2xtXeiXD2GWn/898A+vfr6TMS8GZ4AtQX1q8nMLzrP4N7enn7ePtg//kX kJH34z2n69K0Mxar7/sCrYwMWpO7fYdouqube4btXr3SQuP9pj2R68yrU+6f9nIpvfTWkDW88/GS r4Y9zrfYYAcaH76dv3fD0XmOT/9AeydJptaTFl9Oom+dd6BxK3W+uPFM0QzbM+SKy4NQj8sN5rpZ Iw6u2F4eNe7xC79Bu+A1Mwaul809Oi5ilaR824jLnw3dmsp91mlpqxv0L01CW10uHOoVOK1umdkM 095/Dmq4VNZnGOvRmFbjqRu3zOgs1E/sfy+2vSHr/oIVE1qi8fayLZ/CAyYON85TwW//dJnZ72wb UZ0m1k9y35PrtPDN8+3FFzmNRmd6G+acLStxWlmb5py17Ma3gwkhY7ct6d1ajb9fz2xbfiEp6P2X DTFZO6ELX0wJAsjU0QIytaX52lp0La3eBulytpK3POZg7ZfQu+aWG/4bG7G6zXp6jvq5EY/obsT5 f5XP6B/l01yZ8b+8Mj/A5/sOnqAgUZ5krxTaT0kS2OPJ9qLkZFWSr4dHamqqe4r64CT1we6EUu6R qMK7CgowGEMBx66Dtfv0/5+vHsikD/q1HWfSTWjq9UZamXQ67Wg6Pu9paaE2YTPMGr81a7+FXf6i JQFVQ5dlmfs8nXPWeZmecOwW7ZjFj2IKO0riLnhY1S19uW/jtKUDzz7+dj+643NJLlpJuD34862z ZaPqz4nHn6+sCm454vgoBGp+O+eV3sNFa2wZndomlyasH+xyw8YmJ7NzT3th1H3zwjs5zXWiGhwt Trz0Hhgbc81DSdhfW3Amc1rN+ENOJzJEDx9kBu8M983/EDSicUIVGIKlC6Z9zWqtiwB3Hgh4NqvO +l2tV0bGaZfcTzPjfOctMW9pcJ/yql36IKCYeySEvj1mO6soaBAjz8ziQ1JB/8xFOsOehGtNkOcM mOieO95lql5WcsDSHNcIBtWVNmdUAhn7gGA9A3VE19XVVzdPdYMBgL+WAfrcwV2Voq4TJZGk+rlS utZ4JCXjyVOSAEN1pdj1UXcCGjCm66O9TgDQVc/G3Llj6XPfh9HVpwZcAKe/TqxF72v7P9U20Kfr LI46PQCjvw7RNgCMu1aa6Ohoa+kd/U0UcOuMIbiultffDDaZXNbjadmhhDk1Ds9zwnues4460jk9 3R7wtBQtWlbluaZjeaWfhd7QaYFaerQtA5dl9TE6sbotGDmh6/iopMRUUtzmV//Y4e0KZ04w1LmV ueHUCF8fgUFS0hbPiyU7q+t0/b+FPTv+6PrgC2eJ3YaFn+7Z3P8y2kiyUh0FzNSj2MfvUcCEdoy2 yN9/vumFwLfEs9vBvwYBFWMY4Py9IwwKVarSEsUJouSuVm7P8FH3yCgxkahMUgqT7UOViSp3Rn/A 9vvOFj9vUSbiyWKlgjEQGPC9Y1j+vb0rAtiPnpIsUiaKk9M0QxODAQAjNb3aE2B4ejE0i/8HJfp3 nbRY6/Ax1QO/V9E2TnmrpsYBTzYVL3aMf/81d8Lm/V83bLIPnD5p07pNOVxP6YUQftqLnSmnweuv nq6fa5uTlyUsOyFN5zk02/nfMqEve7SyttpNuHataMia876u1T32oUOOhT80Chy10rXYyafoWeTs kPtZJlVrZRC+M3N6AdctdcLjNeV8v7UTbRkGg83zih8uHWb5IGA1Yc5FdQV5diMnz3tX2L5C66RN UzUUVrZgVrXvM3BF9O4vheny5OgSy4aVhk4DacgSrnhk1XgzfX/4G+vTFqGRwbaLGTDSXuEX1zcj Vef62yO7Z+V+3dM4s7nQOpHtf+ZQh8HmQUCZ3pzTZfapfebc1nTSIiBjK5Cxqav103Uy1gIZq2b1 Zp1XtYsTNzpMmmFeGvXnt/qCxP/9+sv8N21cu6sOcx8ZH13cucrS+3klffDVVNNONtczb6NxfaDu 0vk5p30fDHzVgSx33ZcfcYrX/vlKg58fVjwCFH8dLA863bD9lu70m4zFAXm9VZKqr2YxluKjn8+H 3jfF7GOe8KaVbLc6NWyko9sRQYHZQkcTYvM70PbDwNPNFp2TdypCPfW/ZPZ735Yg6znp7eGXk+sO P6wFPtszDOfb5TpbR12209r6ctYd7XLW6703TyEvBJF1k8GKcm0ns29LmjsMcmZUrjqxY6Rra3pr Uer9lHzaeUnQsYsjFt4ZbVbkLbGRtHjfvWSr01oUpnMK8xqliLLtydtvtCm76TIYFN5oC21TtZj5 zls+Ja/wYr46KpxWzw32auYGEuM1MUdpt7abXroavLboyIP/iLAAqOOAOiyM+muw92Yw1BPY74tA xjaGMRXgdfT6aEFMRh/AtGvBoI8RgieJ1GNusvrv9AZ6da3U76M/WcCXKxX8v0pm9K9K9q8us2vi /I/LdAAGfr8M6x+38NXjvnrQ6Br2J4aOVkcN+39Gk55d0cSAiiabsiyYV42BXsNzv/na1HR6TJOP dIjqvJjd9qXkywmt4QMG17UV3ACfzdBKjtjR4on2NZ/kPOrljNLybN+IfT7RCrCG0cNX/qmxsX7i epvdhVevjRsStO9Efc7Ke5Gv5Fcfrwy8pXuuYxs0cpcHt3EWHlIQCY4zsdw//tryNQAWMYVf3lR1 s2JHjw0xlUl+lr7by+dl75m/JypmQLTpPq9Zt3v68pVj6oYfHrd83aFtdh90HaK5zjkNLq+y1q7Z VdRipJrWPHz0kq37hXVsG7vNXr3WgdrWQauXVDY8DNBJDrXNeefzoGzn2HSpSy8eHfdJUXwJXK0/ 3vwlPfyLBe1OxPWYVt3WWY5adO3NmXQn9f0Y/LvxVfu/I8T01jPUPH5a0NUzATqNmm/a9dLpq2Pu zD5gU9Ho9aJqY+wf79rOuNf2HO4EWHUfYK6l06O/EY1Jm6J+VA2ljf5hQkEPB0yoOQyd/k1HF9BW //pdMAtD760dPfPzhuqxqam7s689sDqBlFsfLj8Qr1UQJvGJ/XBg6Hq3qI2fN7WOWjiKPyjk9gEP l3P7m/XOPHWpvmM9Z3rLJIOA14OaLh2Vz8+wGBPPn82vLV7hurBlychxJvsfXcJzUlLuXnP8Njgr d7EODK4osPUNzDz0Yuu8bNvs8Wnx+yI/xnmKfQeAu6ZE3eY/BPxb+JFjPn2qtQ0hH+QHhL2Q0vJ2 hhw+aFoGt366vMkl4+qA6E3QkaE5qm2bZDbfwIWZhzLGbyvYK0wv7ldYr3c04um2sscMC2aAi071 t6SxNxYNDf1MPHoxeB7ryIgLjxhvPK/F3U5LPwjsFM8d9ynbtNpmMRgLZOqaqIPZu+/BzAjXNw2l XikM//Fmdb02+K8JGl3RzxPw9vQGAG/v4aO6op+XOvh5qx93uhaBjIL/7Qvx/FfdSPtfnOzfTqO2 rznsU2Q59PWwAOMJQdNT3Qvr913I7lnjm3xl+b47+eODYuPOhsWsTXN+GdlgHfECqjEINLN/D716 Ed9058zKQ8Ctr+ipoZ7n54CPOpb2ruocdsSqTXud8Vy7zj0+2ZVfjO38k4bsRIadcd5ksSTT4l7q 5uDJ2os21KgODng8/G2n97JoaPb760CF/S1Ebx8Woncrtv7V7W2HLSJIK0eHi/XKdVZptyWslym6 ac6fj8NncsYYzIEW1p8yCR8P1WevTB0371HxaL26bz0fixAi8bgYKQ895+kL3LB5fDl0iEva19yW QQmDT3ucH37/wadJkXMr/c87xjc/26iNzysWBde9v6f94Jzu92lUJj1YfUf8qaqyM+nq598fJH4b Cv+OKdJTJyfZd5R7NOVX7J4ZN6S0ct5kZyCjuGu7g05GgfphftZv405B8pb/i3j5zwnGuK6iDtAJ BUYDQfkB+X5zfTSPdESizF3+13moJy+VVNy11kOVqORPIZKTPLq6S1dvUfcUd/WGX3o5FRK9Hb70 AT8/vtFxs4d5+sfCsrNfCn1PHWx7+Fb7E7OlcE1x/roR67WfZkbYDjxsXv8wIdiwru9SLehsaEh5 ow1nT6enToBZm12hfmHO5hlhUIrNytyl4o6bozrHLmhXBe9v2QfNOqpd617hdMMos1dd6P30sZxK vQXLgmWKEzfer203PjLQKNvDd9/zwrPkPJHD3bJWyz8qI+hbh9Wi9aULZPFfmlxrlZUOpT2/+b8y DUt+Zai3xvKm8uhcuqWZ3bC+JXC7wKvgSUL06/GZOx6b3KB/vM2dKYzg1LuqGqZFX9OrVGT3+Mrr H/Jh+fRNO4w2nnfovTtq2tClyiFHRB+3BeU5PD21oWoeI1N3gDos2mipn3DVz9L/LYHvp+D90yva /IxngHn3mOlEZ+hrq6tavV/XSKqpfUNtRo8fXwyrS//3kjH1EvnvZQt1q+0+UIdhptO78LLg7dBP g+bXjmDHp1YluAPpP+zegyEDJPnBswJpo2mJNDENp8lo9jSIplB/JmhKGp8mUC+Hqz8paMnqT7B6 OZGWpN7atcaexqC50wAao2DIrL/eXXS9Yfi5oSenqZQJibhKlPbrlFEnk05bNPCBzuGrKbee+KVP cg3sVQT7NkZej3g20T5lSNI6g5wxfv37kgyhn5f+p7uL0zu+Omy4e3ffmYzIxbR7xacWS8L5+xH/ 3jtMH7By+5088Tayek5U88r9w9tar6UUHnlb4mXXdsHWuORJX+NN7J6TK9mP6P2TVNDCQFOjYbMd o+A/ho3KEfU9KDuaM7gCnff50di1nWN8LnIOTX3q2BFI/wPZnyqUWzKnvLm+3u79tWq806K9TuW7 eqTcbFyRJH4KfYTw82LuxThha9SH5h39G2Y8lSbcKbUJppVIlrc3xRkFb/0oE4yv23E4KWFja4Xp jups74vVelbatE+rYbSoYOuMw63NnocLMrUmAJlaY/+uNT1GppaPepU31crL/uPfYP7mHezPbTwW sPyxMRv//a8hdHVb7t6iyzDpmh+oH4d8AGC4l/dI7B9tueeFG7Pbyj94VcJW5PDRpdhv2lNIY5pR zZhb69bYDjSKPpndfvZT+oec+vNaeS3Nvk3rr35s29aHmcz4rLIc1MoTvNazTSEJ72UXaOmnglKe bXbJLXRcva80GT0WZxQ4omRBE+7L9AdqDSOw577KzqW8Pfft7/f9vLxPQ9VX3bql+hfG7JRL3q9g TAW9Yyyu6mdnT4p5bzFjDDNg9huzPTqXmp/ptOttzZ2aZXjudnZ7XkpSx6NLvp3WWeET7jGSRZsf uRk6Ok7b5Hays73qQFbrhfFb0tdnlLyP9L1jwX5QZ1nPf3Z1/e24+xfstUwuPrYMaOy99LokaCSn vjUI4D3d1DEmJiy9bRYzaMERH/mRfOjuHq8S1nnDRbT/Bzq3Y80NCmVuZHN0cmVhbQ0KZW5kb2Jq DQo1MTEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzQyPj4NCnN0cmVhbQ0K eJxlkslugzAQhu88hY/pIWIzpEgIqdkkDl1U2gcg9pAiFWMZ58Db155J0jS1BOjzLP+PZsJNva1V b1n4ZkbRgGVdr6SBaTwZAewAx14FMWeyF/ZM+BZDq4PQFTfzZGGoVTcGZcnCdxecrJnZ4kmOB3gI wlcjwfTqyBafm8Zxc9L6GwZQlkVBVTEJnWv03OqXdgAWYtmyli7e23npan4zPmYNLEGOyYwYJUy6 FWBadYSgjNypWLl3pwpAybt4TlWHTny1BrNTlx1FSVQhrYkeifZEG6SYI6Ux0Y5ojZRERFvUPHeP L1pXa64vNizww7NzNsXTe2tOF9MKlHC6SDuiHClLbwXTf4KcPHPqlJN1vr/U4iX9XZbRJTlcJX+s 8XtrGTVckbXCqyRJzpHW3mgSxSlRTlTcGvVz8etzHbo4GePmjTuGg/Yj7hVc11CP2lf55wepZsPi DQplbmRzdHJlYW0NCmVuZG9iag0KNTEyIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDMyMTM4L0xlbmd0aDEgMTAwNTQ4Pj4NCnN0cmVhbQ0KeJzsfQlAVVX+//fce98GPN4DZJHF 9x6Ph8giiDtSPFYXzA00cJoEwa00KbCpxtLGFkNLpxyrqdRqNCcrH48stKaomRa1UrPUmnJJLbWp nLZfMxn3/zmHB0gzQ0FjOH/u53o+Z73nfO+5936+d+NJjIjCQQpV5RWNHnni8JIaYlcMIopcOTIv v+BS5y+vIlbRiFYbRhZNznn79PuvEaucTWR6dExRccG8xDl6tO+F+j5ji4tGHa1e34coIpNIf8f4 otR0a3VYChH7BvVTJuSOLS7de+NR9LcU+SFT8i4qGeec/Rus+hpR0KqKeeVVy+57+Vui11EvPVRx dY39i+R3byQ6XkNkeHlm1ax5f94QA2N3J6P/AbPKq6sogkzo7xr0Z50199qZT35ZOI3oE4xf+O7s ynnXxK66KYcorYzogYTZM8ord/0iBuOxhXz82SgI/sy6H/knkY+bPa/mmgdLDTsx9gSi0FOXz7jq Cqla3kWsIA31U+fOryj/041PzCU2PILIHDav/JqqgOcsa7D+AdTbryifN4MGew1ov5woenvV/Ooa NY4qYV8Jr6+6akbVsWGr/kC0D/ZYQojPvUw09NNTtdMsmV8ZexuJ46GjMS/yeOvbWxK+rfluuZWM gciaRHsOxAZHUz5dbKVva5rirdRa44NyOS/R19JU3j8gkZVSaQqRbgfGFX3Ig9lK0qHk97qByLqa Y3kdzZSCmU6S9LJO0UmyQnTdrYubuxXmXTT/ivnkJvuJDN3ypgI20OBgz7iJqarKa/XDWXTzgL7w KB2j/wDUFbfLE13x/TYY/vR/Wr/dusPpDtF+Cbk6aqccpUSlmhxn2TDw+210r6jH/2W9alr8Y+z4 PuTbabRC6reIC7AteYjHYszxSF+AYIbdmWdtwwX64RSE8gCEfKz3D5+NZjmGKlHfS2me1ja70LYr dv2vQKnEGf5zj0nqp98vwz544ee2Q4MGDRo0aNCg4ecA26hu624bfix0Uf87tmrQoEFDd4KRus2I YCVNNzVo0PBToa81MMZm+TII4TzRp7V+dvMjYyBiOtEMnnBzGt6ul/RLs0YVHqssHkE08oviSy+l 1NiB/MHwK120yviDlQe62LOGng72w0260FTDDwAq090maPgfgEwy49DJMpNwzETo/ubfSN8YVei+ UW0iE/mB/QT7k7/6HQVQANgsOJDMYAv4DFnJAg4SHExWcAj4W+pFQeBQCgaHUS9wOPifFEGh4N4U Do4UHEUR6j8omiLBMYL7UBTYRtFgO/gbclAMOJZsYCfZwXHg/yMXOcDxFAvuKziB4tSvqR+5wIkU D06ivuBkSlC/ohTqB+5PieBUwWmUpH5JAygZnE4p4IGCB1Gq+gUNpjTwEMFDaQB4GKWrn8MxDwRn 0GDwCMGZNAR8AfjvdCENBWfRMLCbMsDZ4NOUQyPAuZQJzqMLwPngz6iAssAjyQ0eJXg0Zauf0hjK ARdSLngs5YEvonz1ExpHBeDxNBI8QfBEGqX+jSbRGHCR4GIqBE+mserHNIUuAl8suITGg0tpAngq TVRP0S8EX0KTwL+kIvClVKyepGk0GVxGU8DldDF4OvgEVVAJuJKmgmfQL8AzwR/RLLoEPJt+CZ4j +DKapn5Il1MZeC6Vg+cJvoKmq8dpPlWAq6gSfCXNAF9FM9VjVE2zwDWCF9Bs8NU0B/wrulw9StcI vpbmgq+jeeBf0xXqB7RQ8PVUBb6BrgQvAh+hxXQV+EaqBv+GasBLaIF6mG6iq8E306/At9A14FvB h2gpXQu+jX4NrhW8jBaqB2k5XQ++nW4A3yF4BS1W36eVdCP4t/Qb8J2C76Il4FV0k/oe/Y5uBq+m W8B3061Y6x5aitp7Bf+ebgPfR8vA99NytHlA8Bq6HbyW7gCvA/+VHqSV4Ifot+CH6U7wH8Dv0nq6 C7yBVoEfodXgjeB36I90N/hRuge8ie5F+WOCH6f7UPIE3Q/eLNhDD4DraI16gLy0FlxP68BP0oPg LfSQup+eoofBTwtuoD+At9IGdR9tE/wMPQJ+ljaC/0R/VN+m5wQ/T5vAjfQY+AV6XH2LXhT8Z3oC /BfygF8C76WXqQ78CtWDX6UnwdsF76At6pu0k54Cv0ZPg1+nBvAbtFXdQ7toG3i34D30DPhNelbd TXvpOfBbgmEFeB81qrtoP70APiD4Hfoz+F36i/oG/VXwe/QS+H16GXyQXlFfp0P0KvgwbQcfoR3g D2in+hodFXyMXgMfpzfAHwr+iHapO+kE7QafpD3gU4I/pr3qDvobvQX+hN4Gfyr4M9oHPk37wX+n A+DP6R3wF/Suup2+pL+CvxL8Nb0H/j86qL5K39Ah8D8E/5MOg7+lI+ordEbwd3QU3ETHwCodV1/W NL2Ha/rHQtM/Fpp+Smj6KaHpp4SmnxKaflJo+kmh6SeFpp8Umn5SaPpJoeknhaafFJp+Qmj6CaHp J4SmnxCa/pHQ9I+Epn8kNP0joekfCk3/UGj6h0LTPxSa/qHQ9ONC048LTT8uNP240PRjQtOPCU0/ JjT9mND0o0LTjwpNPyo0/ajQ9A+Epn8gNP0DoekfCE0/IjT9iND0I0LTjwhNPyw0/bDQ9MNC0w8L TT8kNP2Q0PRDQtMPCU0/JDT9oND0g0LTD3ajpt/j0/R3uqTpB4SmHxCafkBo+gGh6QeEph8Qmn5A aPp+oen7habvF5q+X2j6fqHp+4Sm7xOavk9o+j6h6W8LTX9LaPpbQtPfEpr+ltD0vULT9wpN3ys0 fa/Q9DeFpr8pNP1NoelvCk3fIzR9j9D0PULT3xSavkdo+h6h6XuEpu8Rmr5baPpuoem7habvFpq+ S2j6LqHpu4Sm7xKa/obQ9DeEpr8hNP0NoelvCE1/XWj660LTXxea/prQ9J1C03cKTd8pNH2n0PSd QtN3Ck3fKTT9NaHpO4Wm7xSavlNo+k6h6TuEpu8Qmr5DaPoOoenbhaZvF5q+XWj6dqHpr/YgTU/S NF3T9B6j6ff+JE3ff440fbOm6T+DphP/fle/3D/MRDL/mJxDEU9qqPmVQcuDm5a0Qd/coPlJva7d 4x0dh6LTY2XZpNfrSVEUXbt+OocO19O3mKpBQ+ch/XCTFhjOnRU9Dsw/rLtN0HB+IyDih3xRywlp MPg8gKl9Cw6dHkubLzKQolN4i66ezB2up/kiDT8BnfBFHX48oaFTkAJ+9r9d0/C/BXOkX4e+SPkP vqi9t9AbsCgGg/BFBrRUkPuXVj8eHa5naDFVg4bOQ/7xTTVf9N+DZI7sbhM0nN+w9Amg5udp1Pzg TZyqbb5AaT0hTUbfkzl/Tu1PUwOHrtkX+XNfpPtpvuiHv+bVddRCg4b/iE74Ir9zZ0WPg2Tp88ON NPRkWO3f80Vtr4QElObbIMBk8nkA8Ts4JjobBiMWpcUXGY0/1ReZOqrUfJGGnwDNF3ULJKu9u03Q cH4jKNbc5ov4o7m2x3ACSusJ6dehLwL0RiP/yT2zEXdQeoOOu4yuPuTo0BeJSs0XaegaOvF01//c WdHjIAXFdrcJGs5vhMRbSKfzvR/ikRD5Nl+gaz0h/f1975HMIteuF6Ofyc+oN5lwniuBJj8/0ht1 JvoBn9IBOrwgFZXaJ04auoZO+KL/r38J92eGFBLf3SZoOL8Rmmht80Vc4NteCQnoWk9Ic4DPF1na t+AwwReZDH5+qNdb/fz9cKOk5y266os6FAH/FlM1aOg8OuGLzOfOih4HOTSxu03QcH4jIi2E9Hrf szQeCXfT5gsMFOhLWcy+Z25B7Vtw+AdgMfoHcF8UHBAQQEaTIeBfWv14dCgCAS2matDQeXTi6a7l 3FnR4yBHpHW3CRrOb0QNCSWDwafs/DZG3HAEttYbW0/IIIvPA4j/k6n9aRoQiMUYEIiVjb0CAwNx oyT+G6iuXlh2KAKBLaZq0NB5dOLvr4POnRU9DnLUkO42QcP5jZiM8DZfxN/E/IsvsvpSwVbfq5pQ TlY6G9wXmU3mQPRjDBO+yP8n+SJrR5XCUWm+SEPX0AlfFHLurOhxUGIyutsEDec37O7eZDT63v7w SLgla2u9iYJ9qV7Bvlc14v8TCKazEWjF4mexwEOYwi1WK/n7m7jL6OpDjuCOKq0tpmrQ0Hl04k1j r3NnRY+DYnd3twkazm84ciL/jS9qezhhar04bPVF4rc82nsLi/BFViv3Rb2t3BcFmHgf1i5a1aEv CmoxVYOGzqMTvij03FnR46A4crrbBA3nN1xjYshk8ik7/ypAPPxqezjh13pChof4PEAUp/aXjNZg LAHBIdwXxYQEB1NAoB/vo6sP3Du8IBXGaZ84aegaOvHVi/YLav896FxjutsEDec3Eosd5O/vez/E I+Fu2i4IA1pPyMhw33sk8Vse4e16CekVHBpsDg2DMwtwhPUKxY1SAO+jqw/cwzuqDG0xVYOGzqMT bxqjzp0VPQ66xOLuNkHD+Y3+l8RRQIBP2fnrHfHFdJsvMFPLTxpGR/re/zg4tf+hw9DwXmEhljDh i2LDwsJxo2TmfXT1Z+J7d1QZ3mKqBg2dRyd+2Cfm3FnR46Dvf0l3m6Dh/EZ6ZV8ym63NGf5ITTz8 avMFZor2pWxRvmducZyi6WyERYT1DrP0juC+yBUR2ZuCQiy8jw7vbzpAhxekwjhrF3vW0NPRCV9k P2dG9Dzo0yu72wQN5zeGzE2kwEDfex3+yYC4RWrzBRZq+XldRx+fL+rLqf0lY0QUluDIKNytWPpF RUVRcKglirr+kKPDn/SNajFVg4bOoxNfvWi/oPbfg2HI3O42QcP5jYyaFLJYfL6Iv94RD7/aPI21 +ZEc4LT53v+I3/Kwt+slMgZLcHQ090VJ0TExFBJu5XdO7e+efjzsHVUK47TPbTV0DZ34LRDXubOi x8GQUdPdJmg4v5F7yyAKCvIpO3+9I9xS2wVhCLX8pGG/OJ8HSOPU/jTtE9snNibMEQtfFTwo1hFL YZEhvA97F63qUARiW0zVoKHz6MRXL0nnzooeB2PuLd1tgobzG4WrMygkxPetHH8TI2592n5SN5Ra ftKwf6LvVY34LY/2P3ToiMcS4YoPxQrD4+PjqXdMKO8jrotW9euoMr7FVA0aOg/rj2+adq5s6IEw Fa7ubhM0nN8o2pBNoaG+9zr8kZr4YrrN04RTqi81sL/vmVsmp/7tenElYonq1y8cK2T1S0ykaHs4 9ycJXbSqf0eVwjjtc1sNXUMn/uZt8LmzosfBr2hDd5ug4fzGJQ2jKDzc962AjXyfvrX5gkga5EsN G+h7VSP+fnpgu1769cdiS+kfiRUK+vfvT7a4SN5HShetGthRZf8WUzVo6Dw68TdvI86dFT0OAZc0 dLcJGs5vVL46jnr39n2fwCPx8Cu9tT6ahvlSFwz1eYBRnIbR2UhOx+IYkI77puhx6enp5OgbzftI pa5haEeV6S2matDQeXTih33c58yIngdz5avdbYKG8x6yL0QTE/n3kEOKfUAKNSKfTHakAiD/CUgP wNXiBVRAo2kcFdEcqqIFdC2tk2/Qu+0h9t6xlScyVJX4ZwttrfN9rctpLl31r63Vox0sFWfWnfEc XnP4gYNpkUd8Fv5oMD21rsIkkPT9Bth033+uxr/1FR8Rtn2i16f144uEfnwegAGc2v/6fV5+wchR o8cUjiUaP2HipCKaPOXiEpR3+W/7Vv2HcllwHaenOtHd//xedOdMLnZnXXhB5oiM4cOGDhk8aGD6 gLTU/inJSYn9EvrGu+KcsQ67rU9MdFRk74jwsF4hwUFWS6A5wN/PZDTodYosMUrOdxaU2T3xZR4l 3jlqVArPO8tRUH5WQZnHjqKC9m089jLRzN6+pRstZ36vpbu5pbu1JbPaMykzJdme77R7Xs9z2hvY 1IklSN+e5yy1ez4R6YtEeqVIm5F2OLCCPT9idp7dw8rs+Z6Cq2fX5pflobs6f79cZ+4Mv5RkqvPz R9IfKU+4s6qOhV/IREIKz8+ok8hohlGeSGdevqe3M49b4JFd+eWVngkTS/LzohyO0pRkD8utcE73 kDPHY0kSTShXDOPR53oMYhj7HL41tMxel9xYu7zBStPLkgIqnZXll5R45PJSPkZQEsbN84Rfdyyi LYvOg3NLbj27NkquzY+YY+fZ2tpb7Z51E0vOrnVwLi1FHx7JVVBWW4CBl2MKC4vsGEu6ubTEw27G gHa+HXybmrduhjOfl5RdZveYnDnO2bWXlWHHRNZ6aNK1Dm9kpHurepgi8+21xSVOhycryllanhdd 14tqJ11b39tt792+JiW5zhrUPK11gRZfIsB8dmJGa51IieY8VTipdV4Zt8g5GoeDx15hhyUlTmzT ME4zhlFtxTA0A0oZ1vJUYn/M8Zhyy2qtGSi38vU9OpfVaa/9irD/nZ/8rX1Jua9E77J+RTzJj5LW Aw31LWlPUpInMZEfIIZc7FHYeKHID05JvrpB8jirrHZEmD6agLktL81IxeQ7HHz3Lmtw03RkPIsn ljTn7TQ9ykvu1KRSj1TGaxpbakIn85rFLTWtq5c5cRw/Kc71UI8xvvWfxRoWkj87w8PCOqie0Vxf WOQsnDi1xJ5fW+ab28Lidrnm+mGtdb4Ua67AhHsUF2ZqtBOH3qSpJbwA/3SuAmf+nLJRONVgoyck t0SOkkqbU1KULLrC8XtJa888UxLA+1JcenH8VzYYjDiARQmzF3isZaOaudTP4fiRKzWop/laImpb zbdNnoyk9vkR7fLtzAuolWGwEi8VFk+trfVrV1cAsaqtLXDaC2rLassb1MXTnXars3arXCKX1Fbl l7Xs/gZ127IoT8HyUmzEbJaBQ1uinDonWzqxzs2WFk0t2WqFO1haXOKVmJRbllNaF4e6kq126LMo lXgpL+QZO89QIcNZ4ZWMon3UVjfRYlGriAKRr2hgJMqMLWWMKhqk5jJrS5mEMqW5zC3KOLhS5BaX nH0MiBOrlD+N3UbFaqN8pD4/P93dgDipv4i9Cf3St/IKb2R0+p/kI9Jj1JdsKDjkDYsSNQe9OTm+ xJBhzYn6xJT0Q9l+8kH6DEGSD8qH4BbFWvUJ/dNPZ5tRwOQbyMIYbtfXye+TB0Eit/xufVx8+trn 5ddQv0PeTpVite1ec1A6OnxFfpqCySY/JW/x1WypDwxKp+xq+XbMQyN4N8JhhNMICs2XH6FFCCsQ NiMoZAHbEFIRxvMSeZO8CXaux/oWcCrCfIQVCAoVy4+i/HLO8kb5MorFusvlVbg/s8nL5LtE/AfE kYgfQnkfxA8iz+O1vvx9iHn9733l9yIfhvgeX3w3yqMQr0aex7/z5a+WF4j1anzxOrna28dmze6D ejtCGoKM1CqkVmHqVvHrHTCTl8hzxUh1iNMRz2uOMV3Xex1OsY+urw/vnb4OU3o9pv56zNz1mLnr SUHVwpY2C5vbpMgL0WYh2ixEm4WYlTS5GuNV84tDsBXBjiBj3qsx77zcA25E2C3KbwKvRFjHc/Kv MI/9YNVt8mXeBBsOsln1w93pWc/IMzHVbnlmfe+Y9BVtOZMfPxARB/piC287Q9TOqDcF8NIZ9ZEx zTFaXZ4dKFfQrxEk6gWOQxiEkIegyBXeuFTbNnkczTOSO9C2SFokL1IW6ZS0PBb8vJxOE4z8CVKw nEKZaNDPNi2TDS0zVZkWm2SryW5KM7lNE0y6+fIieYUs2+RUOUseL0+TdQ1qo9eQMRCRe6Q+Y+BK /3X+Hv9G/93+Oo++Ub9bf1h/Wq+z69P0bv0EfZm+Sr9Yv1K/Tm9aqV9pkMr8q/wX+8tWf7t/mr/b f4K/zmZg67JvlqeLC+7pmOPpVIWwEkHBHE9DuV2+FGEa9sY0TMWl/P88BhNyVoTdSB9GrEPOgnYW tLOg1IJSC/8/KcG8ZgJCGUKVr1bfWtOyDm9/mtcg9EVtIEoDMbeHwad5CmEMcmbkzMiZ0Wq3dAYW WsF2hAkIsig7jICjBtxSl+arL0PQi/rTok1LnZuvK51xl/dt7Mc8/di6fmxlP+bOzMpOd8eCgoOD pzmnuaYlTFuvzHfOd81PmL9eGe8c7xqfMH69kuXMcmUlZK1XUp2prtSE1PWKzWlz2RJs65UVYzeP fX7srrHKtLHzxy4aKw/Frqv3JqWlizjWxeMt3t6R6UMt2SOkzdicaeC1CIcQZLKBUxGyEOYjKNJm sE16HKWPo/RxGo8wDUGHNR7n8gK2+ep4+VpRx1O8XmpXL2PDH/NmDByfPQaSOw1hLYKMvh9D/WOi dXNqsyj3gA+L8vG+9utEuQ3cso4MgZsqZG4qTr+plIUwDaEKQUe75IvpEAJ6BtsQqhA2IyjyVCwX yxdLj2N5THpMTnabB4TaKIx/EB8cZLRmW6UAHANmtlHwPYJvE5wlOM4dOMb89Rjzc2PMt4wx90VC SqBsVKwS7HD7Z5ufzDaPzzb3yzajt3DcdpmlUMF6zuxjweMEJ7t7Ocz/cJi/cJj/7jA/4DBf6TBf 4ODrRePcNUu9BPtzZqsFjxEc7/a3mV+2mS+2mYfazNlmtoZhdMoR3EdwFGf2+ZOWPAuZnmGfUx56 Yt7Mfjb4WBEx1ZuZjajJmzkS0XfezDWI/unNvMv2LPsHEy6Nfe2NO2bLDmVfstEKz3/hi//ORtMm xKcRz0K8gTKZC/EfvJk38vYPY/3fI/8QxRp5+wdpglhvLRstyh/wrXe/N3k6Rr3Pm3wtRv09JYtR 7/YmH0PpXd7k2xDd6U2ei2iF18UNvMybmWjLDmKzKE7ibSvIJXFLxvpGHIWe5yIe2bxyvjeZr5XH B2hguV7nAER9uZXPMidNEMPZvE6xkTHkFF1Ek1MYHUUuEQcyizDeTLEiNnqdN6IX/ZOuY7b/y3yG bzh9xSzeNbajz2L7piD7ARvt3WTbs5VPl9e2K7mBuZ6yveF8xvZSXAOb4rU1JjcYUfF8coPEttjq MMketJXYU7bNybNsjztF7XonarGr12am2O5zTrXd60Lea7sx+VluBs3DFk9BdWnyhbaxmZtsBa4G hmp3JgZz+9kynFfZhqN4WAMbXb/JNiCugZuShj42PWVLxIjxTmHK5KHbpMFkYAvcyYYaw3TDFMNE wwjDQEOKwW6IMUQbehmDjVZjoDHA6Gc0GvVGxSgZydirQT3sTuLPUXrprTzSK5wVkbZKnPkjF6i+ xIwSzh1PiFwoFRblME9wIRUW53iGJhU2GNRJnmFJhR7jhF+U1DF2RylyHmkpLg2LS3CA8qKbo/gN 5VZiLPXm26N4vPDm20tLWaGnsYIKp9s9XxdhO/xwYaxz5kRQ2NVZEVnBFwYNL8j7N1Tm46Q2RCSd jYgYz+rCohLPozGlnnSeUGNKCz0j+a3oVulKaX5+3lapikelJVvZddKV+ZN4Obsur7S1GcVKVWhG mTzizeopljejWFYvmo0VzXCYxubn1cXGNjd6kY3mjXD4vCgazWruKw5DoK8JPEIzqQ/Fib7ipD68 GY6H5s4sZ3cWQMwiOrMEkOgsmjeqc7nQJNnFm9QNdaFBnWuoqN7UVu10NZtTSi4xjouVinEYa2uT 0NwGR4GvjWREm6T/JmbkdKIxqy9/r7KCPxAoc+bPQCjzLLt6doRn8XS7va7yPd+Tgviy6RWzeVw+ w/Oec0aep9KZZ68rr/g31RW8utyZV0cV+cUldRXuGXnecnd5vrM8r7R+w6LcwnZj3dY6Vu6if9PZ It5ZLh9rQ+G/qS7k1Rv4WIV8rEI+1gb3BjFW4aQcVjihpM5IOaW4oxRxveTvh/OhLMpRmhNmrbpQ nBwjHBE3RG1TCG7LH3fjAc4cjxmBV6Vkp2TzKpydvCqQP/LxVUXcMMIRtY1t9FVZURzkzKEkisif k9f6r7q6uoaHBQuSwDULIkRZDU5aR1Ghp4DfoGZ6MvM97rK8UsZ3xwIfckvc1uczd2VK8zMXZa7I XJu5OVO3YEEpioOfj90VK02LnR+7KHZF7NrYzbF6XnFJyVPuzLWxn8XKC3A0sRogP0+MuQAx/vFs zYJqDsIA1QjNwyUtSMotyY6lClztMlyZp1AIghNhIEIRgo7+DN6LcBThCwSFloDvQngYoZ6XyCly Sn7EnDw+YmkSF50IOb0+bXD6sAbE5TOb46KpzXH+uOY4Mzs9ArE3a6BftgUX3oy2gXcgvItwCuGf CDo5XU4XnS9oPmpLq6k6icF8QqaGU3VSDUtCgvHprqlOSiIe+AGOPYCmSaz9cU+segFhKrBDEKGR KK3mqy3gcVtD3R1EurFkQ4gWN2ekHkE4hnCiaYx6Rnc5OZsuUw/L/NORx32B/yHhalpLcXSaDaAX qREivgFXORNoFY2kXbSZAulathMT6cTFxUZIhQ2SX0DhTEf30jt0CV1Fx+kwbpgL6SALRj/5VIUb xeHqSXAhLVW3opUf5dITtI3NZUWUivQoKRmT4KIVaiOFU4L6unoAuQfoOItT62gUUh9SEC7MF9Fv cQd9Ge1QzxD/85Tp9AhbyE7isqqMlimDlFr1chpBW+htVojURXSt7oBpCy4MfksPs3DWqB5SP6Ln 4EZnoKff0FJY7KVGqb+cq1tHdoqnC2gclaP21/QOC2EDZLfaV81R70XpI/S5lCS9LBtgRxKNpml0 Oz2I2dhHx3AV4M8G4+JmE5Y97FPdAdhWSAvoOloMyzdg3cdoKxvABkjhuDSUsIX9aDLqVtB6jF9P u1khK2WN7AV5vS6tKUvtpYaqH6kqJVIJLFxLL2CML1ka2mAEOVauUfooNbr0727EFlbS/bSb9sCO g5j3r+gblojliHSDtEi9WN2oHif+M/g2GkYTaSrNp6vpV/QQ9uqL9Bf6O/tWMqHlLuUl3XW60+qd mNt4yoHt49G6CH0vw17yUgOWfdjKIGbHVgxj49gkNoutYKtZA3uHvSPpJQe85CnZI++U31OG6HRq BnoK4zfxOEouptnYAzdgtu/E9m6kl2g7C2XxLAVbtA/rfy2NkPKwPCztkg7KN8srlDO6W5oON33c 9K1aSwYcZSMxDwvoUczCZywMNvRjl7FqdhSWr5SelANlq+yUB8vZcrFcKi+VV8mvym8oVymblHd1 o3Xluk2G8qYrmvaohepN4tJED7v6UjINoqE4fmbiaLoc9lVhuYoW0o1US3fgeLmT1uFSt4Gep+30 Nr1Pf8MeIOaAzXMw+jwcdTezO7Dcyx5jL7CX2HZ2hH3NFykWS4I0RMqScqUCaZZ0M5ZV0m5pn3RC jpYrcOu9GMsa+Sn5HQi0oqi6dCyjdMt0j+h3GhIMowzTja+d+eS7xO9KvzvYRE2RTb9oWt30QtNH 6hT1WtjvohTqD0tvhZX34hhcj+VRHIlP0cv0Gu0Xtn7OJKbDER/BnDgakrHXsthIXGWMZhexiVgm Y7mYTcVSzqaz2VgWscXsN2wJu4ndzn4nlnuwbevZH9lTWJ5m27C8zQ6xD9kp9rmEg1iScTS7pL5S qjQcW5orjZTGS5OwzJLmY6mSrpKuxh56RKqXtkr75BDZBaEtl6+U75WfkF+U35L/oUhKspKqZCpT lFnKEmWXskc5oHyrs+nydbN1a3Qv6qP0g/ST9Zfp79Fv1p/QnzHoDRNwpbrQ8JZBNbqgVq9gu7e0 e3WUqt/FqnW9lGukQzgvIuQq3a1sMmZMLxXLc+U75Dd1M9lp2c7eZbXyHPly9WG5QPpGns+mSM+z WNmmy5Bn0nJS2SbpiPSl9JESyoqlkyxB+S17Wpov50riP33V7VVClSW6E7jI3U8Z0vWsUXpJXiIv Uf9EGbo17JBujbSH7MphKYQO4ay+VbobK70hzZGWUYkySPctzcG8/1F3Deb7QmkpS5TfUtbQcdkp fYEbq9VQjdfZGCVOulQazjZBcb9jfegTdiVVsd+Rmz3D3mcNuBzeKD/CxkoB2FseycyG4or7ddnB 3pL9qJTbyOKlUDZBOi1Nlp/V75YH445nN71J1zGZpeHYaUETXYEzYJXUF5qWDzXZy9Ipgu6G3n/Z 9CxXbN0B3TIcZw/KyTSJ0uiX0k7KwLlxHEsJ3ULptA3H4FJKk+6hhepiVgndvwj6KRFu2SiV+UMt w2HbIviLMCkWWjgNo34D/d8B1S9kn9KvmB1nViMlKLxmuZIPZSqD/i7DUkm/RO5+ulO/RbeXxrNw /l/uNa3BUf4eXQqfcxTjR1Im7JtKDyrJsNoOZb4Sa9zfNIrcWG6hnUyi62HzhTjPJyijoLyr1cuw hXPgo8bCJ26nOerdlIt9N0ldoi6jaeqD6iW4SS1SN0J/r1a9NIRu1ZVKU3RJyiBo7Hb2F/ijv7Jl 0O1R9C70yMUi6BSWJ2D/hbpnqFbZD+3MUperb1Mo5iMWMzQdXvQYzaNPMW+j5EYa2DROqlML5Cp4 qEM0UX1EtTE/mq3OhfI+S+sNOmjPYuqjWy/+rF/CvSnpovlTL+jhRXUSe0Z6DjpmkJ73kk5pkJ57 UiY/A09sYdTbqNc9j3qJZNaPTOxydilFJFm/zvwuc5z1y8yLvsukLKStZ0AD0hxBjiAXiEUrdMYu N55x6+hbHL2NWP+Yeoy9jKsE/p8xzH5GepR6k0ltdJuGDBtEbnf2ICN/XNirj2OQX+Q3gbOGkDtx 8KBH6GnY2yCPftpskM3uEH+kB7vNRH6K1R02yM+tfNPb+vUnX34SFDw89RPK+iTL+uGANHaluGJJ YgV5zCnHDx40ZGB6WGgvg8xZ74zlJWx2fIk+NzU1W7mif3Z2fwQ2S04cHJk1dmxhRNKZtOwUXpyS zTW+uGmMtBDXPyGU4XauDnokSLol4LYgye8eUxDdA88Oc0wb/x9d3wLeRnHvu7Mr7a6klbR6r6zX rqSVJa/1cCTZlu1Ea+w88CM2xHbiJMKGpKSltLENzaEUTkyB5gR6iKEtr7YkbWnLAe4lSZ1goBTT plDa5jSn7cehPeUk7ZfDpYDbtCelfA22739Gcgin91rZndnZmdHOzO//+z9mHduigyxip91DV+Hp qSwsdnSIHfiJFpoA6aiCPIn6BF0UqRYPy9Iety9M07c88JGZr6BV737mkY1KXc+tS7vVvmvvRXf9 EjWj5U82dL+zdP8PX33qrm8/DM/wyaUn0IPUj0Dbb9LrR+lR3wkvY/KN+0/5GROiOIPBzjup405d sBja7J6IZ9rDeOZQA7j29jE7bfdLX3lU0mDFKv2LFTxRZ50l5HD6SjBbFTTpKjY3Fwv1iViUq80P mTH2k7smTRxnUZ3uprbe5st2HVh6ojF6YNBlNblNbfmmdTeM7TqCZ+gcgIk1fhS09AO6W5fGpUPS GclASbpE7wGxoW2dLtB0nYCfQ4BghuR5yMeg8XuUHX2M8iI81X/WbchuBzMCGU28QDNg1P0Vql+u O202u+4o5ux77TP2Q3aD3e97lo6js1R1UFpHv7hwFs93R7nDgYdWov6y8D76i6aR2Z+suNS8w+31 +jxKcQ1ddMBY8WDPoR7F1bF9iR5v9Zo5tU69zPDy1y7sm2oN06pKh5pupn/zxQY5HMHvftwDKzDH HKEs8NQ79ICivujY1fyS/USUFqwBl0c0CcclgdUpzj3HbNQjYV2yMLrdFDHRpuaA2GZXIsq0wig/ Cvjj191MHhsvBTw8LMciwCQrnoUVKZXgH4EwugStzP9nfVBdDbxX/c+FYo7oGXJP/9vf/n7JaLC0 /8OwnWxIcNQtR1hujqk/bhwwjIEa/R7Th8WdqceRl+Vpvb2tSAF/0INwOgTEfwY8IZY1GmlaROgU AiNGR4cQQyERrCkGbTcBGhmG2s5vIaIAYgCfdyuVySmSpcqVSQ3Y4t0KoQyX4iEf1dBy4RV8MDdc ef5K+OoG4OdZ8DbyqFkv68VdwX8Ifjn3L9KTuedyZ4r8iH+CneD28ntN0+w0d4A/YDLFI4GQElUj AU2J8boo0sO8YrNFTAGew9Si4BJOoekIG+CCYoBGMZvdHspT39QyVFpM0+k5+he60tiogXR+MxR4 MxgM8aYneZ59sszt5WiKE7kBjoG+3tAHSV97Mk82apF0FppeX/ekHNADpwNMYNNgcaJ4qMgUKZF1 uehhUQBEw9lqhXNUjQu4bZwUxutwYfyRwpln0D5Cq8BbHYv4JFaAQ85Xzi6+q1UqCx0igKRDfEdc BHyLS5UOyADjwQRiyIgL71DiXzRUS2uYryCHsqqluSXviCUw2hWM/3x+VTMuY5RiHm42E0mIxYqK K5aAWjGwPxturC+wqmqzOa8cXnpVTLa+ccNHc2s6k5+68HYup8m+uvhQzuCx13vyq5IfMdKLb8Yy Ny4ldwRjyaXOrfU+Obvm1qUnVZ+o72Ambwsn1aV///igx45ZQoEVxf5jGjUcSWbnUFhvUXc2mwwm 8+Es86D2rPaS9ivmF9rvDb83XzBcMJsmjBPsXljjaeM0ewDWmOfMpgaaUwRhDiV0Kx/gQpGAT4my sKi4JGUMsLZIwKvEwpFAQolpjUkzLxgAqCgG0+8Ddz5BJcUkncQrrdYDH3t9fL2WfJJKISqVS+mp iZQhNcOyEQ4NcOgFDnFz6JieoWxkJW1k0WxkJW3RcIisZIgUhshKhh7JXL2DiDZewn6ykOcJ7t+t TC6eJewk/qFycfFg7QhZOUtabfUWV1JYwklYQ6ABB14yWMQMHYs53D6vDxbRU10+snor6wf30Tf+ OjxgVVVUv7b7r1az3JhrWnw2N5SQrOYIgIL5kzVWt/Yj18Givd27e6k40KMujexS/E5JVZvkm5nr q/mlV8dGk3i98kB7N2Gfn3pR360QiVJ0PE5FTxb9ytWOnc18JEArUSkScCpRfySAlJgpEnAoMacD Jp2X/DSeNz+Pp8hvwE39UdMEP82f4ZllHuX4QX6cZ8b4ef4Uz/AGXI0nMwnGwHuzuC1klvQQEear 5Qlg0DMKk1MGlXGFmVdOKfTVv4H5hikmU65VJmGyq/NOJlsjwoDP6t9PmQezqac2pfRNi8/VZqox l6PXNm1K+GEGtZz6obnB+fe/SPIwQ8v/tfyW8XGYoXr0ot57lxM5DyBE6wPFAzRyhmhUT6ddra6b XA/Sp+llmnNFo04xEjArUSUSCCjgIgRMSswdCdTBhDkdiKajzqjb6YxG59DXdXv9k8hsMiE6UMc7 TQw9R7+iC85NDocs5kRdZMS55TOzDgeQytzy+VnCMZA5TmjmkRRmPLFc1FNIxvuEZ1J0yuXGXXgU JRdF81EUJfCNirhldG75nG7GTaP+5NVfX4FwZRL06iIcMMEa5qYK5N/AJh9BMrDSwr6MZrxVPEEB jEskDM6JHZh+prq26EmT0+9MoTJVcg5QPc4xaqtzN3Wd82bnl8ERfA4dc/4E/Q05/0gjzFajFGB9 sgsHrOnlx74TdpZpvPnotZadc8tvHveVkB4s4ezRWhIgyXF/CXCGs6/pdmfJ6XWWaNEDh7/kgrKj lhJ0c6qavHfMXaJ1MA1Wgr4rsS1NG6Uq4PCskGENGTGEwXGJtBGKDKAJZnVQHcyi13IjcW/8/c8G EgO5pWR2c9zbvro91G7se59jbLdGGlS1IE9d2G/ofv/5lSvmqbWNLhPI1vTybw1GsIZb6c263/ml RmRHdtrCUHZDkkoZtQE0QJscbXNonX6qubW5jgkYxqQx/1jdWIA1Wo02qmG+zXCj5UbrjbY99onw RGQiO5Hbz3/Oss+6z3aHfZ/2mOGxvOi05q0FazGUDxVCxSzK0mmDHJYjqVQ6vwa8xbIh58+Fc5Gc srqwurjBuqFhyDJi3SyOpEa0UARF6EA+Ugw0D0lD/qG60VXb89sL24vbm7e22BiLJeWyBFIxi9zW nsq1TTmnXPvjD3IPZh/KPZadT77Y8JI233auzb2Rbw1Qu+nAU+hniEZ7EULPUnNMr24tPtwUDIR2 RwLh8LMhXFLwP+xuALkVbG5BsGlCg82QMJGEjaFFimKTTUws6TbRTyI9HC0gFEmgxByK6WLW8YKD Pu1AsuMpx2kH45ij9z0deTKsiSZkwhUiBzPohcwfM8sZJqOvL+qZn8EFQ2XkTC4znzFkvovWUSW0 DhyvqjFZ0San+hemzi8sAuwXp0pZjXgWWAlji5mYzftsGc0GuJco8Z3zC8DZ5xdIroLEScg35bo+ rTfHc5wrmbA0mvJUyp7Io7gLTlwOLs1pIU9ZhEatXmzII7st1aA6Y3mKz7J5BGjEZlL1VIXobbeh CjVVAZEy7bBca90l7tAMlVEwa6c0cFArIDRg90v2kiFnL+XhwAAfRURlRFkPJrgwTWxJYvWyXMyR D9OgVooFAHQ8UbUnAemgaJgnVGflye0f/Sdtze+/d3fvH7/bXoj8oM4f4lS1bsux62+9t6WtfunR L/Sd+V/Xf7rVV6eYjR9f0vYdumrvFWvyvbde+4kvXvHwaZOxHM6if7vv3vE7tq66tjH8gxs/P3Tf L4r+SBbb0ZcvLzD7mafA217NXH6Exm9h6XKZ6JWyjinfE+AyKm+x0MMqUbUqJeQxP1mcTno478VV 4Po/ZzF9Qea87sEUlid18yWOpFw6gxlQNkGTTJ4KG1KNuYKgm6BTQQ+F8NkBt4S55V/qYVxJEAx7 JSSRUonUkEQ1zHU0GqgsrP0J4D7Q2XgxTmYXsZn+S+0kysIFWaD5+dc17YT4y5NY2QT03ZbgXXna uakZOeVIabr8mOm4mXFqzlupW/Ofo+623F1kQ05vm1ieLhtMwT5jH7tWXhvta9PL+0O82cbJVPRy 1Gu+3HJ5sbelq+3y1Zstuyx3mu4w32GxD3lv99KR8liZHufzVKEjk0oXnkMBcKuF5fnjppKQtJQE PPa6tqIoDAq0DqdxgZFJskcwCB0SJsuUpTQgjUm7JSYr7ZVo6R8jIsIjznXoHTQMeyI9DXZtEeZt jlmnOwyWzHwapcdVKm8VhEIBJv59WAF2OP8c3kanVPyNthKlRtRpdUY16Oo5lZ5WkSriSupzdBc4 Gp7l+aOREvilu/RwIFtq4nRbSeYGuWmOETl0jkODYHF1ren6ZFUQJ6emtH6QJg3MIqyBwDKuOhPY ngIldH7xbEVcmCwvTIGkao4SrqNp2SMsxtRRRgC9MrpQtbFKRCLXF9uDMaOrpbW5lWZNvJmnWSUq R2m2aCnJlCPkClJOlz1iDaJorN1YClKtfEFGxYLFGRSDyBaFUxvbEaSIgY6Fk4ippjU0NNwGMjqF JqlJEEqQyC1Hy07QaaiiUVMgnrNNMFJA5JmjIkmO20otMowd6zEBJ2d0i6UkyZaSD44gRnudpWSG pWxJ4tQMqRlSE6Smi/pr5QeU16jK1jxDMOpbQK6JBvO5L3qL2MjxEA8A+wQeXF7vgDZAD1BEr//n ePPqsc+EUz95Z/Omspqgswk1e/jgzRvbg06zD/8hzI6Ja5va0AONA90jrX13fMLh/+x1XU3dN43E 918bjTa2ZVYV0iMzqchl2p1Lr9ze7uasHa33d38BVTr8jeOlDWMg+csXls8yzxjvobxUHP28KvlH wkYswSKWZaNboCRihEgA4DeI+SdgmOEiksFyLuD6VlxfECQfZaBNrjnmd7rDrZugmttDBVSTRRml OcLZ5de1KmkTOX1dmxdfAqFtygWqINET0AUDXUA73Aa3DRuNCZWSgEbYYYnG6MWP894svobMH57G RYKQUB2EEEDw53HuZO37TlajKgH902ICPcoeZ49xb0UMxkSXtdIsJz7F7DF8jtln+BbzBM+t51Ab 7663drrC7m7JJ1CGgJcSFXTxSZoixhkjPW6cNj5lZIxvC16KkuKCIFoHrRPWGathGk6HrQxlFa2y NQfZeespK2cF6X+6o2gdV7/fW7XksAuCDTkQnMXKVFWbTZUdvhKJkRDRSPplxsIlZCYsozqzFKT8 kkUI8nAVMSgy8lsCQSrEBmSKbCZWlRNWTAB4wHgFTY2OolqYrYqtAgmw1Kt5hwODrrmGSdR+58P/ /POv3/3E4DdH7LIUbLAhVzr/idK2r351Z7GYpN995k//dv5L021tzLGvbKgTYxOLycXfrMr/6IXD zwfcYDetAwz1gPZQ0F+O8ga0oj/oOpaYsyzxxliiA1ivajdx48qEQiv4/TWMJyUEjD/rcoOvNrf8 4+NYo4SaGKB4oG+tUj6xQIBy8gRGiDOGafSGhnSBiuHV81k3G+mga8iwybiJHeK2BLYEuV3GPcZp alqZDfxQPiWfof7LaGpB69GINBwci41L48E90lTwLuc9rhnHjPQt9Cj9VOw76EX0Mvey//f82eBb 8nkksXSPc7Pz7sjd8nTsXIxzyOi7y2coGY4IEAYVojAB5wAX4+D+0JQiKjJxgCaUGeWQcljBftAZ 5ZxiVa4NnQYz8mWvauJC2Ph1l3CitzpLMEiL8tOIgAaEAwItZEUqR+nUODVBzVCHqXnqDGXCBTT1 +A11t9fRg3XoYB2qm0OC7jzHIooV2errmka2K9r1DH1v1VSamuxfqExNLk5Wzk4SWGlaeWFhklD3 WWdNxMybQjtCN4SYL4SAjydHQTZaW1tRK5qsYNhQQNmYIClRKgWA9467SkZRLCH8CqmImXH+iFgl PKQBxCYRC/CiiwUqXwuP1ROjHLOdu8ptTI/62u1feROh2X3/u6mxPeywxGJrdq6+4mv7r9nYUkDb j/0AsadfQ7YD/YlswrMnEu655muPXujKfBpG3718Fqzye8DjTdO9NWwlssTzTbESARVfBRgBGyWH vISwvBYZ05ID40kWMNBkUhtK39MJJGUJt5CDzzK/o0JYUePQQcSJqUt06SYbPexyUyosXGMjQywO zFxZOFDNwngd7It5Ak6wMVbo60ontKJkC8PgpsGJENJD4yE6FLFANxYv4TCvARMWPKEbpzI42XCm 8R1ZzmZSpA4ZHDvMstkMYbWTWpXctPmT4B7hh6lUTpYXgNmA4EA2nqGy4JutX1/IYhG5TMsUxrO3 GG4x3mWYzj6Vnc9yenY6S1NZb4NHGzYO80Pa/Ry3gUNytsW83jxiftDw7YZDWW4+e06jZZmSlWcB 7RbQgms75AH5Kvla8/XyzfJB6qD8OPcM91KDJcG76oVOZ9jV7QnVezuD4VB3BJpZDI0eMmuRRtTY GGEsEcqiCDI2MJyece+09ykvE/HOeGnv26lBFvuTyUwBp0+vL7Jdma69NU+3f2FxCocj8Q9V7gBy XMD0KBJ+pMQPaLIuoRn4ejXBp2RKM8ApyakyajA2EmJEVUqstGKEA74n0dRkBfQzaOeqInaCIi5+ wIxVdewzxooObKrXMEy/3DXdc/+Z937w6QFgyDrNihxpu+INpC1L5zJsx47slrXbDl+/bde61Rd+ +EO0vv9fvkqI8sLrX1sfdMQmX0GvdU+UBj76ox//OyC6D/hyE3OYclMh5tYaopM8/uvWgh0gSNlI UotpeXI6hWSgBhr/z4g0BRNFuBJndAeONVCUJaA6OBwLpXFUdRa35gi7Qj3OMLf8KmkBmR8/jaXB 0GSxEGLAFjQgCKOqUqkQWIM6zp6c/0AZhzw4wHyYYmTCTkz1IarfWI3hxjGERU7mDnMMxY2D4XiI M3D3Gb5uOGpg8FdxMDQsiQkMZ7c7EoZx4iyMFmCPRwuJzYuLbLZI+MMqXDt5CmvxyglwAVeRZ4Un xXAHD31MqvjHqXH3q4zRLwfBTAuWvHqwFMFPZe7qKfARrCIiBGLJAine1JApBFi/aYvrKu+Yb6u0 rY5DjInlTLxg9FzO7qc/z+4T7hLvDH2DfkI65vol/Sv7r8Xz9H8zLuc4N85PwOj2m17kfmQ/x4Gm 46x30IwJywkLctLTbFpHrzcNRIboIdM19BS937Xf/5DrUdOj5jn+mOmw+WX6/9BnhPNmN3+KQxR3 iqMncYrnbgYm7TDHcrca3FTO68GP6nKWnGOevZ6DntMeg8cT+IUBGXDYxF0yYBPVhZPX9A3OEp7j 7QGEV4T7Ke9NBkp2L9rt3es94GW8593uaRzUm+HpHH+AP80zIq/zMBL+MH+GZ/nHbR4DtR/jimnU nTmbbhu0MZRNtMk25pwN2fCTmGAubV3hrprlAi5A/+IkNlsmK5AsgJ2PQ+FYQEHWphywRGBr7/aA rY33FLD3PjlFNrWo1lYcQe3aMstSiKYnR4lzQMI9UyTKxMG3WWIlQU+XrHDg7cejyRJXTTBHHA1U rwLVe7Urc/XKXL0ykSvdZip5RH/JLztKVpkEmMhbWJeY6KOjLrbqYftqGsyJNZiqJKo++a/Rzp37 tt6Zjnh+/OA33/7T8YdfWtyHHjOK/h3Nm26n23964407bnLv/y1Cv3obcT95vG1LvFW/DeyhAYpi bjZ+ntJovibdaproq7SO1U6a+NUBDYk2FvG2FOLxNXLCXL+lO7GA2pxE9KuhbRarJxPoJDMfV8M+ /Ee27HMocNTJ8lS2vDAvzpdPLogLVaU0j83pE+JL+HOCRFlrgvwMZSdtKGiqh1JsHHriU4gIImKx BCJiV5PHeE23EGkk5XD9a2Jf22zpxhUV9Do+wdefPFndTQ3oa+6WH/I8lGC6mW5hg/9O5k7B+LAB ZdN7FfwbJAf5g6ZHxEcch9MmkQWeGmsY0+ggb5sN8/dF0WyYm2N4PRILHwy/EKbDjrjqQ9ogOL+5 hpTTwfKcWQSAz6Erv3MAHN45+t2jqEGbQ6JuTaaQ0+4Q77PbURyD9Tvj4wWStrVV03K5msabSKp7 g0phxoYwxMdsE7Z52ykba/M3PsuwDFcLNlVB2b8A0CWebQckb1TOTpHwdUfH4lRHeRE82yyOY4P+ car1bm9C9SRUbzJI1bvjQVTTOljVUHCAkXRJ1BLv8MSKeXABiQ9Y3VAkBhN4fp68B30rqK7ZtPh6 KnmZ/+jRLccmP7alrRD25XsikURGD77D9C1+azraGI8nu6+ht27o2P+9T3WnW8NF5RMuV9OuVy/b gN8iWL20jvkPsMnbqcupUeYB/bNO7+ADiYeaGSotbqP3NOzZRFMNbIa98m7ZUG4Z2La75VOJiW0H DAeMt/vukA4U71pz+9oDvZ8b+JLvS9JDA3OGZ4yzvlnplcIrvfPbTm07s+3ctkCd7MmLRXdzZJvx 23xPczlAeZlmpSdA+bs++H1tk8vlNvHTKnKqOD7kBD2k4uVwC2Wc6hanpXxQfUp9QWXUOfTIsS3a NDhbUFW34rrOg8pTygsKo9TakBSaKFBXl2Z6UI8OpT06FPU0YtHpGXQj9xziddduHu3lIeOAbvgi +1AX6ppjmnTB32PO+tGgf9pP+5+nf06xIFz9VAfcMrOc/wp0RWOjvf97TA70XRjOJaqfyekRMYd2 5w7kDuaYnIT1a07AIpErljLM9BAawmOzgrRC5sezoptk/pPEYoaqYXwQpCE1kkRJgkFfXeFAEg0k J5LzyVNJQ9KGayZX9gwg8wfdiQkj+Sl5W26bvu0QzLlxG24atAiFbbYD969D60gUZ12T7EV274T3 Z0D2c8t/1h24nVfAhoGXPKN3jn5edz1URuWmHDPI0IMMohiRoRk8lf5QgaTQK4O/HpvJOPM0HiPz sa3bnkU3gV9nPrJf0shuA/ZbF6YWSWZBmzorapNkE2JSm8Lsr02KZ8F2A4dWXKgphcU3sIooiwt4 PwisjCkR14fKoCVmf6acVmjQE1PnF8Ao03CJelqFkikseNhtx4Gi2oZcaSVmdHPv5ra18WIw5JOQ MaGuaso3FZoYtjMxkMioDYkRdSiIgu3hINVb7Jepy1BZplYby0FqMN0fpK7UhmTULa0LouH6zUE0 sjnUFoDqgXaqr6lHRr09xWad7pKBx9cYOoJoY/aKILUpdYVMrfV1BYmrra1EgmunD7/A2wCCfxsJ PVWwspskqk03Z0TAaFF04ljTuSPOWjx4Jc4LesdH/HQ2Fqv5UCQM5COfmgdfT0JJ8CGtUDWMTNz4 +gRiL72C6+LQ1pOHbh//vmZjWCNj1/6h9cQ3u9c3RpRccOJfV1d2X/eVCy/e2WtxFLmxglZCnp6d 3YXBvmvW5pfey+badj4/+0S+8PBv0cbUF0b/6YRuZE2+OrOR3TAxfdydKLkdMmdgjCbrxJWTO+7b vKpZktTLTDsiTZHYVfS+PTc/svmyqZsPbr3s/dvyW9RcfM3eDQWv1wBKH/+1Y+a/wZtrpg/UdGOo VceCK5odZqIIzVIcX0tkz1HCUR4sExKOxxEPT7JhkEoJrC0juCChFIr1aaQYBIEeVkgfSlrCfaTn lv82i0sh8y4JWaVXZAwy7+h2opRJf2kEXlinGVStEw4VjiQc9VQBFK+9SOJYxWaq3hFqNOAoVjaL fUHQuu+8A6Cs+YPEaBVPvLRKPKFVS06Cg3jiEt9wS8GJRbJIzvCN9QXoFHfpqDcT9WsmKtdM1LK5 FukiRbXYl9TaghRSrJBihRQrMJpzhG0g8+dZfAMy7z+N76XTrS01rU2Udi1/EhtdMIpqdIy83oKj 5NlWvaFobh0Hu9mu2hPTrTOthsOt862nWhmNRYOt460TuEhvRTIvpcKOOcauO6LpVLi+J2pOhcWe mJIKJ+YYm56JFesznYVwsRvJ9c0UGSWYVQ6HaPZLcdOMGR02I7t5wnzQ/DOzwYxJSk1TSjwTSQ+m x9MTacN0eiZNH04j/CLIfPpU2pAeb/nWXvImFw6eLRILFKcU2ffsgLF0OEql2jtGNeXsrgsaeVYN JIJGfxBxfB0Xwuq5FikjgWG8o4/jGA6sj6shWRC5mq4mu9PVHRriGkJp7R2NmseI+nd/tnPjRMBl M+f0pTUefZWZiXTnmq7r8ZTWLbWtjrkle6TOk7Uhp/GexWtuXjuyXX986bubZSkYj9cnxI2o+/6r soWBpeBVmUg87jK3jjCrq94j3pnpgBMH8mKhonRtZ+YZKg6KIITh7LQSuFsVEslQJIxsxSUxJtAg hMtNeEMaVzFhLxDfhsy/Hse1TVZphfEh87vZmridWRG3V48RaZNxOMQ3oOxW9oIaju4GGR5nEUss WeK14w7YKOsCa/BVIPWTFfH1Si1CUt2JOQkiAZypncAYW5EEq0xkQCFn3M9sb28t09lZzej+lhZ2 WMehrkMsjb+UomQlyrnw8N7Vg7ilyRSPWYk8WGkMeyuRBzyyqjxIWPCJ/EDJ01URiscukYGqjwnP /vrJ8snqZkVNFPwzcTQen4jPxA/Fz8WNcnwwTuv4FMcKc9WqAklb26ppOldNYypJ9Yy/rgAC4uqJ WlNhJ4hFvb9TDivdgl9wzcBQShQVFTiX0zxjQqYS1sFHu4o40e3lIvNxQbD6rXFJ10oS2TdqbivM SGhQQuPShDQjHZLOSUbpaOzoN4g44MdewDIAqnehaqaC5sVvIV184a6qogDq1bDwJe+xuS7iuvbq UQ3XqYb29oaGjvZ/9Dd1LnV1ZQImLlwXTNqQ23gPvtHR0NC+pCzKIyUAcl3HMLr6S42y3x6fAISs BtTaAbUedO8KZn2wZASzboFFXM3nIW+XIBZTNBIwddX2F94irC2swFLA4CXbC2BVHSM7DsbngZ55 ODjKBQC1uC7uNXB4MbVVF12i6jqfwF7RJUxc7yLIc5MAHN5qoCiu5g1V/SASk8MPVQWSUFUcJFMF kiD4vB8i0zKJw2HsPD3jm/ed8zE+4oCsK+BUbyu1F5DvqHVn86AP6b5B37hvwjfjOwQVOSEV5nqi KBVm62Mrmw/wSBxrplDcKtS6qW4hFtsLMwIaFNC4MCHMCIeEc4JROOq9BApVSix3fLD4YIYQn4Ss /YfXe2W5P+MvrF8qlzN1tohUl3Qgh/GeC50jrSGytoz+5fVVRkL4v0Rnc+BZbGZ+UdPgvlGiwUeJ X+tzkKV1DPflVnRtDi8oXj5cotvxGuc0Uktralm3UmvdSi1coiu41rrO9Z2kXicBSicBSmefG39b 30q7vhXd3rfSAWT+pvtx3T4z7qZPI8010lxrIfvWuKBFxM1a8H6zBbdrCeKOW4hhgau20OQ+eV+q xUH6cJA+HHiTsNqHnKvFlL9f7UNuIPFm8Jl1C64q07X77wNGcQza68+uWrsBk6q8fmhYx3Wyw2hg ePfw3mFmeIRd3ySpjRauo9FY3S3LYlOjUgEWXZzHPyu2Bgbd32drUMc26glRI+lLhHkvBgL0Duge erdwRm5oeISTmtY7COIdMglKyxoxLDRSprV0kqtOctXZB+N46+lqmHpLCzbNcHFL1UYjmT+Tuy0t W/qwBsKFfSsSBJn3yN2+vtEtNcFxXDyL8OTkgCFQZMwny2XsQwB6D1t7h7a8QK1bfpNaC0cWjtzy m8fqJL8EBlH1ZzSgBwvcqdE/eplpgPgotmA0K5oZBUNFToWlOfr92WhLKtwEGd0S7UuF1/dEHamw D2yV2ZiWCufmGOtsrDMVXgcZfU1suL6/cyg83M2nWvr1UirJU5y6fmQzXhi1UTBbONZg5Nava8pJ PvOoz1cnOuJKTkYT8mGZludQUbe3pDJavDXXgiZaDrfQLbjM27+5M97XF+kf7Ken+2f6aapf7Kf7 Qa6Pu72F/vEto3P01u8oYOXMoZ13atrGS/YJz2Nb52w16di49iPdb1BlEhwvk3/9MFfljtrLMBff tP7ADorGBbtVjSXighJENnvUpl5qB4EZpCESqACLh5hB/w9jqKW59q4etoY43wc8crGYu8RK+pA2 yaPBnc70R/Mjt3h23dN7+aTitZqbVy91uNoVn9kQqB8pfryPpj1t65aa+koWo9I40FzclPY39S61 l1fVEc1Tb0dujX5npz3RsHPspt7e4bZblvaMyF4wmnxizDGI7prI6MUNFm2pl1hS8bjjSihr0kON LUuerc2BeDzQPoyueqBRqWkpAXyRvwKT5emLTFYkTJYjjkYTOdt4uzeGKSGDr2KheIonlFR7M5Lw Ae8lLouXuCxestfkXaEn78prMV7s1SdwdS8VIo1DpKMQ6SKUIh5LijgjKSw8ZIMLCw+umlohuRTm NjNukaKCdDyHicTUpOOtq6ZV1u+BQhThiFZ9GN0Ut8dXcXWN1Z33bJY4LCLZf/+Q16LNX8IfIiYQ seq4fEAbV2W9JOJBYgpNJE8eoKnavz3OE+3JE6bgCWvwXrKl9X/Z+xL4Noqr8Zkdzeq0JEvyIdmW 1/Ehy5Zt+cZJiJ07zuU0cQ5TTCJLsi0iW44k23E44qThSDmSAm2htCRtoVwtCUc5UvKR0pRCIRDO lrZAj0ChEI4SwmnnezO7kuWE6+v3/fv7vv8PrzX7dnbmzZv33rx5c+xuJo/K1LCozMz6OpTHU+bx iDx+M49XlK96JcyFmxkTlsLtrq/7sgMYcNum1sMIRlPP2r+3fln9uvqB+p31tEKFWzg8Cld768W9 9Yfrhb31eB1EHKgneZpMt9MkD2bcbmfRwikat9O4sDDP7SyUBzPVrrKZXmf1nFxUWFPLa1xUWGgy GXVZmUXqnRq8V4NNmgHNLs0TGpWGDWZy3LV5RWX57mXudWwH86h7p3uvmyC32S3wjaBaaPDudXXy gKb8yw9oLNl2IqqK7SQrF1MxmzoSzZhtSNsA/2wFl49nPnM0Ay0yNXLCCajFi354xaKwlGnUV88a n2ZtqdWpZi4ZHtIbWUO0zauGkYzSDo8+uGjV9HPHR1bn2/k4xtSGh8/bsHU8rzMzD1ra/ABuv2GB g7UzAYz2EXIftDMTyhMMSkvLBTdQ3jDC3Tm+1mUwsw1mBoeKtR12kwEtVhap4slUWcUavbkYyT2j vC1AHmJMLFhp2X2WzsEy5zCdcqhsXONsBjP34MzcfVNxP4CBKpXTYJAXnnhXxJQL+iKUmNqeaxnN wDdm3p35a/yI9mDe81rR8ncdXqCdm7k64wJ8qXa76fkcdX5LTb2KLzjtyscPZTziEFrycasmQY1F xYRebtE3t4EqqvBhFi5TrVMNqHaq9qpE1RsGNonZYthlEAzJtRa214oNdssX7S1dsWjvsq+dcbvB 2Xp7vqp1+Rlr9rPdZeyNWOzNWawLnL3mfuQgNUiFbKTmNfNrOSmX0Dt0KBVi2yBxnqXYWCIU55bo isWSdJNNQnnYIeFMLUDZaoCsaWYJ5xAIMvRZErJTCOQl/+Qf310FugZah2evaUkfFAbFTbpNxk2W jZmD2YO5ms6OTnknpDbXnN6UA78MNvmllye/2DCET38rU1sNDVlsBtxmUSaxBHT4/PVDT2x+YlPP eY+tqF8/a9dW3/mh+WTPdRftOeeT0Rsu+dn5Hw7PbL7u3IfHX9z9q2OXrmP7mT4cX0j2ga65UJMw RdE19zS+h7FGV8ZObIqFzTJZ7Ugibiu3wVaJb2GU2HxRwl/jdldK7mySSGm5RWUUHWw5JosNOcD9 qCw2NnSIahe3wohbYYRBO8HCgud2lBvcSVudDpgfAsNaNWnHwH2o5sQnP2eKWKNjOsmX/XW6aVOB Oq63Vm4jrZLcB4iMqDdbcrizJkGqUtHoQthuBGL0jBpGAN/3ZJYtI06uqB5WllTLmVafr5vGtLXJ 3Gr+unl7uupCD57maZ62yPN1z9npZ3timpH0Ec82zQ3q1zQfatO809bUdtSF61Qt03CVhpS6LVZw q+wXTrGCc+UqRK6CNpcTzREs5aVEVWluwIwSQc1osmcba6rzdTt1wjrdqG6PjuhelwQr2w+QI0nL 2Fag0QLMttDI22ZowbqpbJMUH8ywh2qU/VHMHLJRbVZyVEuMZub/cI2WqurVaZriuhJDibe4Xl0j 4ao0CGq1DRKu1lcmtwIkpn3Y3CyoICmuzUgsw8hTrK6EA1ObmTLPQ2WDyXacK46OgB0l83e0ffPM DRcP3LKwobQmq2nRuGRvdFkzzIXO7GJcpzX2rQjM+NqZLWu8VUWkKfrciC+87Zmj127OMFWMv3ZW rbO4GGfqqwOkq8Obbdw8fkukcOqapd33PbVhabYFyXOlwj2gy6X454ldAmVck8X8rHQXdyFc2flY GXCljk/yE95HfsJvyGc6w9cG8vnwKZ87Gvl8XMITYjPJzrT/ApQ7G5WAOhvbXBHXZhdxlaqzDQRU 6hAbhxyFUcgpvgOb3zFPnugsZOhKIG9Eu1kraAFBtgiUcnVO5+MMRuNHXJ3z2biNGWYG8JXG/Pwy 90SXD/j5SmNnsqfPaYmAk22qEWpMLUKLaatK3VKG15bhfKaL3Ku/sNDlkmaWOF1zkE5flm6TzFiV PcqmWswGbOggBKnBb18r4hYRi5X5ZbgMpRfl5+dLeFTaKQlIMoMff0A6LFFpnfsnyb2vsicePbJB nmQxH40e7UyXPe4mlDLZEoVeGMxbRkNiR1TCN85KTiE2pg6+F8dGGhfUFRWuzrBkVHitabNmjJfP m2LX0bRCR75LhzPInscfn+1xNcy1uc8ab13sgi62KJN7vf7dp+eybhb0JXDiiPAs6Eu1qk7RF1ct 15faFtaHCpjPEmI+S4hNOQ6Ny8DiXQUmNu3H7pmYuath903Vao3LVKCylFM8QnGYYlpchTEuU9uH ndjvxM5iyYHXOQYcgsOiR80HOzuhp6qCM5w62aYkpiLQOx965pD5GdneJbWjpsDk0qjKMp2WSiqU VatlNHbLIorX03OoQIvL1HOcOOCMOwVnsUWPGYX/bHEwbTGZamscGiP3NV0WdnK5amsUu3ZQPh9k O0Y62c988GBns/kg32+s7AF1az12j2CxVLbomzyl+qZsW4fhjJJrzVcVUZ1aV6pzr6sdqB2tFU21 92Kp5SIwkY+mPWo8WHSw+HeFzxU973lF9UrhK0WvefSWZk+np7/iPM8OvEPYQUYzRh2jOaO52yt2 VKaxJ0d0RGsQc3Weh6c8UqjJJZk2S25mnt2d47lGe43uWunKwiuL9JbytFLPQk9b7draje6NnguN NxXuqX2VvJJrcGuqnWi/4MT5uAoL+F5cfgfaX3kvdrSkl2U77ftznI58BzY7JOAcu2nfn8luTrFY igrT9CqTi5+oE/8GVVaVVSPEmOo4327PZlsXbZlVjLHCYxaMLWwR7i22xkpsLfoBE15nGjDtNBHT vbihxe5y2CvzNVjj2eXC61wDrlEXkVxel+DahyVUg6XbFyUaB3s+g7uwY2z/x4kC3NnRVAW9/x0n MID8AWe4zx/amG4+kvLgBvgOOvCmi9L0trQ0feIxjg75OY7O6KQnOQCUleiuSkmbVofKO7j5zy11 50vmdFGdnw7DW9GtyYUm7MxF6lKai2XTz9fk+PMaH6uPm4+nf1yq6uyAgS97WGNNi30X3iXsIrv0 30vbmbHTsTNnZ+41U75buKvCAE5MOVvFY6uTLfqqwqqiSzzXFl3roZ3s1UYt6aWSvUlbam/CLbom AX458lYUB5/B1jVVQpSH/7RNBrPT0myUWAAd/R05TfxkbyqSN/QUyicDe4TK2uTJtsq4LDIukwWK sEARliaPZGF53m4xmSCZqYmY06CcNIbg7RZLGpSTBmngl53OfydvTp/8h+Xd6uzhFL7QwR9OyUrs 5AQDVZhem9guXORKfTBF2FlQMnzmvFVS/torHt0/2B4uyMhKKyjIva5r7mrf+IsVFdee07CkNt1s MZA94w9fefbCitNK3ZXz/T867xqnzoHnX3r515rmnrVzatPqDVdnmYzZ7K1zJ94Rpqt+iXLwWGLv TF6LBWxYHt9BozfwYbIhw4qplYNW3pFZE+uEVtbzcZeO8YKP4K16jceUaVOxTTPsAwLNh8YOH6o6 elDpw15I7D+fsE/2LHnlnIcZKTDI41U+OnUkADubCeSTyAN6rDfl4IyQDbfaMC+uBVQRytbnYMpd OMqHvJT3gtQqD/JFTinv/wD4iM+QWa15uSlDXr4DrnnscGfnAfMh88HOxGw+iDXnPpQGBMw0NK3F awWhOe+a9GvsD2Q8kHmv/VW7elce3u7AbYa2tLWGtWnvZcN4MSPblU0yM7LtDoJZYMvZjUmGV6GW eAUBi4Z6RnTmExkvZbyVQTKCtpzHkP5e/EaLR4LOs7Iqb2+ekIcwVqlokW2ZFY9aMbKarXutB6yH rX+2itZ1ubduTzhwY/LDIZ3HOtmWgGPsGZGxI6zrNB+FW0cwdJ8IfpYm+ela5plF+WpcbUZhuo2r WS3fqVnCds00sOVvvPC552pLC2akuwpH51SuKftWY6wiy6365fjT88Zu65jhLu3y1671C70FmaEF JUH+ykIYgY6Rq1Cx4FW0KtPFZ3o0ykKEXipV5m0Vf0hyKuOAIy1W7v47eEKHhc8RWxLqZkmMGAA4 xhfMLEWJAYIxu1jUS8ZsMc9j1KvZnrSfswGCRoeqXihn+6bAaWg2H31DWSuTp3DZnuIUP2q1Wt6s RzQ6vaTPNhYVZwFWGaUea/hKhU5eqeBrF5KDr1s4uIvl0PHRr0WjKZG45kmiPHdbYmFrLSyJJbE+ xgCuexaLqyR1dhYCM58VYsEBpojNoITcEQN/kO/ErMcuNt0iuVj/sNelqtM35k+VFuQvkKhDY21j 44OCNmexq1DjwjPVTs0cSV+cp7kXz22x6lBxMXRJrD5GnV6n1xfwjcJGtBdjEx7Au/ATWIX54rDF 7iiyWJZZd1qFUQj2WglTOklRO1C6kgc3T/bToCuarrzyg/U7siLyqa+kpwZdhzkn15Sea3LkInN6 jjkvF/HpFLZlGHeWJ5ZL5B3BCT0Ev01dX6BoJ1y56onfVJCZ7zKOv1kxdO7cJRs8uY0L8MyO5vK+ RU1nkKvGnt3F9wE/ODqr49JRfM3MmhxcPHbt6LKGxYJ6aaNQzGYjx+eRY6CjNclxq02rLS8jaKML u/Isoo17bzYYat6dzsF0BgocFBhYw8EaAG9HItvfe7T8DTiaqw518iHoxByJU1uO8mzpwqYaXIMs IhILN7EyTDZbLUJ1tcpECAxjOw+CtF/oPMwHjtBC95oXta/Zj3JOfIDsJ95GDhjM68zK9PutWrbD xVj+bbdgravMDDR8g14gClottWjsGoe23OYo0RZZihwl5afhBkt9znxLr7ZXF7J3O/w5vZ6NmhHd iH3YEc/Z6Nmu226/Gl2t/a7jO+W/QIfrXhYLtVpNebmnrEyHNeASWe02pxV5apzIokt3Wko0kt3h 8JbpbJDAU15epNXYgHOQpcyhVek0HjjbdVqNptBqAX8HiS6+PxSodVUVNuWZ6rKyHHa2Zyxnhw6/ pHubDVQHdG/BQPW8Zm2bdq2WaM8DdTW25JU/Z5KwSdoFo48daz24ytPsETz22rqb2ZQ9m67vjC45 0rnhyNixTrbrdUyZpl8ydqRcVr/ks6oa2ckBZye7HM5sBAH+zlFsPnBqqDZrpmumy8t47Lke0Eor ex6a9dRWKx+RlrAnpEURxhhYTHm+jOlnIy5hG4JcBnxrRkVFwUuH0tWaKeW4rLg0W2sfv6Rhz9em LW70FjSV6pzzi2aO32MqsJuzaslVxa4819zxGvyRu9Si1acVF6uyC4zNn/RfcPEcT1ltpmlGxy7h zvzKQoPZgASUfaJTtVj1O1A8HSZ3bcTDgiAr2z1YpdOqDHr2NpN7dKRFa6wjCFVVlVcd5ZzIuYuK VCXC3RY9wjaw1lRFRRV79wkRbISwVw3Nuke4mko6rVo700hcSCM8yb6Cg+ewDenC84jCT0IintNS grSaOvaiE7jaLb7Ndg2wF5mTdfxt5gSJktgiEnGfsAJR/E6LXcB1Op1JbVZ71SSi3qzeoSbqM/Vr XpQ7L7b/8+gYDGcABNkdm46qjjrsY2OO7KPm48yLddj50/bZ5RomSpUCdLCerBjX4wytUJBRoFr4 8ROq6k8Wkrs/flxV9/Fjx/HDK/BD3ePD4/HxszrZGwvexL9WpQtGRFDefUgARugQclDco5q/AAh5 ean5OKpawhbCCuoLVOkfv6AqxL9uBYvxSxLE/6TrkQO1teRp7aDZ1Ky1obvTWmwkF3SaTjVl5WeN snVoXHan2Z6Tez+McwvQU/h0xLWVvexmQkWVTXZMz6z1DY2TX27TmHiQ7M2eYofeYNRbHOmlM/LL ps5e3zGNBKtOry+pzzeZ1NrpFTW5JRvah3wtULN9uBjfhJ+GmmXvh5rdgzC5EyFy7+0UV5mPoGal UvimcQt+ExffhuQ8NOeL89Ccj3ZR30QejD4rz8sT5aDxfXjeRB7Nl8ijQe/v06TkMX+JPGb01j6z nIf9TVOOqycdf5AP7E4e1556COxvxeSDTFfZ+HFD4qAPJg5182cf2um6s/SXGY4bXzGXWuI2Q0YP OzJXZu9z9Odcn6fL0zmnSNsK9hRi+Sha928+xv/Vo9iRPNZ/dXx1fHV8dfwbjwv+nxy7vjq+Ov4X HvcVP1189Kvjq+Or46vjXz34uIh9KnIV34fnZSMqZEO2E3chNzKdOBO1otYTf4TwbrQBrYSY2yBc CDErIWYxOhNizgGInOiFcNWJHRCuhrt3o7shhv3NJ2egxAd2x3lIeIlOfsVgARkFDUp8LTmKn1Ng VUoairKFbAUW0RRhgQKr0e+TaTSoRDiuwFp0odapwDq6Snu9AutR1PiRAhtQtymswGniXcLZCmxE Z5qeSn5Jd7O5UoExMpl/psACUqfXKDBBTel2BValpKHIkD5VgUWUnr5cgdUonEyjQdb0mxVYi2bb 9iuwTrg1I/GBZT1qyrpVgQ2oNuuIAqeRM9L9CmxElexlPQirCNBmyJ7LYQqwOXslh0UeH+Swmsdv 4LCGw1s4rFVkJMOyjGRYlpEMyzKSYVVKGllGMizLSIZlGcmwLCMZlmUkw7KMZFiWkQzLMpJhWUYy LMuIwbqU+up5Xb7FYUNKvJHDP+Qwe2uCMft2DlsBtmQ/wGFbSvoMjkeGM1Pi7TzvkxzO4WlknHkp afJT4CKe/iUOl3H4KIcrOPwxgzUp9GtSyjKkxBtS6mJi+tNt16J2NIIGUBB1Ix/yw1lCN8OvHfVy eAmKoH74xZVUEpoNV1GAWeiD+BBPIUFMGPJXAjSHx/v+m5iqkpRJaAXcCaPBZJoYf2t8v1JeNWqC w4sqFKiGx86EHGE4L4c8PUBDnOdaDvhi8IuiIQgDUEYI9fE4CS2F8zBPE4E4H+C/jdPPqAvAPRYX ReshLgLc+tdrJkFsEGgKQalxTgujRIJrliauYF0JtZbQMp6ffeeElbcEwjYou5vXkFHI8gUBa4zT 3qtgqzyFpqlfUFOZMz3A4zCv5VSw4wxXLEl7LWBlj1BL/HsBIahHFO7EOC/iYOMn8MvYJ3Avg5os gftLgfZ2kBv7pvlskA+D2yCW1WkehIt5/Fz+BfO5XILzActc/pUDFtuO0pCO/xjnQ7wm8VO0NxEv c3GAUznA68LSJmR3qsxkbYsAD5jMBiD/SAqPQ4r+DHJOS6iL3x2B9IPJMv38Wy0T8hzkedn1BD2y vPt4epkS1k7CnJ9BrtlBHtfDsQQ5R/shF5N3h1JaL9wf4ukiQAdraUxz5DLjn8OZhKyGuYSDXHNC CmWMxgBcsXg/xIV5/bo59/o+lV8RpV6MY8EULMMKzk8rL6DofBTOXbw9y1R3KZLpVzB/moRcvFaT OcW0rfJTtOLUkuV4xushCJkt8UGpYYXbMY4t/pllV/L22M/TxzimkVNkIctpcmtm3JFLjXE8fojt 5jX4MjKXFF3s5xakH64mymUWKcA5LbdPH7d10RRb50mmjqborVy/+BdyKsxbcygpIbkmE/iGufzX c2mmWrhuRS8mUkYgrWz7BjnHGf7eZH1kulK1m9kMpg0y/+VWNaDoR0JLT9ahz6vRhH608rqfKjnG YYZ/A8QHOe5Ebfz87OdS7T9JBtGT+D2BmdUvwi1pQLH1Q5BOtrgJO/BlpJ/AJ7dJ1laHFGlMtLEE vlPlKHNLrkGc24D4p7bjhMR8J/G6+79E7QSXTy3Br/QwXcpVKkVyfZgGTU1iYD0f+y5MBe9rTuNf fXID3Aj9+2kQ64UY1hMxz28lWqSk9MLdarhTp8CN0GM18lwNqB68AvZj2Jm04kDZVPAwqoBf7KiE epzc4v3c8n1WP8GgObx1Dif1Qu6ZQ4q1ZTSt4PWU7caIwv0o11OGlbXQVTx9XJHBYi69QFIDmD9T C/7MhGWLpvghExbsVFvfzW15jGPx8S9lBRXNmPA0EtgT1wl/JtVTkPVgMac3oLSKfq7LzKL5lJ7V k6JHw5xWP9fOEC9/mFtYidcrxluM3FuxVs/8uLjSGuXWy6wE0zK5NfYn+6Iu3goinLKT+4qEnspW ibW7GLckEYUDDKufc4ZZ727eNqVJGhrl/JnwL2XaEhyJKC09lLS0gUmyj/Gyg0rL61P8xckewOfr gkvh0EQPnLBBct/4+Xoi+4inyi+VwzKP+hVK+5NxUW5leri85HYaRBt5y+zn0hpSegW5b5N5NJTi WyW4KmvREPfUh5JtoptbylTvIKL40LLOfXov/+XamFy7WVxzZL2OJOmX9TKUtE+xUzgu61wgaZEC XEcSFmmQ110ucxnHNcA9hEFuJxNe4TLuLSf6Z09S4xPa3JfsWyJKbxDjNQ0rWtfL5ZiwhFGlZ2O1 i3HJD05qP4xa1uIm98k9SXmwejO+hDl+WcIM6uE9ZYhbcdkH9nOZD/C7k/uTHrgTUUYVfkU2fZBH 5vVqSBfgJYygRN89YU+6eN71Cq0yh/p4X+FDmxQfNTbJVjBdl0dJCY8lMsmGBrh+DU6SYgKzj496 IinYZM9ggMtkZFLKgOKXx3kKWa6V/8WeoIqn7wPsVRDGuSVgdFVxb34txy23Otk+RpPjn8pkzv/Z Eoe5JBI28X+ilMS9qpN6/CTu9pGBYLfPH5Rultp7g9KSSH8kDlHS7Eh0IBL1xUORfmkg7K+U5vji vi9IVMWQSSsi4UEWE5Na+yFfdVOTtwKCmkppZjgsLQ/19MZj0vJgLBgdCgbaQ33BmLQ0OCwtj/T5 +m+S2qO+QLDPF10vRbo/tzApGuwJxeLBaDAghfqlOCRduUJa5otLJVL7Eqmtu7tS8vUHpGA4Fhzu hWSVCUxTTyoUiOkZDPuiU1cFozGGvbbS65VKl4T80Ugs0h138/SQnKdetmJJ+9K29tZ5rbNntre2 LZXa5kmLW2fPXbpirjRz/vK5c5fMXdqepkvTtfeGYlI8wV4GA4kD0chAMBofYbVL1gzYFumJ+gZ6 RzjFIeDPYCwodY1II5FBltMfGeL1HOwPBKMcD9S7L8aQ+KRwyB/sh+S+nmgw2Bfsj1dKHZCt1zcU lCJdcV+oH3LGJxHDajXsiwalYAiQRaVAKBr0x8MjUnc00jdBVwTKivQEeZJhSDmRLwCcj4a6BuOA GsiM9AdTK+SKJYgKxiqTrEhmBtgnDfnCg76uMJAdiwXjqbkrpZX94WAsxivPawF1UsQcj0DW2EDQ H+oO+U+tuQRc7I+H+nt4Xl8gEGLa4gtLUa51HhYd5byF8uInExUO9YVYhaAQnm44El0fi8sK1w28 4JGRYdC+wa5wKNbLygFcMrv7fCMS0A+iGhhhjJvg0OSCOD9auycq5+sfkTYMBmO8GH+k3x+M9is1 iCp088Sx3shgOABaPxQCxWU6cGr1WTqQZDAELUuWGEuXrCOQBQXEff74hIxZxXwK1d2fjpaTnMzg hwbTFUwggnJ88akswcoVM6UKqfS0uka31Fh9WoW3zuvValcugkhvdXVdHYSNtY1SY0N9U31Tmq43 Hh+YWlU1PDxc2ZcQvD/Sl9omgtKcqG+Y8QIaMxAFmFbEfaAbI0B+NBSL9HukVSF/HGqw2BcNMAZU N9XWcGWLchvCFSyp9d2haCwu+QYGgj7FaLDk7MzsjGwUgAeLI/0BEEV/cDg24IPG6uE8Gu4N+Xuh aUrDvpgUCMZCPdCsKiWpNQ5iBPEOdsWCIMZ+1oq6glCTYKJVMJ6CKoUDMakvAgTEBv1+UO/uwbAk MzQa5DoWA2yMEKhaT4gpbUCufUwaBu0HBQsEFQNwEheguckNmGkQtMaTeAIWMVk/mWCgqB+Q9jMo Ghns6QUllIIb4yB20ByoZJCZ2SFurRipwKKhSHiISaJ7MCqbA2gbjHMpTf5TJAbFzfLFgNcRhh94 GWL6FEsQDpwLMEUKDHJFGoyxnMuC0YFgfNDHTeGyMG/PHsZ4xuY+1loi0Axi8REQrb/XF2VKCNji IX9MgubG5eML+AaUltzD6hHc6A+Gw6zCYeg0ukLhEFhgf2RwIJxoJz2RCHQVQEukbwSoXh0KBEGQ gzFZT7oikfUxTlCfr8e3CSxqTNaKaBC6JGZYIrKGBiL+QbmKLLEvHIvwZGAMBsI+2br7AmDL4yFW 18rPaARVvfG+cFVfvN/XF6zqi62NM9GBPkZZ/1PJbn7JjMPBMNPEL87CrqqUhs9To6XcBevjTlk/ n7iAYQtOA9fhbLh+jTseifuJgVBAHsSQ75HbyX7yAPzuI/vIT1Nw+bgbkrj+C8cdnFRWcBI2jk/l VFWrFqnmq06HsIl/HHyIu4Cy89OL9+IfEsRdwJmQPsoHaQxHqzJZzYZqzLVlV4vhaj64vYkBHZv4 Xg/QHD4xM1+ZyF8A8FxO6yI+KJAn7eXBGJu4X875weiuTKxbwt+JAkD66X8EsdW0dIRPnGBrNQgt EV6pERC5CqFZlC6Ga8UAJf5OwB9qPjHevmTpcq8XoQsTq7EGBaOA7MKrwtsIC+8IHyAifEgowkRD NBDqiAFCC7EgQnJIDsD5ZAqELtIA4XyyCOLPJecBvJlsRgL7FjbAW8ilAF9GjgH8HvkE4BMqoFyl UlEINWx9T5WmApwqmyoDwsWqpQirelQhhGmZGEZYjIrbOY3sp0Mz0I8QhgbaBXXXIbxk5nIJOfgq J2XP+wAfKBL5tcjzsBgVwBqwDWFUw8PTQv2hOJrRFwyE0JxuMItoIQ+XhUM9PrQqCid0FkLJdVis YGKhvJqs4iHlHBOhLPnr4xpkQaVoHr6J6Gi7+jrNAZ4XcylpWE3YFX0pJdaAiHi2mEeuZJjFfFES C1Lu3obaSQFxkypSS94ll5Bvke+Sa8ku8mNyI7mT3EN+Ac3hV+Q35FHyBHma/I78kbxE/kb+Tl6H 413qpmV0MV1G2+kaeiZdRwO0l4bpAI3TjfRc+iP6E3oLvY3eQe+i90LK/fSX9Nf0EXqIPA3nZ+nz 9AX6F/oyfY0epe/Q9+iHdEzEIhW1YhpdLGaQAjFHXC82iNPFs8QusZt9mRf0wUUqSDWpJ9vJDvJt cg35AfkhuQEa7s+h0e4nvyS/Jo+QQ+RJ8ix5nrxA/kJeJq8Bre/QUuqhC+lSupyuomfQs2gX7aZn 034apUN0E91Nr6c30Z/SvUDr3XQf/QV9gP6K/oY+Sp+gT9Kn6e/oH+lL9G/07/R1+hZ9l75PP6Yn RCKqRb2YLlrFLNEOvK0Tp4pniuvEwEkcnkLKiJfUkWPkUnIFuZp8n+wm15ObyF3kXnI/OUAOkofJ Y+QweYb8nvyJ/JkcIa+SN+A4Bhwup0vo1+hK2kE7qY8GaYj20Q10kI7Q8+iP6Y30VrqH3kl/Tu+D lP9BH6QP0d/Sx8kzcH6O/oG+SP9KX6H/oG/Sf9Lj9CM6LgqiKOpEI3A4k0wRc8Ww2CieLq4V/WLP /00O4ynociKRUuIhlaSGNJCtZBu5kFxMvkkuJzvJVeQ7YNivIz8iPyG3kJ+S28hecge5Gwz8f5AH yUPkt+Rx8hR5jvyBvEj+Sl4h/4DjTfI2+Sc5Tj4gH5FPeL1Op810Jp1N59L5tJUuom10BV1Nv07X Uj/toetphMboMD2HbqZb6DfoBfQiup1eQi+jO+i36JX02/S79Bp6Lf0B3UV/SG+gN9Of0dtBZvcA H+6nB+hB+jB9jB6mT9Fn6O/pn8QYPUJfpW/Qt+kx+gH9RESiStSIBtEsWkSbmC06RKfcksVCsVh0 iW6xXKwQq8RqsVasF5vEaWKzOFOcLXaKPjEIXLqcS7VckesW8g1yAbkI5HsZSPjKFBnfTG4lPyN7 vlDWR8lb5B2wte+TD8nHnD/T6QzaQmfROXQeXfA5WnA+HaVb6TZ6Ib2YfpNeSi+nO+kV9Cr6HXo1 /R79Pr3uv6UnpqSm5Cn8mSIWiSViqVgmesRK0SvWgAadBjo0Q2wRZ/3/r0n0z19p0r9Rk1RIyzUJ YwE8BwcaQHeg+9FD6DD6AzqC3kQfQGwmcoIr5kE16DTwNOaghWgZ+DIErP4/5LOYT94DH2YreR/C beRDCC8mH0N4ubgRCbRZ3AThTPFcCGeLF0N4OvcKsgFvESpDXtSAppPjHMMHHMNHHMMnHMMIx3AO x3Aex7CdYwB/QzyfpeDQ5iQ0moS2JKGtSegbSWhbErpAgXTgKfyZjkGPg6HPodDraEUdcEgtcwhN 5WcRGZENOMXcUw/4fYLwDpkP4T/JAgjfJa0QHiMLIXwPvD9BOM7aqvC+4jnJXpqB+2EIUeFtkgN+ XS94dgmvSvHqHOfA2SY7oI6Yd6sjImrLLlxw4ftpWC3s3upYB1FnChhXG70GUSPfEShF3nWirlzE Kry1UcCq3cu9y7yelJjcHzlHc9F0frTx1aIIHwqwefEZ7PBKk/GpzC/aY+f97ZbD7ZfjI5e8+VhP aPdW2/3erQL7FQvmhfanTrt0a0fuDZ2xtRmdf/qxNy1JJ9v75t1yXXW+N08kK1U6a+YqGD+ugPG8 1B4dhPH50mCcjW6rs7wZLIHeakwk8PAZzWqPt0y+UTiRE3x3NizvG2BD2BXB6BAbDS6PROLVdd4a OXX50jZpcevMWa2LW9s7pJmzZ89d1j53jkcq9bubGqXJZXidWWlNjd766hov/zsjK81b5632NtbU sumTM/73V2DLrlSeYxhBbLkM+L5d2LIFPV0pvd17rqeickvu7eIdN+rvSU9b/YcVvx/82yO1ZXc8 c1z79bp3X9s5rjUc/mPOGfcd+vvxi2//wYGLil8/b405dvbGRzdkjD205rj71jVnfUc1VtGVvmZL 7m83XPXslDVVzz5mo9sa9l11y11LFr725rQpP1t1zfkF3w9feGDh/O+efddPGp79RFvx9F1N1woE FPoklSBAl2+lccY5v7nCcn66+fIpjz1zp7X866/OOaLfeN315797ozrq/GvHW49t+9v2qxb/canv rTuv/3je6cvq9LsGVh2/vGxz1uMv+x8YCaljlXu/XfrN947ecvNTnYd0vzVrdzx+557S7xwccW+7 4k8n9vXMWvCTneYjD/g++P6Kl698Mtb8wdgP2rb9dOWTY+l+v3erSvBuJet3EwELglmzqe/MSNeV bfsOjs3+iy37B/8XlRh0tqbmtMlK3JBU4t0J+nSn0KfUTP+ZNZvmbZIT1LQn5sLZxK4vLrGZjpgy 1THE5oYgM5/qiA74GKHe6mqXt5hlJlbn59feuxVPOVmPt2ITgnidsBVjdGCT76LX77iR+HPKHb4X R+/JyNt9yc7Tf+G6Yput6fULHv/P6s08EMq1C+BmxaCxdmXJyJJBvDMIYyd7iMYSyl6WLCGuJc1M oUUXFWXLlmVKkaWma02EpJQSEZK1hEy3lO17Z2i7t7773/2++9fM8zzzPvO87znnd85zzvtgTyP3 mlyEWZ2asCqaLd3zUHFDS/LbqgtRyeL3J1deWs4ulqY40Dy2jP32HivYEfTbjttvUqt1++qkJvRt u9/HziHHT6aJ4Ogw9OPtmZKy/cLCiRR62UyRxUv+oqHE7hbvRjcHavDjecDEqlcx0APTe/wuJarR vEammew9PkbRLTEi5HzU2dqxvZqo7xjpFbV8dKTFmFhyU2uK1CL0oUmJTG6TTVk4vIcQn8Tfd0/h 4NyM35gW1bVOH3LJ6pJTsc4mXDavwMeQ3I2Uk3C5V0bQ7f6JYjsUUsxlf0UeDdVKTpQ3xjFNKZ9M A8hVgC6SDSQ6AsEKqieoMADwuQ1A4iTX0k+BHiFB3wuF0aPISLMfDAHYQaGI8oFGwAJsY3zFwLUA hpw5XONMIHHzhhBwakAWkPk8MRSyXuS/SRvgY8wiBecEUJ8vgbEBHIxONBwOgyIbfkCBLXQrD1d5 wWd/SKJtKjhfV9Tsi22UeJNoxPVAyKKOHh2JAfCC3idPV+PTZs/QNASQm6O0oUiWi+Knj/Khms+P 6to3I6QmSkt5fKmjGu2TEu/PYnfr2tILdma1biWoe7GFhFzEPyotqW9BaK4YTt2eeCb58L7HVfai hWHhl0t6KN9UkAK8oBf7tEoBNMstlpOamsd4Hmq/95ga1P0zBIJwcgB21RA2GQQGRTArBgwtZxTe VDFfiljM8pkCbiMgsvpjge9H1gprOHFAbNUwBL+OMwiA0TsY6h0Y7BMaseaacDgAUF2zajyAwyvh 1pr/gxX9nZFSobW3gsY05iyFZbLP/boHeJVHPSXlMr+csj3/xnJWHkY72jovIy/RFe/3UN8zYrok rI34bO51ZpxIYvbRvRXNfpHuEt2imgNoyOmJ1Kb6LXvT072l0zoJ8vWcVQ7St4zGUdpqqfJUGfXi KdMj+i+PoqvT99u6lVCic123hG+fTKv01EjfIYJjk+TPpo4nywmOaZ334Hd1QHhli6raxH8omjkL vSPcVW9rWHGcVE+YIp61vLpUFOkfalkqeC+VXUacxT7J1Ue12pyXVdNuxWnh4l4UW+Ejsp39zHWN PevJ4fBn7+uuklKWyzoOdxcJBTtr3q2ZZcvfBFQgY9sqMOF8sYNrRloMkAsAch5D+yFwcjpAPkfi duoMmvEJviBhHcNfbvHbSntu8D8vP8rf6DiMIcOUCY6GU/RzgipvaBDJnnAeurMrPvsCR7s2IvlY YhthTHxu1v6MfFWOcav7zOLTexoajtStRJ9lSX+dtnuXBhDRz3GntLK5g3yrl3mtBH0aFjsNXvI4 YqxeuUeVXtrQKqcqtaXOK5f3hBTaI/8DUeSjeFu3AN2mJMAAz7pE+WV+dN9+Luv3tW9tWmrHm4BF DI79mGgKVsjiiSi04C1pCFbp9O7a81b7aS/TFhvi9UqYDO9KUvcsW2IM7VzzZVX5kciR4vCXYTks nb46tx5tPTGkx1us4ivs26fy4rEIfKTYEN7qqKQWYCHC5X4DlZfQ9YSoY9QhYlsY1MdLiD9zMLvo UQ5IhTYwNri2Fhv4cqRZNbAMXOJ53KObXlw39n+BBQDkAIgFtc/OXgWHAwPY1SZALsRxMAEPR/JB bXfi+AAeRoOND2XvxqylhoL/ww2sY3Sy8rHaeHn6BwZ4fl4Z6mcr+9ltMgLnv9ymBCC+ehtC3454 gn4fdBrM4pOBHkgNzF9pwsWgCRuTJnlHBXb2cADrlFNWCMKNdMUof1UJC/qjhNGl0qVmqLKYZMto bj9xKgYaany5D++wnt8aq/Y2prwygWBcpW4ZQGzEcRL8Fzo62ndkCl8t6uk1k9apam5PTB02nfPv mUzVHkA8mC20Vb2i6NpBctPPNSWaoQVvmPeeSQMcjQ96VnZVP79+mTPLihaiIUi4VBmfUHaszMJK zJKnSok0yEXwDNzWolxrdiajplD0I0LC0hWbeE927mh62pXiPlRQVLeyXlLBjb0tzsKi+UrrMogw IZ3zSbR741rwUAORxA/qYxUlJpF+suvcIW7qYQFL2udZzfnfQoyWBFiGjJ9ZjSBGSFJQCCyfApEB n4fkj/wr7N+BGG4k+9r2UwACRgIQFma8KboOvh7Oj3W+KXy9Q2m6+sKuQx9G7yo0cSnLABu+XMAP hXNuRDFrSu6MYw/fBBQQIwDNjGEgkBU4AoCBHz+CmaHDcLre4cWsepPw8KsJvWMbmu0rhWorb7pA cw191Xd9vLk5c4vFhcW8EbUTap6b9AdvKso+uNGNvPtatn5IKDa6z5pN692mrscN/sfIAttcPI94 NlHPyp/oS1I1Q9+YeOyWGBb2oldqRfJoyim4HfFsrghBm1IzXRCfIJJgHuFSZfppD96HIEa8ctBi 0HMc0OzzNN22sNAkon9gLEfLcNqPJbtEv/Z3ngq7kYUnebLkHjHLPNu6zYlBhXn7hVeIJyg1ZPPC 3Gt7I6m/FLUjG4xfF1ZM4gR2asnC61dCTPpPbjZY9JiYlox3qtv6cAL3B753z2BE5O9AiU+c2UIC T73wKeIugIJAgzD7sAozlBsrjwEzpaD87cNipA3+NdBg0A8PqOBVAEBFRVmNQT8lEH4q4HaH0QTI uf/0jeB/Zkawn0z2t2HUpbRa9WLBze/ktDi260SHKxS1Vz1M4GokhD49UzWUY66za899Q6v0COxb 03tCxtO2jWzavJh527lpl66hu6k1wMCyQ+tmfGcscWI2mbuaLle3YRSWwREnSi9TT6AtcYhqhkiX 2MvdxeYJJFEEhsPzdW1gJ7Mag34Xm1R+T1c5bWl7ZP4ZcB0zYI+sctRHDuxqnxssrBUwPrBBSuJR e2DGhohBX6e3YYgI7OJtu7uJ29hibU+0t6KNzG3bE1LDzeInqHrIlhWuSW97j+DbPvaVBg/wBKBf ePKJgbRsxHJK36Z9km2KncovxxasTeNomp1SLt1TF2Bu8VRv3Zb5YdjYA8RqGEWB6IJPRJMpKlE0 w85XNxI/ROFXpvi13rHGzFYqduVcv3p4j3Q5Ld4GC5CpjHEJODkX3MyTfsid3NCL/wte/jXAMGMs VQxuAOgBOjlaORpx6mtbOo/g/Qr+n+dh7ryC/HwYvYpBwYGMVztCFBnmwrAW0FIUwIE/WTkTiSoS S3zExcn+2eec/JGfiiruLxURWn8fHX8PW9jZV5RGzcnYmgl7TTEWEa/lbx/fp8vesj4ZanvfQL+y Q3h3GR0P1+IdFS1iLUrMjzG0DRNOTUn2mX2uRjc5PhOke6OvypbUAGtSuC7Tj6KsazF4GWmym4Y8 flp3f0Bz/3z6DEedOCpBkVD1puj+gXhviRcVI4KHaMaQArkmh/by4/tdlrrkmwJpEuVcK5pzPIah c+zINMHngQ1xEEFeUbn1pXYzXkq5r/ZZvjOnXJ5E90M+Dboe3mu8u10+6F6UZS+SFpDAuey+Uf/j mei8y6gLnRLcVy2iNicHStd5fyrUyZZ43ZpVHY+jICRALIpBwR0uuJf+t4DvO3h/l6LNIc8C/F98 pgwExwpDMEvyDE+6Jn12GI7z28QwuPqvLQ5mEvlrWwDU2i8XwnG8cO4FZNnGJuwb1Pqb57nnb5Nw QMw3P+fEBQEBOdtI+n97TtJo7fwK5mcnJHOlSZLfvj7znbKHfn1580/0hFMgLG6Y0LMrD5yGcqu1 eGcPJaB2HeHMiJEQ0/9I6BjkemRUql+/GI0V91TDoE//UbBrhnIswktdeN86TvUKZ4mCdJF2u+Wq HXTaxqYr4lqGJeZzF2DzUO03TYRfxsrnI487D5+AmGigqkP84pZNEoaSHkz1jPj42eu+qtUsvTLj QZu+OhQW2Yk416tAWelNfy0c0C26I7olenC/6zGtmvCsU3Z5aUsRBr967aWLl51yqDqX0yn6Jtjz vlOLVpdqbN1FhWyaKPe1+6YZh+gFM2UCR2Tz/A/AMNRzGR/awvyHsoaSkZkzV4jZPQEHdiY9Xmnu jutfirZ8F4p9U1zutjX/aXOM9IeuXAp0O0CBmnyVHBJHgaqDXSpMTa/4v89i/iAP+72e7wIEv1Vo jq8VEQioz19GEDg0I0bAATg1PA6nildy/Is+n+s37ui7Ve5q1hhGkqyWzPyBPpkQsGMC74YrPrlU 1z1oClW0xso8X35q1njzjo+zAcSmtusPnUkX6kzywgn35KkXrnZbjSYCETN94ubulKk7B/YtgiHo oWumg6w1JJebJHbNKFz5RjUrHXu7OsgLtFWmo9MtvSfVbqmzrSwLLTkD2TMaFjGkcSlrpVfqotqO gldQ7T3zZSMl60hJnj1o593kbVmpImfYLp98MfcJkGXL8RNadqbuGFZ9LrCscd1ChiD5OlARk3Pn 8sJM7dMnCbv5s2hpFtmAcn1WOa20Xm2g0DDK4UD8eEBZZbsPr+xhrIoJ6uClIwWWBwmT3E/uuhyw ccj2KvdaUBnObGBJ9h60EsugxrL8B+l2aFkNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MTMgMCBvYmoN ClsgM1sgMjUwIDMzM10gIDExWyAzMzNdICAxNVsgMjUwXSAgMjBbIDUwMF0gIDMwWyAyNzhdICAz MlsgNTY0XSAgNDBbIDYxMSA1NTZdICA0NFsgMzMzXSAgNDlbIDcyMl0gIDU0WyA1NTZdICA2OFsg NDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzhdICA3OVsgMjc4IDc3OCA1MDAgNTAw IDUwMF0gIDg1WyAzMzMgMzg5IDI3OCA1MDBdICA5MlsgNTAwXSAgMTQ4WyA1NDldICAxNzdbIDUw MF0gIDE4MlsgMzMzXSBdIA0KZW5kb2JqDQo1MTQgMCBvYmoNClsgNTUwIDAgMCAwIDAgNTUwIDAg MCA1NTAgNTUwIDAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1 NTAgNTUwIDU1MCA1NTAgNTUwIDAgMCA1NTAgNTUwIDAgMCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1 MCA1NTAgMCA1NTAgMCAwIDAgNTUwIDU1MCA1NTAgNTUwIDAgNTUwIDU1MCA1NTAgNTUwIDAgNTUw IDAgNTUwIDAgNTUwIDAgNTUwIDAgMCAwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAg NTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1 NTAgNTUwIDU1MCA1NTBdIA0KZW5kb2JqDQo1MTUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggMjU3NjQvTGVuZ3RoMSA0NTgwND4+DQpzdHJlYW0NCnic3JsJeBRV9ujPreq9k/SS pLuTztJN0wlJCCEJSUgIpLKHsGTHTtgSCOuAoICKyDYYYcImozCojDKKuKF2wmIQRNSguOAyMCoz o4DLqDPGFR0Gk+7/uXU6IeAy6vfe93/f6+LUr+rWXc4999xzb3UHYABgxpMCHEU1o0vvaW39PcAf bgawzy4tKi6BOOElgE1HMVdMaWVFzbHM8/fg/Vm895TW1BUcKv3HCYDNwwE05RU1KWnzTt55CIA9 iM8bp89vWph1clkygHoHNjBo+nWLHf/++xcDAVx78H77zIWz5jt2xWHd+k4ArXFW06KFYAMX1u/F 8sZZ85bOPBm/sxBgUBHA+Btmz2hqfrfz4zSsfzA+z5yNCfpx7Am8b8b7gbPnL77h2pY5YQCCBkD5 +3kLpjet/uNW7Mt1h/F+w/ymGxbqPzO0Y/51mN9xddP8GbPGPXUdwE1laISyhQsWLfYnwnPY/q38 +cJrZyzsOLHiNEDYKYCQt4HbCmXJ1nkNUw2534AWm8HPofftgzifPv7bBt8XvnClXn035tOAAPTB Msove75kUxQzfV/4Jyr1ck39PwqeIhyDJlBCKYhY0ggp0IhWfVxul4GomCkcxqca5R3KdKwyhii+ Ds8KoNEKerVWEBSioNgJwucSOMb0Vj2uxuEAPBybSAf1JEFwANzDn4kXlHbeU2CKmTAehZSZKWu0 GqphAnTgkQJTYRvswZRjkAxTwA1rUVbDNKiAqzCvE/uqg9nw/Y/C/5b/LUiAkfJR7T/9A3lAboEO NPX3nm7jdsDWwB+E7bvg7kD6FDyu/Lj9GWCHtf7T2NLqQNo0PAA1rfiBlq/6QX0A5sN6aIGxwC0x Fq+3wPWwFc8j8LoMZSzsgx149zuwYt+deN72g7WY8ZwQOFqwb2PxuPIz83spYbIVwgLHFjxmY/sm 1ABb8S+TU+oCedcH5PJPmf8YRAfS9wXSduCxnqn8zaj3D31+9yO2KMNj2RVpy/BYekXaUjyy8ABm xZFW47kAjmNatf+P/Jn/AtTK+Wphp8yd6F/8Uw2xaMFf+GG7hLVso3x5Es6wlWw+ekY3dLPt8hEB 9+LxBFuCT6tRp5OQxRQshwssQs/gUsaewzFp8XfzA15ki/AwwoeypDINF9gOp2VZi9ruhAYol+fF MchGn52Ns8KJI7Ia0/is2IJzYirmnImepkO9NBAPLv8x/xS/E70S/Hm+L/BcjnnXo04JaNVm2YrV eCzDekKwrB1WYnosjkUB6paO6RF4mPAq4scs4Ufbcd3hDLwMh2X9uIY4q9Dik2Ay8LmjwVanon5N 2EY16hcv6+eBSkjFQ4f9WY16Z8AoTOdlK+U5A7JX75Fb+Qrz8U8Tihu4b0+D5XAC49RM/0WYAyvk 3EZsh/dgpTx/6nBeRKCNlmB92XjoIA/b34jn8Zj7ZeCeu0OudQvK9YEO5cnnFVhXGZYvlO/qIAVH C3Owh+F90GKKEY8itFkEWjIJR2YKXINzi9v8NLyIFkzA3vBjEdpwPabuQH3nYh/LAunLsMcbMH1P IJ1Huo/gQ/gUXkDPPQcX8O4c7OYHS4HPfsXT/p/xaI3ZaAfOFmxxJsi+hzyCOmhQ82XY12z04bU4 4+eifvKKgisBSRStGGwY3uGV6AAFs2HCcIzdCuBXwWhnN/Y6B8ewFEajxeswutXDRPSAG9F3H4W9 cNBhdBQ5FjpudKxwtDo2+f1yG8FYhxvbS8IInY8lx6GH9JZskku295Vc7LjJscqxAUsy/ze4Yt3M 5Ajqf+7SwQaxeBjgnw5t7AQ7dm78e03vBctH0HtBgXVvmHxOQx1//kdkjcIjrJ5NYZPYEmGGMFuY I8wVfiPME+YLVwsLhIVsouAV9oGKfSrn//J7ayzDVZVWZAF++sN6W6Rb4SE5cSVbhdf/RQc5P9eD fxS4XqtAjeOrlSNCUKB+I85oM4TiVThYcNz5+EUCH2Vga1BuDuRbAzejj9yCPrEOI0Ir+vEGnD2b YDPcijPm93Ab3C6vCX/AGHUH3Al3BWbT/7sf8acfC/f/otoUjG/AhslzIOxX+v+v8f1f4/f/F31e Kpk6ZfKkiQ31nrramuqqyorx48aOKR9dVlpSXFRYkC/ljRqZOyIne3hWZkbKkOTBg+LcA10DYm1h JqMhWK/TatQqJW4cGQwudpU0OrxxjV5FnKusLJnfu5owoalfQqPXgUkll+fxOhrlbI7Lc0qYc+YV OSXKKfXlZEZHLuQmD3YUuxzeE0UuRwdrqPLg9cYiV73D2yVfj5OvFXHyTTDeOJ1YwlFsm13k8LJG R7G35LrZrcWNRVhfm15X6CqcoUseDG06PV7q8co7yLWwjQ0axeQLYVBxThtum4N5s17RXdzU7K2s 8hQX2Z3OejkNCuW6vKpCr1quyzGH6wzrHW2Dj7Zu6DDCtMakoGZXc9Mkj1dswkKtYnFr61qvKcmb 4CryJtz4gQ27PMM72FVU7E1yYWVjqvsaYF6l2+hytH4DqLyr69PLU5oCKSq38Rvgl7yLfWbC573X gLqhhtg/p5Prsr5Dgml4411V5aF7B0yzt4OUklTvFRr5k6O9T8Lr+JNVvU/6ije6nHyoihsD/66b bfOumuZIHozWl/+58R8+d3jFuMZp02dzNs1odRUVkd1qPV6pCC+kpkBfi9uGpmD+pkbsxBxuhiqP N8W10BvmKqAMmODgYzCnxiMXCRTzhhV68R0yUMqbUlzE9XIUtzYWkYK8LleV5yCk+8+2DXPY96bj JKvnengthTgoccWtnuaZ3thGezP650yHx+70SvVovnqXZ0Y9HyWX0ZtwFptzyi3KpbBvV+Tuzcx7 rnZrHB7BLtbz0cIERwmeXAW5+MCIwyXf8hEtyHV4mB16s2ErgRz86rJ68EZ0F5bxRyIvWlhmd9Y7 6fMTKtkDOindXk2/uoyY0KcTtfOjqlFurlCCo3hGUT8FL6tUGVAwUNsP6ylwWwQaxhIaPpxlvY9E N85cTBOwGjmJj6LN4YVKh8c1w1XvQh+SKj28b9zW8viOqXGNqWrwyKMd8JLay+7o+fC+Z4Err1CI DliSZO8dU/m+VL7vuy274vHo3seOVo1rTE0rr9kVqBAcOH2wx6q40U3rh5uH4bwswdDmKmly4bJQ 0trU4V81rbVNkloXFjfOzuF1uEY3t7pqPLl2WbVqz3L7jbwpM4xhY2oLkgdj4Cloc7F1VW0SW1fT 4DloxFVoXa2nXWBCYWNBfdtAfOY56ACQ5FSBp/JEfuPgN7ymarzRyPntByWAVfJThZwg30/vYCCn aXrTGEzvECjN2JsmYJqC0iQ5jX9whGyz0b4Ya4sdzXxsbqqf3dpYz2cWWHAc8R/zMtco8AquUW1M UAV5da4ZBV69q4Cn5/H0PEpX8XQ1egWzMDQOD0itjS4MUuhNHrAz8kORV+no8PtrPc4T9q56J/rZ JJQGj1ebhIFf6S7HfKVcGjG51LtqehPXA+o8vKzaPXp6Pfpsb4WYZbRXizVoAzVgjhK5DPdFLDQd xwYHUC6/Cm+8q+q99Um8Uc+cetmXjV4oc+XgsFOdyjjeUEp9q9mVJk9MnAc691oOLeoGNR5KseMt NlZPRlIHoebTXfhoeqMDra2A6TXo5xRIdXZKmYHxUBE3QxadPfAQeLdEtz5Y59UOwQrxH7/WD+Hz UelW19eT8vLd2kAGbNvo1aNGcf1MGSiA1sFHo7ku+G8tqsqzPsOrqeqAatcNGFa40nJNanzsDXaP bsLIT+X1mOIa3ltYwwOEPlBHJ6Wqec+D0O6iu7bD/4BrqbPfJ3mwi68M3DHBfhAdG+pbr0zwTkxK Hqy5MjVYTm5t1QT/cAGylya4j5goXae9luXHLhBTYq8W8mPnJM+um5U8s25GcnPd9ORpdU1pjXWx jSmNwtS0KXWbG1hlA/u8gRkbhjY0NogTkuvqjtaxVXWv1wm1yTV1r9Uwbw3bXMOMNQtrBGQjZ3Vy VV1lckVdYwWLrWBFyYV1Bcn5dR3CmHaHK7ZDKCeMJpS1x8YhSgklhOL2mAREEaGQUEDIJ0iEPMIo wkhCLmEEIYeQTRhOyCJkEjIIwwjphDRCKmEoIYUwpD06FZFMGExIIiQSEgiDCPGEOIKbMJDgIgwg OAkOQiwhhhBNiGqPykDYCZGECIKNYCVYCOGEMEIowUwwEYwEAyGEEEwIIugJOoKWoCGoCSqCkqAg iASBwAggg/kJPkIPoZvwHeEi4T+EC4R/E74lfEM4T/ia8BXhS8IXhM8JnxG6CJ8S/kX4J+ETwseE jwj/IHxI+IDwfrt9BOI9wjnCWcIZwruEdwh/J/yN8FfCacLbhLcIbxL+QjhFOEn4M+ENwuuE1wiv Ek4QXiG8THiJ8CLhOOEFwvOEY4ROwnOEZwnPEI4SniYcITxFOEw4RHiScJDQQXiCcICwn7CPsJfQ TmgjeAmPt0cWIh4jPErYQ3iE8DDhIcKDhAcIuwn3E3YR7iPcS/gTYSfhHsLdhD8SdhDuItxJuIOw nfAHwjbCVsLthNsIv2+PKEJsIdxK2EzYRNhI2EBYT2gl/I6wjrCWcAuhhXAzYU17RDbit3S3ut3G sYqwkrCCsJxwE2EZ4UbCUsINhOvbrWMR1xGWEBYTFhGuJVxDWEhYQLiaMJ8wj/AbwlzCHMJswizC TMIMQjNhOmEaoand0oBoJEwlTCFMJkwiTCQ0EOoJHsJVhAmEOkJte/h0RA2hmlBFqGwPw+WMVRDG E8a1h7oRY9vNSYgxhHLCaEIZoZRQQigmFBEK200Y9VkBIZ8gtRtzEXmEUYSRhFzCCEIOIZswnJBF yCRkEIYR0glphFTCUEIKYQghmTCYkERIJCQQBhHiCXEEN2EgwUUYQHASHIRYQgwhmhBFsBMiCREE G8FKsBDCCWGEUIKZYCIYCQZCCCGYEETQE3TthhKElqAhqAkqgpKgIIgEgcAIIPmRXHwoPSjdKN+h XET5D8oFlH+jfIvyDcp5lK9RvkL5EuULlM9RPkPpQvkU5V8o/0T5BOVjlI9Q/oHyIcoHKO+jvIdy DuUsyhmUd1HeQfk7yt9Q/opyGuVtlLdQ3kT5C8oplJMof0Z5A+X1kIrY11BeRTmB8grKyygvobyI chzlBZTnUY6hdKI8h/IsyjMo0vtHQ/Jjn0Y5gndPoRxGOYTyJMpBlA6UJ1AOoOxH2YeyF6UdpS14 UqwX5XGUx1AeRdmD8gjKwygPoTyI8gDKbpT7UXah3IdyL8qfUHai3INyN8ofUXYEzY29C+VOlDtQ tqP8AWUbylaU21FuQ/k9yhaUW1E261NiN+mXxm5E2aCfFQvRzBAdG705WvRGHY0SOvxHpYao5KEl sVEpUYIhKjZqc9Q9UY9HKVfa2Rn753ZBsttjSyS72YInXXCJFJk6DE/xiXiyO/FktuJJF1JSETE1 Qqi0NdoEsHltR21io22hjVd/wJZTUDLUynhLoVasx2s5ahHAbDQvNK8yK3SYvtcc4yzhz01ma2SJ wzjUKBlFMN5qFEL4U2Nahvw0z5iQXGIwxBqECsNUwwKD36AwGO4xPG54Gi8kQ2ZOiSEkNkTI5+en Q14LOROizAupCJkaIm4OuSdEEA8z+bd8YOzWttqapKQxHWp/9RivpnKil63zumv4Wapq8KrW4dtZ w0RPG2Ob6vFFuLDWa+LfKsj3LRs3QnTBGG90jadd3LkzuqB+jHcVv5Yk+drPrwGz1C9avGTKoqQp iCR+5ie2KGlxEiYsSgp88HJx0uJFiyHp/4cP+99W4H/xgyO4aBGXxfjBMZavkvoG2jYFQD1PzPJN uuJXgqthBWyBh+BpOMdC2XA2h62FtXA7HIJn4Xk4De+Dn4WxMtbY97vSr/4o7WAB8P/TN9fX4k9Q fuX70DdJZfWrlG8pPxQv0DNlC4T6Fvk/wTyn/QmK13yT/KCa6U/wfyFkg6m3BsUysPA05Vxli7Jd eVIc6wvnLajv/m86/MBnCsyBBVAGa/r9WrYRboAbYTneL8dU/mvZVvl3srvgPtgFm+BO+de0Tfhk B57p17N1mGM3PIi2fBj2wKPwGByADngSLXkYnoJn0J47Mf0xzPEI3IPXPO/Dcsrj4IV22Av7sMQT cv4jOB5Hscxz0AnH4AV4EV6Cl+EVOAGvwmtY52H52TEcoRcue7JPbvNgX6u99TzbV9PxK+p6Hd6A k/AXeBPegrdxvP8Kf4O/wzvwLpyBs3AOx/9D+Ad8DP+Ez+AL+BK+hvNyiVNYhkqck3N8GqjpVKCu K2t6H7rQv8woSSwDJZ1lobdlszwmsdlsOVvL1sFKtPV6PG6HP8JmtPntaN178bwTr+9Hez2A9iKr PYL22oVW67VfG973WnE/2oD3/RD2mXp/ULYXt8ELaDFuB24B6n+nbMVL9nip7+oN+LNsmcvtQ33q tdolm72DPfwA/oV26EJLvSnnPCPb7yO03qd4f8miH8gW+wg+Qav2luC2/Qqt+65c6r1ALl62f67P 5Xzn4Vv4N1yEbvDhkiIwBVMyDZbFO3z2jfz0AvwHc3yHeXrAh3OY5xPlnCqmYVqmC7T3U/l7c4cw AzMykzx6LqZjQSxYvrawSGZnTuZm8aySjWSpLBNHdDQrZyk4xll4ncNGySNcwApZESvFJ+NZFatm 1+CYL2SL2RLWAgr+9xyKCJzbIqjBAcNg0mFwsqchCYJZwz6jUROpPsKuAgHC2BzQADCPZFMIkW12 VcjQoXHGu4KDFaodYn6cYgcrhLyeV/O6TNnGLnN2yqvGd7tYyjtd73YZe543Zad0nepKHcpMTpMs YSGCS+0S09MyM4YNEVyujPS0GEHkqQOGCBnDRgn8XhHRnSFm90wQGuJHz8lXtQYtG10QnddUmJ11 7f1z0i6YYuItlkExJlPMIIslPgYD1MUPlfbv5ipM330uPJU1qTCuhQkFQ2KHJ9j+kFo5u2eXJS7a aIyOw8xRJlNUPP9rAgX2fhr2Xg06uIMv93UeKUnH/wJQrRVEjahwqJQaTZBep31XYpqhGqUgiCpl vloNICoUYiHY8tJTTOkp6Sl56dhpc/bw9MhxXWkmM8uOSElPj7SdSFu+trOTBZg61C7ZfmFdqUPr naJTdOFYM2R1mW94+Xm2hnnYmp4X9rAJTPD5eNcVST07cRRXB8bTDLGQCMupT22RiYfY1xhvQ5l/ vw6USjB0CCrJ4gZd5F8ggdnEhASI+CvLT3xXAq4INpzHR3HqlMld2SzlFI4qKoRDKXch7OeUQr3T Tc40SziOqjpGDA9TuELlsTalp40SRJSMYXF4t5rtPnPGOrQsNbW+MN53vucvtoyaEVu35tZkWDtH 1OfGrlxzh9K+4+7UyeNzTZqUMTPzjr8oHnDnJlp9u6PTC3qyYzLKEuoafWtxf1ft/0z8VJkMblhK /cZXXPsRIRqH08wGQihY8MUquADwZe0AuFmw6Hbw1zBJLJKV73mTK57X8yY6btcp3tPDv7Ac9tmt UpEPmzMzuRNbw+PiXANChPCwGIF3PEv89Kr7PBtPbx1Xu+PM+uSKseMT6+7Mm3xz3aCECbdMco6r GOdMdw2o2fX1n+5nrG2yQm8OOT9oQOHSB5rnPrB4ZHB4tIH77QQc5VQc5SD+d1bU18OYroRgnKjf SDpV6Pvq/LD3JVXfsDCagXZJ+71HqLU8IZ04XDGCsneQMhWpY+658KhvH1uz7dy2Mb4LA6rWzVg+ b/9h4e7tFx6fqrSP2fHFgbm7F+V2r36b/+VNB/rxy6iTHq4njZ5A1xbR27Qd7D9SECjPggZ9RqMB BX9fZflaju97Dkvp6TS+04l3XF39zy1G/hbuDEiHGNrzkYDhVMDZ8Lrv0Mu+ra/3ankYtdRCHWm5 XxA0KoZ1/+eAip1RKFQ4zPp9kjpfNhBvAhsgpTpllfb/eC5uSbl9F55ZO/vMZ76Ic3uMb9tLPZ+g Gth+iv8ThU6ZCvGwJjA3w4QO9uf98YxFxUcdEhRoP4z0kjYszMrOxserrPJXBAVODklV1K/XfFLy ce1EYpBF1Q7+oqJc2wyn6TKHtXzPX01CNnujoXPRutPbq+ru69re8Ehd+d6JkzZOTY2ru6XROiDG bhASXu4pTRxUu/vbe+9jwt4psZFfu5Kl6/bMm/3AklGiSqNk47Hn2/jfPMv+UROwvKjSMa2Se4dB pwsKVurOagoVeoyO+aRqWh6F0pSeU51GeUKiO/xQJuxJaEZg7LFH28Qc31nm6H6eORTVL77YvfTl l0UeH5Jx1mTLsfG+QKx3BqnVeqMgmPR46MCs1SkVISGhYeZCU75C5RAd+BL6umQMEVVqQalXKnXG IH2+Th7ydDlIW7OHDx+enpfXG/FtnWmdaabs7BSM5HRwrXW/uD456otq0SXGi6Ir1BlqzcITvlhr 87bcuSZLbXlDYpZFWVlLmT1feJ/FH/cVsqeO+870WJV238Y3jrGVFz/EHuObh8KIPQ6GKdTjvWoB gjrYs/u0uPyg0z8rhUhKQauG4MKgfLVKyVVJwfZRGYz73LwpxlNdgW4E/UhGriyLN3GvZ1YTdlr4 wHdv2Vk2hM3IOysGPdjznm+u0t79+R1CPpuDegngxlmQj7PAgKvUONLsaYxf/I/nbXjWoB9bMeLa +ZdlkrLoyiB28Eeey5FMQId2gEn2ZwewYQF3tnBvVuTXbHlugc/n6+bk2yxf902bSpvzY5ZvLJ0h xQi3tft8uyvZVay0nQm7K30P+/Z8/MGIax+YJ59R87VoUTNaNATsvX7cprIcYv/muyMBpBCDxnJO pdKEn5O0+ZrLQ8ip3gU06Eey9EZiFzdl/1iMmpuLbjl+8/ILbOXK51qKfT5n4cyS1b+TphW6xGUz H11R4puktGfNvWvJsLpch8/pKpiEyvC9QAbqaoUBsJJ0PRBuFQQVhHQIsNemjlZ14GphUVsLQ2PC BbXi7ZgYddR7kiZfXSjH1z7F0KNN2XlyEDwlx5s02SHCf2ZB2Zvj4vr6Je8JLBZrKJO3APKGIKwj cnJeyrds+TzvTYWJY+eMGlo56A3fvTfeOK85e3LBQLYrd2TP+0q7e0Jrc9nCqjSdrr7WVy7e2Vjr 22wbWoq+Ps3/idiNPpUNWwK+Hh8fBYdw+Q+FVEHdro2Ke5JFQrz/6L4Qc1n84A4WvD81VOks0Bxi LlwPQlhony/hWp6Hjt3zZhIO2/Nd8v4HO3wI4n5FDb2jOiAuPiNGTJd3PkNUvbtca/gQMRBwVWJ3 xabOxbOOThnSPKM5pWTaqKishkXXL2rIGn7D4Zb4uppxDsfYqmp3fkNOZNbERUsXTcxi639z96w0 W9TXxqjwIFtijmtoftqgITkTrq8d1zprpFpv0JwLCjNowt2ZzoQRKQkpuROW8FWwAj3DKu97CwI+ rGYd7DspWIGroRbE9yRlvtDrmRSDn5dXmCeufCYveTiqGH6Ftm7fneJxxfjv2hXjT5zg7VyF89yA 7UT026Wwb9Ahg/kuRReRr883n700gfMu7VK+96jPirhWYYgJLE94qTAULt+3cMW+hWnfWrMn5I+s HR71LTu3/KkVknTDnt+I07v3FMwsHRhbPG+cWM51cmLfS+RVYHdgFbArdToVMxhAxf/o12TWqIOD RDE0LFiU9E/6P4YQjNmhOkOIXlQGBanMJo06X8lAXvnT09O5oKtT5P7JdWDvr6iQTx2nGK/GrX86 XwToJHb7zqxOSV7p+9fo07GaEbfetT1V4XyD3bbrQd81GGmf/PAV9oYv9LFXxMm8xzrscQP2WAcN 1OODoBQc7QpRy38H16lBXoIlUdQH6fK1+WoMkzTA5mxa2XAh6Ml+p8v4jjw2uu9nCngBo3VKePSi 7ypmOurxvIjvsK/5UtkJcbxv3vOvsE0YlebjPD2tCIGBkAq3BWZqZKTe1SHo95qYO6lDsEqxers/ MtJqfAW333HGOEGD0SNmYJX1fEzlkB5JVd0b8PNo84evJoG90Km0zq7AzjHm11TBzR0fIva9hqbL 76cDVOoM2s6Hm8S+5SQzS9SoHCW100eMv64yYeTyQytaLKnjsxserx799Kxr7p2Tdn7rqAmZEZXF 6VcXtAzITrQOqV5cUnajJ21kfN5gW4L7uei4pAmrJ/SUs2dsiVmxo/LLi/kSst7/mSKafxeHFupd YfTRhwS9vMJY28M0ER0sVdIaKrU1jm5J2duTvH4rzEGI+OEs/WIROqWaOqUM9NFkoUUyumLj0WsW PH3VeV3WbbMaNkxN84MtOT9x1DV50XWDc6YWDhRCNryyNt8ZpWzw7TteOqGs5alVtdeNdTVP8BXp Q4Z6VqLPteC72DMKDbj63sVcpohDgh07YWTSAYOJGUVTGP8JL7gSDrEszBjDhuE7VXVf+KT3Kj6o tLf9ZeX6v4vxSPv9na34TNmdtUuP3lI6bsOxpdPXZo7akl80rzw+cdy8AkdpaXFMfHRUwW+Prrjx +Q1jw41dsQOGVC8pGb24KklrsgTjOI1FP34Hx8mCe/npvfPKgk4cyhxW7sTB+kEs3FIVXuPqNlZG cZX7ux36HTO+KTusvLH96axX+iV2B8ePyV3JzDJRz0SdylE0vj6TD1nFhqPXxI2LOd+zwJpckDhq IQ5d0ogphQO3xUvJEWUtR5ZsOLE2X6dhGy8uY+drr8fBu4odpsHDvs3EuA04Rx2QALMCczQoyAr8 j3CcCQqEZLY6TygUiXFfR1UG+4K0fsl8aQQC+52utHcCC6dk+i+ZZb9UqZ2BDoX372qMoM4kB1WA KPY0J4yZI5U/NDF+UuO0IYs7VhUV3dQ2f97uhTkXmCNrdOKk6/RCeUSlq3Bm8UBr5LP4/qwuWH1k +U0vb6kovGG3lFufE7VsYeB/kijsyu24j4vq81GjNrhDCJbMBnwXMBiiY8zai4bQoCBbCO40Ga59 PZKtNqSK1j7U3YSqZ6cHFsjOU6/i5Ouk/f7PK8d7HXDK8MBrY4azd3yZwj54aV5SeWYs2+y75lvf aRaft+je5oLr07/7UHEgJNSaNi5r15Eej/DgkTvn3TV9iCnIt5z/P42xvkkKtyIIRkIlNMI/AqM3 VJ9e38He2iuOjAg5xB6DJKhib0ra9EHpSXi4cGqGQgmMEkzSYFdT7XGNOfzr8rHl+qGiOHxQuUET qxEMoqZcUz68aeRruRWTXhpemf+SFDOhz0d5n3C1kyMpvsWY0o1dacYu2cO7aB3MNnbh8eabXfIb g11K/D/WCjejRf6iicc1lYrPcKuVf+d06QvFrLi4fuD2xTd0eingIT4eJ1do7y1NppYo64jfbG3I aLCabMbYJPuXVWumpEurj65c1nZNpnlgpjs13RwdF+5OHTlvqye5ZgBr7HFeP694am5kRPJI91vR 7nB1wtS65MLBFjqLJa5xg+p+60kODzElRBodEUamFdxFTaNKV0zOjC9pynHlZg2LjPKkDRiRmWZz z6moa5mYotW3d6ePGB6ZODzG7o4IFhRhA10DRXvV1Ji0goF1U2PSizDWrsdh55HICvW964WK1gsM RwdAY60K0ogYVA5IJlwQNFWXNuh5l5aMfT+Ri0cf0zB5iXDxZWOUSGuh8MlNuCicPx8UK5VPGDZ+ 8fh4YdsDzRN6litbfLs63CMGhadPXlPVMwFn2xbU8SvlY7iqRfe+ixwGnZCLs9CGTmeOjgqPjoiI Do9SxMTaoi/aqwwdbIwUbFDGKgWbqAy7KFkqyA3elb9tkyedFX0hJcXYI+8Z9/+8Yv33kYHwwviX BvJXB8I5W1LOgAEjkmy2pBEDBuQk2Xxf+c4JEczdfQ8rUIY4c5IiIpJynM6cwRERg3N8+iPdzx85 wqPJ9b5J4lrsXzhGzA29/XNg/ywQjtFSawoNNWmNiUo36WePtaN+dvPFsApNBxu1Xxvil5QTLsVE WVt0dnz7yO7t4N5fXpwvgv1fPTIzeIQJvaL/4qLC5Y/P82xPjSodVxm/4GpftPC3sF4D9Bok+tqH FmTFhJ81RFuDV90kxh5hliusgZ64FWNqHnqiDuYE9tZBWpVGrQb+o4eK4RZPMksi6Ko0FeoKFRMV NWIVkKfhxM7jLwB8r9nJN8wYIwPfOxh+PL/81YPslPL34+D73fnzbDpL9TWzI6zbp1C2dB9jj/lS e95C7cgHW/BNrYK02ycIWvR59D+DSqvV6RXai+oquCgJNb0Rh0L7iZ7OwDqm+4Es3KP6PIidvOQv iheOfJeN7sH4/9tWJGFMToRlgRkaYeF//xfm1B5iD4AeEtiDUgTo9UmDE6tU3XGVpm4ppjLCabFW WKr0lzpMUVDWic/btFNdsoHCfkYhmsOBjZ6r31W6lU9nC51xf+tRBFnDYnPj3lAE2cIipfiT+xWW wWnZA+vqVbaU9BEDF8wV9sVlx4XWzuiZf+lKvHB7spRgrq/g57u298T3xiXcRVhg4hVxKVzQ7wON pUqUd7KSsVKv0VZQyDGTwnJg4ra1t/9Utssjk/WKwHRSFVs4vmF4v8AkXuAbIFsgLOG8LcOdTgzq GIobyX7fRIVDGPwPe18eH2WR5l/1vv32ne5O3510ut9Op9O5O0kn6STk6ISQhJCLQDgUQ5rcmIt0 AiIquIjH4MWoCHiBOq66XgkBwzE4KgPrzqDLOuiwjvfgMZwyO44fJG9+VfW+nXQCju7s/PPbz1qm u97qt6qeeuo5vvVUvS9W9CkHJpg5oq4nZ86mgHRYJOrqv1/FykimR6JsZRv2r1k1clPpnFv3Dw2M 3FTCrRn0X5MfvaGv8JpcKyW64ei9taUbf71x7ZG7a2bf9ubtjz+RuXiw9IldGYtXk1UCFxTFEN66 QwhtJELKYvbK8TJhj0mO8CeGkn6Ftl5RJ290hi8EinnjQow/vzT9sZvDVw5TrL7q0iG+2h5i/Q+v HuRSLshsIrNx5foBoWsuiGRHCczIngZC6NqE0LUROiwYXcuVVLKp3nU5st6G6B71SxpAoxCUIIs6 sofj5YMJf/tOsnj1TUecJt9McE19rbAWz1vixSMq3Xh4o6WgwGd4dia85oKw9ogzP8mEIfbat+6v E8siJK5LHfStMzA2xG93EEWiGTSBPkE7ImQHqEgscpRyBMixYR+J+DdmDEr8cr+23mSSo5kRhN+D qb9p3Hx2Sk/2AelPqYBHmzND+ZFw0hZK7Ui35wTnXPpQZimuacqtWTPfTVM9efVZ5qXtWHMedBel mrM7H+vA1D+KVj/HEfUZ4BFB+mIt4AAVB9QggbKOSC2OMUj5NSBWE0tp6VjXxQQ1Y6uX7of5QDbx K79MFVkpU/41JGQ4TMaHy/gl32GCGsmgHH93M+FxNyyeZK/ZnUZPWw/yYNFG08dr1u9a2D9a33Rg QfNyva91/rxVVa7cvmf6mh/MW7x93rxrtdnLa5fcMJeFyYvX1TgN+j+4nYUZpniny2TIrlzuL+pd kK5XHrWactJNcbEuoyWvchm2/JhPTCGwhLR0NNIiU2uxzzEpZXKUoqJl2ksqpboOTFiME+ELWe8x 3v8glKM5PB7aAlH/rdvDVr3Y00f6yHaUEK04Xnp7QeuW5anceRh5CW7mhuqbCgY8crU2adGmZfDC ISgq4Q4c4mIXL9VH4Dm+C9H+Af1dGK5UyrGBkQCIFdFUJ+LtcmQDGsl8Wd00832W900jf+suonk8 cciDO0ML3Eh4c1FxIbHfbGnNtb7aoVo3/d34ygWNbYuojZelZA3rbdo4n3oeUWlCetSAqJSCAQFz 6CRSmmIhYBiZPIKJYSi1iMH7LnIGSiU0VQcgVgohzpaLRCV8v/4Y1qVXf1I1EpsLxbze5L7keqDm 3eKiE1CMqP3V/hGqEpC3CQHRMkSfFrwi0Gf5oXijbGxi5widLt8/8Xugnvg9XofSMpEQIqzDIcL5 V4YIfyToOPz3tvoDkcdj3DfdDkcnd+H+r+ZGJrbv7/HoCj+Epf1B7nU06jceuwdmc8e27MLIno+1 VqKxK8CvhbHHixm5jHI2yERS2tkglcoYlGigkFA0C6EyQi6JQlnJ2MQFfxSAGkipGchCkVwiUsik YqZOoaAALdDrIQSbyFzkLhdmEc+h5QT6EBihSb7jMP6LhJgbe/8H7fN7cghmOnQ6DDYtX32NFuU3 cw/DxD9+CrXck3AVXMQ9TwH4HTcCazn5OId5YELrcSyfUWCbwIMIS5RBz+qk0GSKthrHJj7x64wm vU6HCImmmagoi0FfJ1Ph89uToP4IJgV54UhvrteDLFyuMOfmw94oQWb3AePf1RI2GVjxJncnfCGR Ppcd/NlzXZZZdqU91qlOqizM1E2JeN9tRzfNZph3KAbpWl6dZ1Lk+Z3e42jEMrBSGLFcSiFJxwAd Hpj4BN0igTl7ZPPFrJgiwS6RsEjLzEV4OhfZf6/Hq/kw8wg5gwF/vAbe/M/GINwAHYat8BsumnZz UfDc89TNx18Y3/w+ngekjCIXsw3JZNWwQo3DPHqzXq8FEU6jNtasvKSSG402LXJb0C8HzLhtoV5z STsfoOaLw0I2UPPREfQ/ujqMl81Q2LwxTO0+h4VwRC5DblGxNa0m1w63cx0w9fLbUM0dhx4SyLnV KxqVRMjEfCCHMx46BP8khHJUmF6ETMsQvW6wdK/bzdoSY1jsNeR6uUSKUkKiDpNq0pvGNXLbJdaq cUiltGYhGHfHfY+8QjG/A+XJ02KyNWQIgiv5LfIlb5MFDfEV8dnhNBvCA1KC41iV2pX9ixe5/4LK qg0vts7f4k3ZXJu2eHYiHOMqi0riGxNFCs0rT8PreeoNql+rLMKgXmiqVaswXl2HfMkZsv53g4p9 wEYVjuilCjSgPToJGosTr2sNagucsECLQkxLv5fXgXGdZnIkOGr00XWrzvKhtvHDGH2HUR8pgLWZ oJs+k7oy6+Awd5TyalyzkhCp3McWvKLll67kGxE//BS8/Nr4Mk9Jok6tEs2dubBF9K9F9J8j9HtB 3T4gR/QDZzKeEI03KiorO27cyV5yRye7TSQCoWb8Znsl467Xj3vTvzcJg/gomQSwQpMRGscV8Qhh XOFbD2hlJgyRenfmAGA0GaTGlZ/kbkxAc3VgWBjsFRGLSyfIYDv4kb6uUA8/xe3gL/AofUIUwwl8 oHHUalXo0g4gSx6HflPv0SkUuXlePDptIh5dIhszbrVc0usYtl6OwOqoQjWBrEzx5NbnWQ0ZMBro e+O/IxqE5kwYKw/J8Abe9FFeGZuo2jTWl7JsUbW1+JkO37KSOItviT//1oK8u0q/+eyKKIV33fCg T6rWKz+JzXTMbi2jFhbWp+vJSPcdoAaviFhAE5nXTcAAEobl1Bil9KsNBqNJcUkumaCgpgEuABiu hGbsLNZ5b+SMMDU0/SXGV++de0+2cXb9kqSBJzvTmU2XddmLimNjtIdkOrXM379tCdJpXop2ADvI GlabsPQY7WIx69CMq5XfS0y0Dqmv3RqmvnlhojIl8FcXDPrcD4kBkXDqYmjS0cW4Sph0iN/tJtKL 8Pu4Fr4ql0stmgidFFH2qioCpahotAwp3K37jdGCN1vwm20kfoWxXvO9tk4lv6Tk7SM5/HaTBq0u QjYGWZwjfMxECHBLiHVEIC/bYeIPGon0adfE5a1orI6D6vHisf3wAcm81+5w1rhot1Id4y1P5GYd OkSte23rgqViKaJzJ+qcI+ulWcNqObYcJqXSbJFj+tS/0ZoOQPx2PAZK9mjrVXWYsuJpZKFFReak webXPsIRPZqzl80pic4PIFounRQjKmwlxflGWq40qKWYEhI3QGTIVTJAzhl+TTiWCqpHU1Otehdm l1UpFqd5IqIxm6zAjtikdUn0NG2ul1+KrAfjqUlTtqwYgQpyzJB4FUTXNGOM4wShyTX5pp3KkkzO dTma34PD/jn6GLEyWbfpF06GZ16Ip+EzDzuaainqEEUtXSzCzDwp8Pf4pAy8y+2kLsIhEA2MeA+r ag9QRoIj0QDJOz7/kJFuMpI4uSikliS0/m5BZ01KZFRMVKQxqdCdUZtjLbvzN3e+TmndBYkxiQ67 M5W1z0qzpta05Fz39I0VgILrJ76mvhRRxAs4hxkLfrhe7dTjpxFtDWgma4ZBHSgm8RXevYa6EiyC bsY15Y0vTbda00vj40syrNaMkvgZ1yLKmlHqChW6SjOs43Uoh0rwz7gk3YqsQA+i6yJchY96HgQM NQ+tYgGsH5ajCcOhnisJoVKTKrNttuzKpITyLJstqxyusmdXJiZUZNvt2RUJiZXZdiwpl+EovZK6 B9AgcoQC1D6iQnhr7FhGOj6xdpnqhaMnT05MgMuUj15JaygJxO/G3Ih4tQ3R9A6yTDSSeOdBQFHJ KCujckd0+LTi3N2qBgrbpvG3oYfEh6ETIfWZZD563AWj72XzkiyWpDwWfZvNSXlwK33++0dRxuHg C8g3wUgTifQF0qcZgSCaghS9AMClAK96ENH41A/jhF6YfZbaf+598TJUB2qIz3gXsSx6RC1TjsHP 90oBLe0ByBWgdaDXS87SwniKHMnymcSIQq2J+vbPf67cuKd785uHD7/JLXsb/h5qtkH1uePXbn6Z W/nJ59x1LyJ6TqG2ryFtW/cBJfzEL0NNq2XSRaCHNH74d5mZeOhGbSQ+9yVx52izsyg3HPrLhcpb R7vvPoz+Y979Lefmzm/jLl44fs3ml+G2Tz6DT78EJiYQ5W/Qd4jzKDFcD9rRHJxC19eQ6w2gHY0s gwvSxcwIWu/aRmh84vOEX8YwlySNoktUtyCmZz88TM61E/gHMygV9y5M5YKS4kOXCg+hNqSoDb3Q BhSJSRs0fYnppi6Bxmlt8NAxEkphMneCUnLBQ8ybh757HdGZwZ2ki8VmRNdGTCdq8yStJ9e3ITpp kI3sUQaTgaTXDpLBXcJa3QzwOwHYOD3+kqc4D8BkYAYmmOjXxunZODNKTPRpdYv7tJ9pmzobiqw3 hihn+c07IcJ8EDj/u7WvEgFl8MFU3pAxWfHZUIgZZpTf8cbN3Xtvq6q4/fBN3Xs3Vl2+RME/OYO1 uc0ViZSG4izsYE1uoCKBemAX9/Ky6qe4YfL9JLdX79TCFS3L81aP3BLp1HA7A035Q7unccQNZoGC PWpGzSRkHoCngQ3o4endCbYCZG3m+BUAWFLPO1t85y1tZDLIxrXmPRxTI+vHKzWfmTko4oynjhVQ Xnsu1rZcO+vDyuWjbOV3vHkTP743b8bjmwCxpU0FudeVuch302wXnWhJzgtVYO15yZatM4a6f93u YK5vcHjtupHB3NzgMEZr4aOMxSerTgM9sMHTfpnccl7d4jzPtIUk7GowcybleCJ+jNArpuBKuiAI Yk/NOIE8FJEZliEU8ZVfRzFATFEKJXOalohEQLJCSuFHs/2gNXSWlzz4wLtr74dHNOPHSMTrJ9ch 60BHJON24bPg22AN91E9fOIYtJ+kK3ce/eD7vScxfevI+5MzABuKvO5Dq8vzu81mu22M8oxqgAPa xmCKXxZDSWgd26pWkh51LaEVNHLfeCX43pGzx8jZhejhn1KBX6QW0aEjRW7hSBE+DClxGG6F2Yu7 8rTmtPLUmttm3dp44qbmR/sKk+qH5h2i3KPox1taFqa6ZmfEzM59pm55RvP9TbV3bNhQsedTvNMy cYacfcwF+0MjYuHX/oiMrKiM+KiMjKh4WoHMwRm/VafIc5+Pd55PyYo6pQMW1pJuoc20xcKktCCN cPsVCr/OValQnQ+ptRBTxXvueWfJ0gXiTfxIsveK8IuGhNgt/9NGw8zF5NIg9GiQsCePMJGwv6MX S2w0fbnyoc+2x86rKrcWP9a44IZaV3zt2gVbNtV2FEZ19tRum5/a0LAwtfupvtyeFcXtc93wvsAj Pfk0I2F+p1Rbs2szksszovfbsyrc9QtslmNqvUqc1njjvDUPuOUZNa1Yv9wIGc8i5+YiQK8gyUAy Bkf8SiUjphUKGSOSMhFjyCgq/ACtWmkoXgFbhYA7Wndj8cxELhBJidcb6eW3s368xuSZSuiI9Bog dNBD58Z3Qg7WH+HquLvhIJRz30L5cdp/+cj7tGt8hMTjz6CVRTTyAKtDEmCBw3sMZoMZz/w5vyxS wRpOR0Uh0AXTRowr0MQk7FGoLkxNyZT5e483fmRX/SfVuWL2cvCM8c9ikFXcuSWP/u4me3llWUze gzVbH/v5UxOAujh+sal17+YF8Mmup/rzRWIZc0IVGWxf2UG9+gX3bdzSbXgOViAbZyHj8oZO6Qyb k8fg2VGpRiNFI/vTblaalTQGXf5Is+usURMdzUR+o1nhOT/NL2EL8SFv2fHTEsKGSdJPqjU5OIRg ikRer4EgceHsnEQwopKQEbVUrn+l69TFqMKOHf+x+aGXun++LE1CZW2au3Ln9dmc2VvnY4tnZRus eY256bU+G3y8ZVewCLIwofvNX9x+nfedlIbVVWYL6+t8sCutxmdXaI3Kts1L3Oys+dhyrUSW61vE DTEoEZ6xoSAQ0wAHxTyjftEKYhWJWYQezzHEe2ycrvKrELrGAbOvuTOUdPwe+m6R58wJ5DvJ2S/y hIoPzAUbQmcZUuFu4AReuMcvtwC9xYmSmjkAvwBzQCH8wq9TV80pLMxNSBXJ07+wtfi/9MunGIlP 6oQdBZpECNH+yL9dCbN+xjme0P4Nbzjd2JyGtnEkKtowdaSHVuInyirX/0tL73PBWe6ypZmpdQVO X88v+tp39uTF5tefjStOs7Y3N7XHFsxn3HO8ttWBlNpZsfGlS6jR6JLG68uW3rkszbPoxnmzuxaV xUQV1TYXVtzclJNc3ze7qHV+Sak+NcfvLikrL48v8Kb82ZCePye5ul4bPysxaXZuJtlbJn4wAziQ 7A4J8xUbY/ZIpRibnR3ReNxIfv0qc1bSGY1Kp5PGno9pkeFXkPilrWFSmHeMP0iViWU3Ujg+pfzR OrzcigQT6vOFn4a0Ua6pvWgf5haXtfy2Xa+ueHhk6LGAR0pl3zln+aOriirWv9zZ/uL6Ci4aS2t/ S3Rhoc9gyl5EfbDj1JOdBcbjiXWraywWNqV5e/eKXQPF+Zu/+IjNn5+5skOuNUUsvfO69BAaE20R 8GnFXqc5Dq3+ARYeFsGxL/xmBE/Pm01np5Dln9Qd7tNMCJNNw6RosYNk4ypw5gfQZfXPXh/CoKZ6 M/7m0eXJ2O45IXSZ7FxZStBl2Z0fP76o7L6PH73zo8cXzUbfxiQtXFhWkh54oD/SoeFeKpiFstPG g9FlA0GXmXqMLhNAJjw9YisAGFyyH8vPyyfktFq+XN4np+1yj3y9nJbLLannnB2+c1OI87pVA6GB /cMw58xRXwXKfYqWhHY2F1fIRZgzyfLYDAY817l1RVra8i0tnVtb0tKat0xiTmHsceGYUy5PsJxT dzjPhUAn0fefgjp/Aqkzp+ZKygiqE4lFG/E78YdlyEt/ifEm5PHm1zx2bCfYcRiZweKrYM0jGelh 4HEnrOc+qIc7f4vAI/X8zl9/cHnRSdTLrRg7ovHbQSFBjXvNGpRsMWNU+W6EuWIQDHw1ikYo0N6K QeCwrgPw8R4CGBFeJNEx3JPrKkhQrKYwEPRWNOdbjKlz0qoHc9bPPzrU9Ehf0Zat622UePTb3GUL 5qfEFnmic9J31Dd6rr1j8Zo/9TdZMAq8eyKGvoxoywWLePwn98RbPB5LPC0l4M+ukxLwdy6Jx2mw 2QIRSEvqkH4jU51juib3DK5bNQX1fidAPUz0tLNkVwVoYZCWILRH/vpC3i1ea1l5WUzTzxYlxtXc 2PjK0wJCe6Ckantz15M9uTE5dV5/V1XCieanBkskzDs0w1CxhQszUqtz2f2sb25izWK76ZjV4ll0 Q1Vh87x8Y2R2TQfGZxOJolmidQSfFRNkttsfgZAZRZCZSsqgGUjyywWc1Q47QQhmYVimeS8zDJe5 fghw1WLAtZJ7DZZgvHX09whv7Ua8fmHCQp9CfTtA2T4QDV/Za7KgJNchu+6XAXms6bTVykTj11CZ 2xFsco0qNBdCHJ5aZWpD4jAVFueP6ZHnoibR06kluz6/25CT6zNZCgvzDM/9y/2PfUN9wEnrV+69 bd6FjhdvLqeQ6B8XSRj6jmBfK3X0FHcqafnWEH6SMiuJDyoZjiLISa7VymPH4B/9RiDPSvoq6j73 WXNkTAyjvxDZ4jk/aXWxdoyH6OQxU5gyXx0IiSdxkLRs3fPt3S+tK3XOW/3PH/zsrgdufGFVnoTy 3ja3dVtn9jcxuQ3ZucGk6NzGfE91DsJBgV1Bf/WD/3lv129ffXSV/+2q4L1ztPbE0oHtKzwLiuLi o3ofXBrvEFDQRCL9LeK9GMT55ZQYISBGgEC7Re0AzzIPfzL5LXBGADqfcxd5oPO+qP3MO5NIZxOx 4nVg5UHgg3uABSGdUb/cqQcY4jjV1dhNMcCP3FSMur7an5sisskBSLAXKPR6u8Ke+YXtekX5l3LM NS/6H/lnC+IcEjLkqk150Ezs4PTIyE/ANFNG0oRRjfC0EyqmvstqnptcteGFwPXPBgsTyq7JTJ1f 4PQP7gq0PNFf4Cha8pfUioyoKO+8jNTKjCg2p0qZUO612XPr0wm4KVlMfRxdtrS/ctmW1mxf88Z5 RSuvqbJFzV7YWVJ3Z0ued+maOQWtjXP91uzcwjg2PyUqKrUw1l3i80xYsvJL4hPneGOiPCXxqRUF XvwcOpoJbHFYkA5Kh9WpWLqARALi8HsoTRkpGJYr1e5vIrRaseOctQMBlfhhcWdIwARMfvbwpHhR EoRSfgiwiMPxyuWBjmu/f2nnKyu3dxZEiPNvmNXyWHd+xc3PBgIvbpjHOdp7ugMErBi8C6lZh7m3 Oq5tfDe9cWiOw27LW7l9ed/La/3F9/7x1K19PTfKIk2qlTta08HEBBijOuiXmG2UhLobWfpaVPIl tYZew9yLSu4RSk6REnzPvULJGVQryOxAJfcJJUfRPTuZO1DJ/XwJNFFd9BAp2SLc8ymqtYmU/Fwo +Q7V6iQlD0z23kGvJ309OFlrDaqFSx4SSp6hfk6/zvSgkq2TJRdQSSQq2Sb07oEt9FoxpnC7cM85 VOIjJTtwCZrNMWTTXqKqpuJJB4lvP4jjSXvVAedeZnl4PMl1xQHH6Z6dfim/4/5F825vzc/vuK+x +va2/C+N7hyHLSfRZHD7HDE5ieaxzkc6szB27HwUfQe2D8xb5tUac5aVV12bpTX6rsXa/iWSsTWU H1n59GE5EqBDfh0thhJa/BQybAyUNsvofbApzKPDydARg3ecJNife+k143e9/0IZjH599P298O6G p24bfwK3foq0XgVswIv9+cXdJhN25ul+jRqqH1MpDkmANkDFvAZCPZB9m1DgB3XgC61AZsRzUIdr D/nmuCMyMpKbkluKd143Z7DRY89bkNUAq97f+XxGSXq8wepg7VvSZ1nzFhdkNFRVuAsRRWfQLASp amSvl+0DMfCCPyItw5gWZ0xLM8bRMuTIv/E7NLK40TrnciflZEcTM0w7XzO+Y6SMRjoxIH1Vphil l0+5cuLIVyGaZ8RsXHqxsFz/0VgLajj40YfGHF+WofF2b5lbo0mpK1pS5it3qzxFRW25roJZRfFV Q/OTZ5e2LYq6+TZKxNAvapUGu17LmiIeVllidbGxBtVzcpWUjsmpSq1ZrFfh55OPIt7vpPKI/y7w y5UShZhRiGQAjsFX/RoRIxMrd0MFQm6UpJlqmua8PR+OHzusQYkscRmnwZnNe29Ie+mdQye5IZgH k4e4sTfeKN+yZSf8mEuEDu5jQHZ8o+kh1KsD5O6OijKhZcg+EAmscIdfa1IYn8Rue7+5Wb5HoRph loc7bMTB9/jnmVwzYx3kMW3krg3EXQ8V9j58jSEjy2tI6MprWqxNmZszQtm5USd+0sNV1lrK0oxY 9LwsItkT7dCK4b+NrdFkXIO99ado7jch2qJBIkI0RtcY/OWoVK3G8G3Mr7dK49xG+9N6FQJt6t2q ZveIoJC83B+LDL2qhRhTAazxjzHyrtpANhOFg8gScriD3pS1bF3FUy8ndh98YOChgto0g8g6m338 4Q+yCzQOm0WaW5Djc5SsmB378u7OZ4KFz2qdmaxYGnHTPyVkiiUyen51Ntai79BMdiK6xcDuV9EU hMhj0r9imimsmF7ijjHWwiYeEm9Md3Kvc9/CPG4n1Q+3jG+jat/Azy59ica/HmmjC2SBclB9ECTD 7UAL4uF2v9wa4bBqUZKiGdsLskEx3OtXS4vz0+NFTOLjpkDpEyFumMjh3xmxBmaKHTP8LUaqmCXE 2RbR+C017slIAr0++9oby3f9M5uWpdemJljddWvqKwfnJ5vd6SZrTlLUZ1nelVHuVJ082qJVxqWn R0hsdlNRnimZ1YnyGvOsXYGUkgynSmlPLUxKr8tnsfNMLE6PV6vjMktgk8laaGAtepnMEB3Hbba6 LJFSsTbaHe10SbVWXiISkURUEfxWuJuPHBwc0aS7sETozB5N7EiMJulplU4niQnId0uaAP9IKxIH vIVBHomdFNrJWED2VVyr8FQk9q2bEsqbelbnb3qivDFdz1irYkpXLUjPvu6Wyoq1S73cs3m5Bkey UWGzRctklpTPO7asyLdJn9XGepFkKM35zZXFK0qdrsa7rstKsDr1EhzZs+WlRCM5eWaijH6dsgMF cI4oADLmj/jlCLzJpOJfQjT9Hu+x8WN4o/Hw+OFjIUyOlBqpFvX4Ce5D6DwBnQu5C1BzEKq5bw4i /jwz8ST9OnyTvL/K7JdLaMiIDojx+x49Z7GlPkw2H4VzWfTrl0/R0fgPSg+Mf7wfWQMPZ6DX0tX4 adsRnUIzBg/4ZX5GIe/VsaAPFEdZjpmLLceg2RM1/t4RcnyASBABZUYTbRnce0tp/toD/7Rk2e1L ksde5gxp9758pH3ZayOP5D7v7ly/pe7Fv9ZgDTmH+vEJ/Sh0U/30oX56r9IPjxAlfHzLDWuDqJ88 3M+1uJ+X6GrUz1HUzzDqJ77rFtxPLcEvExfol2gHj1/A+xhBIMVaQ5t4/EJKTpESB49fSMkZVCtI O3n8QkqOont24v1ojF9wCbKbF+khUrJFuOdTVGsTKfm5UPIdqtVJSh4I9Y7uWU/6ejBUC92ziZQ8 hEv4f7NL1E52nXWv0oCC1AI4n2zvHsMWw+uE3qNH6Z1H0B0MABPn0L3b8L0gBqQCH5hXokAgpQOk AS/6jAci9KlHi9sOv0mJW8vYlZyzy9lg3SUz7YpcKLRdjOwD/iN9YGPBQxrcFwyzm4KxJLbgh8oJ beN/iK/oKFl/jwt/3juS7mlKT1tO7b1KIbOJOzV71YK0bQ+hT8+2HXXzdtTOG1+Eix7eWraqgS+q q0J8qQU+kUUkRdqSMiLH2nLCLxOLaFoZgRQGv8J3Smf4x5R4tYHhavP0p9xmOPQpHIIHuXVw01tw I3fzW0hvNoHL9Kd0ZUhvxBQQSTiG4kC43uAjChD9baKXXX6aXkbd/sYb3Oo33sDy/CZ5QngJmhHj PiCiZu+BNAOoBlB8GNXFMXMZ5YYQNlFPjjc9As9zkaIl42+N/+vjcBt8BE/4eiF9BdvhB5SLuoEa o7NRWi2k82hlv010TnSOaWO+F3vEa1G6KL4oyftfld6SpkgfkylkN8u+ln+myFI8rXQrVyt3R6RF bIj4g6pa9Uu1Vf2KRqUJaIYjPZHD2iTt0P/adEyXpXvwyqSXXCVtIOnVqWSAYalRSDv4ZKT/IcmH 0kbjyygdNh4zSX5yclwl1ZluMd1uutf0iuk/TP9p+uz/0v+/yXy9+SNLkuVGy+dR90b9Mbo++n2r zPpSTGbMDpvZ1mbbZvvC3mR/1H6BvYa9xWF33OnY4tjheMrxgmOP45DjqOPfHScdnzlOo/RfjvFY cez82A2xbzmLnGudR+OccRVx/+7yuZpR2uAadX3l+sZ1KZ6OV8Yb4m3x7vj0+Lz40vglQnobpcuh 5LYKqeDHErLFqVQsCP0Lj63kE+ch0JArnKeAlPkIhP5V0wJmr5AXgSjmt0KeAWbmopAXgyixXMhL wGVxnJCXgiTxo0JeBlgJK+TlTMNkXwqwSOIX8kqQJNkq5COobZJfCXkV6JYvmfx3QjPlh4U8BFL5 t0IeebSI3aF/ERTYIp4Q8iIQEfG8kGeAMuKXQl6Myt8S8hJwS8R7Ql4KDCqtkJcBjWqhkJdTz032 pQDJqlYhr0T33yfkI2C16mkhrwI56gv4X4EVyQQ+83mez3ye5zOf5/nM53k+83mez3ye5zOf5/nM 53k+83mez3ye5zOf5/nM53k+83mez3ye5/NzgAWZIB2lbJSrAV2gBQwgdBxEf+1gEJXNRrkB0E8+ A6gEv9W5FyEyFpSAbpRY0IDKOkAn+i1IrtrQdxu6ezX6bEV3ziY1cIvdqAV8Txf5DKDvHnIPi/rC 7bNgiNTFd/Siz35CSwfpuQclXNqBytvQ92p0NUBa7iHXg0KbvaS9PnTdSahg0YjwnS2o7R50zyC5 p4VQyYI1wl1tpC6L7sAt4vH3o+uWMOp6CTd4yvGvbaTddvTHj3KKHy2ozQChuQXVwa3jOrhsNemH pwy3EiC0Yyq6UBu4PAVddaOr60k55lgrqbGW9LgGtdU12WYKoTeA7g3xpYvQiMfRger2kbqYmj4y r21hfO4X2sDjChCqQ5xbQeYAt4g5FCQt4DoD5Lqf1Gid5CEe90JhPHg2+RlbLfBtMWmnFZWsIS1N 8bGVcLKfSMRa0jvmHb6Prxkg97QRSjqILKwho+uclApeIkPyyNPZTWaOn/VBlGfJXA4QLnWTsjZw A+l/kMxHL8nhmWolrXeF8eNvS0Jw2jxhCR8ic4P7DvEkJOWhkQXD+N9DvtsE7vYI5Vg2V6C7MUfw rzxd/NxifWQF+tsIV9sE2QiNqY+MJ0g0uI3cgympI3PdiyjiZQjT0EY0eUiYU17bMPeGSKuswJuO sL4HhPH2Tpb1En1qI9zrRq3MIn3zGt5JaEshc4g1cXByVnkZmz4rN5JW+oQ2Qvfg33hJ7xXszmpB azB1/QLlIX4GJilaIcw/z6+QTGH9Dwi2pRt9Dk5qUbgEdxOtuX6y9hRvWwRpWSFo8BDRj9ZJObtS nwZJf4Pk/hVkRlcTq7B2koMhO3A1uleQe8Mt2hrBfmCKr7TT+YIUTrezpYIFyQ+z8osESrsEeclA 7eFfZtZOnaz9Q/a7TdDItskZwPLUQX4dFKxqa5iGtZEZHxD4G6pz9V/b/1veKOQvQhxtJHIakroF ZC4GBYnh+ekRKJjuJ/rIvA4Kmow5XY1KWkACGXeiYJNYUEGo4utiSepHHPagtIakNOKpplOeJui5 R7DlIa/Wj1pYi0qxp5iyLdNbDZW3E+swQKxOqL2lhGbeD6wN85+Dk/Znyubyc8dLag/hT4hDvHyG uDcH8a8aebMp7Qr9wlveVsKTwUmuryF9tRDbfLV+u65iY6Y050pPwMt7Pxlpr6B9fFu8n8caO3Pc +HfebiagWolEOnmdav1BqnqvaPmn82iq9SkLzVtTXnpapnmmK8c+Ja/T6Qq3gHgk/FgGSX8hqcft 82PlPWsvsVuBHxwpz+fANJ6GbM1MHcBcxZI3JHjpNoKzWgSZ6iO+oQ311/8jM/SP0ospnfAQarAO DBHPkEbmqh/c8BybmZ6ezdZ0tQz0BfvaB9nZfQP9fQOBwa6+3jS2pLubbejq6BwMsg1twbaB1W2t abP7eoN93YEg2xVkA109ba1se98AOxRsY7t62f6Bvo6BQE9PV28H29a7umugr7enrRdVD/S2sn2D nW0DbEvXQMtQT3Aw0NvSFmTXoKI2NsD29PX2BfsDLaS53kHceLC/raWrvQt1Seho6QwMBFoG2waC bGdgdRuLGmODgZ62/1fddcA1lWz9Ozehg/QizYBILzcIAoJUewGlCJYVQhIkEpKYhG4h0aWJYgMF FRCsqKDYUBYFK6C4KixPFwV9IlgQ7Czq4jf3JiJr2d3v/X7ve98zP/6TKffMmTPnnJkzN95LSWAx hNG2FDYrhknhshkUYRKPmcBn4S1tKbG0GJwXlhD2sZjLZUAyXBadSfDMgy24HBqbYC4yTsDiMAUC Cp3L5zMFPC6HgXNoTwmG/bBi4cDg4CmhLA6DmyCQ8MhgCXhsWhKFxmZzE2AljcJgCliLOZAjYTQu CihIXI6QJpsLpUcRcikcLj8W9ihkJgrhCGgcipBPY7DwVrD0CyEIJGPy48bxWUw+zgkucrwzAcF/ LBeKjs6Nhd+FtEh2EoXPhLTgaLlRFEifyWFAQkRPXA5FQOczmXBKA3hMTjCUECWKSRPGwZHCaaOz 4xhMKFXOYuJqPuyXg3/jxMUy+TS2wJ0igBMezWTYUhhcoRAfKpSYdCjJTKg57kQJjQ2FzoG6A6dH EE3jMSV80nBCkXD8kC9cUnw6DWoLmynEp0giYDaXG4NXE9zSoVgi4QTHcXD+uZ/nSUgTCJmUyCRK PI2fhDOI68Bn2pE0vkTREqB+COyHdHo8ZUhnfaGCjCdUfi4kCqVOodpj2KdqO7x6uH4zWYTK0qBk F7Ng33ycIThhzFgaP4ZCDG1YNurbZoTbBc5oCIeFiy5ISBMyCT4dIAGpTXDjOEI4yQL7mXF0S5rA CmoSZQqfC2uFQt54B4eEhAT72E/E7eGcO0Atx02NF53kQBcS2iJtin+PokXyWTF4u3ncOGgDSYR9 CnH9ITQXjg4KNZZFzCWUJ87epJCZPsR04RmovIw4uhBnPSGaRY8edi1rSGOIyRkyAih3Hp8FG9Bh K2jz9pRPfXM5UDctWVYUJpwpxnBSnE+Nv8kR0ZxQaKimUDx0iTEN9U7IVUpLooCWLNiLkBmLi57P gr1CY+WwubThnUKeaRJOca35NAPcOCEvDpo0Mx73DrBNNJPN+2JAf2cuiJlwYDCjaHFsoT1NwEuU nh8hHy2Qc8RJzJf/8JsVivAzApH7+BFRJVoowz8d4qwG5lD8FIc8dC2OinDXPRch0ZP4bERrMZ8Z g1izaUIO4gRrQFCgLwVRQ/C7XogUyUPfYH1gwKwv6z/TPUOK/gPduQRd4RBdc+IKJfyOEyxTRbQQ XcQQlpogNnAfLKmThbSUYA/aiB5ihP9mBkYz1CEeFBE5OC5lRB0ZiRjDdXo03C07DvFlJm0jD6Wi gmgg+sgouIqb4XexpNTxUx/8uWQ6iAFcO62RMXB1c0Kc6dD7AG8CpxI4m8AwAiNwlwOiCeQQKCQw mcBUBocbC9IIzCZwI4FbCSyMgusO2EVgOYFVBJ4j8CqbS2eDVgLvENgJPRIfPCHwOYFvCfyAI4py YYLKEziCQC0C9QmEKxpbiJoTaE+gK4HeBE6FS1QUOpvAuQQuJDCSwGhBXKQA5RAoJDCZwFQC0wRx PAGaTeBGArcSWEjgLsm5IDGrf5UC6Sno91DhT5CEP9gHf/LP3/5GvJ+QsAN0mAXI/ikq/wmiUKtG ED18+va9FNfhfx0Vv4sa0FrskXGIJzIZ8YdWvAjuy/ATuRVIGrIOyUMKkT1IOTFSgKyXpgXSdJc0 LZOMFBhL8mCyNE2UlhdI02PS8lvS9J0kRQOlaZk0bZHMHUlekicj0lRRmqpBqSjCvyVILzETLOSZ pASdhuJ3ZFEwA8zET2khLfxJNwDVhjlrRAOEg0jABFzAAwIgBIkgGawAIiAGP4I0kAmywB00CJc4 WIT//25AAzTIJQMwIMVYwEFIYCngIzIgASQgciAJJCHyYDlYjiiAlSAVUQSrwGpEmXhP2wjQBtoQ NTQQjk0dP6WFngNAWUtGokrwuBWUwr5IYB84AIsPgXKEDA6Dw1BWKPRUCmA92AzyYKtCUAr2goOg ApbLfN0a3AQ3ITetoBWOF4X9KKLL0RXoSjQVFaFidBW6Gv0RTYM1KMpEmVCholEeYR0A9vKZJzVc TiAO1214fZrk3Bv60s8t1IfVQWogDrZG0G3obmIO8H63odvRHWghWoQWozvRErQUWvKX/aKIKzIS zULXfIvLb5aloxloJrxOlpAyQlBDIbWlCAkVossQFfQAehDRQQ+jh+GIJPTz0QI0G12LrkNz0PXo BnQjugndjOZ+sywP3YJu/V/QN0SU0IXoUlgXh8ajCWgimoQmoymwJZxNdAG6QEoDECNG8beywfkZ BSjABLiDo+A0wO/syyLZCP7bD/xdegCMB+OhJlSCSjirp8ApOM/1oJ5YuS7BFc0Jxl7ehH0GI/OR CGihbBhZJUIbXY1kQavMI94CWIZUIqeRWjgz+GNcUaAEoNYDU2AJKdsDRzAO5pSBDkQVoAtxBICj AapgJEQ1oA9RHRhA1ACGEDWBEUQtaNMoGA2sIJoBa4hjgA1Ec2AL0QLYQdoO+JsKYYoBJ+AKUypw Bm5QgovRKIgClA9Hq4BkwA9CvLsQQL+Cv2FgM/yQ4C6kEXry60gL9HP4+/40CNlpQ/kuhWsqYdWE 7n+2GNyqdw9p6/f17pOuIlK/LfFViEEQTLUkxQYzMLHBFFkF67Spaf0qQA4tFhu4wiInFACqEqYg K2MzgoTqyyAYTVbRRhaQgdgFBeTiIGwOZjusxLDEONUQ8SA+AUik9ICNSQTRnvgHMxlGjKwV5fV2 NNqt+Wa7d8oGh0eF5XsolR+KxdrvMDHpAvyzK8af6YCqTTk7MrdjbeBkv/622Kkq1F2YyhCrQAYy JVpDMEkKIctqovN9qNqYJp6R11QOZeLxAYfiB8MeqhamgRfLaSpNjONH0mAgzGYzqaqQGixV1JQN jqYlCJlUI8wAL1DS1JIUUPyYMGCMYtGJuIE6CjPCq0maOtLqYBhuw8A5lofvif18MGNdFWws1RFz woh/83VVqHh2rONYZzdnt/lY0DBmQ4Koupi2pP8RMPhhBcFI1ZYyjUO3p9pgVpKOTD9VEF3hoYqk ryAY+rPwcB12Kgamw6UCZBCSGKgisFwRFQOA7G+s3HW1iVKhuDzzYHrc82P+LzrqVM8uptWUMgx/ rR5oHHtgNZYZtiK7LebuuELVszd6El8m7FnB9Ti7qULldPRr9ubGmkC7A1MnvDnxyw/hBmjRO4cY 4139pQV79OvR+ytnBj4YEdHjbbjilEq71+VjHek14clLqPakfJHmvimUa1SBSqhdU6LT2FyNfI1T 7dEOZV0PzmVlW59fY5IeVbMqLJQbd9ajzDz9h0Y1bY+i1U+C6xQ5FwYvTr97Sk59i+myNk+LG8aJ PUXUhhddpiPbLhyd4legH15svL5z0ZveZS+WH4gEOW9mKbVfN527L7epPCO+vPe0yqvOWbeL30cX l2u5H02vq0ZJUPFLRW2Y6BbmJCsPNVZGRg4AsiVmjpl9ymMgTU8aTnDpAp59PJQ7fnSAhxOE7hhp AvCRLI/JwgQFCOaDl40ij8dcsXHFTsWOaZj0cjqf/YerHSS6MlxV/HzsYStCU43GkJUxxU9ckOSx EXihKt4XGVqALOQQ5tXJUDN3jcR0P+k3SVM5OMgHKpqrHdXOeewXVkESiZDpMQNPws5NNKRmJuXb 5J0VHwSthjObDmeFcTrkrUoX1Tdu0uwmB6r0TbFwQFwPdzZs8i9oMY3U7vdyMQngUVNfrHFNP/ro 0RZk8OeQPH+zm/st/JPLT9J8Xllf6264vehutc2Pnsd3HL99P/TjmWMXV7z5Wbnw+ZZBm2b3QAMD V4t+r+nQhj9iYrRbascqj22et9yyytBzlFFYVBCf8aUd/1ss42tzxFyHm2Po3+zUAbOTdGr+V53i dUz+X5pk5WzLqXebo5NX602MivthxYWqIrr5xwl+25epu6qNCRHcjrNg/e5/irKwWXGg2MD6Wchc E9ot47bOn8bGXO67W+rCXGewSflEkPHCZVHO4TJZkwbj/TuCUktElB3lGQtL5PsfYgO9pi4zfRWv dVwadaE15LHI63hgqW0ZSH5ZUrbWebCo64clMkUTYh6czasdvBox4N0tVzzxqWgOZ7f1yxNZapbP cu7IFqfNLkiZLq+CGTWqFcb0Pw4rJ+/3zq+0fJSjc9DjQRB3RrPzjuNchtHRPNvqCd1JT2OTB3S6 zA9V9OUHnfS2za1KKhtsCTxgJVzh2+NmXLJEp2tetVn0LSTVTy09NUZqko2Y6PK/aJLKQyaJYgg2 VmKMtpg1ZllsXmyWZvo9YxQKBHZ0GmF+OoT54ST+xAJla/+WBTp9aYH4LKcn8n71DwSUBfeSGsTY hd9Pjcyr2YCcr2lquvR6xK2PA7Nqx0Zi6hffCA1aNraHb6doHlk26czsplXdqbqr9lpsWqw5+X1j 1VYf0tVtcxbIrFm5j/vKYLaBmf1L1lq2aX91o07uM2VhbXTC7af5kel1gvW/ZQqTRx8o3Zqy5Uh/ jtXSWfZxBlN9fn1+XIUS3JpQvEVMZ/2u8HPW87hqhW23B9RDzAtojmeS0cMpaWdKzq8xtU284Rz/ 00bBwoFTXTO1FUdf7bzZ4mQ/zVvbQzUi2ezS7qi+vJ95Tz27X6usuHNjWWn8Ulbd9oApmLPJkZIK /UgPm9vryqzlUm7pHV2Y8s8du7mDHpmHMDFZA7qAdxIXoIrUIWs8PDLUb3i+pfd0eA+XGBl6AN4n 21bSNPXj8pL4+DE3xZJuRaG6ubl8cZJnTzXGDCWNtb95xkc1wUZJpknvc30glyuk+MQJo7l8ljAJ dw9uLhiVimEuUvfgiFHxJ0dJsv8Bjv5yKUdr6nhd7i/9DSyLtiQuwp6U7F87Jvy3wdyZpScHd5RQ PJfNKdlWkhPhGHPDl5HUezC+IfjXl0+3pxnmFK2OOnoxJjlydKuRR7sq2Pgo78JZu6iCgmjz/Ovj bc8qHw8zr5vcrejpmme739JtX8+0Vb4PVqtWF7BDaAfFy3ZG2CXMfJx/jOFeMNuQKm+mVbS/e4ON XteErXStiDAZZpGRS2B6/96+zeglg+azIZOOZqaeHd8TvNm//Pe9ybFC/wq9q3kKliZI6PoIlkv1 DA05j7kfF7zfFaUov+emaG5o3wn3RTqiBPKvb8+Up+YOHm5a2bpXn7/Qo/Gn5/KlpthR2R8bjlIS NH/skPqNfZhoNyYqwe0SkEUFmGhLqtqC67w+Fr9w9JwVWpWz1n28spP/fz9/4r/QccIr5D5Sql37 aoue87MqYHYrQf3VwgjHokKlK54yGzJyGsZ3mbx8HrrJ9njxlPrIvg//uOruPn//uGDWoFmsV8PV snaZZXepaycUqfGWVA9qBOixaj9c93ugPp8S8CQypaJsZL2Nyxi7M8ydGlljVOml/cGGAyYNrdqv Ag9y/Bzlfhfr/vZwMVtlztuaF4GXa7ovYB8oVIUMo1wr/Vm/GKG7X6TeIx1b8PrI3frQXua0y4HB J46RLDU+rm99Lp+zomrLxQMutp3JnfsSHsQXI9eXeNXdHJd1z0djn/MSgyVtzvdbDMmd+yaR6+eP deXMMlSJPKlYkt38S7DX5CbDkD28No3x6ZviivbeLIZe4QrcHByVbgyWKOUH1CLKB9RvmfYtZyet +H/hFjBHzNlxLNzaSTfxVMzN0VmaxUR7/rht0MTUJSGHYihNEA23A0LYjxqxjMCAQy6QyYjlchif OFP8HmffG6Yj7PSrYY7GTCTD0B9ew2ASGxB8RzKbCAwoX3sTFdybyBPe5PxVytqfOj56zu5NPtdi NuZt/DWTj03Wc/0bt58UVzon2SEX9sn/Qm84ufvt47q61iPZeSVy71RPiAMLnoov1ahd3FfbG7N6 XZBB9ex3DJBZp9Mijka8Eye+0XD1f0+fc+/dhFMPXY500OVGuy/1dpryOqZ88hsLgbHpFd+RxnNO BBY0l17XvDTSa6ls7Mtck4nhvs9qG/IZlKo6pw8lE7tSKo0cqva0v97Zsc1EdTCM6hPiuqIirLuz Z17SmAP91g7qXq6Jnr4r90Z3rjCN1u2avvFC4sTAKTsDVmdu2la7OOWJwvs00vK3+Us9bPZGbb3a YfdPG1Rf1Wkq842HRsWLdEMj80DuVah/pFIxsIbyMP/WXpz03+FiNGQVpEG4NjQYlERCSESYajSC rEPWGvObzYwf6vnBhx6+LbbW1XlfNxAkwkYOXaKFkpWNFZEgJA6G7H6ID6ZEbH6I2GMypjq0yZLB SDD5ljsrYkwX3mdZzP9NNshiy2XjGyLBjWunRa/1n2zakl5xJ2c8enyN2tlme6EQuB/z1uydE+5x 3nFbQOvjeY2WSB5f++lSh61ba0n3nX0fyztEUvM/UF/d8S2/E5Bz1bWd5+MaoeJB2Wijt11ucO6m /TdnZNTkTzdFf+RO7NnQNbLdpkq7chvv3cWn/qtsxy8tdgx76RzYtiHDu49r0G3le4zXtJzN1a9v 2/7uxqKs/pu2BUj47dfnjhaltLgPBgmtFxuJLEriHnlvldNbo0dRmszv6OvvGRfbG9MQFWRU41z2 8IrREr7mpFTj2z+kR2UZ2u5pvEIjkdoVGsCRebWHf++K2nLlnYL7MkwsMxm6NHuJO1OkKT7BiKPb RV+dVPy3uA3c/zlTHanQAzq5OBNRkwsMo2DWGc9ioox/y0AgwxLerL5909ZyGoe4mc2mhAiYlAAO O8nqL/dL5/fq3FRq8Ypc3zsv2CFXifu6hXWGnX1W7+eg900NzdGdkSfDhUqkrrK6p54WPTe3rt9G mzuI9e5vZs+MurVwjGhdWWvsaGCVm1VSleHVPme22WZG90/1hUi3w/xtYR9007rplMNJdo+OqIXz Zz76WT9n5i75DkaE6zZ/+oxOp4mbHZ2rVOX49zkpu6uam44OLjzkOOd+1OHiWSeV2CSKRnStrdZv OaLGtfY/gdOyQGylu9ekcdW6y7MYlNu7Vwny3guD42frnjzaM9Ui69gY/8MPqxtmMEu83drvDmSO uWe+fWtgaY3QaYJAFVNfTLnsl57vZXqEbiNijngQK+M99uG5ds9od8l+SQzWQ4lkfxXYfPYSFSlG 0aufXR6wH5WWmOtrdfzFRZ1N33GJ+/HS0WTRTkxUmPpN97JTuOs/4Ri/3klMl0SFfpgP5lU8odg9 zW1YVPjHG8a8GBZe6iC9zS5wwK0CN4rZ0rMa/2FRqi/mjXkORalomuN370MTZJn8r+gJvxUuAg+f nGvmrmFPi+nN0d0HmkN5fdP6ZELStc+nN1SF0rznPq/qx0hRyU/XrDmQqLegpXevb11t9u+H/nF9 3UBGukJEpeKKeNbtpAtk+ptNwYX3GHqvsjNmsHM4Dffk3csyZmcp1r3qOvby9RuPW9STCkf65tcE 8JZ4Pzi5vOmJmW1jhMX94spjlmXBZkcKN79x27F4LC1g+jJ+0xndrMD+RS/+8U9P2nUXeY+I2LSb 1fS7j+pDKimu1RqGqwpE44JtbrQ9vqfx+xX/SS3vxi0ZEDq3mieodFZelz3XL1Tefay1/EkiLcdX LTyOE+m5u+6OPy1x6qnW0GvBPU1ndh+YVDHClFJyMMXhPlVMPgs9aTUKACY6/l/jL//g8z+fcBeL 7mBaQ+usJaDKkWSIRvjqK516BRJVefihOmT9c06JOgIbXquNjf58IZkKrfbSndLGUYV9qUWZyG+H 3jQvQrtuVmJRwy5RpoZhc4ttU63//o9Pd5qnmv2Nn1V8ubEkiwHCXTnf8Up6N9vT4Hly5yrtqnUr a6/uRF/p2rVQS2f5PrjqpGXe0uo0+kPAtEsVp8iJl9UjnSaxkk47zvmw9HyV5/2iC4vP2zLCop75 j05wG9Vkz9gQbKCxP155b8Zg7Ty32AuZnAhOaHpv25UXzvssSD3kyelvlfud/Lwve9Xs17V0zLZa draTd8sMdRq7vmvUtH9eu5LBUZ5Dr70ZWDd1SU+21/jb56qoSg9f8Zc0903ekPHT2wPruja/r17Q 12DiXVgaz7p367G8ftFj4X7Xeiekg/p2bu/rcZnIPLunybYXUW39Qxp6uYhCYkiN2xjXyllH60uD GK9PhKcbtB7fe3I5ryj0vOmunWK4QxKD959nSZYqBj2w6BGu0ov/LWec3zhZVZaVlzCAQs9SPA/T G65vSp/v9ACobkM1MlRV6bLvRnVzdHFymw897jB10yCrrSsNoVS8vxxQthzLDMWuZ3xDBXYoxW6t mHf4UM0l64+s3ltBbUKbjAH3VW1T60+OPB3BPKz0crBi5ojjqVPdZ7Rm8FPRGz3ma1aVOBieDzTP n6eg0Rf1xi3Ku99HadU4bFdphu+hmkLt64pTQwOzPoxdlyJfsNkHDb/rdovl75+8aUnHlox1Jy5t 505ft3VlmkeV/SyFq8uvnRHdPzhn0KLu0knnTNUp3JLX8/faGj9KWflE5de2+4oNhsvS+gv4D73X 7FuGss9lPEcSN9e3O1S9ysY2mpdv6Lrh6trO575Z/UIj+JXeU137NSPfUdWrfqgPf236NHfRuLvZ uvZnWi0N7qa3l1CPte9Zk9CgnSjubn6fGjb5ZPH7+oUzkf8BFM2uyg0KZW5kc3RyZWFtDQplbmRv YmoNCjUxNiAwIG9iag0KWyAyNzhdIA0KZW5kb2JqDQo1MTcgMCBvYmoNClsgNTUwIDAgMCAwIDU1 MCA1NTAgMCAwIDU1MCA1NTAgMCAwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUw IDU1MCA1NTAgNTUwIDU1MCAwIDU1MCAwIDAgNTUwIDU1MCAwIDAgNTUwIDU1MCA1NTAgNTUwIDU1 MCA1NTAgNTUwIDU1MCA1NTAgMCAwIDU1MCA1NTAgNTUwIDU1MCA1NTAgMCA1NTAgNTUwIDU1MCA1 NTAgMCA1NTAgMCAwIDAgNTUwIDAgNTUwIDAgMCAwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1 MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUw IDU1MCA1NTAgNTUwIDU1MCA1NTBdIA0KZW5kb2JqDQo1MTggMCBvYmoNCjw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMjU0OTUvTGVuZ3RoMSA0NDczMj4+DQpzdHJlYW0NCniczHsJeBTF1vap 7tkny2RPCCEThiSEJIQkBIgsmayEPSskECCBBIKC5BJQEREQEYgiIIqoCIiICAiTsBgWwQVwRcWd qygRcUfFi1xFMvO91TWFinqf3///v+f7uvPO+3ZVddWpU6dO9+BIjIgC8aEje17poIG7miZGE60q I4qsH5iXX0BxystETSvQqtPAohGlR3tdWI9rF64rBpaW5xwY+NlxojtNRKbBI0pT0q574oFZRGwL 6qsnTqtpKEsp/4DIuBYDBE+8YaZ964knFhAlfohr06SGydPYGr/XiKzozxw2uaaxgaLIgf7n437b 5KmzJ/ls2xRFlPIpUc6x+rqa2o+e/yIP/Sehvlc9CqzDGO5ntbjuUj9t5k23T5ibSKTAHv09U6dP rAn5IM5MNGM7ru+aVnNTg98zYV+g/RK0t19fM63uS/8FXxLd1AdOiG+Y3jjT/TOtxPjVvL5hRl3D PzJO3k4U/CJRWDBxXwF7F/X9cLx/vx/JjGFwHDgT2Y3z4RdvG+kxuhN0F4zrcGkihcSBe/Tn28+z cbpJHqNnhu6C1tNvDx0vUY5SDekpm1TcaaMUqoNnbtHGZaTqJrEVqDXpH9Sno8toweoJmqSQyaxY DWZF0amKbgMp3znJPkR2PazUbicU2O8WNhirFMVOtJ7Xqd/oI/lMiekmUQUgjOFsoXVURdPoJTpO OTSdttNeWktfUirdSJmoy6StKB2JFjpKpkDcMZ3+eFg873jeof7es8pz8k/aEMYQ9TnQ0X+o3a71 jAjy+GD8ZHrOW34jzquPTM9a9LDOcxIjbfWWTdfuH4nzj8e0P7WHaBFtwBynEWKZxkFvp4WY/3Ya DV0FcL/spSyoHIqlAupLm/60Fz6bBJz9gXWeH6iWJvyh1ay/sOHX+W+nazE+Ag9ngqdRK2nw1m7w 4vdHlcdF8d7yl7xl/O5VLMYzGHZn/ck4f+xFHEU4l15VtlQ7/1hWiJNYBpV4jPgsos9QVuJ5WKsz wZP8GOe16CWvLyYgljL/Yuy/PNhuZTtzafJbusQeZIuoLzPh3M5acKbQKziPsNWorUfv31Ims7NK DlqOWOJoZG1YoUWey/xkCluGM4npNFSK1rSRzmrYRLtxLsO6833xJfWG9Tyu0rASa7ED+K7YgXFm oXa6N9IC4eVE7IDVnmke5DzPVs8AfB6GVzZgzlnoawFaL4VuxOdeRNIGRNJKxFeiFmXr0KZJi57e 6DGeRCT94fAghrntdInO0CnNPm6hD73kuYgx+B5ZS5GwcLrXvir0lqnZNw8ZpowGI+OWoHwhNF+h LzGf0d7djLwJy/goP6CNDmIOPjOBRTQXVv5AYTTL48bVDq1lDMYRO4Tvn3HYFwmY0xpajB6HauNs hjVlmod+ANaJ3rVxFnonNFr73IDWVfCJ2KGzyYnV2oCZPssUMmN8H5zXYrYR6Csd1s7FyT3Xm9rg hVioCu1cTKuweonUAstnwRu1f1l+HP67yALpLRZL3yIdX4YnNvOTVSB+/n5t8JWTMONFiMNVGi+C 35fSCU3NIp4dfegfsKI/bOcrn4DSEuqqzVv1oqN4YrBuuIJSQ0nH/FDQC7lbR6FQvvB9LO7tQ9fQ ABqEKCunUTSGxtLN6PNJ2kX77DZ7nr3BfpP9VvsS+90ejzaCL3rogtGScF9/PHuGYmxxX412X8uV +2bab7HPt9+F+5jnR82aUUAMYuN5cbKuLJ46eyZSMzvOjrYN/6TmE1/t9PnEx/vES6Oe+OQY/H+4 0VVWrYxRnsBuHMeq2CylTqlXpijXKtcpU5VpyvXKdMWl7CYD+0Zrff4PT1aGZ6l4Div0nw8mx9Ma Y0ytcB6br/Ffjo+6Mdod3A5+6PCUNpAR+c6M+LRidfnhjyd6APZcEHQIViyMwqE6eIdG7LPbvXYs pNsRGXcgQpcgTproTroLmedu5KwVyA73IIrupftoNd2PffUAPUgP8Wfj/+pD/c/VymN/qzcduYlH Eo/8wP+rqP/7EU9/O9r/myLdObB2/LixVWNGV1aUl5WWFBeNGD5s6JDBgwoHFuTn5eZkO7MG9O/X 95rMPr17ZaR0T07qGhfbxdE5Ojw4wObva7WYTUaDHm+JjJLyHQXVdldctUsX5ygsTObXjhoU1Pym oNplR1HB79u47NVaM/vvWzrRctJVLZ2ipfNKS2az96N+yUn2fIfddTzPYW9lo4sroJflOSrtrnOa HqZpXZx24YuLmBjcYc8Pr8+zu1i1Pd9VcEN9U351HvprtlpyHbl1luQkarZYIa1Qrq6OhmbWdQDT hNI1/5pmvCP78mFdamx+Ta2rqLgiPy8yJqZSK6NcrS+XIddl1PqyT+E205325qRnmu5qtdGE6kSf WkdtTVWFS63BTU1qflPTYldAoivBkedKuPnTcEy5zpXkyMt3JTrQ2ZCSKwMwlz7W5rA3/Ugw3nHu m9+X1HhLDLG2H4lLPsUrbkK91ATbYCHmFxPDbbmz1UkTcOGaX1whru00IbKFnCmJlS6lmtc8I2tC ynnNfFlz5fZqRwxfqvxq798N9eGu+RPsyUnwvvYXiz/U211qXPWEifWca+qaHHl5wm9lFS5nHoSz xjvX/OYeKWhfU41JTOFuKK5wpTgaXMGOHNEABXa+BlNKK7RbvLe5gnNd+MLovcuVkp/H7bLnN1Xn CQN5X47iin2U7jnd3NMeuSsde6uS2+EKzcWixOU3VdROckVXR9YiPifZKyJjXM5KuK/SUVFXyVfJ YXMlnMZwMdqI2l2Y21WtZWM+c2OsyV6hRKqVfLVQYC/AhyOnHypsWC7tkq9oTj97BYsk2QyjeFtw 9bt+cKHG5hbyKpXfmlsYGVMZI47/YFKk1yZ9rMv0m75sKLhikxjnL00TrblBCfb8urzfGPi7TvVe A729/bmdCveFd2DcYeLLWSir1FjsXJQp6EYr4qsYbndRkb3CUeeodCCGnEUVfG7c19r6Dil1DCke XaGttjdKyn53Jer7XKnzKpeSiwAsSIyUa6pdD9Sur1wWXlU9SFbbm0yOIaVNvGeHt0OyY/tgxoa4 QTV39gnsiX1ZgNTmKKhx4IlQ0FTT6pk/oanZ6WxqyK+uv4b34RhU2+QoregXqZlWUjE38mY+VCAN YUPKcpKTkHhymh1sSXGzky0pHV2xz4bHz5KyihaFKbnVOZXNXVBXsc9O5NRKFV7KC/mFnV/wnkpw YdLaR+5zEs3XanVagXY9sZWRVmaSZYwmtiqizCbLFJTpRJlTK+MHVii8Hv5Frs231/K1uaWyvqm6 ku8sCsU64o+5mGMAuRTHgGamGHxcFkddjsvqyOHlWbw8S5QbeLkRUcFCGZzDE1JTtQNJCtFUQZFM xKHKu7S3ejxlFTHHI89VxiDOqoDRFS5zIhK/PnYw2g3kqEbxQNf8iTXcDiqv4PcaYwdNrETMyg7R ZJDLjB7M3h7QokC7h8cibpqItcECavfPx4VrfqWrMpEPWjGlUotlm4sKHddg2UWf+jg+UEplU6Aj TduY2AeW2MWczLCNSitESSQuMVilcJLRB5ZPdKBqYrUd3tbRxFLEuUiklkhRUod8qIur02CJ9FYS n5Yaa/W1uMzd0SH+uLZ25/tRH2usrBTGa1eLvQ0wts1lhUVxv3Gl9wZ4B1WDuC34WwxTedNneTfF rVTiuAlphRut9WREtcs3dlANMr+434oSRx95s4knCKu3jyOi1Mhn7gO/q7FlrZ7HHbNjfnMkJzn4 k4EHJkXuQ2BTZdPVBa4xiclJpqtLfbXipiaT75/fIPxl8r3CvNCej0cG7SO7ou42h7PB9lZFkYJJ QV7BPFK4pWiX4hcpLknxsxQ/SfFvKS5K8aMUF6T4lxQ/SHFeiu+l+E6Kb6U4J8U3UnwtxVdSfCnF F1J8LsVnUpyV4lMpzkjxiRRtUpyW4mMpPpLilBQfSvGBFP+U4qQU70vxnhTvSvGOFG9L8ZYUb0px Qoo3pHhditekOC7Fq1K8IsXLUrwkxYtSvCDFMSmOSnFEiueleE6KZ6V4RorDUhyS4mkpDkpxQIr9 UuyTolWKp6TYK8UeKXZLsUuKFimapXBJsVOKJ6XYLsU2KbZK8YQUW6R4XIrNUjwmxSYpNkrxiBQb pFgvxcNSrJXiISkelOIBKdZIcb8Uq6W4T4p7pVglxT1SrJRihRTLpbhbimVSNEmxVIolUiyW4g4p FklxuxQLpVggxTwpbpVirhS3SDFHitlS3CTFjVLcIMVMKRqlmCHFdCmul2KaFFOluE6Ka6WYIkW9 FJOlmCRFnRS1UkyUYoIUNVJUSzFeinFSjJWiSooxUlRKUSHFKClGSlEuRZkUJVIUS1EkxQgphksx TIrBUgySokCKHCmypXBKkSVFfyn6SpEpRR8pekvRS4oMKXpKkS5FmhSpUvSQIkWK7s4buZrBsqOn q9nR1yvZ0VOS68snJ08qr0uuLZ+YPKG8Jq26PKU6q1oZnzauPHr04dFKw+jTo5WRyeXlWeWsLLm0 PKuUPVPK1mt/JcnF5UXJI8obRrCUEWx9IWsoZM8UsumFzFnICpLzy/OSc8tzkrPLWxW1pVPnaDwe BbGWqK4g0oh5BLkFtQu6LOiXlo6JoEuCfhb0k6B/C7oo6EdBF1oiU0D/EvSDoPOCvhf0naBvBZ0T 9I2grwV9JehLQV8I+lzQZ4LOCvpU0BlBn7R06ANqE3Ra0MeCPhJ0StCHgj4Q9E9BJwW9L+g9Qe8K ekfQ24LeaonoC3pT0AlBbwh6XdBrgo4LelXQK4JeFvSSoBcFvSDomKCjgo4Iel7Qc4KeFfSMoMOC Dgl6WtBBQQcE7Re0T1BrS3g26ClBewXtEbRb0C5BLYKaBbkE7RS0Q9CTgrYL2iZoq6AnBG0R9Lig zYIeE7RJ0KOCNgp6RNAGQesFrRP0sKC1gh4S9KCgBwStEXS/oNWC7hN0r6BVgu4RtFLQCkHLBd0t aJmguwTdKaipJWwgaKmgJYIWC7pD0CJBtwtaKOg2QQsEzRc0T9CtguYKukXQHEE3C5ot6CZBNwq6 QdAsQTMFNQqaIegfghoETRd0vaBpgqYKuk7QtYKmCKoXNFnQJEF1gmoFTRQ0QVCNoGpB4wWNEzRW UJWgMYJGC6oUVNESWg4aJWikoHJBZYJKBZUIKhZUJGiEoOGChgkaKmiIoMGCBgkqFDRQUIGgfEF5 gnIF5QjKFuQUlCVogKD+gvoJ6ivoGkGZgvq0hEwA9RbUS1CGoJ6C0ltCikBpglJFYQ9BKYK6C0pu CUZKZ0mCEluCYkHdBCW0BPKc3FVQvKA4QbGCughyCOosKEaQvSUgAxQtqJOgqBZbHqijoEhBHQRF CAoXFCYoVFCIoGBBQYICBQUIsgnyF+QnyFeQT4v/EJBVkEWQWZBJkFGQQZBekE6QKkgRxASR0wPm cAPtwGXgF+AS8DPwE/Bv4CLwI3AB+BfwA3Ae+B74DvgWOAd8A3wNfAV8CXwBfA58BpwFPgXOAJ8A bcBp4GPgI+AU8CHwAfBP4CTwPvAe8C7wjl9J9NvAW8CbwAngDeB14DXgOPAq8ArwMvAS8CLwAnAM OAocAZ4HngOeBZyeZ/B5GDgEPA0cBA4A+4F9QCvwFLAX2APsBnYBLUCz74RoF7AT2AE8CWwHtvkW RW8FPwFsAR4HNgOPAZuAR4GNwCPABmA9sA54GFgLPAQ86DM9+gFgDXA/sBq4D7gXWAXcA6wEVgDL gbutTdHLgLsAWwfW0GF+B6UhYn6EkhKeFT4iXI0OSwnLClPXh+0MU5xhkdEFDcHzg98IdppPB+vm B7ENNtbqeWaXLalHAdjpsEV3LmjwZ4f92XK/9X47/dSdfof9lMN+r/t97Kc6/QbkFKgHmfbrHmJs RXNZaWLikFajp2SIy1Q0xsWWuGJL+aezeLTLsMRF5aPHVDQzdndlM1Nyy1wB/J8etetFy5ZRVM4Q V1RpRYu6YUNUTuUQ13yunU5Ne7gmNKlMbJw5q3FWYmJjYyNLbJw1s7FxJiX+rz/Y/7QB/z0H9zwW YiZWAWLmzFmJM0GJjbK+mfi/OGd7FJVqFQVgAFEt8wBuoB34BbgE/Az8BPwbuAj8CFwA/gX8AJwH vge+A74FzgHfAF8DXwFfAl8AnwOfAWeBT4EzwCdAG3Aa+Bj4CDgFfAh8APwTOAm8D7wHvAu8A7wN vAW8CZwA3gBeB14DjgOvAq8ALwMvAS8CLwDHgKPAEeB54DngWeAZ4DBwCHgaOAgcAPYD+4BW4Clg L7AH2A3sAlqAZsAF7ASeBLYD24CtwBPAFuBxYDPwGLAJ2Ag8AmwA1gMPA2uBh4AHgQeANcD9wGrg PuBeYBVwD7ASWAEsB+4GlgFNwFJgCbAYuANYBNwOLAQWAPOAW4G5wC3Z/HMOMBu4CbgRuAGYCTQC M4DpwPXANGAqcB1wLTAFqAcmA5OAOqAWmAhMAGqAamA8MA4YC1QBY4BKoAIYBYwEyoEyoAQoBoqA EcBwYBgwGBgEFAA5QDbgBLKA/kBfIBPoA/QGegEZQE8gHUgDUoEeQArQnWr/Bzfn/4ej8n/agP+3 I5zIOFXt7a666ncGJTSJGqmJVtNmeoeZWDpWv1H7xeMOepZepu+ZgUWxoX/rNxl/cegj+S9DPd+6 53l+8STof3CfdVcZwjwG/XueYPUbUadfRD7uSZ6L7nnuk54E3fPuKg8ZJnkSPN8rTjLJHnRzKBBl P+kn6Rfpt+hPYF7ab+G0X9r+3WMYfDCe6uCHa4Gp1ACuorGEHURTcPUP+GMm3UCz6WaaQ3PperoR fCvdRgvpDlqC60aUiNp5tACli2npb36nswAtF2m/37nTW7IUvFxry/sQv+75/W97VtIqrIj8Rc9f /9LnYa3l78vX/sf262g91vYR2kibsOJbaCvWWZT9WrKNttNOakb5Rq1kB72Ds43c9Atdpu/oPOLE wgJZB0RLfzYMOaOO6jUvVcFr19Msmg5/NWp2zKP5mCGf21zNB/M0n3H/CCsXXPX7pl89cI9m/xpY we1ahTlw+4Xtj2plYn5/nB2vfexK/Z/Nf+OVNk9gti5qoV20m/bSU5j5Dsy9BVd7oB/H7J/weuRJ 1LjgFdF2j9Z6y2/qdv6htpX20wE6SE9jJ7XSPij+KcsO0RHvtbh6lp5HyVE6Ri/Qq3QcHn8P6kV6 hU7Qm/SWdn2SPuG/cKWP6XOswymsyVn6jL6gr+kblH9H39N5uog1uoy1uoydy9cpGSsVgT0ci9XK xE7WUQWRzg97SSUjRVMqVe0jB3ugJdnfl/87ps1m6mA8hASuUBBSvglvs+lOm07xXWOzdY14oIPh fjXb345vfbu76lazXMpq/6j9NXycC8xMOcdSTrW922Y7fywgM6Xt6NttqT1YQEyAhmA/xWF0xKen ZfTsrjgcGelpnRSWFhrCyzt3VzJ6DlB0fpcHqxXtOuU6e87kQl2tYcaKbkOvczoSpjxQl+pujU31 DbMHBkaH+fmFResjL53VR/6SrZvwyzrli+Ty7Ph1lxcmF6ZH1qYXT27/Oj3W2y4w0B7ux3/vZ8Gs qzBrI1StM9Ci6sw6vUlhZkZ2o8FsMeH7pbOjoqrmrmbDcmW9gkNnNGTr9TrGdLgZU01PCdD+stIx 2bGBmX3SU2zn0lhESnp6h/DjaXMXHznCvJzaI8ahxqgOlh6kqrqq58a0n67ax1ouVJ06xaLcZ/SR lx9RDrTn89/DIWupP8GyAOpECZTbHBF3AG8sBgpkm/b4GiwWA7WyTc6AaEM334i22FhD+BljdtwZ A+w5l6V5PZPZ3n27DS4PzITvj8Lp3KkxATH2gGCDsZOqah4PSE8boARJ2Uv9adDiw7PcW9kNbE/d jIzxhd2+CO83aXhrS/+JA+MTuxU1Fu49+MBqtnjcytqe+kj3c9euibX0GFrP2rsOTO/kntyhV3H7 hbSi3p3cA2bgW0+V53v1jD6ROlLfXX4dO4Xyf7vURyGgwnaP8GN+AfxbuyWHDrAgNIlgfs1KHiLn 3XPA2HMwv832LlwWa3DYKQCRkJ4WGhYSF+fo7KeEBAfC2t7qmYe3u792v1ey5v07xqwtHLhmdNV9 9X1ee6HswYGp2WwIy3vY3Vwdbd8Zn5C/8OnZbrc73sFXfRoWLgq+9aFQ6rqPiB3dbfNlvsHcoxZT WNAZc3bw5ybhSm7G22PbNPfpNPeR9JxdFxXlnHTvkbnuL1gxS2PJB3peu2HqA4vYIWXtuO33zh6Z Ahcdde+885kbMi6HwB8vYU1dGNdKqc0GCx8tGLtRR8zHcMZsZvozSrblLPt1CTH2qSOBmdrqxWDo EC9UV3uE8nn7K0p0e5uSoY9c7b5utXsA/33qcYywAyOYqdtu1WxUDK1si9PXaFE+0euN7Kwp24je r3R+/qjtSCZmJrp1oOMd7e8ofu0/7FXadAvdFfe170dfjHI836oX9MmIw7xdwTEUegDvzUFkYkec 5phuIaeDguI6JrSy8N0j+P+F0sr898Tl+H7VMY/Pg69kgHe4trfPHwvk48k17KTw6OsdEJMRE+Cn yg3Pl1n9dtCDY+o3Tu/bY9L66UFJSQk294/sQMKY8eOS7njv/uLRj55tqlg/SNc3PnHw4kONNx26 vUBntBjYhlXttUGdgi1lj13c+IineWx0Z1g03buTrJTebNLxf0rWmxl3vo30PtZs0+eqqseOziXu mixuaxazHUs5f0z4HW6Ba9Lxma7+1NL+QUuLEtuiVLRv0Ue2v6ckcK9vxwj7tRG67mFmq84Et292 Wq0G61lzrp6wrHBFGv5Yyvl3jthOHeE+z/AuZ0YMO+l+S/Vzv8WSL//AknWLVq++HLRmDfr9Ev2e RL96/hsHHXvcaSZmULJ13hiBS4+3aZEB69ST7bY9Sl9kv7m4MxURnqG9GTU4o3x9TCarxT8wQFVx v97fPyhYrws3hitOs9O/1fO+M8LfrBh1qsnoYzBYAwN8fbItFitjZOXZzZvb0nl2CwzL7MOP9IBA ltkfCS78SFomT3ThNq/QMpxqVB1qvKo6gtKDwnoHpesydnSw9n92Tmt/XdgW51uuzN77TqopLHNv +0/swsvufZc/xkYJ3ryZ/0Sb8f8fQf0etvtS5m5m0lusPPHhTREr5m/wzVYtqsVkzDbkMr5gaVlZ 6ZmZc1NuSQnPYiltKW1pAZmZ3AimBvBlY0EBWLfvv3AvvH7zWXbdws0Y19A+zT0Oufay+x3lIL5g ISNk4v0xBREeRPHU5SAFayN24unA0jXiS/8cxxf6vCvpIEXLBorBICI2sFcv/tgy8qzwm7DWpZQu e3rKrQfm9CtZdhB8S/99juFzRpXNHh7XZdjNI8tuHhGnrHZ56PHiMdv//dAOBlG17eLjjYebhhbf eWDKzMNLwfthm3wS+FEYdefZ6vld/qZgI49gX1N48FmDwRTUZs42XbWz327zpnwH39magXEyyfe7 9ciSjS2soaZlcdG+x+7du3ndNvXOoodvGeZO1EcmVq+Zdesd7Z81YeytiKNIjB1BXWiI06xEMIoI NRMy95FdHSzRZi2HWWJDjUfsEfYIS6cz1mxLLvNuJW5NZop4EnGD+O7PRKyKIOmuXrGMP+6Nodj1 XgvhvMiXng/tnpEVX9bCxs3YNCW1y8Apeb2HdR2+8MYtK7LqBsazjT2yYm08P6WNnjes/7TKbFvQ +BGKYUq9uygqs5TH0XRkrbNY0wwqaI7DQ+YIVjcZdls69orbz/wp3vOM0ycgtDC+2+fJQfqYHCTk 0N1Wv6/03ocQjG1/N5F78wgy1xGvN7Hk8RmhodxIvLMYRMLqpIgHkwGLb1DPDl1yuLHn5PFlnYcc uHHk7GGOvtVz5s+p7tvnhn3zY4aNGBYz7MHCB1Z4C9mEsXeN7W7ysZm3d7RHZgxNzRjSN7Vn/9KG Ybm31Q0wWP1MG0LDJo3MGNovteeAcv5UHYk1sWnvLFHNpPBMY9arTHfWkK1qIYAsc+z8MS2tO3hq 1dncc3e756r7dQt/matbuIb7Zhp8cwl9hPFoJ0R7CPlq0R4elm3NDvxERHuWlrTbfp15BlZPC+9e UOql/jdsm37z1utSW6Jypgy9e3ELe2Hqzjm5zlmb6tTpl9cPmzm866b71PF8vGTYnKnloyW7fXXI jK3ssz1GP53Nhgl8vpcZcRKi6aE9DSZm0gW2skanhXS6oGCbVWe3HPK8Tz6e0xTgeYP8PaedgVb/ AB+LzuDnZ+SPNARcthZwiH5vhgrwpqjwt9tseHxrgWhry8SjSHxiTjxH8UQlchT/0GVWfL4xOWX1 x6O3pPtnrZuzt7+uJ3+lZCfue8SN1Hp58YXX2dn2n7bvVvfxrLEIXnxWdZOdUmjI7pAQM4vm//XT Nya+lb3s9Df38HmV2akz69y5g704pJUh4QYH/NyhKOmirkQ8HHmU8XdG8Xg8AtMyU7A74mVu6ZWe ntGTB5YxY4DK4ywkQP01yeAFKFZX8sTYkTePiG378I0Zs8ofq4gpHj0hbcw9db12nsoe1y8qsKuz e7+HRi4uLkwaVt///m0VldfFOR72CQu0di25pax9KHupQ4/cblEZCeGDRmBGGzwXEBeLsFPi8I5i jT7AduJln9gupy3YFO+jj2j3LzKXdn7LpMcE0s9pW1x7z7T9ukHi4uF84++TojFAbBn1Uv68vTMq 94/ZYRqybcLI2yqSWsLShveKyRtU3D392h79ppWmKqa5R5cO6hyrH+yes7+utHDhvptH3D4uIyS1 uJ87IjgsrnIV4mmd5wd1u3qJoqhPiz+F8f9Ibejk18rMTvM8f+Yf+LO1CO/HxqcaolhUh0tqCWkv IlfeK9/WXivhY8q4+r0yVHPr9rzlQ791ewbfsb9h+JIB2YsLc28c3bP54YGLBsR2iGDKTzc+1zQk NGJz5+j06qZRe/fY7fytkkcDfBdMMdSz2cfKQ8EUiWXf5QygziZfffglW4m12FIa/aO+SNteWoKU K5/aI8hrC9zn8EZAb2FPgJZcphUs2DO9x9jknWsNg7ZOHLlwVFLLdRNyVhUn1qffvZ61zX9h6UAf X7b50pxD104qXNg6Z++uG2ayN4NDWnmszoJ13yNW+bcJ5y4fnxD4Z++u6JAEvBE95QwJ6RZ9fLmO 6XTdupzoUOT7jo/xoq1E5EH+TNHcdh6vLm1agDJ8g4gJ1la0d4iMVZEIjb28K65+ryjtWds3JlWU DLEP3FW9YP+Nmf1nbZ06ZeP0zD2qPbc2J3NcXje9khibFvrgY0Yff/Py4IiCRc/efO3Ty8tyZj9Z kju9KDmpqCHX+/9l4Tm0EnEZTFnNenwta3FG+lmtPkYK9Qnx01+0+ptMAZagX0i5GFBmKUY2gOn8 xTMzHQnRdsz27mu4OKJ9D4IvQ0K8b7wZMRm2mLQwpotcOvFr1uoubHY/zXLZxvpbfzmrOxN10bWy vbfy0srNbGW4u5F/LxvnrtIFw499aShV07KD5Mf4/4I5jDU/lUrWJDW1L96Am52+o7qkjkpIHTUq NUGNCTvAXqU86sdeccbF1NiC3AWFBSWvmLoUJKmmXlTACkwFpppefd++ZkTVK72Ksk50HKm9a2Tx CSBvjeUUkGk7F5DOv1hqORlvYikpKTyd4akahqRm42k61PvNOQ7hg1AO03dSf/0q3at3d1V+ikCL CWHB3idZXHysnxrkfXXJ8O5atbFjdGb9ylFZ19uDOgzqx0xD5o1Jv2b2/vk3b7s+LW9gh7hwn/7d gqJCrJmTV1bE5nVgU9vVe28v/Ud+p9rJ7ksxieGWDPs1I3r0LO4dJVkd5xjba/iCqvTI4I5p0XFp ikXp7Bw3IPemMb3i88dnDro+3adLYo+w7Kk9wpLS+8bxlhbT3ZcDBmZ3Ss2K6X+N3hzaLTFRje5R 1Cfa0W94N85d+g7nz5gNWJ4XsP/CKaXZ38ozlw+Kdzr9mU+Ezar/JaTIr9RaTMXy1eTXvIV3/J5x Ik3xN30jT7WhIeoLO0YVO/rnDE/fscOQMGJESdLqTcqCmY1BKUX92ifpF7knr0vN7Rb4VCvik38D OIH4NCMjZR8kf9aOVyYd4sDPzHDi+7bOfNFYjFeMrk5LMJJpYTD9qI7AMn+UeC5LW9Tj4hGlPW75 FyLtq0GQ9+1I7jB20f0eO8kSL3/ABvePSosNCYlNi/KyWrXi8mMrV+opJC41qmNaXEhIXFrHqNS4 ENi30F2l1sO+EP4d7iDFwr5ICkLMkiW4W0A3Ax695j0W/58NI0M1E+3cRHvQjyRNFLsJZh47JUwM 8AZaRidVex2IyWBX2aoW9mt4dNLgZZnRA4cM7TLjNnewkn61yd9cjpvyaMM1keGbbR0CzSvuUotW sMek3XIeWNu92P/xWFsL5ezDF89vdpnNZDnEPsJLkIqF1mGhzzttTGc1j1AsRlWnL9V5VxqbI8u7 0kdPIwW0aV8OtHVm/8Xel4c3cWT7VnWrtVqrJWvx1pZsy7tsy5u8yhs4NuAVY0Mwlm3ZFtiS8YJZ Q0hCNiCEJYSQjZBcXrYhsYHEJJkkTBgyy+PmZkjCbEyGOzeTmW8CA5kMIYDFrapu2bIhy33v/vPu 9yisrq6urjrnVNX5nXO6WrJDgfXv/pRDh+B7f/YnUqbJPzObrz8Bf+nPCHh1H6I+kS99jIylmh9L KRlL8DHdSJZp0OAFD13wUAkub78WsmMHbnUx4iQE6Y9UUDUWacC7pExyiA+pcQgxXnHq5fI0m/By Ul3oZXNdZJwpvNZULw/MWqQHOLUAHbZLDmzaYNyIUU+hrCU4a9dzExl/qtV0n0ipV2vNVhv7tEhp UGtYa3rM/s1iU0ZWQWx9kyEt25n0Y+pDW6FFYchpLZ1cR72dWxGv0GYtnjO5jv7iHUddhn65D69h /9nJuMB6Q5zo0XqjwvB60wMZXm8hegMF9PWyetU1UR2eQRjrAuuNAF2AMnXQwtv/uCilAS2yx58+ 1LKILSqbn36I/uJAVmWS+vWJyZXUplUruYWHZvPtyFuTop55bw2ZJwgWohDOYm/tG2Wd5QrTMB28 CbZfAyA121eTlq0fX9n30mhJ4DieOK+/fIFvbkzivL4KfIT+kfe2IJv83Q0jx9Fx07v3LN2y1FbU fV81st/xEVtP/m76KqJLC+JA3mG5lBXjgZXGA2ID6MTy+BDTpKoupFay0HKaI7GEU/LIdcU+ErFL A0YUHsBbWVE59NWae4540pdlHHpcVoMMgRlWVPpy+7b9lPjen91TJg3x387c+3zPTTbUO9haQbQe JzI0I2tFLMXWSkiElrNWLHJJrPGqskG6UFLHfjRlrXAaYJa1kosIzeWNFc4o5a0Vx+gbm+xdefte kTx0ouWuRcnjRvv8LGSuJLgdu/bBc30/2dWsUluv9sJ1Z35Rdc/E2qZ7l2ZigyXU8BMuViYQE/oy xyjNm3CMRJzGnCpJqJZSi8UgtD7kGhOYXhjoZ04wLLkwkSUnML1+/jTT+qOWJ54Rvko31lnm1jSl v0p/cWxF+y/ev2fUmNtcNLkOr87XkJX0Juo1GzQeAynw8NHw2PBYKRq/o4fV0hzLGxCAWOw2aoxV sdbL6hQRW4ckxzilT8tekVEyxRVRwNSc9h5xEBZph0AIEetMMowYZa3TYKybjorpo2j6zdjihqUd tu6XGloONW9YHZrpWVIx1JRubdu/uuDhBQ27ckpbcw06R3dD69p5MVCT3VSaFqXQaPcbTRUl4cnW pHCtfU6bM6mr2SFXPa4N1Vps4eEpiYkGk2NOC+a0BFnQP0fesR5kj6nkWPOESUUisV4pNohUX4dI 5bXgml57heaNQPspouc+wuFIYkUR8zk+m8Tuckn8kDedf15wR+mP3/B/Do1IrfqLhgbSB4sVSvlL Y1TITqhN9b+z00/1rVCqsAZB0n6f/gKEgdQxCmANokVu6CtOhVRPAV1tSK3yKpJnfZACOccpPIsV hwvjiTvKhRDt9PtPCFPr6+pTH3/q0CG2qBypD6I8XpugHp6843OkO4qofTiWiWO/qE8xcDiVjBAC ViyiaYl0LQ3piRv/5pTQInG9UMjgiZWZaSuxO/KWYn0bCOefysTTi7iM0FJ28nJ27lfv+Ff9jP5i svfAQWr3dfxdPHGojzLy9PJhp5URCIUhITKRVCqTScQCqFaraAFFKZUqlQYo5NjHVRAXF7u3f8Tu LXZ1nXqZKkSplgpEcrlIIq4ViuopWK8hVJXYcZr2de0B+vhoHPZ9SZwlEJVTc+nbvN6ynad3RMZs ObXjxSZN8s4NT6YqFyBg1sLnuvv8HYix5r2b0UiWb95GvYJnzhzEXSLiTgZOj1nEEzf+4oyyWCjW AoGcFoRIpPi5Sa1IJKylaUE9hHj8sBy5/9Bmt9lVJzPR/5qGliMUFEppZbgzhGSk6NPSAFXJ9ylO qDbcJz7RCvJwLQYKJQJci2QkzOxauI4YiLg6JCNBn5YGcFNLMiDi+iMZqWx2LWIcQPTfjv8LEj/3 X/J/dQ5u9m/7FIohfcZ/H9zo3wSvwK/8d8C7/Ng1BgX+djKjDKDOKdeGGgCrkSBL3GjSTdz441Fk kWvqkXlFO5VS+Q2YLoDC5lCt1sDPL3uJw5HHR5vy+HE0nLCbuIkGIZnngYBTLuQGLNL/YvbKe/d3 mpKMYVmR6Y3VFazfd9Jvz/8bGrc7Hji5sZCinqKZiJKuuXhePrGf2o3ofA7h9SlEpwTYnCoaiMQU A6UiVkR/zdRSiNQjlPgKHqzzmXn4D8e9TmSePYGjdci4w/FqGEOfun6Gyp08Q12dPE0t2ECd3Xn/ pA21Xcf7Z3owb0zMYO/MotTINVKpRk6rgMioMmiEl8UqlS5Ej100XZNCejqE9BXw04ib9q+qP5zk PBvVLFeNmFRT7tqUtwZrrv87NAdcNt5hO7FtG1VIXDZM2Y0vBRmIsmRQP65TyLBvFhttNrNAnsqm mEMuK6SWBKWRZROMydcAczmhKewbneaysSHwIIoQp3Gg4ZmmkDiSON6RxgVjdNPqL+ANE1J5zS7I YCvKneEFHZXx8GN/ctX8pDo2bmlWcV+dzf8baC0aOtib/UCx4KxYLmGii5YWvbrDf9/yToVsd4jU PH9dK9y942DXni67Uok94QeQ3j5LPGErmMN5GgxgkdKURkZaoxJiIlg9wCa8WupUa6ukUV+ztdpv rLGX9QFvHlnzai7scAIZkcQ6mu1kBPHAs0XZZlnu8Jdxy7KqVi/K8L9MUUtakxrMzI7ZdvvVUY4B Km7nZBdmKJj+aGAHc44BG5wcj8PPMseOhqlUWdkspl2X5FTpq5JM+ithoZdNdaJvhPRl6fSIqAgL yAQ+eekkZ93NFD0fMONsJx09iztq25LFSfUsT/7ixUmNlvj27LlrWjLaZvNYFzwKK/DJLjk6Wd9K nbnJR6FAFfKxhhBnFuAAt70FsuAN5Gxp4NgRi8SUH4v5Ct1oe9r2iu0dm8AWFX7FpL8cVYcsROkR ieIa0xzEHom2INYwc3Gz/CxiCgZxx3v4U9YtXVW69hVf/d5i84LGhYl37Igp63AWrrZnrq+4/YlB 57JIO2bNHhkSmRFLeNVw/tfz2P96aCs1VLrEYSR8xi58aDktgKjOTEYBhNloDD/looRjoTJsMirE WpmYljaCq6GKywGbgQ9uBWJtfPiY02T0pwWPVrft7s4ZH14fWVFZERUTZkxz7ekVCK8rHrhPJA/F 35AyPVeyxsgccYaFKZVsjP4bNC9UQGpqmjE1iMk1NTO+b158+zyYMe6Uf0XH1AmiqQ1pUWzjh4PS I1qtFGowWQqDQWrSRxi0p6EwDGt7mVOCtL2wzvRvxIPmySMm1Am07Pg4L+TcoIDpJyJazq62ZMPT wtia5q6i9M6EdG9qduO86hSYPLngzBnkESWXpxmk4heVoWEZ83Mm/4F03ccP8s+Wv0B0GUHqYXk4 hTzLsdeMJkpkrA+ZgCGvyTU3RHWwlouL8baUQ3VyyhfDTzA4bcbZyimLu4bn6gsK87TsnNJclbNv WaMVG8zZ8zMMjEQuPqTUKoTmosaMyY0YAzvQSGGppIO6ozKZMDVWiMUSog1HKSMzVpikTMVC0aSB pLqIr8MNl6PrQr6RSS4rp1d1yVmiax14/Lhg/QlOSIQmPJQ3j2QmITx3Soq0LbtpXk3KksWNZZbF 2Xhcm+fJ9HJ1tCp72YICFWVdsMjNCZXu0mcsyPFPLO/U75bIAgscUjspXVpVFp02J50TMuLtgv9F 6kNYhiQbeQxoKeookIIPjMoJmDwmxBCGN7icRCtVH8ZFzgJOJlmXF+ztt6VExkaqYuwWS2lGZNGa o6tPUWHJzsSkrJTMJF1avCGycHFR42OrkFlFwX03LlCneM/WMsYY8Tt4SosWv6kR1YA8jaQxUMd5 tgiCTt6sumfHiyh7dF6S0ZiUF83mJhkMSbnsrHPaP/vipGV2CVrxmxFdH8ICRFfYW4ChaKDEX7E5 hlceIuUWGEIlm4tSTabUIrOlEB8LYYEprchi5k7MlqI0E9YkYvgB3UYNARqox5EBfgyKkcCxQE9x oRS6bfJFqhl+8NyNG1BMNaC6lykRxN9BdzeS1suIqiNID9HI7rDgOMCnKCuBV8dDKcEEjD+saACN eMb/KyKRAAWye2+S0L7wfVHLw9MtOp0lPTwiHWnF2HRm87WrAuG1lbrYjPDApXCkMBFxQzcSSZSR BganFECaAnQjpFoBNskR2XZitVkg/f5kw0HqELP5m+eEt2NOUxA6dDAfAjnQj8vFFH6JWyrqB0jt 4+fWeJ8LJJtccvVArdXoqW/89oz+w3e6/etPvOu/Hb5EMWsuffnlaI9/kz/tL/6mt3GbAtRmfnCb R47IRPgLN4PbxM9WrTmabBWE/fBUyvLD97vfe9e/gfnQv3Dyn31/+cfVO3qOw+f+DH8P1wMk5RT/ T+gOYS4lhBtBNzoXoPN8cn4n6EZ9tvq76TnM80AEosZFAtTng04Jw/yK7hP+Cizkp+Y5bocDv1ll jj8Unvcfg3P93aKyrd98gilnUStyvhWKEU3AF50SgeBXwj76V3BWK5zZR8tRK5X+N1FL3VuFSVsR Za3+/03PESoQZXcTSll0Lifn9yBKaeDDO0iZMwiE0xEiP+KMTExKj47Sh4EwSiJ1ZGh1EI2nLiwM moRCkxK/SZllQlrqhFMRm898LpRQSVSS5LNE0wTUOA3hUVEZn+u1WY5oaXqqUJ+IEgxbAOcDEpSz 4Z0RmarzmSoE3+eJ+vqEBJ9O8DuwiDumwlvA8D8Vf0Ts2fFzb6S5rDyQi0SW3Hhi8OtDudhAroiL 5YfmcBEDqm6HKcuTmjuQ4yi/x1NasfblnpidMfW7ckoeWVJQekdncZb3+WHthqFlbSX3rTNlzc9i zrzHqGT7FFrG32QqahysbbprsZ25cEGoVxwMi2DgT4z59d55xWtcJcI9smXVla1xkw9Lu5pjHWkJ WvzEY8MNIf05kWMmKADbnabEpMwpORbYg+SoxO+T5mAhvoGEWMhc4oX4dyxEExGi/bxem1MQLc38 rwrx/1qCCCiCRBiV1ZtVOJSTXX5Pj7N8zQs9Mbtjau61F25pKHCu7yi0r3huUDO6MiKj3Fp630h0 TnUSc+ZvIp1yr9bA+D2mggbf/MaNizIE1/1MWMiB0AghfNVQUNtXXTjcVsTslC2pYrNT4lSTT0na G825qfEaJMWWGxcECrLDJAbYQPWYwYzfGSWxwW2HtdJ0/ZswHMSDOBjhVBvMWkM8SkzyBWVn5AXG ze8IwyJyOFRIOiSsZFedy7xVbDPeCrGxWEzFoWnD+ygCReHao2s9L68tK1rz2hp8fJWhJ88o00ob syt8C5ImX0SqLFGZ5myw41Nq256vx1y1z/kP7bmCjv/iP2IuZ/3urJYSS9ldx7dEF0fCx+xNReay u4/P4M2KZkjh0dzU3FRt1JtwG95fSdgrTJiAZqcsM5MxIpYs0yzZzvNROxIj+/5I7WycwXxx/Ezx FTlnaCHmIaqSO/o/NqWZQ0PNaQh5zFqtOTWIua/HOjBzXe/sXlx+1/GN7rd3LUb8QanWkmYycrWN pjSLFnsuwVySqPM2EnXeRqLOwVz94Kjz99P+vaQiRLoPLdLPmBgka8dhIZQi6/Ntp0xE07IQ4XmG gQgJIw6LOyQ0WoJjsIvbiYYFTwxl+7kTZ08SDz9GzVjj8Eayz67/Etb533fC/ftg7AH6jRd3/+7a JtTPLrIvKxWwwIGfwbx11Kg2qtnoCfgnZwiMUcn/IRADbSeFPLjwMcD1gy3yk1gcp/gIKI4kFNPZ vBNj5U1xsmpj6IvXn4UNjb35WlNOc2Hj/Y726uN3Ltre60ioX9d0nlr3BKxrWN3ZYk9fVBZfXTC0 oC2r46HWmjs33l//OY5u3LhAn0HU5YDFx9Co7HTKbZl6W6zeZtPH0hK0ynY4I9WS3EzD++rcV/RQ r0/KjbsUG3MxqVP8lSTkIh66IIcfb8nANvIn59RTD1rPTcfmpzcAcZuWyRPU4F0a3A7bM3O2frRt wfqc4gerOra0JKQvWlP1yKMFrsq4O9eXba0zz58/z9L71PKcoS57Z20G3Nb86MpSqfgJWYilrK0g py4nfHt0/sIcT7vJtDckVC5KbVpdM7A3VZxeg5+BJAMgyGDC0ajLQYVTEiIUyYSMTIIA+SGnTk7T gBHK5ZIvBTIxGjaRuINGI0KChhocyFAjW+UEHv1MPjiIeCO7sbIhOoEwRpDx6fjkFir16qd+n98B 34cx/k9hzGO06/rT1LHJudjmH0cS/wBREANKj4EIuPQ1vQklGRL1m055qMwcdiEiwhx+ydCB7Fbj EZliSsaBZf8Jt+hVQUtlWrJ4Jxi2H7A46Q+adv1sOLK8rMSYs2Vu3Z2L01957gr17uR/DLaNb1kI D7j2DzlpRih4Sh4SP9ddstZHPbHXv8O8cDuS0zq0agGhMhs4x0wp+NthpBqNlMwInVmak3LeZD0Z GZljZEIvaToy3p9STZjKs4EAvm22rhXY7TriLs3e6RJY3KB09Qs9fQcH8k2FXY/8YvOmrSMvDxeL BSX/0t75SGfma5HFy8riF9RURMTO7a1wLKu0wqcWPzVSXrn9t490vXXwwc7cvXndD7cmxqXm9zzs KnSVxymMrGbTj3pT4qp6sPRH0LD+FfElBDGv0xSEQIC33pqOMB0UXuR2sg/sBEJN3iDFNtRfJ3// PuWYLKaHBWuu3SdYcwDp7lG8LwStG4xK5cD9FkiA24EKmNE0kprkkSYVSlLwJvwxsqLy4VtOo7Qi NSEyO12enp9g1uXL5Uzc33SdJdMa3WhzcPaOxvFTtQMaiDJUB7DrnGqGYsxBUD3tL3Hb0vl9dJQ+ JwdvTLcq6IDCpC9WrD3oWvGsN+/erXeuyvI8tcL9WG/WxpH8rurEDzasHNgQVdJWutKrMRT31lUs dRisFW252W2VCbCqcVNLWnrzqrmrD80tfbqnZNXtucl1g3MG9xdGzmleTnW2Lmputpbl50VmD00+ HjenoiI2prS8KiG1Mt0QlloZQDjBNqT7o9HKq31NH2uwCLTsm/AYgbhjCOJSEIKbQCywIEtHbWC1 hliUGOtFZU/4xW9DcBVWL98C4dxCIBDOhQcECuf6IyPul9ZX4mPvS+vKJ2h68u/sqrbyFfMSJ9+g BZSCXXV7RV9NAlW29jcHllXt+sOetWeeaave9funo0si/WuqF2f3HVgfXRQJ76tenNv/LJjBGcbu ucdAKvzscG4uhm+eN6cM4Xd0gi3hlQQawbiFg3HEl+ViEIwvncJx2w+AvribYPwm3iLKB5owL+Hl Awsxg/6zs2F8isk1v+aYbHl2fTVia0XzM+vnIU6vYRTnK5tmoDjPL0HxYwTFjxEUD2bqh6P495L+ vZQGUFyw6btRvPv/GMVNCMWvx/Aofg7xHwPyMIr/mKB4DALt/3CqKbNKfjFSIKaBtodivwqAuP6H griSiqHPXR+H8+rdedrwvMbc+nscbTXHBxbu8BSYa1YtPBlNte+FUmdHU0NGSl2hpTxv5fymjKX3 NBWvGh517gkDBMdj6DOIvixQx+G4LN2QaoiNNaTyKG5US7LjLiDkTkhHWK7XMwk94ksYwT2BKKAN Ybdq8pPzQfitcQSHUr8VvQOscOhdtfvf9+X15xSOFvbtXZaM0futtzF63zFy25a5JU/WuB/3ZA/3 ZnXXZfxm2YGRMhGzlxHHV/WW5jflGLfHFDXneHoN+kfCwtMXra1eiYF7wXI8A5NvJAoyBOumkJsA Nx2M3IoQiRCZUzIRhLSom+4l/hEH3JmZXODefumnyB06QdR73Hci9yb/87BlH91+fT81MVlFcDuG /gD1H4PtOITbRzFuS0IxbKuBhMA2g2C7W6LgZHoyyE7X8FNgRlT6ZrhufvqPW2xdSTp7Xn44Rrtg uL7gen7DXIZ+ghYIqLTa/pJ1PurVvf4NlqZptO4mTwecY4Yk/A15YpVKzBK0BuKspJ8a4k6GqcLD GfVF1XLbNFoj8QTQWjMDrSn1DwXrjz+PLPc++7vtm7Zsfu+uSqGgcH/XNFTPv608wlzZUzkN1TAO RnW9//qTw2WP1t79fGt0fI7Tt8dV2FOTrDCwmgeO9qViqEZIfSOR/iuStxCYOaRmCFIfZbqpXojH lkD1qW+Davo31+oErx4ABKv/Sn/JbAYWZMvMBUNvgRSE1RoQCx92aiKUmoLojAhNREFGREaBRiDN eRO+DQAoRr54uLQqI9r6fk5xbIpAv6KAiVYqhWErhO7yv3PiK8Go/VONw1Cid5xXO6Z2GBbZbAZi +xLzVzVLGd4auvkdDMU0wW7O8SbY/WXl+pfcfc94snRF3paNGwLo/cDG8v75SafXrcxtKYoxOVpL 7C0lsRpjUfe8tXfEVSzLT1hckwEb6jYvy85ru6Myuc3VkV760qjzTneJvXXNXM/rZea69pXUo0u9 kVm3pVornSUx0SVllZP5CfNrquMqttXZF2SH69Orb9wAp6ge+jFmDyWitiJhLkAlf6JGaR/zECrZ xpdcRiVDpM5DXAnUoLvaSMl2vs5pVGcvsxmVPMzXiUN1OkjJDr7OBVQySkp28nUAuqudlOzi61xH dZaTlnfzJQdpQB8XXEAle/m7WuAovUaI73os0DIqUZCSfbgErZlTN4z0Y1QVQTQzRrQ9BNH2OCVS 44TSZXmdWRaIqE0/UPp2PKMfy152f1P1xrbsrHZ8XJozHplZGhtfmhFBjmXpEa917fPkpLr2ruh6 nBwH63sL9VGl7ip8jC51Yz3+JzTrfZQTabn0MYxmu52htBCKaOERgRjhmbhdQn8C23gvES9eaLOf 5V65YvBDEBGGMTvtm3z8wu/yYd6Wn5/ZAU/33f3E5Frc+mXU+hDiOQrrMBF893W5IgylyIgJ+E+n Eih2yKW/FgG1C0b8DgQ6wYhg40BMbcfx+uxcjGLxN3uiusu/yb8tSVleZr89rjnnkaaS/tq0CEdT 7iDcdGb786lOe2p4WmEcuzynILp4SaGtYX61tWEfgFCDRqINUZWDn2xGwUeRpaS36ePj9TYau0Xv OEPVsnjLREqm4TDCrRSXTDGBxwZpWPLCpgrBrO0WiBVwi3JmIBb/HJDbSMetv7ZM1872yPysFJXZ V7ikT2tbkN8wL6MsQa1gcxNyvKmGgpLSqN3bygrii1L0+ry28jhKIBRsFYsdWQZruHKTOtKqC43W yzWKbSKZmFnRMrfVJI1KzseodRpJfC+VS1DL6ZSKkF3CyAQSACdgl1MjYDBk/RqiuxjkbbbTbcHe JgIt29lLPyWIlYl9Tcais2TziEXb6b33P+Pvgi2f3e//3Zdfztmx42F43m+Et/ufQzKNQzLtQP1G g+zDBoMOeSJ7gBKYoMupkuh0R00mxvjbsHZJyDFekvwbxyfPfcJtVZ8B+rwEMVLpCFJ1OHoeWhjn yspwpfd0hGUsyDtEUf59cyrXtGbFlHaUm6XiHRJ5UU6k1SCFE4/t1WQsxrK4gGgaRTSF41/eGQuL xV9YKlYoxABPc1WEOPq1MKORUR5TtFuP8YuPWCXQNu1K8nSRVciDk47bs8bviCQPL+nRjEWrq556 NsXzo7tGNlUuLYgURCyx7X7k0Jx52uQEc0j1/Ip50cUd5ZaXx90HR5zb9MklVqlEuX5dejEjkgr6 lpTiaDtAY9eO6BUC1qkMQNBvmXaqDa/AAP7YgvGn3f/827DZ3061w/HJUWoEqx9wHfG9HM3vGJAG nGDeW8AKOxH+mGEn5ytqUBKjEepGvqQD9jiVaGKlmAVM7LjeVXg4IAm9g2iimS4hMy2O6Q3qAVi5 hUPIvU2yPL1puHzPk6ZUBxuZlWiIr1lZs/WxuhJzfpL+0ANlc/VJDnOOUxZhK2JNNrN2QWV0rlUv zmvKC1/eZS3OsKoU5rRCa+p8B9u9tOx2Vhmf4YRt1XFxYZYoU0hYkf9JozXKGCIzslZDarJEZ8Zj f/DGOH0c7ifvyRucUgFSaoIzQvoMfmyFFcyJGU8tjl//jA7Hf1C+y6/ZhcaixZ9Ir6FzgQ7EjOtk qgm453VGJvXqWOADJSbjKUOJ8RQ02C59cpLsLyEC0XMusJ6OG/rRUH66d+zOOteDrYkpSx5s8yem PfTSj5ctev3Q3txNib7Ne2qbn9jcHw/Ic8tEWsH3JNMFevKhnrw398THzq2cXW+FZagnR7r31U21 rgdbcE9L6VzU09ttN/WEkfXGRfoxOppDVnAGIyuaLj5azyErKbmMSoZInYe4EqQtL9JtpGQ7X+c0 qrOXVnDISurEoTodpGQHX+cCKhklJTv5OuhAt5OSXXyd66jOctLyblyCZIFcP0EDeWoX4ZRDCtAU 3UjVw3ryfBA/LbNxMTA0+wUN17ufwwB/dR26Aa0U7Y0v0b27yFNG7CPXgMZSGUiAy0AhqECfmUCA Pg2AhcucEQrSeMl47tzx1AbLuCR8PLRpRlcl5z86j/+4LvFC4J9N4l1nN8cBpl5KKqa++ypPtn9H /Fx3cRHyUgLHXU5HZGq0ivuk9lqDL3egy6VTl1kVx7T/L6W+elt8jbfK6WtIi6/2zm9pMqWVxJHP 638o9eJCH3exxjsv6CJ+Jw4m0edoY2B9iGgGMldE9JVbr49z15+jb8d/1L27/Gr8ZteHaOzOChqQ 3MOOAQZeOIqMc4h3lJzA9yJBheZCaIUf9lH7J9v7kMP5J9/kB5MfeOFx7ptb1vHpZzAJroLj8E+U guqnnqJ+QdLndCW9kT4lkKHkEXws+JqxobTvf1oS0sJFwmeEF0W1ot1il/hp8d8ltZIHJEekRmmz 9ID0iqxKdrfsSkh+yHDIQblO/qT8kiL6f2zqU3ykzLpFeubmpAojqToo7Q5Kf+SSOppP2/5b0nvq 9zTIeUOpXrNYs/sHp1dvkX4bKggNCdWG5oa2hrpCPf8//b+RtHLtq7OTLkq3Q3c2TB3WHvZrvVHf p/+1/rphO0rXjcPGd41fmSpMR03/DC8P/1H4ryJWorQ24u6IrRGPRDwV8b8iXo04FvETPv0y4qOI s5EJkYsiD0SpouZF7Ym6EK2J3s2nI9F/ZaNYK5vOOtgytoZtYpey3awPpW1ciomdkSr41Pl9Ceni VMoMAr/t1kU+cR4CFTnDeQoomNdA4FcMM5kTfF4QVIcBBuYynxcGlYvAdaGCz4tBkvBePi8BrEjK 56VMw1R9GWgWJfH5EJAkupPPy6m9ohf5vAL0ScumfiEwU3qIz0Mglv6Rz1NAJH8g8FuAwCh/mM8L guowIET+Ap8XBpWLwB3yo3xeDHTywK8RSoBKYefzUuqFqfoykKwo5/MhQKfw8nk5nKe4m88rQI7y A/yrj8gbAzy3OM/JmctzcubynJy5vCCoDidnLi8MKufkzOU5OXN5Ts5cnpMzl+fkzOU5OXN5Ts5c npPzC4BF1lM6StkoNx94QCcYRHbwEPrrBsOorBzlBsEA+XShEg/KeZH3wYJS0IcSCxpQWQ/oRdeG yJkbHd2o9ir02YVqlpM7cIt9qAVcx0M+XejYT+qwqC/cPgtGyL24hhd9DhBaekjP/Sjh0h5U7kbH VehskLTcT86H+Ta9pD0fOu8lVLCII1yzE7XdT74NDdfpJFSyYJSv5Sb3sqgGbhHzP4DOO4Oo8xJp cJTjq27Sbjf647iclkcnatNFaO5E9+DW8T24bBXph6MMt+IitGMqPKgNXJ6CzvrQ2QpSjiXWRe5Y Q3ocRW15ptpMIfS6UN2AXDyERsxHD/nl2y6eGh8ZV3eQnAf4NjBfLkJ1QHIdZAxwi1hCQ6QFfM8g OR8gd3RNyRDz3cTzg0eTG7FVvNwWkXa6UMkoaWlajl1EkgNkRqwhvWPZ4XrcnS5Sx00o6SFzYZRw 1zs1K7gZGZiPHJ19ZOS4UR9GeZaM5SCRUh8pc4PVpP9hMh5eksMj1UVa9wTJ47tnwtCMccIzfISM De47IJPALA9wNhQk/35ydPPS7efL8dzsQLWxRPBVji5ubPF6ZHn63USqbn5uBHjyEX6GyAp2kzqY kloy1l5EETeHMA1uspJH+DHlVhuW3ghpleVl0xPU9yDPr3eqzEvWk5tIrw+1UkD65lZ4L6EthYwh XonDU6PKzbGZo7KWtOLj2wjUwde4me7l9c4qftVg6gZ4ygPydE1R1MGPPyevwJzC69/F65Y+9Dk8 tYqCZ3AfWTUrpu6elm0nP1s6+BU8QtZH19Q8u3k9DZP+hkn9DjKiq4hWWDMlwYAeuBXdHaRusEYb 5fUHphjr2B50Vx+pdbPWzufnZLDWzQ/S9M08tR5+zmSgNvGVb9PUbn7tuadkPUgo8PAcDk7JgltL bjK2g7wkA/fc+mr3fwl3AsgQkN1CMiMD86uRSH2Ynxuc5Gw8BTMRwUdGcJhfs1im81BJJ0ggfCfy 2ocFcwlV3L14zgwgOdpQGiUpjWDSTMrT+BVt47V2AL8GUAtrUCnGhGktMrPVQHk30QODRL8E2msl NHMaf00QUg5PaZpp7cqNHTcn+4l8AhLiZmJAepVIfvMQbk2vo8AVTsd2EZkMT0l9lPTVSbTwrfr1 3EKbTK+Rm3U+N7MHCKdefp1xbXGIjtfmbL7xdU5DJqC7Esns5FZP17dS5b2p5R8uo+nWp3Uxpze5 2dM5A4Nu5n16vs6kK1jXYU44XoZJf4FZj9vneOUw1Es0lOtbOeXk7Joh04BWmb0GsFTxzBvh8dhN LKpOfk75CAq4yffufvcI/Xeti+k1YSPU4DUwQjAgjYzVAFj9ApuZnp7Nzvd0DvqGfN3DbLlvcMA3 6Br2+LxpbGlfH9vg6ekdHmIb3EPuwVXurrRyn3fI1+caYj1DrMvT7+5iu32D7MiQm/V42YFBX8+g q7/f4+1h3d5VnkGft9/tRbe7vF2sb7jXPch2egY7R/qHhl3eTvcQO4qK3KyL7fd5fUMDrk7SnHcY Nz404O70dHtQl4SOzl7XoKtz2D04xPa6VrlZ1Bg75Op3s6OeruHeFLbPs8LN+vq62OE1A+7RQQ+u mcL2u1ZgWjzDqI8en68LNePzdLoJzQOohs/r6iPEdYwMebzuoSG20zc46B4a8Hm7MIVpbBPqx9OP GEPMs4s83i7f6BBHY5dnaKDPtYZ19fX5RtFFF9vlHvL0eBFFw71YFEiQWI6ozT4fkh477GO9vsH+ /6zuOsCaSrr2zE3oIL0oxYD0ekMREKTZGyhFsSwSQpBASCCFpiKJLiAWVBQVVBDEAq4NC8qiYAfB yrK69hXBjp3FAv/cm4isZXf/73m+//s/8/BOptwzZ86cc2bO3Gsu6lHIShWiETC4NCGfEc0mWqHS L4QgkI5pBE/EZ7P4BCeEyInOBCT/CTwkOiYvAX0XMqI4aTQ+C9FCo+XF0BB9FjcaESJ74nFpAiaf xUJTGpTI4oYiCdFiWAyhCI0UTRuTI4pmIaly55BX81G/XOIbV5TA4jM4Ai+aAE14LCvanhbNEwqJ oSKJyYaSzkKa40WWMDhI6FykO2h6BLGMRJaUTwZBKAqNH/FFSIrPZCBt4bCExBRJBczh8eKJapJb JhJLFJpgEZfgn/d5noQMgZBFi0qjJTP4aQSDhA58ph3F4EsVLQXph8AxmDVHxGHw+1R7GO2T6g4j lX4qIovkTqM74nh/pWaxST1lIHHOYaMO+QQXaJZYCQx+PI0cT79szLdthzAGgrswLpuQV4iQIWSR zDkhAjJD4Im4QjSzAseJIqY1Q2CD1Ic2hs9DtUJh4jAnp5SUFMeET8Qd0UQ7IdUm7CsxNs2JKSRV RNaU+B7DiOKz44l203kipPhppFEKCaUh1RWNDkkygU1OIBIiwd6osIn+5BwRGaSx0SKmkGA9JZbN jO13LbtPTcgZ6dN8JOxEPhs1YKJWyNAdaZ/65nGRQlqzbWgsND3R/UlxPzX+Jkdkc1KLkW4i8TCl FtTXOylXGS2p1lmzUS9CVgIhej4b9YoslMvhMfp3inhmSDklVOXTDPBEwkQRsmNWMuESUJtYFifx iwH9k7kgZ8IpmhXDEHGEjgxBYuqn8yHQ8xasIE9avvwHUQtl9NEGCr29QJ1soYr+9MizGJTDTgLi 8VfQd1YDUOtQtM+kMNP4HKAzh8+KB7YchpALXFENDAkOoAENQNy5AjKk9n1D9cFBk76s/0z3KCX2 T3SnknSFfXQtyStUgBzZWh3oAH1ghEpNgR3a40rr5BEtFdSDLjAAxsRTGyhaoffxoAwU0LhUgSYY CEzQ6jwEOKC98ye+zGVtFJFU1IAWGAQGo7XbHK1TLjLqxKnOAOJ/6gFDtGLaAgu0prkCNybyOdCP xLEkTiYxnMRIwtHAWBK5JApJTCcxM5rLS4BZJC4lcRWJ60jcFINWG7iFxF0kVpN4nMQmDo/Jga0k 3iCxDfkhPnxE4nMS35L4gUAM46EEUyRxAIk6JA4iEa1jHCFmSaIjiR4k+pE4Fi1MMdhkEqeSOIvE KBJjBaIoAcYlUUhiOomZJGYJRIkCbCmJq0hcR+ImEreQukYlZ/XvUig75fweKv0FUpBuKBC/uPiP v5FvFyLtAOtnAfJ/iap/gRjSKump6qdv30sJHf7XUfm7qIWsxREMBT5gNAhEVhyBdmPEiVsGyALL QQHYBLYC6bksBCtkaaEs3SJLK6QjhSbSPBwtS1Nl5YWydL+s/KosfSdNsWBZWiFLW6RzR1GU5qlA lirLUg3yt+QxEAeekTPBBk+lJdg4bDxRAifAiagEXY8Rz2BCjPjFAFugBWfDKMiCPJgIBVAIU2E6 zIBiKIE/wiy4GObCG1gIIXFIPKoBIAMyEJfEG14wmAC5gAKTIB/IwRSYAhRgGkwDinA+nA+U4AKY CZThQrgIqMJsmAMGwOvwOtDAgtHYNIlTWOQ5IPHmDHIE6iSP62AZ6osCt8NKVPwT3AWocA/cg2SF IU+lBFfA1bAAtdoEy+A2uBPuRuVyX7eGl+FlxE0rbEXjxVA/yth8LANbgGViYkyCLcQWYT9iWagG w1gYCylULJZIWgcEBv14In4hCEIRodvoeunpPkS+9HMLzX51iBoUodYAK8LKyTkg+i3CNmAbsU1Y MVaCbcZKsTJkyV/2iwEPMBDLxZZ8i8tvlmVjOdhidJ08KWVAUsMQtSRAwYTYPKCGVWI7gR62B9uD RiSlvx4rxJZiy7DlWB62AluJrcLysdXYmm+WFWBrsXX/C/pGQAWbhSWhOhGWjKVgqVgalo7NRS2J hxFmYjNlNCA5YjR+tCopwMGQBk2hF6yCR2AD0RtYCojnN4j3TEA4DA5DmrAP7kOzehgSt+LPwrPk ynUarWiuKOLyI+0zFMwAkeQ7UvggFdnoIpCLrLIAbAClyAr3gSOgDhDvU0C2AFUg0npoBq0RZUfo DIeinCrUQ6gG9REOgGg0UB0ORKgBByHUhIYItaARQm1ojFAH2TQGh0AbhObQFqEFtENoCe0RWkEH RNsJukB3lOLQFXqglA7doCeS4BwsBqEA46PRKoEc9AFgCfpA5FeWo7LV6EMBx0Ej8uQXQQvycx3g IdAiZaeL5JuE1lTSqknd/2wxhFWX92nr9/Xuk64Cmd+W+ipgGIJSHWmx4QRcYjhGXsk2a2xWlxpU wEokhh6oyBWDkK6CK8nL2Q2gYIPkAM6QV7aTh1QocccgtSQEn4Lb9ysxKjXJNALe5CcIRMmO1Vhk 6OxDfHDTfsSoOqbJ+gNW7fU5MC8neUHQqpXxF8a5WZdIdN/hEspJ9OdQQsEghmmMOTZwze1lwaNH dF1PGKtG34Kr9bEK5RBT4iUkk5Qwqrw2NsOfrotrExlFbdVpLCJA4NJGoGCHroNrEcUK2iojRfwo Bgp/ORwWXR1RQ6XK2vKhsYwUIYtujBsSBSraOtIC2ggWChNj2EwycKAPxo2Jaoq2nqw6FAXZKFxO SCQ2xSP8cRN9NdyF7oy74uS/GfpqdCLr4uzi5unmOQMP6cdsWAhdH9eV9j8ABTzsEBSf2tPGcZmO dDvcRtqR2acKsisiVpH2FYICfjYRpKNOJdCsv1SgHKBIoDpA5cqYBEKwo3HflqZm2m7l+Yt3Zoue 7w98cbte/dgcRm1ZtNFvNd2NLpWL8MXhGUuvx98cukn92KUnqS9TtmbwvI/l71Y7Evuas7qxNtih cuzwNwd/+WG2IVb8zineZEtXWeHWQWexuwsmBt8bEPnEzyjjsNot3zP7b2fXzk6PoztS1ou1t4+h nacL1KY5NKe6uqzRWq91+FasU0X7veO5S21PLDHNjqldGD6NJzrmXWGZ/UOjhq538aJHofXK3JM9 p8bfPKygudZs3nUfq0smqU+K6Q0v2s0GXj9ZNWZE4aDZJSYr2iLePJv3Yn5lFMx7M0nl1kWzqdvX NO/KSd717Ijaq7ZJ10rex5bs0vGqyq6vwShI8cvE13HxVdxVXhFpLPFqCki1xi1x8095HGYZyOIJ HlOQ6JiM5E4cGBDxBKk7xtoQ9lIVcXmUYBDg/kTZYOow3AMfWuJa4pyFyy5n8jl/utpJqiv9VWWE vyNqRWqqsQVVFVf+xAVFER9AFKoTfVGRBcgjDlFek4o0c8tAXP+TflO0VUND/JGieTjQHdxcvrAK ilgMxsd3Pwo/PtKIvjhtvV3BMclO2Go0sXlPbjj3tqJNWcTZxnztDmqwWucYKyfgsaetIT+wsMUs SrfL1900KJGe+WKJR3bVgwdrQc+FsIJA88s7rALTdx1i+L+yPd/RcC3iZo3djz4HNh64dnda79H9 pzLeXFDd9Hxtj90Vr2BDQw+rLt/xyIZ7cQnWIbNjtYd2z1uu2uQYOMspRRQm53xpx/8Wy/jaHHGP /uY47R926oQ7SDu1/LtOiToW/29Nct9k67E3r8SmLzIYGSP6IeNkdTHTsnf4iA3zND00LMIE10RW 7I+Bh2mzrih3lxjaPg2basq4anK97WeX+DOdN8vcWcsN81UPhpjMmhfjNlsud1RPcuDtkMxSMW3j rpxZpYpd9/HuZ2buEwOUz98+Pfhka9hDse+B4DL7Cpj+srRimVtPcfsPcXLFw+PvHSuo62mK7Pbr UCgZ+Vg8hVtu+/Jgrob107wb8iVZkwvnjldUw40bNTbFdz0M30Xd4bd+n/WDPL2d3vdCeBOuuG08 wIs2riqwrxnekfY4Ib1br93yp92d60MO+dmvqU6r6GkJrrQRZgQ88TQpjdNrn15jHnsVZI7QyM6M l5lkIy4+8y+apGqfSWI4wF2kxmiP2+LWJZYl5llm3zNGoUDgwGSQ5qdHmh9B4i8sUL7uH1mg65cW SMxydmrib4HBkDbzTlqDBD/58fDAgtqV4ERtc/Pp1wOu9nZPqnOJwjVPvREatqy6NXsDTXvvvFFH Jzcv7MjUX7jNKn+O9uj3jdXr/ClNRVNmyi1ZsJ33ynCyobnjS/YyjllXTaPemqeqwrrYlGuP10dl 1wtW/LFYmD6ksmzd3LV7u/JskiY5igzH+v/2/IAaLbQ1pWSthMn+qHQh97moRqnoWrdmmGUhw/lo OrZnbtbR0hNLzOxTL7kl/7xKMKv7cPtEXeUhTW2XW1wdx/npeqtHppufLo/pLLiQ+Nin47Vaxo1L 88qSk9j1G4LG4G6me0t3D4rytru2vMJWYe5Vg6pZc3/fWM7r8V78Ey6haiEX8E7qAtRBPVji7Z2j ecnnLfPJbb/+EqMiD5D4ybZVtM1G8BLT+MThNs2aaUOje3q6f3GU50g3wY2kjXW/echHN8UHS6fJ 4HN9MI8npPmLhLE8PluYRrgHT3ecTsdxd5l7cMbpzi50WfY/wNHfLuVYbX1iu9fLQEPr4rWpEfij 0h3LLGb/0bNmYtmhno2lNJ95U0qLSvMineMvBUSnPduZ3BD628vHG7KM8ooXxVSdik+PGtJq7H1L Ha56UHDymENMYWGs5fqLw+yPqR4It6wf3aHs41Fgv8Pac/uTcQsD7i1SrynkhDF2SuZtjnRImfhw /f5or8LJRnRFc53iHR0r7Qzah69j6kSGy7GKjd2Ds7u2da7GThteORY2qmpx5rFhT0JXB+76uC09 QRi426CpQMnaFExbEcl2r5mgpeA9tXfm+y0xyopbL4unTus86BWhJ06h/vb26K7MNT17mhe0bhvE n+Xd+PNzxTIzvEr+x4YqWor2j7dlfmM7Li7HxaWEXUKquBAXr83UmHkxsZPN3zRkSobOvknLe89t 5v/fz5/kb3Sc9AprHqjULXu11sDtaTU0v5qi+WpWpHPxJpVzPnIrc/IahrWbvnw+Ld/+QMmYs1Gd H35t8vKasWNoKLvHPMG3oanilty8m/Rlw4s1EuNqerSCDNh1Hy6OuKc5gxb0KGru7oqBZ+3cLRyO sjZr5VqoM8u6Qo26TRtadV8F7+SOcFb4KNH/4/4cjtqUt7Uvgs/UdpzEP9DoSjnGa2wGTfrFGCt/ kXmHsn/m6703z057xhp3Jjj04H6KtVbvitbninkZ1WtPVbrbt6W3bU+5l1wCLsb51l8emnvHX2u7 W5xh3HW3uy1G1Lbto6hnZ7h4cCcZqUUdUi5deuWXUN/RzUZhWxOvaw3LzhcVb7tcgrzCObQ5qJJt DOJU1gfVAdVKzatmnfM5aRn/L9wC7oy7ObugrZ1sE0/HPZ3dZFlcvPXP2wZtXFMacihPYwhi0XZA iPrRIJcRFHAoBLOiE3jc6E+cKX+Ps+8N0xl1+tUwh+Cm0mEM6l8TzSI3IMSOZDIZGNC+9iZqhDdR JL3JiSbasp9v9/pMfpZ+vMXc4m3yedPeZtupgY0bDkn2uaU5gJPbFX9hNhwqf/uwvr5179KCUoV3 6gclwYWPJadrNU5tr3sWv2h5iGHN5HfRcHG9XoskFviljnyj5RH4njnlzrvhh++7773NVBjileTn OuZ1/K7Rb6wEJmbnAgaaTDkYXHil7KL26YG+SfIJL9eYjpwd8LSuYX00rbre9UPpyPa5+4ydqrfe er35dpGpek843T/MI2N3eEfbk+lpFpVdtk6avh6pPgELtsW2ZZjF6rePX3UydWTwmM1BixbnF9XN mftI6X0WZf7b9Unedtti1jXddvjdDhuk7jqW9cZba/eLbCNjy2BeE9I/SpkE2iJ5WH5rL07573Ax WvJKsiBcFxkMRqEAChmmGg+g6lF1LP6wm/DDWX7oT/ffltjq672v7w4R4wP7LtHBqKomyiAEiFDI PgL44yrk5oeMPUbj6n2bLDmcgpJvubPi6PHCu2yrGX/Ih1itPWNySSy4dP6I+PWgR/lrs3ffyBuG HViiceyKo1AIvfb7aT+bMtv7hHNRUOvD6Y3WoICv+zjJad26Ospdt4CHik5R9PUf6K9uBOy6EZTX 5HEr0d8jUs2btsrOYINCz9T8HZcn5NSuH2+G/cgb+WRl+8BbdtW6+4oS3516HLjQflhSiXP4S7fg 6ytz/Dp5hh02AfsTm+dzeIPOXt/w7lJEbtdl+0Iw+9rr41XFc1u8ekKEtnOMxValogd+6xQMlhjQ VEbzb3d2PRma8Cy+ISbEuNat4v454zi+9qhMk2s/ZMfkGtlvbTzHoFBuKTXAvdPr9nxsj1l77p2S 1zxcIjcauTRHqTtTZig/wsmj24ivTir+W9wG4f/c6M505AFd3d3IqMkdhVEo60ZkcXHOv2UgiGEp bzbfvmtrPY5L3sLm0MIELFoQl5Nm87f7pRPb9C6rtPhGrXg2PdRpjQrvdQv7KGfpMYMLIe+bG67E tkUdmi1UobRX1D/2sXpyed2KIsbUHvzZjiuciTFXZ1mIl1e0JgyBNmtyS6tzfG9NmWy+Orrj57Ob QIfTjKLwD/pZHUzanjSHB3s1ZvMnPrgwKG/iFsXb0ZEeRYHMCW2uI1c7u1WrK/DvcueWV19pruqZ 9ZPzlLsxe0omHVLhUGhasXX2On/kiRuXOf4Mj8hDiY3+NtPGhcvPTIqmXStfKCh4LwxNnqx/qOrJ WKvc/RaBe+7XNExglfp53rrZvdjijuWGdcFltULX4QJ1XHMO7cyI7PW+ZnuZdmLWgHsJcn4u94/f 8on1ku6XJHAFksjSrwKbz15i91zj2EVPz3Q7Ds5KXRNgc+DFKb3877jEHUTpEKp4My7elPlN97JZ uOU/4Ri/3kmMl0aFI3B/3LdkeIlXlme/qPDPd4wT49lEqZPsPrvAibAKwigmy85qAvtFqQG4H+7T F6ViWc7fvRFNkmXxv6In/Fa4CL39885beoQ/LmFeie2ovDItsXNcp1xYtu6J7IbqaQy/qc+ru3BK TPrjJUsqUw1mtjzbFlBft/TjT79eXN6dk60UuU85I5l9Le0klfkmP3TTnWiDV0tzJnDyuA13FL0q cibnKte/at//8vUb76v0Q0p7O2fUBiXG+d07NL/5kbl9Y6TV3ZJ9+60rQs33blr9xnPjHBdG0Ph5 /Oaj+rnBXREvfv3dh3HRXdE7MiHrcg3z5oOzYftoHjVaRgsLxUND7S5df3hH6+O5wFEt74bGdQvd Wi1T1Nr2XZQ/3iVULd/fuutRKiMvQGO2iBvlU15/I5CROvZw67TzoU+aj5ZXjto9wIxWunOu0126 hHoMedIaDEJcfOC/xl/+yed/PuEuEd/AdfrWWWtIV6DIkY2I1Vc29UoUumr/Q3XE+uecCn0A3r9W Fx/y+UIqHVmtvfHeUaKIMeMMTDqplbFCnkZxyUs8pt8lqvRwfGqJfabtP3/kdLNlpvk/eK7iy40l VQKBu8doWJS8T6P2+B8LTAOXVNusFU2g3nid30pf67X1xEWH9lclMS30lgPdAaNMAs0m3qhfOvrs mMnuXeqqHaeoKuk3OFFT/e/9GE9je4TJl4+9JX9t84uIgAuLtBY5D8M3nbXiRJxV3bzH1//phem5 TyNmxBdZCuj51r8fONpwoomyS6I2JdLz6fLNj29elNCfW78LLmq3bXxeHvfbQq8q6snQ6XFTsmvO Hxc/mGj6PnyL4ZSPW/C80JzKuLHhjTG7+WpZOzmRne+bmAYtg8N/W3cymxVuGGdRdTCf86D6h1W7 tow5t0p7rE/5kifMm3Pfx9sd3l9QNuWB8YYEH854vekXd8dbFL7pluvdLEE7JAl8/3mW5OkS+AQV PSBUes6/5YzzGyerqvKKUgYw5FlKpuMG/fVN5fOdHojUra9Gjq4uW/Y96Z7O7q6eM5DH7aduWlQN 6yilqI4HhhG9fldu8Dfq535DBWaLDX++tJ2xwsWo6ICTcWF554YtT2e155+JSE4arj/9w/Pr3IrS gUG1dZm/vlBK3tjg9WZoVLdN/PEXhokXhZVlh/3k+e+uSQTPdQAtMsmGP94IWGOL1xx6VnmsUHew nXvL7GvLVj1r3jjT9u7xW8fTXeQ0D9d8CLjR2ps3LMk6YrVO2Numu7uX+qbNmt6ssSDn/u1DO28Y PsfnzWgzXLAQS50PmhbJW705cmSVhkrNyINDTFd6vrlb2+YOVyXNdZw4dKyIZvPRYqepR61f7RHQ 6it4u4cKPJPZkpsRh1zeDT99PMnbzH/kMqeFbUUv5JPTFJnbTDx5A1XdOxrvQMrDdA2rmq5lBeB/ AM1MnMsNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MTkgMCBvYmoNClsgNjAwXSANCmVuZG9iag0KNTIw IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE1NDg2L0xlbmd0aDEgMzI4NjQ+ Pg0Kc3RyZWFtDQp4nOx8eXxURdb2qbrdnc7SZCGEQAy5TUNYsrEToCEdskCIrAmQIEo6SWeRbKST ICrC6LgFFNxRGGV0dFREOgE1AZSouKDiDo7LDC6oMyruOAsk93uq7u0s6Pg63+sf8/s+ujhPnVt1 6tSpU6eWSzcQI6IIgInUzLycWZa/3X2c6MI2ogH3z8rMyv7DS/faiM6bTcSGzMpbPPPcksZLiZZX EPWbNz8vZZxNGdOBuvuhZcmSzLkF41rnjiAKyScKv7mk2l3HLjL/hSj2r5CpL2lqUO+91/0NUQqe Ay4vqyuvbomYNI4objmR+U/lbm8dJVAg+kuFvrDyqjVlEQMtXxBNriLiHRUed+nBU6NWQ1ci6idV oCD4Eu7Ecymeh1VUN1z0Bu0qhCwegxZV1Za4K1ZV1BBNhXzQvGr3RXWBScGoZNdAQK1xV3uCHx7/ MlEmxhS1ra7W29AVT4vRf7Sor6v31O3fvimOaPgEtG8h4Sv+SdmxkOT7VoQ6T1oDrSQ+9wxf6Bb5 I4ce+Lv25r82mwdbE/AYKOXFB7nlgc7b4eTD2pva66ZT3TX+jyJKzPGkStPFAMIoRVii3IV+pQ7T YbaZzJC6wzwej7F6rripjEeYzTxACeTczE0moouvXq9rlebNra2pJRfZqdb0addlwhJe7iKmaZqo NR2mciMXnXzOgmgfHQd1sQ/4+SyJPqTNLIH2ssP0CX2Mmh30NB2lgyyC3qBPWX92mKVSMXnoZtaf 3qJwWkrr6E4qoLtoPa1Eix1UCC6akqmCdoMKqJ02UR7GN5wWUAkd4dPpI+aEZmL7aTMlocVlaPEW rcX4H6c9dADWDKAqugF161H7Ct1I59E0SkWvt9AJdgt3spshE460DvpFT3nQ1JN2oJ2e9hpJaPOn 84x0mi2EFZfSJlYrrZZuYftYGvqJgK3V0FRMN4OWkQ9xOon+SB+wkSyepmM0dfQJ+xzjvJZaYEse RrYO7YRNFaAIukH7BuN/l3Wy4dCzFZaXwPMBtJLnUz/qT6fgyQR6H7rCMQZBBfCengg6CDpF2suc 6NPJpnJiLWwvm8behPeWoM92eOYIneBOrZN+A+23oL8kzF4/1sQWsxIj0sS8rIVOIb0O4xR0mfYx P4g+N0u6E8+d6H29pPXQ7Kdk+E1QBbxWgHaChJ5NmBFBefCiIFghaR1GuAz+eoTF0BZ6lS7RPmYR 4PsRZ2v9JJAegK9up808Vi6xWB4rUCf/h61FrZDWF8i/4f/9h5f7GaRQgx7GfMdj9SmwJJ3aMEqO 8d3FQmF3IPXXvuOMJdM+1HFWySrpYcSG8JHfc34v6Z5a200rEbsraQb8/Hgf2oF4LkRE39jtz/Ug gj/J8Knuz4u7femn4Yh3Madvyf4jEHELqA6rUpT7CfWILyddA+tDIBdMMdyK+NjHrOTSTiPK0rUf aLT2Jn0rV6oHPR6Rq7QQ3hBr9CbMbSni5iBsKEEPseREbSkVY9Y2sH20lJkomy2hDbSbhyJS0imf 5rAs2P4C7F6KOcyiRjYS3A2gRhnJ65DaZRzvIAfGGU6rKRE6hQVit5hDBdopqqeRSKshEQ2LdCvW wYpEaUchjcIJZZJztxTRHQV7N8N3lyCuliGPxNNUpItoPMWh/Q0gsZPcB/tXY5xzKRs7oJ1yof0+ upyG0RVodT1ai/3kcewIe2i89iVm7CK0WImet2CFj6UKPpzNYTkshw9jjyFtYVvA5fJhfBKiegt3 Khuonb2E2L6TDaB7aDtbzXIwuxXMi7naQx3YNa7E+juH5oP/lv5Ff6G76Rl6iF6i7ZjlK1F7gP6O +f0r5G+R8dmBunZJr8rk1+zBTtuj90qpU2js1sdWY0b2oOQhnsE2siI2jD3HnqNTHIuKvcduA73H 7gG9wN5lb7NS7Gzfs3Usn01mVhbARtCtkP6Ez2Gvse+YjY1g4ZjZnvX3Alc44wq7m/2B7WDVbBHK trFiVoTYGy5FgskiJcNgh/hshufF2hKfICTxeRA75dd0G+hrSN2JtYAES8Q+rZffxq5gR2D5/ewF yMdiHhK6cz//K3xg+zZ5whFFYpUH0Yvw0G2I/A62n/1D2ik3C/DG+Njz7LfdY/WXGWP9UX4nWyhI +kCQRfdNd37mJ8Twj5GzwZjfXrnft4jeozLfQ6my3kqrZN7KWmV5F6JaPH8HW8UH45FjeZCa5HM5 1ujl9Hvahp0ExAdhthEX5KZz4ZF3ERs2RMA98MT5uI2YMQ8vIB3BbFyBWtHLNtrGPmMn2Ums75Xs EfY9+4jF8xJ4zYd1k07x7H2UfMS+ZE9C43Pwwp3o6y3cG16mw+xC1gALD9N+2OhELF+LCAynLxHt +5Geozuwf1zFzkd6Amk/u4Md6/F2txdEpAg/x8p4IDYLqYC+o3fYPzBfuNHJMwr7Jmy4Hav2IHuR dWAffAaR284SsDKi2QUsU1lLz8v2d7HH2b3sabnGE2QaKZPWnQ7CA72fe9JMSIO6z89fSr3Pjp+i j7EriTNDjOQ/oTNPjt5UIu8dOgkbRB//pg1LYZF0EoS9EPtzJPbRiyStRCpGe0ELENmjsLeuxCk2 EzZXyJNM3GcVJj5mRWFYXBRt/iK4g/5h1XAntWhdOFsDcccIkhhMwcAQCgHagKdxP7ABQyWGUT9g OIXChgiJ/SlM2hMOHAD8F06DCOBAnNf/wv4eqf2TBlEUcLDEGBoIPAf4D8RLNHAIDQLGSVQpRvs7 TgaBQ+kcoINicUoOkzhcYjwNAY6gOO0kziiBo8gOHA38HhE4FJhIDmCSxGQapn2H+/tw4BiJYyke OI5GaN/ihBoNnEAJwInAb3CTTAROpiRgqsQplKx9jfNM4DRKATppLHA68CucUuOAaTixvsLNXpxb 6TQBOJMmAjMkZtIk7QRO48nAbEoFzqIpwNnALyiHpgLn0DRgLvBzOpecwLkS59EM4HxK0z7DDAtc iPvDZ7QI94fPEBvp2t9w7s8ELpa4hLK0v+JcngUskFhIs4HLKEf7FNEkcDnNAZ4v8QLK1T6hFXQu sIjmAt00T/sYETUfWCKxlBYAPbRQO05lEstpEbBCYiXlax/RhbQYuFJiFS3RPsRpuxRYI7EW94oP sfMVaB9gjywE1tN5QC/wfWqg5cBGOh/YJHE1XaAdQ3wXAdeQG3gxFQMvoRLtL7gnlgLXkgd4GfDP WBdlwPVUDvyNxMupQnsPNwuBv6ULgVfSSuBVwHfpaqoCXkPVwGuB71Az1QA3SNxItcDrqE57G/vj KuAmqgduJi/wBuCfcK9oAN4k8WZq1N7CCmwC3irxNroIuIXWaEexxwu8gy4FbpW4jdZqR+h3uNsf kTf8I3gTWIeb4Hb6DfD3Eu+my4H30BXaG/QHiffSb4H3SfwjXam9TvfTVcAH6Grgg3SN9hpuUNcC H5K4k5qBDwNfpV20AeijjcAWia10vfYK7nWbgHskPkKbtZfpUYmP4R3pZdzBbwS2Aw9jb7oJuI9u 0cR5cZv2EnbDLcAn6HbgAYkddIf2Ij0p8SnaCnyatgEP0u+0F3AzuhP4LN0FfA54CPv9duAhiS/Q 74Ev0t3a87g/CTxMfwC+TPcCXwE+h/vXfcDXJL5Of9SexXvv/cA3JR6hB4BHaYf2DE44gX+ih4Bv S3yHdmoH6V16GPiexD/TLu1p3AFbgcdoN/B92gP8gB7RnsK7tsCP6FHgcYkf02Pak3jzbgN+KvGv 1K510N9oH/AziZ/TfuAXwAN453oc+CU9AfxK4td0QHuCvqEO4Lf0JPA7ekp7nL6XeJKeBv5AB4F/ B+6nf9AzwH/S88B/STxFh7R9dFpiJ70A7KIXtb2kSey9pwfJPT3o/8s9feTZPf3snn52T/9f7Olb zu7pZ/f0/6o9/f+le3rmf7in557d0392T191dk8/e0//2T1973/Vnk7y72EFnWN8+5ipf+vI5pAJ u6X4m0kTnrn4plB+Nyhz7SOs2e5vK5mFer7U5ETGt5W9/lKVxDfJv+Zn0a+q7df4/GJvudLzXWkz pjunTZ2SOnnihPHjxo5JSU5KTBg9auSI+OHDHEPtatyQ2HNiBg+KHhg1ILJ/RHhYaD9bSHBQoDXA YjYpnFFiliO7SPXFF/lM8Y7Zs5PEs8ONAnevgiKfiqLsvjI+tUiKqX0lXZAsO0PSpUu6uiVZmOok Z1KimuVQfYczHWobW7awAPx1mY5C1XdC8nMlv1nyNvB2OxqoWdEVmaqPFalZvuymiuasokyoawkO ynBkeIKSEqklKBhsMDjfQEddCxs4g0mGD8ya2sLJaoNRvsGOzCzfIEemsMCnDM9yl/oWLCzIyoyx 2wuTEn0so8RR7CPHTF9oghShDNmNz5LhC5DdqJViNLRBbUnsaN7YFkbFRQkhpY5S9/ICn+IuFH2E J6DfTN/Ai49H9zxCeURGwdW9a2OU5qzoSlU8Njdfrfq2LyzoXWsXWFgIHWjLh2cXNWej641wYm6e it74lYUFPnYlulTFSMSo9PF5HFmipOhC1RfomOmoaL6wCFMzuNlHi9bYWwcPdrXjqBucpTbnFzjs vrQYR6E785yWSGpetGb3IJc6qG9NUmJLWLju2JZ+oQYTYuvNeLrrJCfFBZe7qNuzTFjkyEFA+NQS FZYUODCmVAGeVGouSYUYPoUMrXylmJFKX2BGUXPYVFEu2vvMw8McavNJQgQ4TnzRt8RtlFiGh50k wYo46Q411Pt5X0KCb/RoESIBGZhT2DhDPk9MSmxq45WOujAVGdxHC+Bbd+HUFLjfbhcTvKHNRcV4 8K1fWKA/q1Qc00qulIRCHy8SNR3+mgGLRc16f0138yIHInmPXMYDfNb47j+hYVH9syqm+ljUz1R7 9PrcPEfuwmUFalZzkeHb3Pw+T3p9anedwfn6ZxQoMdzgeIwiaxGUy7uFxUNBiM80HH8sMqhL2wKs iEpZwtRsX1jRbB0Lg+z2X9ioTftatJJZTzPDTN/UhL7P0/o89zEvpFmBwaZ4npu/rLk5qE9dNnag 5uZsh5rdXNTsbtPWFzvUMEdzuxKvxDfXZRX5Z7RN27shxpe9sRCDqGBTEa2cZrY42DULW1zsmrxl Be1hROo1+QWtnPGMopmFLcNQV9CuYs+Vpby7VDyp4olyGSK9lVtlVUy7i2i9rDXJAvlc0sZIlln9 ZYxK2rheFibL8Enai0tth9LRuni8qw3ZVJnt7jds3HqRB9tk3ho4Pi09RemgOtAu0CsgE60ArjNK FIoDpoFE6SZZv13ZRz5QB+hVkCjZi5K9KNmLkr0oSVPaiCmPKY+2DotD13t2Dxo27qv0wcpu0kBc uUHZgOMoTrnAyFcY+Sbko5FvNvLrlA2t0+JC0wPxzOgroAbiGNu21lnzx7VLZrJTMlv9JVt3oyQu fZCyDVZtg1XbYNU2WPUVkEHrVpRvRflWlG+V5VuJSVX2UYYqg9nWGhpllIBJD1IKlSV494pTCox8 qbKkdVzcgfQiZTFU75K4XckHbpK4QuJ8ietk7TrJ10q+VvJpkk8zeIEpvTBOYqhAZZGSh/fFOGWh MkfmC5QsvFfGKfPxLPJ5So7M5yqzZH4uyqOR50IuAvkcJVs+5+A5E/lsPIt8lpLdmhk3Jr0OzytQ x9GfKM+EDZmwKRNOEiWbQNtBx2TJCuA60CuKuKcJSaZkImUgpSvpaOGCDhdqXKQoLqQ0pBnKDNRM h+x0oEtxyjE6IeVET074ygnNTkyPE9PjpADFCVSViTQG5AItABWBzNCTiHaJsCsRPSQqSXjXjlPs fCPe6eMU1cjj+Aa8p8cpQ/iG1iFxrvRAvocWgIpAdaD1fE+rOSI0PRJyQjYFNB+0ArQOdBdoF8hK aXqNK5in8TRlPp+vmBDdo3Y7neNkPn6Snp8Tq+chg8eFptcro+CmUXQXSIHJo2DyKAzV/xQH4gid EXQA9AroGEg4fAScMQLOGIEBjkD7EVLKIuW+AmkgBUE0Avr7yphl6zhQSi8tonQkSkbiaSTajITs SJQeAzLZQtQvAG0CHTDqhspgHiqDcyh0DYW1KcA0yYUC45ShrTwwtA3+ZVND0yfD7/NBqOTXwZvX wW/XiQjhYhGnoCbNkNgE2gUyK+1Io5BGII1EGopkR1KRMIPKEMzeZqRNSNcjXYe0EWkDZiNyV8KB BL5iYu3EdRM3Tbxr4q6JByYG7ONupCJe5AqiqCichBHh1sHpYdxEy8nG/iVxp8R6iS6JA12Dl9uO L7c9v9x2+3LbLcttBctt85bbspfbUpbb2lixa2CC7d0E2+YE25IE26QE28QE2/gE26gEW3o4K2RL yUZPSJwpcZzEoRJj2dJWGwXuZ+eR3YqIZyP22H8T97G9zcRa466wt1mRXa4/nadn00Tho3Fj7OVx iXpJvJ4Nsz9uggZazB6iAJbgSgw4FLAiwBUwJSA5IClgZMCIAEdAXECkNcIaZu1nDbEGWa1Wi9Vk 5VayRrZp77sSxFtQpCVMZBaTQJPkw8TvTuULE64OnFk5zSFffyWX5+bNZLm+jhLKLVZ9P+Q52lgQ zlSzYybzReRSbv7MaN/khNy2AG2RLzUh1xe44LyCFsauL8STj1+DIyu/oI1poujKGHF9bSfGEq+8 LsbICwtFm4IWE7vuukKKakqLTouYET4lO/MnoMjAhJ5PdELvB1gS67s1N6/A92BsoW+cYLTYwlx4 Ttx223kqn5SV2c4ni6ywoD1oPU/NWiTKg9ZnFvbIkYryzHayi0zKkSrkSD1DbgifLOSGi0yXGyLl hvSRa5luz8pssdv9MtOlzPS+MuV9ZcqlTLkho+gy9l4yAe+TXcrYA97/kcyQXyAz/CdlennTMzPh Zz6sneawoy0ZF4tXhSJHlgdU5NvQVBHtW1+squ2UwY4abxHxRcUlFSJ3e9rYUYcn05fhyFRb5lz8 43rfxaJ6jiOzhS7Oyi9oudjlyWyd45qT5XBnFu6e5R69s0931/q7axnt/gllbqFstOhr1s6fqN4p qmeJvnaKvnaKvma5Zsm+ZNQjLK00sxB3U5nv5sFBCOCiGHvhzKiwuhkymqfZoy+L2WsSvzEPxlU9 BK99NpCoSkpPShdVWGWiqp94IzSqoi+bZo/Zy+43qsJQHO6YSdFZlZn44/UazC/84/V6Gy7wXuAV ufzjbWgEiWkiL3kbCCNID5HnWxx2Y7E3bwBtlHu04vUWNpCcU28jCW0NAnqUd3ON0My8vYOAvGd+ RGQkkE5Q521kkBKCjUbYeMXPl6CGhJGGFiLTp6AbKQb5EKUYJzZpxwz6UPwqXNR3dWoafwvC+Qbp n3ykWyTms7l6TqX0JlXTDXQbysazl+kBclEoyt8khRErICfdRKvpCC3WvkGpne6hryiRplCF1iV/ EdrF1tI9TP8lbiq9IX4jx51KgulzbI6j2RhlB7uckqAln26lgfQKNI7WgvC8m8dyJ1rl04vKCmui Nkb7lnWYDmnFdDdz8qOmh+klOsGGmqjrCm2DtlXbRv3oeyW282ltrFaNVoupiBrpUliwnu6kw6yQ T+cHtGvl7609KH2MXmQJCKgi3OgWQfq3tIXa6Ql6hf5EHzPGQtlItp69wd40U+fBroNajlas1VIW zaMFtB61sWw4S+fLlGXKTuWtzo+63teGQHc+NdFFdAltkr9Ff4vepneZwoN4Pl+s7KQYmi5/JX0D fHYnPHmIjjErm8CmMhe7ij3Em0xK50Gc8CYaAA/Olt6/gbbCp/fSLjpIr9Jr0PkNfKqwQZj8xWw5 W8uuZNezm9m97CH2MPucm/mfFEX5jelZ0+ddR7Ug7Q7tAfQbQ+eQirtuIubgXMznYfoM4xvNElka e50n8ESFmUI6u7rGa7O0ddoz2lvkoBGQnY57bRbNpaWweg1dQfvoWbQ9TC/TJ/R3eElhQSwCvlCZ gy1ieawRVuxkX7FOHoX5S+VVvJW/qSQoh01LTQ937uka0NXa9VWXpu3QfNrT2ktyfiehnwzMwPlU hyUmZuwR9PMMHae/0Un0YWFxsHU2y8V4t0D/MXYa4WTll/GHuIbb72blkGmQaUvXvK7qri1du7UJ 2lzEloJL1yCagDQV0bSYCqH7cnjzHnoQM7Mb0XOUvmTRbAgbw3LYElbAilgFq2V1bBW7hF0Krz7A 9rB97Ch7l32JV0cLHwA/JfASfjm/ie/hB/lRflwhJQ/vMKuUS5SblD3Kq8pfTWGmRNMY01xTkWmN 6WIzrmSWKOtLpweeru4s7ryj8+mu5K7MrpVdG7qe7Dra9aEWrB3QPsZVdAxsLKRy2LgW47+Krqe7 EB8PwsYP6FP6HHP+LXyhsEA2GBbHyXnLgN1zYflSXJnKkCrYhfD/eraDtbL9rIM9yQ6xF9nr7D32 FV6eB/BkpGlYBYt5GcZwB9/BffxtpJP8n3gtT1TGKePxVlGE0VytXIPx3Ka8p3xs4qYBprGmPNM6 03NmxVxqvtW81XzQ/Lz5M0uY5Txjj+jZQfBRXuJPmmYoVbQdbweK8hl/nTvZWn6K/ZHHsifRWyze txbwDD4Nd6N9iPJqigzYarFb7DySwgKKhA5+O09SlprilRBqwHojvoxfxYvoPrafTvHZiLQm5TDf zlcoW003mmawt/B+8aSJuI39QOmUzmZg7t6gVZihJGWXSfxGlMxW5bS5mtu0q02fmrnyOvbB6Ywr L7Bl7ARbwKPgrWn8enLgOYydQJ6DFfg2Ir8d185U0/vKRj6Hv4uyKrqJPYkx7qMqvo/djXlJxXqs ZwvYNmUsXcZWwRtT6EJ+Mw3ldXwo4nkxfccuZwOwck9hbobxMjIpNl5Cb/JCzPqrLIIns8sQp9W0 gTVTIutkHfQSv4EmMY/yxOlBnSM5O32CtSizqYWdMh0yHcLl+xQ8GYvIteLC/QFieit6eZbsSjyi JpXMHO9xWE9FWOvh/CS7lFdRJdui/I3dy9NpPnkUL89mt3adNKUr4+GxvdhNMixTrGR2mmNNEzDj n9IMRGM5kaXCdMx8ueCVN5TvtULN3rXC3K/rPboY3pmN3W0D1tJseodFsQvYQpPGc02atoR28F2m 97SBLITZ6TUNK6zrEeZkwzSVrdKC2UJE+AXi30mZNpiuNDWaLsXZdAq75lV0I91BT+E0+QPOrRHw 47nw5nLsPZU4I8bQOJqI0c2gmdiVclC3gJZgPy3CLllGNbQKO+/v6CFqwQmVC39cgHZldCHKvTih LqHLsP6vpo3YA26l++g1/iC/C++41/BneBOvpHfoHeU5xcWW0Juma03rKA/vwAtZf/Q8GbMUh3Yb tTfQ2yiKwe4/AasUca99rh3V7u98Bfrug+03WmbS55YMEcDiLw3N4h9xKRRA2S2WgDYWsgelZpNg FAqymME8qih8cGCAKHuU0SDr/EuiE+aFfe+c2+mcF/aDc25YJ17mnZ1OQWPH2MPt4cMBeM+g06rS cdplplOkmjpEf59rH/IPzWacQXE03xV6NPjjYG4NCKIw1r9hMDp4zNXfRoODox4Om8GCZsQ+jBeo ABawn+fgXOhi8yg6IeyH808cPx52/DilpZ0IO8HCI6bgz9gx2BAVi8UxNH6EEj9xwqTx46IGRCoS LQ6Uoog/Fs8HhkcM5MN5isOR7BmRMH3GaAGmGzuXqYMHq/y+6OChycmOoNPW6QmJzumjk5ziG6Ub tGMmp7Kegmkgm+1KjYgyRUUOjFIOsUPBR/i75j8HHAm2rAyoDOce7jFVWiuDLrRVhXv6lw20DrAr ofZAJTgwIMRObVrH7tBBaTLvN1DmLtuAiT7xE/0xCA+F2vjVrugIu8UFMYsLMrWWA5ZXLO9bvraY LW3sw93Ro3dGt+EdSjgB16wTneevShA5XBEGX4wdQ7m+4Lxc37CFywr2UZT2PUVq3+8Ji+wXOXCv 9iH11z7cbRsSPiTV+BTS+WzV+bQKl0VXcFRkWExapIDwNu0HV//QIWnBkQBrECBAAMq/cMVGBKcF RAZHoBIQFRk+cEakgP6RoZFC4qArAkxQUEgYWgK4EhrnFJfDvp9CFkmOoTRxAo0fRwET4h1DLQMi o8aPm2Rydp146mDXlyzi4FOs/+IPtm//QBDb1dH1NQs/0MHCu75+8s6/HPvdtvfF7/BTjXTjf2/C iX02nU1n09l0Np1NZ9PZdDb9Fyb51wLZyjwi418Id+l/USC/IInCJV3nOfVjBeT/9doyKaXIX2H1 yJgpmpUZvIXOwXuzzgfQfewOg7dSPH/J4APpHOv3Bh/EhwT69QRTVXCywYdQWbC/rc2yh7sMvh8t D+n5Edy6kOUGzyg45LjBcwqwWQ1eoaSQdw3e1EvGTCG2UIO3UD9bjMEHUJ5tlMFbqb/tKYMPpH5h Rw0+iIWG+fUE06Tw7ww+hMZH+NvalGW2Sw2+HyVHLBe/9jMpsC0kolnyZvBhEXdI3iLLH5R8gCx/ VPJWyT8r+UBjjnRenyOd1+dI5/U50nlTLxl9jnRenyOd1+dI5/U50nl9jnRenyOd1+dI5/U50nl9 jnRenyPBB/Uab7Acy1HJh/Qq7yf5TyQfJsYS8YPk+4OP6G+SfGQv+QFSj85H9SofJNr2j5J8jJTR dcb2konrxQ+T8sMkP1ry4ySfJHk5Fmsv+629+grpVR7iH0s+raE68lAZuakEuUoPgPKpQvJzqZZq QA2GlEoZeKoHL9CN8kopoaKkCu2TwWXKcvf/UlNKt2Uq5aGmihq7Zbwoy0Gu9zeWpiCNoSSDmyBL 09GiCvkitCmHDQ2y1SLo84LqqQlY+iOrpkqrGlFfKaVUmod8Ncqb5LO328px6EX0qtJIaKmELfWo 8YLKoG2U7Kkcmqowtnpa8m9a9+1N72sBxiu+MelTZx8qfSk8VYrnaql1JcpEf//3XlZRKuyshG0N 0gbhFRXPQqZEloi59D8Li2pQolvlxSjm0Xz0nkPZoAz5P3vkoGQepOejTKVzZbn4riMPKOZlFnyT Jb8JEKX5ZKMgSWIMlXKWGn4Uk/5yfZR10td1hnVrur3w49HrMVSLEYrR16G9kHZDSh+lHhWNMiZU +b2EChKj9PcpxtzUyzONsq0eG357dM9VS3ndEhH9VTIqPDJePbKsXGoRs+eRXhRxWmj0VoH6JilX Czv8Ptf7bPgZz/gjbrWMCFHikeOqMGwsxZMoL0FZlRxfmfRe9U/6q9YYl/CYp5eW1YbOn+qv1Ige ERPFcpXqVhcbM1NjaP6pGRohR9XXU3pc/TgqftyzXi583QQUO4QbvVYZ3vZKbQ3/tm/h/cUoqZI9 envNfM9c6PPUd10I7+i9eqWeEpSWyRH8kjlXjViskWuxBk89/Yq1XSo9ra9St9zB6nvtYInd0vW9 4lYfX8P/6ClhXbXU74+r2j76Vsv5Xylns/deUWbERY9kLWT1XaRRelzor+gej25X7+gW+5WIBt3/ +qqqM+LDH6VnxtDPjagnPnLk2H88c8LDQv8qlHukbv9oSmSu7201Z8xB/Rn+7tEsxlcr9/NSY9ds knvg6l77wC+Zfb8+fU2KtdpkzEbPGvPr+/E86t7SR9Ag94CGn1zH/hlzn+Hrsv/I2h4v/7iHEulh Vf4vbmdapI9HRNDUbg2Lxb8sQ2kSiRMzFaf0ZJySKnCs+FdxOAsngMaI/+MDsrmG5BjUjpXfvOr8 ZBoPEq0m0UScoIKEdjFbDbBsKu4NKfCXSMkYx5krvkTufLNl/AqfCjtz5S7RIPeBetxePPKcLu/e fd3du4xfz2oZIw3G3tizF/u9nkMz4TGxVs+8Taw2tPl3TrETrDb8KGYoXZZVGr7NBq/fesq7++rd g7gZeaTdJcbaKZFR4+l1PqtSq9/2SjlvVVJTJV1kjLBOjqZExl5pr/EnypXr96F/J9fvAqtl7Orr pOdE9cr7TnEvK8qo5zbhX3d1xtkn9l9vn71IxJ5+Z/LvAD/l8VrplTqJPT6pl5pr5Z1A3ykbpC3+ O1jP/tZjb4P0XYXcB/yeKYVUCVr5V0HPTpj8H8ZZipSvhtYUYIPc0YXWFHlXWGHcp/zRUSPHmdzd 5tfta7WMFF3W86v04q9LOWMn6dadv6bOU+Yu8agPqPkVHlX8l5INKFIzauvrauvdDZW1NWpdVUmy mulucP8PQilCmZpXW9UoSrxqTg3ajZ0yZUwSYEKyml5VpS6qLK9o8KqLPF5PfZOn1K9qakZtY32l p16d51k9tclT7xUqxyVPGaOOnFtZUl/rrS1rGLXIU95Y5a5f0qvaaIZWC/Lm5htPD6r59e5ST7W7 fqVaW/azJqv1nvJKb4On3lOqVtaoJZ76BrfIaxtrGqDKmzxvfn5Odk5Gen7O/Hnq/Gz13JyMrHl5 WWr6rEVZWXOz5uXbgmxB+RWVXrXB70nBo8u6+to6qFsjTOjuHh6qLa9311WsUd016BKuaPR61OI1 6praRtGypLZJGtNYUwpvCD0wrtorlLjVqsoSTw3E3eX1Hk+1p6YhWS1Eswp3k0etLRaWo2VDH2OE 41a76z2qpxLK6tXSynpPSUPVGrWsvra6x65a9FVb7pEiqyHZ064U7qmvLG5sgGqYWVvj6T2gEV6/ UfBVtyu6G4N3q03uqkZ3cRXM9no9Db1bJ6uLa6o8Xq8cvBwFxmTMRUMtmnrrPCWVZZX/p7kngYuq 6v69dx7bsAgii4L43BCU5Q07isYIowwi4MzgliYDDDAGMzgziGZfH4yFu/ihlmYKLrjklltpapma S2paZlqZu2aW5Zbikn3n3mEZXL6v7////v3+Gtfz7jv33LPdc8677z7KfVpyAbWoN+v0BXSsJi9P R0yqKRKM1MFCSLeR6hbnMz/JVJGuWEcEwkkoXpnB+LLJbPWKfNQF7TSUoYuU5hTpTIVkHqRlVXex ZryA/KOpSsYTxTVrqOVEVB+K/GbhNPrxwphSrYlOk2vQo7fpGyQwNvBNkU2FhtKiPHTNsTptGfWB p8UneGhJrQ4XkdViBK9JRmQLJzBrcs3NNiaCaRq4zn82Wcpy04BcjV7I0TYSwnk05p4EIUslE0KF oLio2GAhVhoXKkaJopNT1gDsFKXSqChsYyNjhdiY6PjoeFdJodlc0jM8vKysLKy40fC5huIUA3Ka JwzQms1FWmOy1qQrIO6rIS5DcMqMaCKjQL2YsK7oOzBEaAwTZYhGnNOoQSOhW8ryjDrktp8RQ08B GWUdIKi0RejuRvQgjDdkPQuCjFDX5aKr5OvG4YQlOnNuoZBH5w8RKIfEyTEKlGmJTehCNRVpciiJ fBomiO1KcPUJWSarF2mLMTIRB2hm3FBqLik1U06MWow5xCnNmhwSwai/UbpmbW6hnjKTZ8gtJSag Thj2HJ2FF5qLi8KLzeT3G4cXm0blWtWh15aFkTt/clSZtgh7tf9+CLkKb3ASis2k0+xcTLOwntbJ WBOxrphRRuP1jzQfNd5X0bxMcjit4uBt2AA74WP82QYfwhobWhqanRqvz1Pa2hZzaVtQo/T4AF7K D+D7872xjUdsDX3CzGvIiYXse+xiYOiTgwzxjQ27IpqGPWnmcWd6jo1lnv4DDNkd7UJ+lbL1S2rG peEOx4RyV7kbDMvd5OoZ4O6DHcOCPTgwAI7giLATOCEsAReEXaEVw4E7uCPsAR4It4Z2eNcP/LDH H/wRbg8B2N8BYrAnFvoh3B8GYH8aTED4Vfgb9r8Gf0e4HMoRroDpCM+AOwj/Bo8Q/h1+R/gxj3zz LM8xHA9kt5aXkL1Q3pX3Qtib90HYl8fZeT/eH+H2fGeEu/CBCHfjwxEWeSnCEXwUwtF8DMKxfG+E +/CJCMt4BcKp/ACE0/hRDMtn8/lMw0cPWN0HogewGqMmB3VHvxNH3dkx1g8jyAlXO51eh5VgsTZP xwTm6/QaJqRIV6BhIooxKTAJTZZg6b/WzynAOpLq3R7ncGMCmANsOtfFrp3dcsdxkmrJLskvzomu i1w3uu6jI1lqOSUTCB2hKwRDOETCbXgRsiEHCqAQdDAaTDAOpsE/4C1YADWwFFbAJvgAtqNn7oH9 cAiOwnE4Cd/BWbgIP8BPQPbgA9FCnaEbhIIUotFO8dATekMfeAESIQnkMAWqYC7Mh4WwGOrQz7eg j++ET+BTOAhH4As4Ad/A93AeLsOPcNOG00SmPXSCQOgOIkTBHZgO1TAP3oFaWAYrYTNshR2wC/bC ATgMx+ArOAWn4RxcgqvwM/EAHG3L1/+Ui0JGCgEgQBcIghAIgwiIgXRQgwVeh0qYDFNhJsyCOfAm ruFFsASWw7uwBtbBe7AR3se1/BHshn3wGXwOX8LX8C2cgQtwBa7BL3ADbsFdqIcH6KksztLIb48G juMgGT16IrwBk5D7Gcj/bBsJVsFqWAvr/40k1+FXuIlr4R7ch4foL05UKpbbxXjh82hPfFp8jall vmTusPasO9uO7cKGsXFsKnuB47lALpszcq9y68jHPOCGq+lnCpG1eolxYNwZb8af6YRPw2FMFMRi 7wWIw/YGDMW2FoZhuwyGY7sSXiRjYASlwaO30rGQhtfrYCC2VyCdjszA9hZ5M8S0Ydrhs0wgEwLx lPJISvMlSnMUpZlNaWqeoJlJaQ6iNJWUporSJKvEBXpSWjlUAiJLbhOU1wRpm6D8Jmg8haw0elGq CZRqa+QwDJ/l+6AmU+kZTHJCs5BG01eYcqaSmc5UgyvGrEvI/Wv032UYsQA99Rr0RhqLoA+2S+AF bJdDIuVPRmfoS2aAAip3IZVbR+UeTeV+mcgNv2FrgXvYvg73sZ2MVuZgpo0+7lKMeorxgGI8egKj iM5QTGfQ0xkMz7RwKzpjEuUwmXJYQkeOoSONdKTJRk9qipNF9UR0aKb3WtpWTqn1o5illNpYSq2M UhtnQ20wtesQYlek5oUxLBjjVDVGqnktYtVxjE3naHS6SuITRgIeJaFejxYBzFZ90D4tuWjNcNxN 6I/tLUjB9jYosL0Dqdj+hhmH4+6SN5dobV+Msl3Am971oaN8sa2HthSzHaHQwG8bMgq8CDVyAp+7 Bw7gSX97hnUFLkftBqLHvIIesgg7c9gidixbzk5lN7Nn2Bscx6lt5+SjyZwk83A3+T5kTv4FMifJ PzinLWY2xdRQzByKmUsx85q544lkd0m+Qu6sPVrak097XBo1w0TQM8ZNvk24AG/CBfgQLsCXcAFt CRfQjlCFNoQqeEF7bP1JnkYdVSDsBBOxdYBJ2Hr+ixmy6QwaOkMOnSGXzpBHZ9DSGfLpDAF0hlfo DBY6w+t0hsl0BuJxb5BrClU2QVOaoKkUstUcSzXHUc1JqOacqeZcntKxH8X0p5hdKGZXihloo2Nv qlEfGx2LtEdKeyS2awsjcSLTj0kjHKD0HJVeQqV3ptK7UOm9qfQ+VPrfqMT3qMT3qcTPpuhHKfpT il0oxa6UYiClKFKKUkrxLqVYTyk+aNChO+af1+k3EDMwz13HrHUTY9I9zFr3MW89xFhi15QpE1iG 1iMMaklAHlj6m+utmdShxZVjiyuSk7KxQnTD/Cfguu5Ev9cNxrwfjbk2FvOgHPphzZcOGeRrdcy9 WTAY65YRoIEiKAY9GLBqKcc8WYnZuAqzMYkLczEjL8ToWoMxZTHG16UYVVZhbl6LUWQD5uZNWEGQ Wns7VhE7MUt/jLXEQczTh7CaIJn6PMalixhnf8Q4/RPGPSL7rxiliPwYVTCn3m2hB1L93kTbs9wd 7jds72ENbK1+WVr9Aq1+WZTSjda6rRH2xohhrXVZlL0T4nQjn1+j9N0RB6VHOJbmVHlT9cuiJtKw H7WBrZLGxRdpZtXQXFhEo/c4GjtJVQxELwhPRX8H1E41tqgb7FkICxFeBLUIL4bFCC+BZQijlrBF PWG7ATZj/zbYge1O2IU9B+Ewtl/Cl9h+DV9jex5jNKCefkb4OsZboLU3b1NDWRh3nuGd4A/ekbfj ed4BK3J73g1r8da8O1bhHnwrG2w1YrfjO/Nt+U58B3yS6Yi1ucAHYVUewnfHerwHH2yDHYjYUfic E8kn8PF8HN8Lq/SefF+sz/vxyViZy/kk+hky2oZYhtiFWAWt0Ro13x9SQAGpqFdbPw55rh87t7hy aXHlij9j8bnGDVrhE82TvtwDq8dGfyYVci9IaKqSZdAXK+XkBj8fSD09EwbZePsQGArDYDj1+pFo 6QJ4GS1dAqUwFsrQ2sT3ySqdYrMCbL2/DmsL4vnrsS4l3r8Fa1Pi/cTzidcfwfr0BNrze6xPiedf xurpz/i8lLtN8ht3FzMkeaZzRR8gHg6oA1IvWJ/sPDEPNnt4d2xRGw0ezqFGemJPL1pXJQD5vQ4y WgGhThBOprUG8X/y3EeqxAzq+Zm0xlNifQGon5FN/l9AK6aXaVVTQiuUUroW3qCRv3kVEP9fhHBN g/8vQRi1hO1a2Ig9qCFsUUfYopao53+Gd1FT2J6gno/aov5/AXtQY7Q++pXWMrewh9Qe3FNrgTxB evFteE+bPgH7wvkwPtSmzwX7FHwK359WD7exlvBsega0PgUyXrPx3zbWh2+vaaLFa5K9U/fKlMp7 rqwDV2vxGoddZo5lpW6ii72j9Q5nZ8eI2faSHvYsz1piOZavVYqZYohNj/+SgHJ/fOokfzOwmjXR 0yta+q6hD/krCi3p8e7fng+oeliaedxueadx5sTONbUW96OihUsULewqzh32V8V+Vx10NmF7u7WW BwXuomsTnyyH7GikHmIre8jiHTwdFWSTU681S31EL9Il8XQbrDXqVHQDimyaSyNFKbnh7Nm98YaQ ZCgu1hpzdZoiQdW4y5dp3Z3UGk1CkkwM8HGNjxGjxHiR/hnu44oXUjE2IpLsww3/K1ioqLGVm7Vj oGIGI1ZM4SoqmD3HdVolO0e9Omhfju8mddanyZPkqb12v3bq+MkD5ZUzTrnc9H7n8MurgjdWjTVV H/g0Z3nC9QC70hueTFGbgV/Nm+Xwkc5UsTUnXRrwxaODLj/9bdbH6zb3H/Sz4fO8aO7rvxXYlV2o +mbQyYdvtd3R52RZxb6k7299f/azpROnHZJ90rtTSsrythz5fvkJswDytWXHe6Wjpyyp3Jk3bs+K iFKjx7uBnE+2mHYxJartNmXqIN/yx6rQCSek0z/VzpfJwm+ty33lqmm+16x2HV6ZJjs2s+exI3FR ycdK66+N2VvRNs4nOnXdp30irnTcardr9vn9cSNO3Zsdlzfruvrzz44fPzbqV37BGc7y/eTgDXsy 6o6MyZMmJIgWuIQ/A2vJ/4OF82AeLaurCWm1axvMi/SboFa3t2WZR0+qWCTtILa3Gs27yTZqY6nJ LKRrzWRrsdGqzk9ZNUTsbr3RuXmkrlgrqMya4hKyF63SGsfqcrWC0mAwS6PECCt2j/QMIU0h66tI U6iHCbKkJHmmWp4cIgTlBsfHCi3noH4YL5VKY1r6YUyjH1ZsfL7XNUjm/FzJ+onJVoTeZMtyLCKR fVu6ZUl2WU06s8E4PlyZKSP0DMaSMLI7rNTmh4UQ/sPS1MmE5zhpGIYDpAOeXf+NIpJkgmqIFBd5 pydd28K2YrBfwllYlvlq3tWC6k+KPTa9W7/i6IHuEfuu3TocsvxLu5p2f6/94aPwjFHnjvltNfoe XSX3lP3cNnxP4qHqKx6hVW8OzHmrbr2/fXik3VeJdd+3b3fivTtbofhE5cOMr0e5K858cEnina51 kXeW7P+jpjrYo1dFbHW/Y5sXDO2crTxyb1OrjUfHSkomd9Zsm3Rk9+mNn5dssL+Ys/E3D8nVFOPB SRtjnfapQuyC5y74eHqKb4RdoN36NSFREzPTU1PFqpy6RZzXGwHXevQfM/8XVbszrvJBR+5E1P16 ZdGjm4fqv4mYXVN2V7y17Y1q5claRfy1HzZ7zdxdFXllyow52fOHLeEGe/St7/rzDx7zHldUzZu8 wIuurqUVk8SK10VP1Gz7rryLKLF3xIhrZ+cAjmIG6RT4FJFY0Dm7MoWtrJezDiwrRouRjXgc692N 7EibGrak/4V9aShr78k7ivYs+wfHMqIz6WjF88DZ73pi0ZB1/uq1hbfn/CNpaccPv7tdeXvCUH78 ZN8HGwcUvXDYoeNLJ/dEH5o9+c6gpOuhq0IWj9m/fwtIu/540ONhF6+ppgvfpO3p/7DU4hLA9Lr+ 04q5Gdn5uZUpeWeC/IzrRg2d6XFpFzdNl/VB26Co1b7rIzK/ejFBfqfHdHW/KYcPrFxWV+d72JQe aGcWLZIa/HG0rnP30lsz61c+vFbsoXyrzdwB2hFPLvO/JmHg+owir28aF6pUjJI2JQwLO/L/nIn/ 2oLuIyZY6UQn6wp0ZpxQkSwkFWlMJiFSCBWa3iI38zFYU6TLs77zGxshdRadyHh7Ty5LJfUUPciF o6dkiIa+/TMb9FJ30c2qCgelNq/YoM+TBoj+NIi08Womb/OCufG+83PuixULn0qX0zDATyLp8oTi xz8+sp8fGJezZnVW9dztu5VL2i3+fXVyv4utT0cu0HyxcUdBoktCZtnWTW6/bFvRypScteWXvV3q Ny3sdKl+6JyaApWj2e3ziNum8q5+Z7c/aLOrm3lPhyqPL1budUkJHbkxvk9M4uy1008fGzZoVfFe x0HmHvpVI931j3o6rfyp18RBI9NXcywstTigEzgMpprBpcaJtovMrlasmEOuWL5iOub4cvcJb176 Iun3wnm34w7re91ytizO/Qu82PJ06dWRcMVjVOB9xDYiKQybCz9v4BzKGVQ7okh4e5FECyzh+Bgb HAkZauE7Y3eH2uDyPxWRkjJViy2wtcICm+krcHKSgLy5Ji8FddRxidG1JuK9Rm2+1qjV52pDWhwC IK+OyatKc9F4iak0Z7Q21yyYDSH0TW2zPproEr/NNGpyzSRLYdoyW18MByEnwZLGIxQkzwmasRpd EX0Dr9O3pNYsAHm3K3meoL0I1/LQYiSDeALOEGrU0jfZpsSWeAajBFEbEVuaN0SIiI6PRItqMJ/L xmqxYyA5Z0EOXAzWactCSK6Nx3AUSd8wJxlKxtOX4qTKkMbHxzxBTnjWeZIwIUmuVMsU6ZIhMqVS lq5WyFVCskKVlCZTDJQnC7L0ZJtCJk0xUIF1TJiEYKcr0vv3FNQpciFLJSdHPdQpChUlZz0AIhfw UqVWKpLUacMEVVbfVHmSWlBnkCGSwXKlQqXon26DTw6MZCplSWpFkhzHIQFyXATZJlMoVKosnE+Q ZalTMpTIi6SRSVWjBIJiYGaaooFn+dBMpVylEpqlQiWkJ6VlJRMqzb0S5HugXJmUgpeNUmYohX4K dToZ3g9hmZApQx6TstJkSiEzS5mZoZKH0EmGKNLShPQMtaSvnCopTU4HJGWkq+SDspB5hSwtBIek K9SKwQ1jGpnNQKmUQrJsoKy/XBUmqORyCZETXYXSSJYjVpoKNZ1kwDCgN5sazyDY+GLTSRy9QU/c Kl+nzVNZF4LM3HDEwiTRjsPx1LnJwRKtYCrUoB+QAxnWswomXR4lQg4S5OaWGq0rMN9gLKZrRjLW Gvatx1kIBwpZmGRpTHnUn1nmjf1FhgJDWIEuHx8AO5BQAryF88aL1vjjhj+SliWOhb3vbWFX/Bci g/C/jAy20QCXvPBcoRH5P1n2wn9h2Qtk2au1RWFCD6kQFCWNDhbiY6ShcXGRYstoIPzH4UB4djgg Sn46HNS62bvYWI9d3PKaE/EpyjvoT2YFQfS2SS1+DfUq/veMElX2rXeVh9/Ed4VrAT4Be02dS7h9 p3Tfafbnp7wdfP+c94lHb2+tvyw9tXyq3vv8/pVrJ0jsF42L1L43dMC54Qtq9Pn5yY8++XZk3tCq P07MSP8k5oUe3mcjDJXVo08Nul18O8F7R1qGb2rpwl8sj47u8Lj4wMdhy6W+b3b0m1y2Wug7t/6s 35KRUgsfhEmvC4cuW/oX5O5nVMEtNl1qK94X2zZpyQmktpmcx+Kq+cpZ+kSeFzs0D+SlrXn3U6rL 4fkjUlYfnV90a8Xjtt7icBt0F2mamFrbqVx4zrdF1hOsesa8uEt5J9szM411HbW82ViqpWdmnijr +IryqV5d3WpeC1w9K/vKDw8OuF6p2D1/QWHdHt37fhs63vK9/8OWiPaGpTlHHuycNkpZd3Fu8vLJ H3bkPd7Ufj7yusIufbGyQD7O6X5WoepyZq+gck4V6fbh9mG9b37nOaQbeyP50YyVv77Z6qF//t1g j+nc9BSPMSNaH4oZql0wPmXa1ReGlqwI9F1s4QZiXFI0K8VeauF6YlcMsXbF5v/3+wrP2hpp6S3D RF9bZ3Fu3ilk0Vea7thJW9EHn7iIKGlkVIwYM/wpX1mlXJZwt2LI41OXb2hH1Hz31ZP2tLDM7D3m zxb87hCzIb19Rfi5z6q+CV80OOjd1+bvmHJONn+Z24jH667ZZWTeuORofFy9ZuKGh+u7rlbU59yJ 8VK86n70Qr1Tq5P7lrGp7YcX9lvz1h6/3mMMy+eoROOR0/vYlXpZyo0Byv6nE+/NnFhVt2b71jMj r4+erzl8fNLMt+su/ng2y7dyeUbtlMt1s9f7pHz48ixt7Uunz/tnJoRO18UsKct579C+nQFuqxZ0 2Z//4rn6d5JWru5Wv1W9/J5fsmVh5yMTOmyd5z0za98Q9xjL5GUbNUM/rvnAv89czz4u9gcHVEe/ kRC+N39Cxpedyt29XnLvtm9Mpw1XP9JP2356bVDlvCUTt+7w2bZ7kafDUTXzT1vZRcQNCmVuZHN0 cmVhbQ0KZW5kb2JqDQo1MjEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzMy Pj4NCnN0cmVhbQ0KeJyFks1ugzAMx+88RY7boSKhLR8SQurYJnHYh8b2ADQxXaQRopAeePslDmq7 VdoiQWT7Z/8Ndlw3942SlsSvZuQtWNJLJQxM49FwIHs4SBWxlAjJ7WLhmw+djmKX3M6ThaFR/RiV JYnfXHCyZiY3OzHu4TaKX4wAI9WB3HzUrbPbo9ZfMICyhEZVRQT0rtBTp5+7AUiMaatGuLi088rl nIn3WQNJ0GahGT4KmHTHwXTqAFFJ3alI+ehOFYESv+JL1r7nn51Beu1oShOK9OI/UeeiGWI0x2uz WegQT66K1gErKm+xILH9R4JtEWNBaZv8kLjqm+0Cll0W3VwVzYN2fodXyrCh/AGtIiilNTqLIjgD mWXeyVJEWOrFEsryPz+bZVnA1pib0/Bni8sO/UT84pzGzY/GuEnjduGI/XClgtMC6lH7LP98A+sS yqoNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MjIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTg5ODUvTGVuZ3RoMSAzNTE3Nj4+DQpzdHJlYW0NCniczHsJYFRF1vWtft3pNUkn6eyE dGiSEJKQjQQiSzorgQDZoYMBE0jCIkg0ICoiICAYRUEUURGQzxUROmExgIoKqKioKOo4My7RQXQE FUcZBNL9n3rVhaDOzPfNv8z/Xp8+51XVq7p161bVe6EhRkTB+NKSvah65Igd7VNiia5BYvS0EUXF JZSgeZ2oeSgSeo+oKK8+lPPjRlzX49o1orq2YN+IL4/geieRYVR5dVrm1U89MJeIPYn8himzGlt7 0YxXifTriZSKKdfPsW85+tRiouQINGhoaZ06i60LeIvIdJLIGD61sa2VYsiB+lJwv3XqzBtbgisn P0CUZkfzOdOaG5s+OfBVEern+TnTkGAew3A/a8J132mz5tywdPKCZCKNgUh3z8zZUxpXxt57gGiM C9d3zmq8oTXg+fDnUX4FytuvaZzV/HXg4q+Jqv4CJyS2zm6b4/mZVqN9C89vva659drsj5YS2bRE 4TbivgJSw0w/XBU49Ccyohkc+76I7s95/2u3jvPqPUnaH/UbcGkgDYkD9+hO95xmk7QtXr33Ou2P ak2XHlqeojlEjVBh0BqyUho1E5lvVttlpGhb2CrSkUH3oC4LVcYKVo5Si4YMRo3Zz6jRaBWNdhNp vnOSvUxWPababick2O8SNujrNRq4cyPPU07qonlPiWlbyAUIYzibaAPV0yw6TEeogGbTVtpN6+lr yqB5lIu8XNqC1HEooaVUCsYds+m3h8n7vvd9GuY7670f/U4ZQhsivwA69je5W9WaEUFeC9pPpZd9 6fNw/vrI9a5HDRu8H6GlLb602er943D+9pj1u/YQLaNN6OMsQizTJOittAT930oToOsB7pfdlAdV QPFUQkPo0d+thfcmCecwYIP3B2qiyb8pNfcf2PBL/7fSDLRPaHE3JXnb1JRWX+4mHy4/6r1uSvSl H/al8bvXsDjvKNid9zvt/LYWcVTgvP1Xaber52/TSnESy6Yqrx7fFfQl0qq8D6t5BniSH5N8Fh32 +WIyYin3H7T9Dw+2U7OVuVX5LZ1jD7JlNIQZcG5lnTjT6A2cB9la5E5D7d9SLrOzOg66G7HE0ca6 MULLvBf4yTRsJc4UplVRJ0rTZjqu4lHaiXMlxp3Pi69pEKzncZWJkViPGcBnxTa0Mxe5s32RFgwv J2MGrPXO8mLN827xDsf3fnhlE/qch7oWo/Tt0G343o1I2oRIWo34SlajbAPKtKvRMwg1JpKIpN8c XsQwt53O0Rf0sWoft9BCh71n0AafI+spGhbO9tlXj9pyVfsWYoWpoVFYcauQvgSaj9DX6M8E32ze SjxueCs/oAxWQZqP71xgGS2AlT9QOM31enC1TS0Zh3bEDOHzZxLmRRL6tI6Wo8bRajuPw5oa1UM/ ABtE7Wo7S3wdmqB+b0LpevhEzNAbyYnR2oSevsQ0ZET7Fpwz0NtI1JUFaxfg5J4bRN3wQjyUSz2X 0xqMXjJ1wvK58EbTP0w/Av+dYcH0Hounb7EcX4AnHucncyF+/ue5tosnocfLEIdrVF4Gv99OR1U1 l/jqaKFrYcUw2M5HPgmpVdRP7bfiQy/fjvEarvhOsRMe4D5LwNqtJT8of/g+iYppJOKrhsbTdNRy I22yh9gj7TH2W+x3eb1qDf64I4mK1HJVKNdIM9F7Xi7C3stXjnl/gqfHew/Ik/rw0zulu6m7vHvM 5/6fW3z29PmXE1VhDeTHTqr69G/2Pb7TiV1SQ//8YBdruzx50b+04PcOPRl8ynJZeggQih04XL2K +p07l9BSjNttiJ8VGMV2ukNNvQsryirM3XswxvfSfbSW7kfqA/QgPfRv2ff/8lB+kQyrBZvOZrCp bNq/WZuW79SICx6Xmv9WTP7rePzXsfjfikPniKarJk2sv3JCnau2prqqsqJ87JjRZaNGlo4oKS4q LMh35g0fNnTIFbmDB+Vkpw1ITemXEN/X0Sc2whZkDfQ3m4wGvZ8OT1iMUoodJQ12d0KDW5vgKC1N 5deORiQ0XpLQ4LYjqeTyMm57g1rMfnlJJ0q2/KqkU5R0XizJrPahNDQ1xV7ssLuPFDnsXWxCpQt6 ZZGjzu4+peoxqtYmqBf+uIiLwx324ohpRXY3a7AXu0uun9Ze3FCE+jrMpkJHYbMpNYU6TGZIM5S7 n6O1g/UbzlSh6Vd8RQeeL/15s24lvrixyV1R6Souio6Lq1PTqFCty+1X6Narddmnc5vpDntHyovt d3ZZaXJDsqXJ0dRY73IrjbipXSlub1/uDkp2JzmK3Ek3/SUCXW52pziKit3JDlRWVnWxAebWxVsd 9vafCMY7Tp28PKXRl+IXb/2JuORdvOgm5EtNsA0Won9xcdyWO7qcNBkX7kWVLnFtp8nRneRMS65z axp4zosyJ7SW5yySORdvb3DE8aEqbvB9rp8W4V402Z6aAu+rn3h8kG93KwkNk6dM49zY3O4oKhJ+ q3G5nUUQzkZfX4s70tNQvrEBnZjO3VDpcqc5Wt02R4EogAQ7H4Pp1S71Ft9tbluhGy9bvrvcacVF 3C57cXtDkTCQ1+WodO2hLO9nHQPt0TuyaCDVcTvcYYUYlITidldTizu2IboJ8dlid0XHuZ11cF+d w9Vcx0fJYXUnfYbm4tQW1bvQt1+VloV5z/XxBrtLE63U8dFCgr0EX46CociwYrjUSz6iBUPtLhZN shha8ZXg6rJ6cKHEF5byLIXfWlgaHVcXJ45/YlK0zyZdvNtwSV1WJFy0SbTzD00TpblBSfbi5qJL DLysUp3PQF9tv2+nhvvC1zDuMPDhLJVZSjxmLtI0qEZN4qMYYXdThd3laHbUORBDzgoX7xv3tTq+ ZdWOssoJLnW0fVFSc9mVyB98Mc+n3JpCBGBJcrQcU/V6hHp98bL0V9kjZba93eAoq27nNTt8FZId 0wc99ksY2XjH4OCBmJclWNocJY0Ou9Ve0t7Y5V00ub3D6WxvLW6YdgWvwzGyqd1R7RoarZpW5VoQ fRNvKpjKWFlNQWoKFp6CDgdbUdnhZCuqJ7j2WLFZrKhxdWqYprChoK6jL/Jce+xETjVVw1N5Ir+w 8wteUxUuDGr56D1OokVqrlZNUK+ndDFS0wwyjdGULo1Is8o0DdK0Is2ppvEDIxQxDf7FWltsb+Jj c3PdtPaGOj6zKAzjiA9zM8dwcmscwzuYxs/iNjmaC9xmRwFPz+PpeSLdj6frERUsjME5fEFqb3Bg kUI0uSiaiThUeJX2Lq+3xhV3JPpUXRzirB6Y4HIbk7Hw6+JHodwIjgYkj3AvmtLI7aBaF79XHz9y Sh1iVlaIIiPdRtRg9NWAEiXqPTwWcdMUjA0GUL1/ES7ci+rcdcm8Udf0OjWWrW4qdVyBYRd16hJ4 Q2l17cGOTHViYh6Y4pdzMsI2qnaJlGhcorE64SS9BZZPcSBrSoMd3tbSlGrEuVhITdEipRnroTah WYUp2pdJvFtKvNnf5DYOQIX4cG0ewOejLl5fVyeMV6+W+wqgbavbDIsSLnGl7wZ4B1kjuS34LIep vOhLvJrKLqpy3IBlhRut1qRHtts/fmQjVn5xvxkpjsHyZgNfIMy+Og6KVD3vuQV+V+JrurxPOG6M u+RITXHwnYEHJkXvQWBTXfuvE9xXJqemGH6d6q8mt7cb/H//BuEvg/9F5on2YmwZtIfsGmWnMYKN sndpNFIwKcgnmFcKjxQ9UpyX4pwUP0txVoq/S3FGip+k+FGKv0nxgxSnpfheiu+k+FaKU1KclOIb Kf4qxddSfCXFCSm+lOK4FH+R4gspPpeiW4rPpPhUik+k+FiKP0vxJyn+KMVHUvxBig+l+ECK96U4 JsV7UrwrxVEp3pHibSnekuKIFG9K8YYUr0txWIrXpHhVilekOCTFQSkOSPGyFC9J8aIU+6V4QYrn pXhOin1S7JVijxRdUjwrxW4pdkmxU4odUnRK0SGFW4rtUjwjxVYpnpZiixRPSfGkFE9I8bgUj0nx qBSbpXhEik1SbJTiYSnWS/GQFA9K8YAU66S4X4q1Utwnxb1SrJHiHilWS7FKiruluEuKlVK0S3G7 FCukWC7FbVIsk2KpFEukWCzFQilukWKBFDdLMV+KG6W4QYp5UlwvxRwp2qS4TorZUlwjxSwpZkpx tRQzpJguxTQppkrRIkWzFE1STJFishSNUjRIcZUUk6SYKEW9FFdKUSeFS4rxUoyTolaKGimqpKiU okKKcinGSjFGilFSjJSiRIoCKfKlcEqRJ8UwKYZIkSvFYCkGSZEjRbYUA6XIkiJTigwp0qVIk2KA cx5X17H82NlKfuw1mvzY6anTaqemttQ2pzbVTkmdXNuY2VCb1pDXoLkqc1Jt7IT9EzStEz6boBmX WlubV8tqUqtr86rZi9Vso/qpSq2srUgtr20tZ2nlbGMpay1lL5ay2aXMWcpKUotri1ILawtS82u7 NEpn7z6x2B4Fsc6YfiBSiXkFeQT1CLog6Hxnr2TQOUE/Czor6O+Czgj6SdCPndFpoL8J+kHQaUHf C/pO0LeCTgk6KegbQX8V9LWgrwSdEPSloOOC/iLoC0Gfd0YNBnUL+kzQp4I+EfSxoD8L+pOgPwr6 SNAfBH0o6ANB7ws6Jui9zsghoHcFHRX0jqC3Bb0l6IigNwW9Ieh1QYcFvSboVUGvCDok6KCgA4Je FvSSoBcF7Rf0gqDnBT0naJ+gvYL2COrqjMgHPStot6BdgnYK2iGoU1CHILeg7YK2CXpG0FZBTwva IugpQU8KekLQ44IeE/SooP8StFnQI4I2CdooaIOghwWtF/SQoAcFPSBonaD7Ba0VdJ+gewWtEXSP oNWCVgm6W9BdglYKulPQHYLaO8NHgG4XtELQckG3CVomaKmgJYJuFbRY0CJBCwXdImiBoJsFzRd0 k6AbBd0gaJ6g6wXNFTRHUJug6wRdK6hV0GxB1wiaJWimoKsFzRA0XdA0QVMFtQhqFtQkaIqgyYIa BTUIukrQJEETBdULulLQBEF1glydYbWg8YLGCaoVVCOoWlCVoEpBFYLKBY0VNEbQaEFlgkYJGimo VNAIQSWCigUVCSoUVCAoX5BTUJ6g4YKGCRoqaIigKwTlChrcGToZNEhQjqBsQQMFZXWGVoAyBWWI xHRBaYIGCErttGFJZymCkjtD4kH9BSV1BvM1uZ+gREEJguIF9RXkENRHUJwge2dQNihWUG9BMZ3W IlAvQdGCogRFCooQFC4oTFCoIJugEEHBgoIEWQUFCgoQ5C/I0hlYBjILMgkyCjII0gvyE6QTpBWk CNIIYoLI6QVzeIAe4AJwHjgH/AycBf4OnAF+An4E/gb8AJwGvge+A74FTgEngW+AvwJfA18BJ4Av gePAX4AvgM+BbuAz4FPgE+Bj4M/An4A/Ah8BfwA+BD4A3g+oij0GvAe8CxwF3gHeBt4CjgBvAm8A rwOHgdeAV4FXgEPAQeAA8DLwEuD0vojv/cALwPPAc8A+YC+wB+gCngV2A7uAncAOoBPo8J8c6wa2 A9uAZ4CtwNP+FbFbwE8BTwJPAI8DjwGPAv8FbAYeATYBG4ENwMPAeuAh4EHL7NgHgHXA/cBa4D7g XmANcA+wGlgF3A3cZW6PXQncCVijWGvUoihNa+SiSE1aRF5EeYQSG54WnheubAzfHq5xhkfHlrTa FtnesTmNn9m0i0LYJivr8r64w5qSXgJ2OqyxfUpaA9n+QHZ3wMaA7QHK9oD9AZr9AW8HfBqgOAOG F5QozzH1lzHE2KqOmurk5LIuvbeqzG2ouNLNVrjjq/m3s3KC22+Fm2onXOnqYOyuug6mKaxxB/E/ ParXy1aupJiCMndMtatT2bQppqCuzL2Ia6dT1V6uCUXqktvmzG2bm5zc1tbGktvmzmlrm0PJ/98f 7D9twP+dg3seAzEHowAxZ87c5Dmg5DaZ30H8L875Xo1CTRoNwACiJuYFPEAPcB44B/wMnAX+DpwB fgJ+BP4G/ACcBr4HvgO+BU4BJ4FvgL8CXwNfASeAL4HjwF+AL4DPgW7gM+BT4BPgY+DPwJ+APwIf AX8APgQ+AN4HjgHvAe8CR4F3gLeBt4AjwJvAG8DrwGHgNeBV4BXgEHAQOAC8DLwEvAjsB14Angee A/YBe4E9QBfwLLAb2AXsBHYAnUAH4Aa2A88AW4GngS3AU8CTwBPA48BjwKPAZuARYBOwEXgYWA88 BDwIPACsA+4H1gL3AfcCa4B7gNXAKuBu4C5gJdAO3A6sAJYDtwHLgKXAEmAxsBC4BVgA3JzPv+cD NwI3APOA64E5QBtwHTAbuAaYBcwErgZmANOBacBUoAVoBpqAKcBkoBFoAK4CJgETgXrgSqAOcAHj gXFALVADVAGVQAVQDowFxgCjgJFACVAA5ANOIA8YBgwBcoHBwCAgB8gGBgJZQCaQAaQDacAAavoP Ts7/A0fdf9qA/70jgkg/Uxnkqf/VrwiqqIXaqJ3W0uP0PjOwLIx+m/prwW30Er1O3zM/FsNG/5u/ nbjs0EXzX1V6v/Us9J73Jul+8Bz31PuFe/10H3ptykmRp1tGFk+L94xnoecjb5L2gKfeS34t3iTv 9xonGWQN2vkUjLSzuhbdMt2TuqPol/o7MvVXqv/TYwx8cBU1ww8zgJnUCq6niYQZRNNxdS38MYeu pxvpJppPC+gamge+hW6lJXQbrcB1G1JE7kJajNTldDvdQXfSSvVXNItRcpn665o7fCm3g+9Wy/I6 xG9vxC9v5D2raQ1GZJ3v9za//h2OTF9PD6slL09f/0/Lb6CNGNtHaDM9ihF/krZgnEXaLylP01ba Th1I36ymbKP3cXaTh87TBfqOTiNOTCyYRSFahrExWDOaaZrqpXp47RqaS7PhrzbVjoW0CD3kfVug +mCh6jPuH2Hl4l/9+ugXD9yj2r8OVnC71qAP3H5h+3+paaJ/v+0dz33sYv7v9X/zxTJPobdu6qQd tJN207Po+Tb0vRNXu6CfQO+f8nnkGeS44RVRdpda+slL8rb/JreL9tI+eo6ex0zqoj1Q/FumvUAH fdfi6iU6gJRD9Aq9Sm/SEXj8Q6jX6A06Su/Se+r1R/Q5/3UofUonMA4fY0yO05f0FX1DJ5H+HX1P p+kMxugCxuoCZi4fp1SMVCTmcDxGKxczWUsuIm0A5pJCeoqlDKrfQw72QGdqoD//O6bVaojSv4AF XEMhWPINeJrNclq1Gv91Vmu/yAei/O5X8gPteOvb2U+7lhVSXs8nPW/h61RwbtoplvZx9wfd1tOv BOWmdR861p2RzoLiglTYAjQOvSMxKzN74ACNw5GdldlbwzLDQnl6nwGa7IHDNdqAC6MUV49Wc7W9 YGqptsnvulX9R1/tdCRNf6A5w9MVn+Efbg8Ojg0PCAiP1UWfO66LPp+vnXx+g+ar1Nr8xA0XlqSW ZkU3ZVVO7fkmK95XLjjYHhHAf403C72OQa8tFEb99hCxQzut/szf1sUedZoM4SFfGPNtJwzoz6m8 U8z6Qfexidx6W4DWERcUZydFtTooy66NiXG23HtwgecrVskyWeq+gTM2zXxgGXtBs37S1ntvHJem i/Yc8my/48Xrsy+E4n3gMJHiRrtmyujwM/HWbBgXLTGL3xdGI9N9ock3HWeiXdWF1g8+Phicaz19 KCM9Dk2H+qC4eyI1J3re0MT2dGuyddFrPVev9QznvyPcihb2qi3028WMZq3Br4s97jSb/czHjYU6 QgOoPBMflnb6/YPWjw+iX3HZvoqz49hHnveUAM97LPXCDyxVu2zt2gsh69bBY1hNlbOoN4DCaQD3 2IEdgQabnnfB3xBhO+7nZwjpNuZzn100/fQh6zHhN+4tR1AcRlk/MIF7LjNHOTv0loMrNney1sbO 5RV7Hrt39+MbnlbuqHj45jGeZF10csO6ubfc1vNlO9regtGKRtuR1JfKnEZNJKPIMCMFdbGDO6JM sUbVj6b4MP1Be6Q90tT7C3O+qRBe5Lao1uSmpZ3K9Rl0+hVcB2UFZcGjDmWActEyHnz6sLBwxWch QjD68IGwAdl5iTWdbNJ1j07P6DtietGgMf3GLpn35Kq85hGJbHN6Xry1B/7OnLBwzLBZdfnWkKvK NX7Tp3kqYnKr+XjM9n6rHNelUjaVdCTQPjz5hlAq7Db1yknYywIpEa+TlqCw0sT+J1JDdHEFCIqw neaAv+qKMJk+OJUHY3s+SObePNh97PRBnzcxRxKzw8K4kZhBfny+8CkUHpqQ4OjjF2rr7accH71i f9vAqVfV9CnbN2/cjWMcQxrmL5rfMGTw9XsWxY0pHxM35sHSB1b5EtnkiXdOHGCwWI1be9mjs0dn ZJcNyRg4rLp1TOGtzcP9zAGGTWHhLeOyRw/NGDi89jr0axzGxIox0VMM3mZ4jBl1CtMe98tX1BBA fL1y+hUeXNy92XFaq2fBTs8CZa92yfkF2iXruG9SUUeuuo+v2OmvRYx2sS936QO0VisqPLGb6XES RvehXa0GZtAGd7E2p4m02hCb1ay1m17w/oEs3s8oyPsOBXo/cwabA4MsJq1fQIDekK/nAZCvBgCi MTx3MD8w7MEsd1haxLFuK6a0GhjW7twgzDD1G+YqDiVRj6+skPBBIeqXNtd1YnNq2tpPJzyZFZi3 Yf7uYdqBfMFhR+97xDNEF31h+Y9vs+M9Z7fuVPbwtWUZRvwlxUN2SqOynaGhRhbL/zbuH5fYxV53 BhrTLW8yO/VhffpE2StDu5jGabQF/RxVkXJGW8Unvhj1tInBuWLpOQjTctMQrYl+fmJxzMnKyh7I B1qfPVzh4x4apDj6BCCCeyMMcgYp8dqqpyaOu6k8vvvP71w3t/YxV1zlhMmZV97TnLP94/xJQ2OC +zkHDH1o3PLK0pQx04bd/7Sr7uoEx8OW8GBzv6qba3pGs8NR6YX9Y7KTIkaWo0ebvD8q5/A0FkIJ WLfMsfvwrmXAAO5wWm2GRIsusiewwljd5z2DDh3IOqVOOZgOJ/8SsAmJcL4+JydLXQOwfMJefZAI YeVc8cLd19XtvXKboezpyeNudaV0hmeOzYkrGlk5IGtG+tBZ1Rkaw4JDt4/sE68b5Zm/t7m6dMme m8qXTsoOzagc6om0hSfUrUE8bfD+oGxVzlEMDe4MpHD+Txh+vQO6mNFpXBjIAoN/NldQF9M/2xrD YqLOKVV8hk08pX4JT2ekx3Mfk5hPYWI6cb+GqW7dWnT36G893lG37W0du2J4/vLSwnkTBnY8PGLZ 8PioSKY5O+/l9rKwyMf7xGY1tI/fvctu5zsNjwb4zkZxNLDDYuahYIjGsO9wBlEfg78u4py1ylxp qo79SVfBh18sWHLkM9JDfLbAfQ5fBAwS9gSpk31WyeJds9Mnpm5f7zdyy5RxS8andF49uWBNZfK0 rLs2su5Fr94+wuLPHj83/4UZLaVLuubv3nH9HPauLbSLx+pcWPc9YrU3JZFzh8USCv/s3hEbmqSF 85yhof1jj9ytZVpt/75Hoyr837foz1irxLrE13jVbaexiXSrAcpsfvo4mzqig0JlrIqFSZ/jG3Hl e42mJ2/r5hRXVZl9xI6GxXvn5Q6bu2Xm9M2zc3cp9sKmgtxJRf11muT4zLAHH9NbAo132yJLlr10 04zn764puPGZqsLZFakpFa2Fvt/UY19Yjbi0UV6HztDFOp3RAWazRU9hltAA3RlzoMEQZAo5T5oz QTWmSqwGMB3zPC03CwuU9RXrB2/h4iDfXRl8GRrK90F1ucq2xmWGM2307VO+YV2e0g7P86yQbZ52 y/nj2i9izrhX9wzSHF79OFsd4WnjvzGf5KnX2uDHITSaGmjlcxTA+H9uGcM6ns0gc4qSMUTpYh1O //F9M8YnZYwfn5GkxIXvY29SEQ1lbzgT4hqtIZ6S0pKqNwx9S1IUQw6VsBJDiaExZ8ixK8rr38ip yDvaa5z6WJDHO4B1ayKnoFzrqaAsK+8M4qU7OBwZaXw5wy4XjkXNyrffMN9zVQLCB6Ecruut/PKg lTNogCK/RaDFhTKbb2dJSIwPUELUVUXdaNQxVNp6xeZOWz0+7xp7SNTIocxQtvDKrCtu3Lvopqev ySwaEZUQYRnWPyQm1Jw7dbUrviiKzexR7l1afW1x76apnnNxyRGmbPsV5ekDKwfFSFYmOSbmjF1c nxVt65UZm5CpMWn6OCcNL7zhypzE4qtyR16TZembnB6ePzM9PCVrSAIvaTLcdSFoRH7vjLy4YVfo jGH9k5OV2PSKwbGOoWP7c+47ZCzfYzZheF7F/IugtI5AM1+5LEje7gxklkirWXc+tCKg2lxJlfJR 4Zd1K84RNDBBLFMOvnbxpTYsVHl12/hKx7CCsVnbtvkllZdXpax9VLN4TltIWsXQHryCeqZuyCjs H/xsF+KTP4sdRXwasSLlP0eBrAePMFrEQYCR4fTT99Yaz+grseX3c5psWExLbfSTUo5h/iT5VJ46 qEfEFqU+RiEsxUNaiO9pRc4wdsbzIfuIJV/4Exs1LCYzPjQ0PjPGx0r9qguPrV6to9CEjJhemQmh oQmZvWIyEkJ9z4pH4Rsj9d+j2hXks8uk2kXvK9VqyF1iyKVmXNqs9szd5y2rV3OPT8CstGAupFJp R0wE//fgKH/GKTUeq992Z7i//4A0vzP9K0LO9KmIiY+KLo+q9JcjgJgWIc5y007n8m2ar4FxQRd3 DMelMitcDAr/DgpSZuoDw4NsfRLT7Bv1gRFBwfbE9LhNywxRGQOH9K2siRiQ7ez/vOZo2lBHQERO XX7PfM0Lg4oSAmwDJ5T0zFdO7s+tyAifMZvHo+fjnngZO+hJOGJHE8ZjJ5zMPHYs4REaCq80V1rP 6yuonD/vcNNF7KiLtrQs6JIg2vSQPqUKAfPQxm2u8fZhBWPStyknNw8s7h/0bFfPtZrF118rggiR U+/9VmtCyyGUSH2f41stlrje2DNMpn6RPwdWOM7qqn55Oen+5anw4oLr81Kob/JqTQU3d1478+l5 eZI7k0bPKhw7e0Rc0uiZRZyZZ+6BO/C89+KCuS+BF7+4dOIdE9OGtSwfhWdDzvxJwNOinINdNoqn wTv8TXYDH1hTAqn7WajBP8ES1WOtsJQbax3vCRPzxILF0rr587f6jCUfCPgA/t4TQY5yrmzpzunp V2Vse8hchk3tsieC9BlZKzdpDLe9trTAZPHU6257cupvngf2850Xtr6k+rAPdl6Die+8ll42sfM6 /I19I88FVplqjRX2Yxd33qDg39l5B8HQQb6NVzxg+Xbe3Hl7F2c1DX5wu/Gug65bxyd3RmaNGYit t19z7poHWffMl9eMswYlnpvG5n/4eunSrptqbpuYyTffkIiXxbug1qDal9mhCd7HOqAMmIRWY4hN E2QwUEil5bxOhhfftC4PMO65ML0jR4bX4Y26umdc6x/xcyvVFY4RZTXpbuXknqsbXn916bzIQeOG 9czns3M3dvx9aDWbqvdQCtuxK7pvdF8Txm/XjiBTjmMvI+rLX0mCI0v7Jp4JStHbK+A5ndO00bzd rDEHnNXLx6Zf3kyOYf/H6iBfkTG06rtJDt8xEn/ZWC4+TeFFpbei7Os7vGri5LSWp6tc28YtuCEk c/qVRW016YmTNt0wZNXYqjU5+XWDIkJzW6rqbhodx4Kza/IH9A4Itm2KjCrKi05O7B9tyyqZ5Ozf NC7X3/qQLcTmSIuOTklKiojKLXHxnubhafAw3rzCKbvD6s9XnjCTXm8IDzRE6K1/t5j8y+l8uO2s 4nugyTqirnPH+Ou2+kSgPgomZPOngaBB6mu37zHw8JBb8p/f6znBIrexA55hba3p1w0PCPR/ukNj uYfZUj377/FoZl4daOUrCLz9qnKSwii1Q0N8BbGRPywJMIVrKLTcUh54Dv6svGQB6RYLniMxQFFb zwqyqQ9UQVnKq+v9UisrKlMf2rBtm31YIZYPdfHY3aVZ1XPLCawdwzQPos14xFWB+jfUVc5EndbP z2Ix600ms9lo0LKgIKui1WgCA63WYArw5+9SAeqrFH+N+oy/RvFXKme42WoJDDJp9f7+eqOh3E9f qWGVwTwUM/Oy+PnLO5X6ShWZlpUVcTCTM3/HUt+vI6wXE0Ti779dFdzz3uqYuDuOrN5SE5x8z4KH UwPHKicv2NijLTM9k5WTPePWLYOXC5et1Gzno1qC3iWhd2Z6r8Nh6PJ+5eztcGjsDkb+itZiNOn9 jKZyvd6vXFG0lYxx32am5WWJD0vLSsuyvpKJT1mVa6eG+ZmUwGinRRUmfDuqmDV5ecBB64LlhoN1 NJiX0jE/o5aXUoVR9+tSvIyB9KKMKoz4dlTRb2oyk160pwqT+del+Lgzhk8W/2iTTnhOe37sZss8 Kz9lBqZ86FnOFnoWs7PsR88t7FYPfwWjIZ4GbQz8EUEVTn9bSATZg4144ouMCu3yfrYLT37BlXiD VpyBpv/V3neARXW0C8+cLcDC0nvzUKSXsxQBQQF7LIiA3aDL7gIry+66uzQ7WLB3UdEotlhjrzHW GKNGEltIjC1+MZbYe7DgPzPnLKyKSe59/u+//73PZR7eMzNnzjtvn3dm4az4LWT4UNjHwdHRlWgy KjI6OSEhnjtliOf06Ho02r02qjYKaQsSGzQeNMRBVmFeDetjh02skbmHuDnHeDGZXTvQDZpjDdGt 7yC9jZ58bEwSRS3lCTyT5Z2R+vKX1FDzEJ3pXK7uArpvNRfgTN3Pxl5sLxLZi3m2wMzN1tVe+Nzc 1tbJygWn605Z1qJzVr3IWRWXs5OU/XvbK8fYLNf2vbSdpCSNqXtj5g67vf4X9DWm71zyfnT6dCqJ pO+YsreP+RJEWSjotc3J2hLn6f4tfH1pIA6nw3ytnluL/IJs3Gg6yC30FRA8D8pyrneyf+7GhQ2O OPsEJMImCsmmAu99I9iNuVNT+DDujAipXGTkS+gO7VM8EnM6BsAfG0K79AhJp1t+GtNWlR7ZcAEG ttF/nh87uS3/srnYQtCizadttsxuqBwqs7acZyXy7TGiP5w3+3N5lTzaxgbviiajuHeZ7IoCQSc2 6xQAGgUdkZdXoHeQjyftAnDGaSdKsXPsIvJ+Qfd0rA/0f+5i3Nmh5NOO3YIeRUkYyS7eTzhNeODY oiLfSzzhdy0Hx3Qp7Stp2EhRA/uHZPgKZhtzT2Mu+rKEZYBqOeeNHDNkSn8LEA067QWR8M22lkJE 8dadzra2MbE0pt0pJMXWpUuIu8ufzg7P3dPN6oW856ImjdgSFlAKeezRMTY7elf03OEJm3s48d7j jpo+cEBIL5ojf8CAkEy/gCGxncv6SbLf5zHdVAsFuDFXjBoj+1M/vc8rgDAWcXaVPUfZ6mCJExFr c0dLc54oE7x0sH5uXIm47b/xNAITHG3H7at5VxMXdM2el9tqm2GkV4eOHbx9nN0ipFX5fOFr68mV ZmIH/P/CTRKM2Uokl+LsbGND+7jUI2nZApF71jsCIwt5o7z+Tlofl8470qAaCnIaG4imbJRL48zR A6TucHQUQXtMlrWrq8jdxdPV8RwUOuM4ZZligeKUMN39NI5QxrMwsjAfRcbInYRBNrk2JhRmxPej 7fxi4Tmhf7c+8jaMLIhRh8dmdu8aBkPfpP30E8qzQ9tHuIrM19s4OEt6tHrzBEWAH6dwJ/J3EV1u IHy72INC+5Wtu9zcKTO3XlZ7oNUusf1bs3TYkz054FboBNtjjRk+PnNlfZzNwMIGyA2dXRKT4h3p TqlxtimqwZmBOA2L7SFxFViIzTfZOFoLfdtkSt6MwdE7B2kKS4UB6TstLYXh/kIsFitHD1QkUf7C EJtwLBT7CBCS7vnCw/V5i3SrekuL5zZNtp58mUSgBKw/9jjzKCskQhNW5YeajCKExzVKkRcZm9W9 W9jAAZnt/AbEYr326W7pIrZrYRs7OC3RlgpM66tghcqTu0jSWjXsGSpzmWdhaTR7SM2hnCK6xPAi OjGskAEFN769T+1A1s5DMd8P72GuoqoFfLnNgeLvgQHbrTNAJpbr92hrQJwU5QXv72ypao9q76Ee jJ+Tkx/j4cn4Ozn5M4IJr17yha+GOflLPIy3PCT+2MOqqJe8MmT5bsBlKxDtoaidjjbgB7csZEtH YSQx7gA2AzWdJZpXFj3kkzAvfy9bn2g//xSJV1LZzjKBOXQMTQkJiQ6LDnaKCHD1ShqQlFld1Anr 7T71kjrDzrMXOFLULiBC09igec7fg5HHEDcOzuyJiXFDRua7bzKNX6rEq03ZzlLeOMoJTxMTFhXs HI6mSRzQJnNRcScUCfN5fvxwMks0CNvq7o//JD8COKJLipUIBLufiM6yASdY7giDdXiP9TEmBc11 Uj5hmalB7rS7TQvGxycpwiNBs1pFWaHOQJPOeNQpsIUOQUmBgUxIZKBjqJ+LZ3xWQtpMdbvy5rtx JE9AGm0woX8fBQCiH5EvFoEIRH5wFiKflRoRXB35uBAfWTUjvJbNdVKdQrNS3qV/lerNk2aY4q2i HIPaBAZGhjCBjiGI0LjeLP3Nd2MtT4A/8q5RhchsrXfwIO8NBPhDzVr2DIR37fUq3iD440Lw9i2Y QCWikecoISwBucgO+Q2DeK0FZ4AYuGwTm1P4f7gszfDrpJKTkbXX4cwA2OHPmwJb2cfaQlgIa8OG bp+k+PpQwyjBmYbeb56pbj15OTrvMFx1A16CI9EcCOcRXmthHJpjLMhFc96HJTxr4QTKDGX9gJeG rbIhmGfNiwNOwGebpZPtHli1W2Ap0jjRQA2S3d1qXZPdaqFr5KM6LGL2ENAssC2PbNNgO/0X+gRG vaW8p3RKv+CwgVM+5cVFzNhwILvv7k0L48qDNROqevZZMqEwgP1LiRHvlN3gFlug4zslA5UtlCfV lpR1/9MKz56Xy9vCe8vP5q8UaAWbBA24CIOFM4TfmbmYFZrtN/vTvNB8s/lt89sW/Sx+FcX8Dy7l otuWnzRTdn20/NFUrGJMyliuHGSLOPzfUPLeKYvF31tHWM/4aFlpveG98iMql/+3/G95p9z4q2Lj 8e8oKBaHU/gNQeybjuQE4joEtqSF6xSwFuwCxjduRQmOcnW+yRgBcBU85+pCk34z8FpozdXNQYhw Ile3ALSZiKuLBBmN4y1BH7MQrm4FQszGcnUxtdBsPVe3BipRu8b3ZUWJNnF1CMxFv3J1CpiJJxvf jAXcxLO4Ot9kjABYiddxdaFJvxkYLd7J1c2Bk9j4bi4LYGsdzdVF1LrG8ZYg1Lo9V7cCTtZqri6G 3a3HcXVr0MrmB/yGMr4FJ2e2zsqZrbNyZuusnNk632QMK2e2LjTpZ+XM1lk5s3VWzmydlTNbZ+XM 1lk5s3VWzmydlfM6QIMotMdgQCyq9QBKIAM6oAF69JsLDKivParpgJZAKepRopoa5Wo0SAUqVGiQ gfryQD66pyctBboq0OhiBOVoZHvyBMaoQhjwGCWBUnQtJGNoNBfGT4Mi8iweoUZQS2jJIzMXooJ7 81C/Al2LUUtHMBeStoHDqSb4NKidT6igEUd4pAzhLiR/fYjHyAiVNCjhRinIszQagTFi/rWoLTOh Tk2kwVKO7yoI3lz0y3LZJA8ZwiklNMvQMxg7fgb3FZN5WMowFimhHVOhRDhwfxhqqVCrgPRjicnJ E2VkxhKES9mIM4zQK0VjjXJREhoxH3nkLY1yjhoN0avCRM5aDgfmS0qoNkouh+gAY8QS0hMM+Bkd aWvJE/JGGWK+szh+sDZZjRVzcutL8MhRTwnB1CRHOZGkllhEGZkdyw6PY5+UkjEKQkkesYUSwl1+ o1WwFmm0R5ZOFdEcq3UDqtNElzoiJRXpU4BSMr+B6ENNalhTcoJdaSKPv7YE/Tt6whZeRHSD5zbK xGjlRs70JvIvJFcFJ91Crh/bZg4ajSWC77J0sbrF/khz9CuIVBWcbRh50hB+9MSDFWQMpqQn0bUa UcTaEKZBQTy5iNMp621YekUEK83JJs9kbh3Hr7qxT038SUGkp0JYEsncrIfnE9rCiA6xJxoatcra 2LtaGU6waDgcxjH4Hmvpai7uFHNeg6nTcpQb5SltpCiH0z8rL6NNYf+XcrFFhaCh0YtMLVhFvKag 8ekm2co4a8nhPLiI+Ie80c4+9CcDmc9AxucQjRaTqFDWKEFjHGiO7hwy1jSilXDxA1OMY2weekpF Rn0YtVtzNmkadVubRPo+HLVKzmYkCCe+87FIreB8T9Eoax2hQMlxqGuUBetLCqJbHSdJ4zPN3839 D607xpXBKLvexCKN9pVJpG7gbIOVXCRHwbsrgoZo0MD5LJZpd9QjA0GE72Au+tCgM6GKfRbbjBbJ MRKVElIiyJr0LuURnEdHclHbuH5pEYYy1IvXhKYo8i5WY38uiQM6El+M+PoTmtmIX2ayUhoaI01T dGV1x9pkIZGPUUKsJRql1xHJrztat5r8yHiHjbFyIhNDo9RLyFwyEoWbm1fZTDRp8pEPYz5r2VrC qZrzMxYXu6Jj33yfb3yfjZBB6KlgYp2s98g/SpX6A8z/XEZN2JtiMRs3WeuRvbMGfch7k72+S5dp rMOcsLwYyHxGq8f4WV7ZNVRNIpT0o5yycpa+I1NjVHnfB7BUseUVceuxgmRUMs6mNGQVUJD/c/lr Df3f8osmn4gk1GAfKCJrQATRlRaUrqOjGCaW7qGU6TR6Ta6Bbq/RaTU6qUGpUUfQqSoVnaHMyzfo 6QyFXqErVsgj2mvUeo1KqqeVelqqLFTI6VyNji7SK2ilmtbqNHk6aWGhUp1HK9TFSp1GXahQo8el ajmtMeQrdLRMqZMVFeoNUrVMoadLUJeCltKFGrVGr5XKCDq1ASPXaxUyZa4STUnokOVLdVKZQaHT 0/nSYgWNkNF6aaGCLlHKDflhtEpZoKA1KjltKNMqSnRKPDKMLpQWYFqUBjRHnkYjR2g0SpmC0KxF IzRqqYoQl1OkV6oVej0t0+h0Cr1Wo5ZjCiPoLDSPshAxhpin+yrVck2JnqVRrtRrVdIyWqpSaUrQ TSktV+iVeWpEkSEfiwIJEssR4VRpkPRog4ZWa3SFaEaDotSAOJCqaYNOKlfiUaj3PSHoWZ7aa4p0 SoUOU4JFjifTE/oLNUh0Mk0hqhukOaoyWqdAuBC3mlwa4Veo5QgRmUmjpvUynUKBVNpTq1BnIQnR uQqpoQhxitQmUxXJFUiq6jzytA7Nq8Y1dVGhQidV6RNpPVJ4vkIeRss1BgNmFUmMY2W4AllOIumR qpDQ1ch2kHr0+VKtgqVTihHlIP4RXVhSOpkUWYtKYcAqYgWs0mgK8G1CrQyJJQcpuEiN6dc06ckg 1RsUdE4ZXSzVlWECsQ004c6R6lhDK0H2oY/IUOQVqaS6RtNuTRtNtzUx+j4ILZI7LYlgGFOjViiJ nUqROPOUaEIdpgJpSVEo1RXQhB+TZm7zvoOdAVPXW63E8so0SA0KQlwkQsA5gqZIbUCa1Ud0L5IF SfXByHzozjoNumswaFtHRpaUlEQUGpFHIEVHItPG/qXNL4uUGYiJcENxPVeao1MW4HH9NUXI8MuI Uxqw0RBzRdwhSRYqiQKREDF5HXt3TyU6wg1ksfIimQGTXpKvlOWbPKtsNBOikUbLR8LW6pRogAyN Qo4eQRvn1qiRQQYpg2kFUo/cFJXaOLhZishwYsXINpF4ZKwHNc5O5MrhYq0uSIlmMSgKseh1SjQr 8lC1SiM1nRTRLGUpxaZi1ICmyKAtQn6sKMYhAY3JV6i07zH0T3RBNBEpV+RKi1SGCKleW9r4JuyG 52AWAI1nL00/EI0QoeIAzN6+BTZkBH5/uDM5i0Et6iiC/MZnMRSRt93zZGU6FXDM0ykKQIhKalCD GHQHZma0o4EtAOy72QnkN9bQ/YyePd6/34T3AC//Hbx9CF5DI94A8oQlEJDRNsARuABP1OsDQlGO y94TIlyWaAYn4Aq8QCDwRbsVSSMNImCG+LICdsANeKPV2Q+Eo9zZSJc/N8YcSUUM7IE7aIHWbn+0 TkVz2PGpjjWSljPwQCtmCGiJ1rQYECtDMQemENiFwHQC+xE4BAcamE+gmkADgcMJHCtXawrhRAKn ETiHwIUELs1Fqw1cReAmAvcQeITAUyqNTAXrCLxE4HUUh3TwDwIfEvicwNcYUpQGXShzAq0JdCTQ nUC0jqkMVACBEQTGE5hCYBe0MOVS6QT2IXAQgTkE5uuLcvSUmkADgcMJHEvgRH2RVk9NI3AOgQsJ XErgKmJrfKLVv7tC7pTzY9DiLyAP2Qb7lvx/WiNv8yB+QJl4gPAvodVfQApZFXuqaqx97Ipt+D8P RR+F9shbIkAr0BZ0AmnIi7NRNoZP3EaDiWAGqAJLwedgE/etQLO4azV3XcVd17OcQm+2DTtx11Ku v5q77uD6f+auL9krlcFd13PX86zueOZsmw+4q4i72iKpiNDvUHCfaEIJ7rE91CdUV9wDu8HuqAc9 T3XBOqOcUCsE2MPBMAcqoAZqoR4aYCkcDkfDclgBJ8CJcDKcAi9RmVjiMBtmo4mkUIqoxG9UoGAh VAMeHAZ1QABLYAkwg2WwDJjDUXAUsIBj4FggguPgeGAFK+EkYA0vwovAlspAvNmR77NwR7/2nM3Y EBoXwpVoLh5cCzeg7i/gJsCHW+AWJCsKRSoLOAvOg1Vo1FK4Eq6BG+Fm1C/4cDQ8C88iaupgHfk2 JncgokZRo6kx1FiqnKqgxlHjqQnURPwdFJSCUiCDyqe0xDsgcDWhCf+dKoRF2LbR8+zpPiTfyWEc YWdyD2GDRWg0oBZTq4kO8LyLqSXUZ9RSahlVQy2nVlArkSe/Py8F4oEbNYWa2hyVzfZVUpOoyeg5 IZEyINgohG0Y4FEGaiQQUxuojcCZ2kJtQRyx+BdR1dQ0ajo1g5pJzaJmU3OoudQ8an6zfVXUAmrh fwC/J7CkBlHD0L0iqpgqoUqpMmo4NQKNRNqkBlIDORyQcIy/+8MR6acFpKEPTITb4ZfwBJ4NTEMF kP/rhrA1bI0sYRvchrS6F+5Fej4Oj5OV6xha0WLQjiuF+GcWGACGkHcS6EAp8tHxYAryyiqwBKxA XrgNfAkOIc1YQOQL0BIiq4e+MAhhjoBRsBVqWUFnBMXQBUFriLiBNtANQVvojqAd9EDQHnoi6AC9 EHREPk1BPxiMoD8MQbAlDEUwAIYhGAjDEe5IGA3j0JWBMTAeXSUwFiYgCeZRuQjqKR3A32YzCeDv I5uKCkRxZQbqm4cKDxwBJ1EkPw3Oozh3E9wG9kR2Tki+w9CaSrya2H6Tx2CvXt1orR+3O6OtAi5u s7EKeGSiqyPb7dGNqfDoLLQImdhl4gsxNKNqKjziUVcMBaHEkrEQCkKteZS7ADBSoShUCPmwIo6C /JpMphcTZtLjucJ7rCdIIqUn+bIjDXf0qECBFRXGxwQZ39Gn2MV6zta2O0dOKh7Tc87sgh8+iQ2q qXB6yVTwjqLf8BoeBSnKtvNBt/lXp2d0av/iYmEXsWQVI24kFQoQUeVTCZG83nyhAzUgVeLEOOCG uYNVXwXeIKjp9mizI3Fk7HG3mYNlhyJdjhRtf1UqhcQGYUO9IgdhVr60xKCQeDEeuMPSwZHtoNsr 0DYxVykjGwdJC8YL3+Y5OHO3s9AmG22XC7U4KW6fyni7iJloSRQTw5CfAS5iCW5GR0XHJsQmDGAy TYjtnSlxYZzY+a3RhkeZifanYfQnalmEJJQJZifyNd4gU+G9CjtXJtrwK/EmHU1aAX1NpQIFgFcB bQDqF1EVEIJ1J7etOlVLbxaNmryxsujhjrRHVw/bHMyT7l8p9/xlX/3J6A3jmcn9Rk+7WHC51VKb g2fulj4u+Xy0Jung3M3iL/Ofquad3J8RvqFLm2e7fvx0sAe17GVkgfeqFyurP3c/Tl0b0z3jN+sh d1M8R+8VX0n+dsfVyv2Dhw+VRPAWlTus7Ux/L9GL+4bXlsZEz7dfZL/3Sn7k+hu/HZkyLeTrqT6V ufvH9eurKTqYtD6g8tOTtk5Jy8b/kXVYpD7a8E3Xy3vN7Bb4jrzYNvCMd+ndZZITj274ul08ur1z +2r3wTXes65nP7s/8tGoDTlw5rMelldO+/ZZO79206TiTfe/FD+53uNCzav8mk2OidsrD++jeMjw V5ZfZMp/ZmKE5shiBQIzCPlBTADjb2wzcKIrt5/QyPTaiGIkd3xggPcTxHa8HCB8yzdnhOhCQcCk 4r4W/NZMPNOqJqYmaiLDPS7Tqd55OpK1FVNTaZ8agUYRS/VqybdiREYqeOaMNe60wXPh76ARIgpR 246PLHOVG+NitG+eg1VWZioytPhwSXhs9HtewSsvB10L6v/od6SDp2Ry2aLQqoMVG2GdZ/faLVP6 qa+aB6/MPn5yrsNNfob4QefASBC/5fqJuWnV531znF4kx/n01ErGPpoaX7n91q0FoOGH3lVp/mfX BaYN37Rbmvok5PubJy5kX94XOqHtzs92XrjW9+2BHd+MfvaD1dKHCxpCzyVmeHjEB75I7op8+C1T Qd3k/Fh8O/Th+Z+DJ7lGCSyyq4snve/H/xbP+NAdmXhTd+z7DyeNZMLZSQP+blJ8T6H7W5fclh7U 5fK5/OHjXTvkFn06+uieZbKAt23aLxlpF2/bsrf+QlGg8k3aXnrQOVF9jUfIvd59fKQ/e1+8/lV0 wbcPLq+MU8zwmGu1K9N70Mjc2MGCKR0bitOuZo5dUU5/tmnSoBXmL35n6u/7xnVvJ/r+6rEWR+t6 3y5P3pmxMmw9HP54xfrpsQ3Lbnw6VLCsTcFvB6sONZwaUp9y06ymw53yXurVIY93TbENujfzkrBm Ynr1iK7mYsbrpO3Sghe3+23ir0tZtC3o1kznjUm/ZWq6nYv9bKdG7rW9Kmxfm5tldwqH1zvfCPhi 84NFmbtTwubvKVvfcD5jQ7BhdLu7Cd4rhjrf6L/PP/9nMLa9beXYAs4lTzLl3/4nXdKq0SUpBjDR rDOGMSFMUE1Ajf9E3485o0GvD5dJifs5E/fDKP7CA4WH/pEHxrzvgVjLlaXaX9IyID3w17ITFczR N3vdqvbPBl/vr6099tT657f1PQ5F5zB23zwzeJyfc2XwEtph68iOB9Jrx90c6zJuTeDcPIdOr07u WZjKO7W410DB1DFrNU880j38Ix4rp6t8X+w76Tz/npXhUH7JhTuLcioP62f9Odkw3G/DyoUjFmx9 MTN4WI+IIo8uqb883Cmms+pKahZUyJRvLH6Y8rBon8XiC/V2vQOqpVEHhlNbRkw8sOLrqb5hpWdi i7+aox9Uv/dGdyeR36nrZ8/HRHyS4pRkM2S4/7HVuQ+qftDeaXvzqXj0pTMjVxYPUx5e0rMzE+uz dcVm95yk0Asz1oeYjfjZdfugEf/6bLWmIWnyF0wF3x6FgJdsCLABh8HUpKRJdmfaPpfdvZpiKjE+ igBao29bOvi212jLdPhwmw6SBdOShIS4947yIiTejCc72KnZQz6JD9OCVZNr0/0MjcZApxYZ8jU6 paEMh4eEOEYiYZg4LjxEMZKoaAnX/C+g6G+Xcmr/Ye2NxMdpHkHLFpRmM3+sWDe95eA/G+Z3X7m7 4bMVdNuRvVYsXjFzSFTBmXbysvsbi09k/fL4zpKJnjOXjc/d/k3B8By/Oq+kKzZwzq2qowfDc6ur 8wMWnW4ddtBqZ7+Aw51uitrGV4WtC0pYe/eTce1+G2+zr1rVW7qxYuTyIeEl3W8v2iFPrE73lJj7 Oy5bd3N2qOuNNgtljkP6CRTLvOIyKl+seTCPOuZx7mDvjtsnjz3Y+m7WvLRNb9YMLzSkbXY9VWUR 5AP6zhqijNvXzd4sqc/bga9W5YrMPz9b3qfvg12J2c7lJfxfnh/YNHZ+w5baMXVr3HWDkk5+9dB8 pS+zXTjhxHa6xGHCVS5urGXKVzPlK7BfQn55NVO+YKztwNPaB0rdUr9eox239Zjx9rvluv/3+qv4 GxsnUWH+LctD058scI29twf6/1xi92TQkKhlSy2/ayuYPWnmidY3fB4/7Ds3bGdN5+M5D17/dCox ccC6VlnKBv/C5BOn1l8RjLwsmd5mma126L4G+56uykOvT7f/zW4A3fOPnBGb17sdD41rGX5Asdx+ Sksb2coXWZ71PifqnJ5kbFS3jzJ7U+Hy5+95KnGv5/sfZXy7/+ZR5jUtsZjkNT/YvcePXtTqR2N/ 5e0Y+HTr5eN97ys++TYja9cOXpD921l1D81njt6z4JsNcWHXh19fW/JbcQ04PTT58NlWU35NtV8b O9Rj6MXYa+c9+dfXduQfHxAdr+7hKc7ZLVox7dyPWcmdaj17f669aN+6cm7RsjVna1BU+A4lB9u5 xGCo5aKeh4DVBruffR+MUpWN/v8iLDBRTGxUNErtuCRewiRExXJNpvzzd9MGB8aO3XKI+kr1+Sgd MKB5bMkygjYcZhkKeaFGLTdSJvoYZR9jMwpN+gGbfowPy4a76R25giQgOCNJJxsD+sNoIsbRxJxE k69P0dO/uvq2bfr94UfO+7d8Xvy9z9vakD5pJ5fsrtgWWxYOjq41/1F2Yvfq57cPH67bOq1qhdlL m10VGdV3Ko7tt/1m7aH7BeNnZHrsS38ph5MPO5+vyAcppR2e2cenvZL1+vVlm72/x229KjPzSxyW EtP5acGmTs8C9d6+37Vz8+61K6P63MrTDsfckocJCx/P9+kwuN29QycWyek9h2Ner+hwY8Q2r8g9 n195uvzqYh+bhn6S1N7xozf3u3n9bv+ylhtehETaJceXtm03Zk3+9dG++S43us45Wtoho/PynuMn z118KG/EHxavJvJGPV80LCl0Te7CU1fD/xVKudvEdFE8S7Lf/KjS0ysgQ3MK2R9vZQUMQfIIaC4X 5/33CDH2QgtuE+6EHIbi8QCPbFO9rPnOfMeWf4Z2+/S4LuuL35/XhLg4vzpcn1nOuDU+4kjxrbxF IBMUoS17e5DKWJLkh+w9OjE2jUmWgOGhS3PhbJm8q+GaMnDAn8LMwAXfep8p15/5/svyp+5/zF1Q ufnSzNbUzqm2B89FGAwwcUeKw/1eg5O+jlrcs+52/5NBoErndGdY5MKFh3jXYtvdNo/MkSx6LXly qd2mSz1nnoq/ok2NHyJOoueEui4xa+gzd93ZbpP2L+rqS03QdLg7+4bbldA9TtsWa19+cydtXFjr YTVR/R7HZlycPSnlgcbjZnC7HdraUSqN+/GLS16eyZ7y4mxYNRh84emR7ctGnE9syDSE5HmVB64o upWy0Mx1qitt2Ul39cGLu60K7xecyM302h+7/vfvvIbqHDqO9b7waWXuFM+wz09+J+XxrlicgFv7 H9ry5kbugu9eWiSOZCoEnVBIi2DDmUgq+oMhR7fZH5xU/HcJGzj+xUqiJCgCxsTFkl1THNpGoWYs bjLlk/4tjCCCWdqCm//UNugTNfkIW0X31ivonmpVWfDf5ktfr3E+a3k+OWfW/f5ZkfMtNU/PKw+o ph10/SHzVe2Jc/nXc3YPNljybqw/fKdt4N2zC2ctlvZpYO6vO6fqnvvzoJblM9bXFfrB4PlTVuyZ lHylV7r/PPnNr44vBTcjByzu99pl4k0ZvaUs/NZW28G67rd+cJ/ZfZX5VfmQ+MVpsm7XYzrMi4rd Y2Omu6YesXrPudrtDYO+iOp1LXdLTY/dlioebZ9/KMzxz5nlJ6dHfAW/FMKKYJc1PifHzfi2h5y+ sHqcvuqVIas43WX39rtdAqfsaJm25fd9J7opVqQkXLlcP7nlrwFLFmas3G+IaaO3Yezy6G/bVy5K 9t0qCy1XWP9WKEiJ/v3Ilbb5iWy+VAFnIYlM+2Bj0xQlNo/wyh9/79v6iBYTS+e3C9756BvnuR8J ietwrx+/fDlTvnRss+FluWHVf0Vg/DCT6MruCtszqUxyTZuaxIkJJrvCdz8x1hYocW8k9zm7PhJ7 BXaKdO6sJs1kl9qOSWHaNu5SqYlRH/0gmqBV6D7AZ2huuwiTUmd+HxDf706N7Fz+zQ3n+moffPJA 0LvS6evKE3v6SlP6PNzzguHlDr8zdeqGUteB5++vaXf40LQ3X/x0ekb9pEqLIdtEo4uVF8qO8mXP 5mYt/VXu+mTapG6qmeoTv5onrp+UPkV0+MmNHY+fPkv6WbLbYuuDAft7aoem/LZ7VO0f/mEnhwRe q9m2I2h9lv/WpfOeJXyWFy3t2XWkrvaAy5SMF9mPfvpXW+npOPOkIYUTz+6TXb51vPc2On6fvee4 6vJWWaFnLt7+1f7Nd2kdz79sNbTeEFsXUCK+vu208MgLg9XqHXWb/iiVzmxnO7hIndN29eFLadLS Lnvr+n6fdbf2wOoNHTdb+9IrNo6IvCap4B9EkXQfBSFTvvO/Tbx8J+Y3nXDXlF9iHBvX2SAoMeMJ yCC8+nKqt+BJrEwP1RHpTS1LiTVjeteJ8Wt6kC9BXhvmtbVjUXbnT1y9H/A35Bs0tstqHjO5Jo9Y SfoxfWrCxob88z85XR4w1v8f/F3F+4klvwKCuPhOcHHxNtv9R/4c45M2dU/wgqJu/EtP59ZJFiR+ /vXp8BtPanLPS87vrG/X0TvNt/ulw9M6He+cHvfCxurmN3zL4ZdUOX1Sf5tQQCvjewtXd7kivLD8 UXa7H8bbj49qzSw9HqjKPm61fEty6r0f+k+5lz2gYHGAXjI36F87D5z4+hRvU4W415CEezOW37l8 ukLyMOhlxuIbIScfrh76y7jE7fyjWf2H9qrc9/2R8lvdfV71W+XR680qZmbWpA1Du/Q7mbtZJ564 UTXkwatTMtfzLfr9svBopaKfx9CW23fNVd3a8+mcTas6fzfHoUvb1VPvyi6PeFUQundH1cpet7yW FLZVdXXuf3pzQcvqZ/WCt8srUIZUAV81aUkoqYB3UdctbNJ5/5YzzmZOVq2E5iwBFIosNf0ZV1N7 s2z6pAcic2u8I5DYcMt+giQhKi4mYQCKuCbmZs+3DcqxyLl5yyP7bcq5S7rPXKY0YwKDyz2+OrNW Oivac/HOSK/q1Q+WrLo36Mbcb7OLh7Vx6f/64UX1+hVuPfcfGvvTI4viz04kPmuVUx9ccOSRh/a0 YcPKvSlC3csLFfqHjoAeMixY19UTBFGT5+++v+FgtVOL0Ljzgy9Mn3O/9rOBIdeOXDkyPFpgt3ff 63aX6t7ObD0sKHueY+/np65tnpZcNqh/re2YSb9f3b3xksdDZuSA6x5jxlGlo8Cp8cLAZ19+OcfW cl+HXX4+sxOeXdt/PQ7OGTYionurLkV08JuWG33i96fs/xLUJeufb+GDhGJlxeXs3dEv2xw7MizJ N7XD9Mhx1xc/EhaXmcvWeCdo3Kzibp78FfJuD7cN3PdiehX4Pytf3mENCmVuZHN0cmVhbQ0KZW5k b2JqDQo1MjMgMCBvYmoNClsgM1sgNTUwXSAgN1sgNTUwIDU1MF0gIDEyWyA1NTBdICAxOVsgNTUw XSAgMjFbIDU1MCA1NTAgNTUwXSAgMjZbIDU1MF0gIDEzMVsgNTUwIDU1MCA1NTAgNTUwIDU1MCA1 NTAgNTUwIDU1MCA1NTBdICAxNDJbIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUwIDU1MCA1NTAgNTUw IDU1MF0gIDE1M1sgNTUwIDU1MCA1NTBdICAzNTJbIDU1MF0gIDM1OVsgNTUwIDU1MCA1NTAgNTUw XSAgMzc1WyA1NTBdICAzODRbIDU1MF0gXSANCmVuZG9iag0KNTI0IDAgb2JqDQpbIDYxMSAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAzODkgMzg5IDAgMCA0NDRdIA0KZW5kb2JqDQo1MjUgMCBvYmoNCjw8L1R5cGUvWFJlZi9T aXplIDUyNS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyA1MCAwIFIvSURbPEZEOERCRjhFMTUx MTJCNDRCOERBOEMxQTdBMjlFOERGPjxGRDhEQkY4RTE1MTEyQjQ0QjhEQThDMUE3QTI5RThERj5d IC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExMDM+Pg0Kc3RyZWFtDQp4nDXXd9iVcxzH8fN5 nsgmKyOlkpKZmZFV0hQpq0QyIiMrlL2TGaLsXQpZoSTZZUtk7xmyQkZ5/F7H+eO8rt917utc97nP uX/v861U6h6LFqXuuUGl8h+nYU6hpn6h0bjCWn0LjXvgn0KTuYW1RxSatsYnhWZoPgjDC+tsjFMK LYYW1t0C7xVaDim0chLtRxY6tC/s0haLCh0XFHYdU+g0rNC5ZaFLQ8wodJ1a6OZduvUvdK9F98Ju 7Qo96mFhYfdJhT0mFnrOLBz9fuGY+YXhAwoXDSzceEXhpmsK45vWXcW669k20/Aknij8/9r0uiMn 9KmuKvujHmoQ1GIJLI7FUB/LYCksiaWxGpbDslgBy2NFNMDKWAmrYhU0RCusgdXRCGuiMdbC2miC ddECzdEUzbAOWmJztMZ62ADrYyNsiE2wMTZFG2yGDtgSW6AttsI22BrbYVvsjJ2wA9phe+yI9tgd HbELOmFXdEFndENX7Ibu6IG+6Ik90At7Yi/0xj7YG/thX/RBPxyEA3Ag+uMkDMDBOASH4jAMxBAc jiNxBAbhKAzG0TgGx+IEHIfjcSJOdlc9ZXUKhmIYTsVpGI6zcCZOxxk4D+fibJyDC3EBzsdVuBIj cBEuwcW4DJfiClyOkbgao3AzxmA0rsG1uAnX4zrciBtwCx7BBNyGW3EHbsdduBN3YyzGYTwm4V7c g4m4Dw/gfjyEB/EwHsOjmIzql1rdP6diCh7HdNhpK/bdytN4A6/jWTyD5/EcZuAFvIqZeBEv4WW8 gtcwC29iNt7C236f1VOaY1XdOD/Fu3gH7+M9fIgP8DE+wif4EZ/jM3yJL/A1vsIP+AbfYi6+w/eY hz/xM37Cr/gFv2E+/sDvWOBDVxv3N/7CQvzjkGoUF1mpYdQwahg5ixpGDSOREcWoYdQwEhlRjAxG G6OGUcOoYdQwahg1jBpGDaOGkcEIX2QwwhcZjDBEN6OGUcMoXvQvwhdRjFJGKaOGkbOoYdQwahg1 jBpGDaOGUcPIYOQs0hpRjBpGDaOGUcOoYdQwMhipi/5F8SKKkchIVuQsshtRjBpGDaOGUcOoYdQw MhhbegQsMhhtjHs6Mhi9jQxGIiODkchoY1QtMhiJjBpGIuP/WfQ2ohiljDZGqyJ8kc9IZCQyEhmJ jBpGIiODEcWoYZQyahhVixpGKSODEcWoYZQyOh31TTWRahg1jBpG+CJ8UcNoY4Qvwhc1jDZG+CKD EcVIa4QvMhjhiwzGLhz9ixpG/6KGkcGIaaQ1ohhRjP5F/yKKkcjoX9Qw+hc1jFJGUyOK0b+oYfQv ahj9ixpG/6J/EcXIYDQ1+hc1jP5FDaN/0ZyIYmQwohg1jKZGriOKkchoY2QwMpipdUPF0+eWKeSZ aYXn2qCMO5k1qjC7DFQ1ezYp9CqzU03vMgbWTK4yujBl3n/UNvkUZT6q7VuGtNp+gwtjy0RUO+6P SuVfnixygA0KZW5kc3RyZWFtDQplbmRvYmoNCnhyZWYNCjAgNTI2DQowMDAwMDAwMDUxIDY1NTM1 IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMjE2IDAw MDAwIG4NCjAwMDAwMDA1MTkgMDAwMDAgbg0KMDAwMDAwNzMzNyAwMDAwMCBuDQowMDAwMDA3NTE2 IDAwMDAwIG4NCjAwMDAwMDc3NTkgMDAwMDAgbg0KMDAwMDAwNzkzMyAwMDAwMCBuDQowMDAwMDA4 MTcxIDAwMDAwIG4NCjAwMDAwMDgzMzEgMDAwMDAgbg0KMDAwMDAwODQ5MCAwMDAwMCBuDQowMDAw MDA4NjczIDAwMDAwIG4NCjAwMDAwMDg5MjkgMDAwMDAgbg0KMDAwMDAwOTA2NyAwMDAwMCBuDQow MDAwMDA5MDk3IDAwMDAwIG4NCjAwMDAwMDkyNjMgMDAwMDAgbg0KMDAwMDAwOTMzNyAwMDAwMCBu DQowMDAwMDA5NTk0IDAwMDAwIG4NCjAwMDAwMDk3ODEgMDAwMDAgbg0KMDAwMDAwOTk0NyAwMDAw MCBuDQowMDAwMDEwMTAyIDAwMDAwIG4NCjAwMDAwMTA0NTYgMDAwMDAgbg0KMDAwMDAxNzI5OCAw MDAwMCBuDQowMDAwMDE3NDc1IDAwMDAwIG4NCjAwMDAwMTc3MjAgMDAwMDAgbg0KMDAwMDAxNzkx OSAwMDAwMCBuDQowMDAwMDE4MTY5IDAwMDAwIG4NCjAwMDAwMTgzMzAgMDAwMDAgbg0KMDAwMDAx ODU1NSAwMDAwMCBuDQowMDAwMDE4NzI3IDAwMDAwIG4NCjAwMDAwMTg5NjcgMDAwMDAgbg0KMDAw MDAxOTE0NSAwMDAwMCBuDQowMDAwMDE5Mzg5IDAwMDAwIG4NCjAwMDAwMTk1MjMgMDAwMDAgbg0K MDAwMDAxOTU1MyAwMDAwMCBuDQowMDAwMDE5NzE1IDAwMDAwIG4NCjAwMDAwMTk3ODkgMDAwMDAg bg0KMDAwMDAyMDAyOSAwMDAwMCBuDQowMDAwMDIwMjI4IDAwMDAwIG4NCjAwMDAwMjA0NzggMDAw MDAgbg0KMDAwMDAyMDY2MiAwMDAwMCBuDQowMDAwMDIwOTEyIDAwMDAwIG4NCjAwMDAwMjExOTQg MDAwMDAgbg0KMDAwMDAyODM4MCAwMDAwMCBuDQowMDAwMDI4NjYxIDAwMDAwIG4NCjAwMDAwMzUx NzEgMDAwMDAgbg0KMDAwMDAzNTQzMiAwMDAwMCBuDQowMDAwMDQwNTkzIDAwMDAwIG4NCjAwMDAw NDA4NTUgMDAwMDAgbg0KMDAwMDA0MzgwOSAwMDAwMCBuDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAw MDAwMDAwNTMgNjU1MzUgZg0KMDAwMDAwMDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYN CjAwMDAwMDAwNTYgNjU1MzUgZg0KMDAwMDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1 IGYNCjAwMDAwMDAwNTkgNjU1MzUgZg0KMDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1 NTM1IGYNCjAwMDAwMDAwNjIgNjU1MzUgZg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0 IDY1NTM1IGYNCjAwMDAwMDAwNjUgNjU1MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAw MDY3IDY1NTM1IGYNCjAwMDAwMDAwNjggNjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAw MDAwMDcwIDY1NTM1IGYNCjAwMDAwMDAwNzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQow MDAwMDAwMDczIDY1NTM1IGYNCjAwMDAwMDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBm DQowMDAwMDAwMDc2IDY1NTM1IGYNCjAwMDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUz NSBmDQowMDAwMDAwMDc5IDY1NTM1IGYNCjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2 NTUzNSBmDQowMDAwMDAwMDgyIDY1NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4 NCA2NTUzNSBmDQowMDAwMDAwMDg1IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAw MDA4NyA2NTUzNSBmDQowMDAwMDAwMDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAw MDAwMDA5MCA2NTUzNSBmDQowMDAwMDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0K MDAwMDAwMDA5MyA2NTUzNSBmDQowMDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUg Zg0KMDAwMDAwMDA5NiA2NTUzNSBmDQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1 MzUgZg0KMDAwMDAwMDA5OSA2NTUzNSBmDQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEg NjU1MzUgZg0KMDAwMDAwMDEwMiA2NTUzNSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAx MDQgNjU1MzUgZg0KMDAwMDAwMDEwNSA2NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAw MDAxMDcgNjU1MzUgZg0KMDAwMDAwMDEwOCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAw MDAwMDAxMTAgNjU1MzUgZg0KMDAwMDAwMDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYN CjAwMDAwMDAxMTMgNjU1MzUgZg0KMDAwMDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1 IGYNCjAwMDAwMDAxMTYgNjU1MzUgZg0KMDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1 NTM1IGYNCjAwMDAwMDAxMTkgNjU1MzUgZg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIx IDY1NTM1IGYNCjAwMDAwMDAxMjIgNjU1MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAw MTI0IDY1NTM1IGYNCjAwMDAwMDAxMjUgNjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAw MDAwMTI3IDY1NTM1IGYNCjAwMDAwMDAxMjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQow MDAwMDAwMTMwIDY1NTM1IGYNCjAwMDAwMDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBm DQowMDAwMDAwMTMzIDY1NTM1IGYNCjAwMDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUz NSBmDQowMDAwMDAwMTM2IDY1NTM1IGYNCjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2 NTUzNSBmDQowMDAwMDAwMTM5IDY1NTM1IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0 MSA2NTUzNSBmDQowMDAwMDAwMTQyIDY1NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAw MDE0NCA2NTUzNSBmDQowMDAwMDAwMTQ1IDY1NTM1IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAw MDAwMDE0NyA2NTUzNSBmDQowMDAwMDAwMTQ4IDY1NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0K MDAwMDAwMDE1MCA2NTUzNSBmDQowMDAwMDAwMTUxIDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUg Zg0KMDAwMDAwMDE1MyA2NTUzNSBmDQowMDAwMDAwMTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUgNjU1 MzUgZg0KMDAwMDAwMDE1NiA2NTUzNSBmDQowMDAwMDAwMTU3IDY1NTM1IGYNCjAwMDAwMDAxNTgg NjU1MzUgZg0KMDAwMDAwMDE1OSA2NTUzNSBmDQowMDAwMDAwMTYwIDY1NTM1IGYNCjAwMDAwMDAx NjEgNjU1MzUgZg0KMDAwMDAwMDE2MiA2NTUzNSBmDQowMDAwMDAwMTYzIDY1NTM1IGYNCjAwMDAw MDAxNjQgNjU1MzUgZg0KMDAwMDAwMDE2NSA2NTUzNSBmDQowMDAwMDAwMTY2IDY1NTM1IGYNCjAw MDAwMDAxNjcgNjU1MzUgZg0KMDAwMDAwMDE2OCA2NTUzNSBmDQowMDAwMDAwMTY5IDY1NTM1IGYN CjAwMDAwMDAxNzAgNjU1MzUgZg0KMDAwMDAwMDE3MSA2NTUzNSBmDQowMDAwMDAwMTcyIDY1NTM1 IGYNCjAwMDAwMDAxNzMgNjU1MzUgZg0KMDAwMDAwMDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1 NTM1IGYNCjAwMDAwMDAxNzYgNjU1MzUgZg0KMDAwMDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4 IDY1NTM1IGYNCjAwMDAwMDAxNzkgNjU1MzUgZg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAw MTgxIDY1NTM1IGYNCjAwMDAwMDAxODIgNjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAw MDAwMTg0IDY1NTM1IGYNCjAwMDAwMDAxODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQow MDAwMDAwMTg3IDY1NTM1IGYNCjAwMDAwMDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBm DQowMDAwMDAwMTkwIDY1NTM1IGYNCjAwMDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUz NSBmDQowMDAwMDAwMTkzIDY1NTM1IGYNCjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2 NTUzNSBmDQowMDAwMDAwMTk2IDY1NTM1IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5 OCA2NTUzNSBmDQowMDAwMDAwMTk5IDY1NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAw MDIwMSA2NTUzNSBmDQowMDAwMDAwMjAyIDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAw MDAwMDIwNCA2NTUzNSBmDQowMDAwMDAwMjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0K MDAwMDAwMDIwNyA2NTUzNSBmDQowMDAwMDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkgNjU1MzUg Zg0KMDAwMDAwMDIxMCA2NTUzNSBmDQowMDAwMDAwMjExIDY1NTM1IGYNCjAwMDAwMDAyMTIgNjU1 MzUgZg0KMDAwMDAwMDIxMyA2NTUzNSBmDQowMDAwMDAwMjE0IDY1NTM1IGYNCjAwMDAwMDAyMTUg NjU1MzUgZg0KMDAwMDAwMDIxNiA2NTUzNSBmDQowMDAwMDAwMjE3IDY1NTM1IGYNCjAwMDAwMDAy MTggNjU1MzUgZg0KMDAwMDAwMDIxOSA2NTUzNSBmDQowMDAwMDAwMjIwIDY1NTM1IGYNCjAwMDAw MDAyMjEgNjU1MzUgZg0KMDAwMDAwMDIyMiA2NTUzNSBmDQowMDAwMDAwMjIzIDY1NTM1IGYNCjAw MDAwMDAyMjQgNjU1MzUgZg0KMDAwMDAwMDIyNSA2NTUzNSBmDQowMDAwMDAwMjI2IDY1NTM1IGYN CjAwMDAwMDAyMjcgNjU1MzUgZg0KMDAwMDAwMDIyOCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1 IGYNCjAwMDAwMDAyMzAgNjU1MzUgZg0KMDAwMDAwMDIzMSA2NTUzNSBmDQowMDAwMDAwMjMyIDY1 NTM1IGYNCjAwMDAwMDAyMzMgNjU1MzUgZg0KMDAwMDAwMDIzNCA2NTUzNSBmDQowMDAwMDAwMjM1 IDY1NTM1IGYNCjAwMDAwMDAyMzYgNjU1MzUgZg0KMDAwMDAwMDIzNyA2NTUzNSBmDQowMDAwMDAw MjM4IDY1NTM1IGYNCjAwMDAwMDAyMzkgNjU1MzUgZg0KMDAwMDAwMDI0MCA2NTUzNSBmDQowMDAw MDAwMjQxIDY1NTM1IGYNCjAwMDAwMDAyNDIgNjU1MzUgZg0KMDAwMDAwMDI0MyA2NTUzNSBmDQow MDAwMDAwMjQ0IDY1NTM1IGYNCjAwMDAwMDAyNDUgNjU1MzUgZg0KMDAwMDAwMDI0NiA2NTUzNSBm DQowMDAwMDAwMjQ3IDY1NTM1IGYNCjAwMDAwMDAyNDggNjU1MzUgZg0KMDAwMDAwMDI0OSA2NTUz NSBmDQowMDAwMDAwMjUwIDY1NTM1IGYNCjAwMDAwMDAyNTEgNjU1MzUgZg0KMDAwMDAwMDI1MiA2 NTUzNSBmDQowMDAwMDAwMjUzIDY1NTM1IGYNCjAwMDAwMDAyNTQgNjU1MzUgZg0KMDAwMDAwMDI1 NSA2NTUzNSBmDQowMDAwMDAwMjU2IDY1NTM1IGYNCjAwMDAwMDAyNTcgNjU1MzUgZg0KMDAwMDAw MDI1OCA2NTUzNSBmDQowMDAwMDAwMjU5IDY1NTM1IGYNCjAwMDAwMDAyNjAgNjU1MzUgZg0KMDAw MDAwMDI2MSA2NTUzNSBmDQowMDAwMDAwMjYyIDY1NTM1IGYNCjAwMDAwMDAyNjMgNjU1MzUgZg0K MDAwMDAwMDI2NCA2NTUzNSBmDQowMDAwMDAwMjY1IDY1NTM1IGYNCjAwMDAwMDAyNjYgNjU1MzUg Zg0KMDAwMDAwMDI2NyA2NTUzNSBmDQowMDAwMDAwMjY4IDY1NTM1IGYNCjAwMDAwMDAyNjkgNjU1 MzUgZg0KMDAwMDAwMDI3MCA2NTUzNSBmDQowMDAwMDAwMjcxIDY1NTM1IGYNCjAwMDAwMDAyNzIg NjU1MzUgZg0KMDAwMDAwMDI3MyA2NTUzNSBmDQowMDAwMDAwMjc0IDY1NTM1IGYNCjAwMDAwMDAy NzUgNjU1MzUgZg0KMDAwMDAwMDI3NiA2NTUzNSBmDQowMDAwMDAwMjc3IDY1NTM1IGYNCjAwMDAw MDAyNzggNjU1MzUgZg0KMDAwMDAwMDI3OSA2NTUzNSBmDQowMDAwMDAwMjgwIDY1NTM1IGYNCjAw MDAwMDAyODEgNjU1MzUgZg0KMDAwMDAwMDI4MiA2NTUzNSBmDQowMDAwMDAwMjgzIDY1NTM1IGYN CjAwMDAwMDAyODQgNjU1MzUgZg0KMDAwMDAwMDI4NSA2NTUzNSBmDQowMDAwMDAwMjg2IDY1NTM1 IGYNCjAwMDAwMDAyODcgNjU1MzUgZg0KMDAwMDAwMDI4OCA2NTUzNSBmDQowMDAwMDAwMjg5IDY1 NTM1IGYNCjAwMDAwMDAyOTAgNjU1MzUgZg0KMDAwMDAwMDI5MSA2NTUzNSBmDQowMDAwMDAwMjky IDY1NTM1IGYNCjAwMDAwMDAyOTMgNjU1MzUgZg0KMDAwMDAwMDI5NCA2NTUzNSBmDQowMDAwMDAw Mjk1IDY1NTM1IGYNCjAwMDAwMDAyOTYgNjU1MzUgZg0KMDAwMDAwMDI5NyA2NTUzNSBmDQowMDAw MDAwMjk4IDY1NTM1IGYNCjAwMDAwMDAyOTkgNjU1MzUgZg0KMDAwMDAwMDMwMCA2NTUzNSBmDQow MDAwMDAwMzAxIDY1NTM1IGYNCjAwMDAwMDAzMDIgNjU1MzUgZg0KMDAwMDAwMDMwMyA2NTUzNSBm DQowMDAwMDAwMzA0IDY1NTM1IGYNCjAwMDAwMDAzMDUgNjU1MzUgZg0KMDAwMDAwMDMwNiA2NTUz NSBmDQowMDAwMDAwMzA3IDY1NTM1IGYNCjAwMDAwMDAzMDggNjU1MzUgZg0KMDAwMDAwMDMwOSA2 NTUzNSBmDQowMDAwMDAwMzEwIDY1NTM1IGYNCjAwMDAwMDAzMTEgNjU1MzUgZg0KMDAwMDAwMDMx MiA2NTUzNSBmDQowMDAwMDAwMzEzIDY1NTM1IGYNCjAwMDAwMDAzMTQgNjU1MzUgZg0KMDAwMDAw MDMxNSA2NTUzNSBmDQowMDAwMDAwMzE2IDY1NTM1IGYNCjAwMDAwMDAzMTcgNjU1MzUgZg0KMDAw MDAwMDMxOCA2NTUzNSBmDQowMDAwMDAwMzE5IDY1NTM1IGYNCjAwMDAwMDAzMjAgNjU1MzUgZg0K MDAwMDAwMDMyMSA2NTUzNSBmDQowMDAwMDAwMzIyIDY1NTM1IGYNCjAwMDAwMDAzMjMgNjU1MzUg Zg0KMDAwMDAwMDMyNCA2NTUzNSBmDQowMDAwMDAwMzI1IDY1NTM1IGYNCjAwMDAwMDAzMjYgNjU1 MzUgZg0KMDAwMDAwMDMyNyA2NTUzNSBmDQowMDAwMDAwMzI4IDY1NTM1IGYNCjAwMDAwMDAzMjkg NjU1MzUgZg0KMDAwMDAwMDMzMCA2NTUzNSBmDQowMDAwMDAwMzMxIDY1NTM1IGYNCjAwMDAwMDAz MzIgNjU1MzUgZg0KMDAwMDAwMDMzMyA2NTUzNSBmDQowMDAwMDAwMzM0IDY1NTM1IGYNCjAwMDAw MDAzMzUgNjU1MzUgZg0KMDAwMDAwMDMzNiA2NTUzNSBmDQowMDAwMDAwMzM3IDY1NTM1IGYNCjAw MDAwMDAzMzggNjU1MzUgZg0KMDAwMDAwMDMzOSA2NTUzNSBmDQowMDAwMDAwMzQwIDY1NTM1IGYN CjAwMDAwMDAzNDEgNjU1MzUgZg0KMDAwMDAwMDM0MiA2NTUzNSBmDQowMDAwMDAwMzQzIDY1NTM1 IGYNCjAwMDAwMDAzNDQgNjU1MzUgZg0KMDAwMDAwMDM0NSA2NTUzNSBmDQowMDAwMDAwMzQ2IDY1 NTM1IGYNCjAwMDAwMDAzNDcgNjU1MzUgZg0KMDAwMDAwMDM0OCA2NTUzNSBmDQowMDAwMDAwMzQ5 IDY1NTM1IGYNCjAwMDAwMDAzNTAgNjU1MzUgZg0KMDAwMDAwMDM1MSA2NTUzNSBmDQowMDAwMDAw MzUyIDY1NTM1IGYNCjAwMDAwMDAzNTMgNjU1MzUgZg0KMDAwMDAwMDM1NCA2NTUzNSBmDQowMDAw MDAwMzU1IDY1NTM1IGYNCjAwMDAwMDAzNTYgNjU1MzUgZg0KMDAwMDAwMDM1NyA2NTUzNSBmDQow MDAwMDAwMzU4IDY1NTM1IGYNCjAwMDAwMDAzNTkgNjU1MzUgZg0KMDAwMDAwMDM2MCA2NTUzNSBm DQowMDAwMDAwMzYxIDY1NTM1IGYNCjAwMDAwMDAzNjIgNjU1MzUgZg0KMDAwMDAwMDM2MyA2NTUz NSBmDQowMDAwMDAwMzY0IDY1NTM1IGYNCjAwMDAwMDAzNjUgNjU1MzUgZg0KMDAwMDAwMDM2NiA2 NTUzNSBmDQowMDAwMDAwMzY3IDY1NTM1IGYNCjAwMDAwMDAzNjggNjU1MzUgZg0KMDAwMDAwMDM2 OSA2NTUzNSBmDQowMDAwMDAwMzcwIDY1NTM1IGYNCjAwMDAwMDAzNzEgNjU1MzUgZg0KMDAwMDAw MDM3MiA2NTUzNSBmDQowMDAwMDAwMzczIDY1NTM1IGYNCjAwMDAwMDAzNzQgNjU1MzUgZg0KMDAw MDAwMDM3NSA2NTUzNSBmDQowMDAwMDAwMzc2IDY1NTM1IGYNCjAwMDAwMDAzNzcgNjU1MzUgZg0K MDAwMDAwMDM3OCA2NTUzNSBmDQowMDAwMDAwMzc5IDY1NTM1IGYNCjAwMDAwMDAzODAgNjU1MzUg Zg0KMDAwMDAwMDM4MSA2NTUzNSBmDQowMDAwMDAwMzgyIDY1NTM1IGYNCjAwMDAwMDAzODMgNjU1 MzUgZg0KMDAwMDAwMDM4NCA2NTUzNSBmDQowMDAwMDAwMzg1IDY1NTM1IGYNCjAwMDAwMDAzODYg NjU1MzUgZg0KMDAwMDAwMDM4NyA2NTUzNSBmDQowMDAwMDAwMzg4IDY1NTM1IGYNCjAwMDAwMDAz ODkgNjU1MzUgZg0KMDAwMDAwMDM5MCA2NTUzNSBmDQowMDAwMDAwMzkxIDY1NTM1IGYNCjAwMDAw MDAzOTIgNjU1MzUgZg0KMDAwMDAwMDM5MyA2NTUzNSBmDQowMDAwMDAwMzk0IDY1NTM1IGYNCjAw MDAwMDAzOTUgNjU1MzUgZg0KMDAwMDAwMDM5NiA2NTUzNSBmDQowMDAwMDAwMzk3IDY1NTM1IGYN CjAwMDAwMDAzOTggNjU1MzUgZg0KMDAwMDAwMDM5OSA2NTUzNSBmDQowMDAwMDAwNDAwIDY1NTM1 IGYNCjAwMDAwMDA0MDEgNjU1MzUgZg0KMDAwMDAwMDQwMiA2NTUzNSBmDQowMDAwMDAwNDAzIDY1 NTM1IGYNCjAwMDAwMDA0MDQgNjU1MzUgZg0KMDAwMDAwMDQwNSA2NTUzNSBmDQowMDAwMDAwNDA2 IDY1NTM1IGYNCjAwMDAwMDA0MDcgNjU1MzUgZg0KMDAwMDAwMDQwOCA2NTUzNSBmDQowMDAwMDAw NDA5IDY1NTM1IGYNCjAwMDAwMDA0MTAgNjU1MzUgZg0KMDAwMDAwMDQxMSA2NTUzNSBmDQowMDAw MDAwNDEyIDY1NTM1IGYNCjAwMDAwMDA0MTMgNjU1MzUgZg0KMDAwMDAwMDQxNCA2NTUzNSBmDQow MDAwMDAwNDE1IDY1NTM1IGYNCjAwMDAwMDA0MTYgNjU1MzUgZg0KMDAwMDAwMDQxNyA2NTUzNSBm DQowMDAwMDAwNDE4IDY1NTM1IGYNCjAwMDAwMDA0MTkgNjU1MzUgZg0KMDAwMDAwMDQyMCA2NTUz NSBmDQowMDAwMDAwNDIxIDY1NTM1IGYNCjAwMDAwMDA0MjIgNjU1MzUgZg0KMDAwMDAwMDQyMyA2 NTUzNSBmDQowMDAwMDAwNDI0IDY1NTM1IGYNCjAwMDAwMDA0MjUgNjU1MzUgZg0KMDAwMDAwMDQy NiA2NTUzNSBmDQowMDAwMDAwNDI3IDY1NTM1IGYNCjAwMDAwMDA0MjggNjU1MzUgZg0KMDAwMDAw MDQyOSA2NTUzNSBmDQowMDAwMDAwNDMwIDY1NTM1IGYNCjAwMDAwMDA0MzEgNjU1MzUgZg0KMDAw MDAwMDQzMiA2NTUzNSBmDQowMDAwMDAwNDMzIDY1NTM1IGYNCjAwMDAwMDA0MzQgNjU1MzUgZg0K MDAwMDAwMDQzNSA2NTUzNSBmDQowMDAwMDAwNDM2IDY1NTM1IGYNCjAwMDAwMDA0MzcgNjU1MzUg Zg0KMDAwMDAwMDQzOCA2NTUzNSBmDQowMDAwMDAwNDM5IDY1NTM1IGYNCjAwMDAwMDA0NDAgNjU1 MzUgZg0KMDAwMDAwMDQ0MSA2NTUzNSBmDQowMDAwMDAwNDQyIDY1NTM1IGYNCjAwMDAwMDA0NDMg NjU1MzUgZg0KMDAwMDAwMDQ0NCA2NTUzNSBmDQowMDAwMDAwNDQ1IDY1NTM1IGYNCjAwMDAwMDA0 NDYgNjU1MzUgZg0KMDAwMDAwMDQ0NyA2NTUzNSBmDQowMDAwMDAwNDQ4IDY1NTM1IGYNCjAwMDAw MDA0NDkgNjU1MzUgZg0KMDAwMDAwMDQ1MCA2NTUzNSBmDQowMDAwMDAwNDUxIDY1NTM1IGYNCjAw MDAwMDA0NTIgNjU1MzUgZg0KMDAwMDAwMDQ1MyA2NTUzNSBmDQowMDAwMDAwNDU0IDY1NTM1IGYN CjAwMDAwMDA0NTUgNjU1MzUgZg0KMDAwMDAwMDQ1NiA2NTUzNSBmDQowMDAwMDAwNDU3IDY1NTM1 IGYNCjAwMDAwMDA0NTggNjU1MzUgZg0KMDAwMDAwMDQ1OSA2NTUzNSBmDQowMDAwMDAwNDYwIDY1 NTM1IGYNCjAwMDAwMDA0NjEgNjU1MzUgZg0KMDAwMDAwMDQ2MiA2NTUzNSBmDQowMDAwMDAwNDYz IDY1NTM1IGYNCjAwMDAwMDA0NjQgNjU1MzUgZg0KMDAwMDAwMDQ2NSA2NTUzNSBmDQowMDAwMDAw NDY2IDY1NTM1IGYNCjAwMDAwMDA0NjcgNjU1MzUgZg0KMDAwMDAwMDQ2OCA2NTUzNSBmDQowMDAw MDAwNDY5IDY1NTM1IGYNCjAwMDAwMDA0NzAgNjU1MzUgZg0KMDAwMDAwMDQ3MSA2NTUzNSBmDQow MDAwMDAwNDcyIDY1NTM1IGYNCjAwMDAwMDA0NzMgNjU1MzUgZg0KMDAwMDAwMDQ3NCA2NTUzNSBm DQowMDAwMDAwNDc1IDY1NTM1IGYNCjAwMDAwMDA0NzYgNjU1MzUgZg0KMDAwMDAwMDQ3NyA2NTUz NSBmDQowMDAwMDAwNDc4IDY1NTM1IGYNCjAwMDAwMDA0NzkgNjU1MzUgZg0KMDAwMDAwMDQ4MCA2 NTUzNSBmDQowMDAwMDAwNDgxIDY1NTM1IGYNCjAwMDAwMDA0ODIgNjU1MzUgZg0KMDAwMDAwMDQ4 MyA2NTUzNSBmDQowMDAwMDAwNDg0IDY1NTM1IGYNCjAwMDAwMDA0ODUgNjU1MzUgZg0KMDAwMDAw MDQ4NiA2NTUzNSBmDQowMDAwMDAwNDg3IDY1NTM1IGYNCjAwMDAwMDA0ODggNjU1MzUgZg0KMDAw MDAwMDQ4OSA2NTUzNSBmDQowMDAwMDAwNDkwIDY1NTM1IGYNCjAwMDAwMDA0OTEgNjU1MzUgZg0K MDAwMDAwMDQ5MiA2NTUzNSBmDQowMDAwMDAwNDkzIDY1NTM1IGYNCjAwMDAwMDA0OTQgNjU1MzUg Zg0KMDAwMDAwMDQ5NSA2NTUzNSBmDQowMDAwMDAwNDk2IDY1NTM1IGYNCjAwMDAwMDA0OTcgNjU1 MzUgZg0KMDAwMDAwMDQ5OCA2NTUzNSBmDQowMDAwMDAwNDk5IDY1NTM1IGYNCjAwMDAwMDA1MDAg NjU1MzUgZg0KMDAwMDAwMDUwMSA2NTUzNSBmDQowMDAwMDAwNTAyIDY1NTM1IGYNCjAwMDAwMDA1 MDMgNjU1MzUgZg0KMDAwMDAwMDUwNCA2NTUzNSBmDQowMDAwMDAwNTA1IDY1NTM1IGYNCjAwMDAw MDA1MDYgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDUwMDUyIDAwMDAwIG4NCjAw MDAwNTAzNjcgMDAwMDAgbg0KMDAwMDA1MDczNyAwMDAwMCBuDQowMDAwMDUwNzY1IDAwMDAwIG4N CjAwMDAxMTk3MDIgMDAwMDAgbg0KMDAwMDEyMDEyMCAwMDAwMCBuDQowMDAwMTUyMzUxIDAwMDAw IG4NCjAwMDAxNTI2MTUgMDAwMDAgbg0KMDAwMDE1Mjk1NyAwMDAwMCBuDQowMDAwMTc4ODEzIDAw MDAwIG4NCjAwMDAxNzg4NDEgMDAwMDAgbg0KMDAwMDE3OTE4MyAwMDAwMCBuDQowMDAwMjA0Nzcw IDAwMDAwIG4NCjAwMDAyMDQ3OTggMDAwMDAgbg0KMDAwMDIyMDM3NiAwMDAwMCBuDQowMDAwMjIw Nzg0IDAwMDAwIG4NCjAwMDAyMzk4NjEgMDAwMDAgbg0KMDAwMDI0MDEyMCAwMDAwMCBuDQowMDAw MjQwMjMwIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNTI2L1Jvb3QgMSAwIFIvSW5mbyA1MCAw IFIvSURbPEZEOERCRjhFMTUxMTJCNDRCOERBOEMxQTdBMjlFOERGPjxGRDhEQkY4RTE1MTEyQjQ0 QjhEQThDMUE3QTI5RThERj5dID4+DQpzdGFydHhyZWYNCjI0MTUzNw0KJSVFT0YNCnhyZWYNCjAg MA0KdHJhaWxlcg0KPDwvU2l6ZSA1MjYvUm9vdCAxIDAgUi9JbmZvIDUwIDAgUi9JRFs8RkQ4REJG OEUxNTExMkI0NEI4REE4QzFBN0EyOUU4REY+PEZEOERCRjhFMTUxMTJCNDRCOERBOEMxQTdBMjlF OERGPl0gL1ByZXYgMjQxNTM3L1hSZWZTdG0gMjQwMjMwPj4NCnN0YXJ0eHJlZg0KMjUyMjE3DQol JUVPRg== --_002_DA677CE046E02E42991EB3154C5E54060C0AF540BFGLDMS60322gol_-- From Peter.McCann@huawei.com Fri Oct 28 13:29:34 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 0E0A021F8487 for ; Fri, 28 Oct 2011 13:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 hRXXFe4mtPPY for ; Fri, 28 Oct 2011 13:29:33 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8521F8486 for ; Fri, 28 Oct 2011 13:29:33 -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 <0LTS00K6UM98QU@usaga02-in.huawei.com> for paws@ietf.org; Fri, 28 Oct 2011 15:29:32 -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 <0LTS00B9HM97CL@usaga02-in.huawei.com> for paws@ietf.org; Fri, 28 Oct 2011 15:29:32 -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; Fri, 28 Oct 2011 13:29:24 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 13:29:22 -0700 Date: Fri, 28 Oct 2011 20:29:22 +0000 From: Peter McCann In-reply-to: <20111028200501.64AD611E8089@ietfa.amsl.com> X-Originating-IP: [10.193.125.192] To: "Mody, Apurva (US SSA)" , "paws@ietf.org" Message-id: <5963DDF1F751474D8DEEFDCDBEE43AE716403075@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: IEEE 802.22 Feedback on PAWS Requirements Thread-index: AcyJLY8H0bjED5cjTgqFaAdMmKqbFwMd1rLQAAKp4rA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECAFF543A2FED4EA2BEB6CACE08E47612DACE@008-AM1MPN1-007.mgdnok.nokia.com> <20111028200501.64AD611E8089@ietfa.amsl.com> Subject: Re: [paws] IEEE 802.22 Feedback on 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, 28 Oct 2011 20:29:34 -0000 Hi, Apurva, Mody, Apurva (US SSA) wrote: > [NEW] O.7: The database must be capable of keeping track of the > channels that are currently being utilized by the master devices and > the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.). I thought the point of whitespace operation was to enable experimental uses, e.g., completely non-standard air interface technologies. Do you expect to enumerate the complete set of allowed technologies? I don't think it's possible and it raises all kinds of political questions. > If a request for the available channel is made by another master WSD > from the same area and it is found that the new requesting master > device technology cannot co-exist, then that channel should be removed > from the available channels list going to this new device. Unless the > given master WSD fails to re-query within the specified contact period, > the database should make that channel available. Accordingly, the > protocol should provide the master WSDs with a means to release their > operating channel when not needed. > > Note that without an active channel management mechanism (e.g., 802.22 > spectrum manager), it is unlikely that having the database just > specifying which channels are available to protect incumbent services on > a 24 hours cycle will be sufficient to allow for proper operation of > multiple WSDs in an area without interference being caused among > themselves. Without area specific centralized spectrum management that > directs and juggles master WSD channel assignments virtually > instantaneously, the result will be inefficient use of White Space > spectrum. I think the working group agreed that keeping any state in the database was out of scope for this iteration of the charter items. -Pete From apurva.mody@baesystems.com Fri Oct 28 13: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 84D1E21F84B4 for ; Fri, 28 Oct 2011 13:36:22 -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 IVZILOA4mvJp for ; Fri, 28 Oct 2011 13:36:22 -0700 (PDT) Received: from dmzms99802.na.baesystems.com (dmzms99802.na.baesystems.com [149.32.232.66]) by ietfa.amsl.com (Postfix) with ESMTP id E60DC21F84B3 for ; Fri, 28 Oct 2011 13:36:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="190976650" X-IronPort-AV: E=Sophos;i="4.69,420,1315180800"; d="scan'208";a="135640836" From: "Mody, Apurva (US SSA)" To: Peter McCann , "paws@ietf.org" Date: Fri, 28 Oct 2011 16:36:18 -0400 Thread-Topic: IEEE 802.22 Feedback on PAWS Requirements Thread-Index: AcyJLY8H0bjED5cjTgqFaAdMmKqbFwMd1rLQAAKp4rAAAEJhAA== In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716403075@dfweml503-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20111028203621.E60DC21F84B3@ietfa.amsl.com> Subject: Re: [paws] IEEE 802.22 Feedback on 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, 28 Oct 2011 20:36:22 -0000 Hello Peter,=20 In our opinion, the database service can do much more than just providing t= he list of available channels.=20 Especially now that spectrum sensing is no longer a requirement, how are we= going to ensure co-existence between disparate technologies and efficient = usage of spectrum?=20 Why can' t we create a protocol that is flexible enough so that if some dat= abase service provider does want to solve the co-existence problem, they ca= n. In our opinion, eliminating this possibility is too constraining for a t= echnology of the future.=20 Thanks Apurva Apurva N. Mody, Ph. D. Chair, IEEE 802.22 Standard Working Group BAE Systems=20 Technology Solutions 130 Daniel Webster Highway, Mail Stop 2350 Merrimack, NH 03054 Work: (603)885 2621, Mobile: (603)-809-0459=20 E-mail: apurva.mody@baesystems.com =20 -----Original Message----- From: Peter McCann [mailto:Peter.McCann@huawei.com]=20 Sent: Friday, October 28, 2011 4:29 PM To: Mody, Apurva (US SSA); paws@ietf.org Subject: RE: IEEE 802.22 Feedback on PAWS Requirements Hi, Apurva, Mody, Apurva (US SSA) wrote: > [NEW] O.7: The database must be capable of keeping track of the > channels that are currently being utilized by the master devices and > the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.). I thought the point of whitespace operation was to enable experimental uses, e.g., completely non-standard air interface technologies. Do you expect to enumerate the complete set of allowed technologies? I don't think it's possible and it raises all kinds of political questions. > If a request for the available channel is made by another master WSD > from the same area and it is found that the new requesting master > device technology cannot co-exist, then that channel should be removed > from the available channels list going to this new device. Unless the > given master WSD fails to re-query within the specified contact period, > the database should make that channel available. Accordingly, the > protocol should provide the master WSDs with a means to release their > operating channel when not needed. >=20 > Note that without an active channel management mechanism (e.g., 802.22 > spectrum manager), it is unlikely that having the database just > specifying which channels are available to protect incumbent services on > a 24 hours cycle will be sufficient to allow for proper operation of > multiple WSDs in an area without interference being caused among > themselves. Without area specific centralized spectrum management that > directs and juggles master WSD channel assignments virtually > instantaneously, the result will be inefficient use of White Space > spectrum. I think the working group agreed that keeping any state in the database was out of scope for this iteration of the charter items. -Pete From Gabor.Bajko@nokia.com Fri Oct 28 13:55: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 CF23111E808C for ; Fri, 28 Oct 2011 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 PX7PRBiGF12K for ; Fri, 28 Oct 2011 13:55:35 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id DC73A11E8082 for ; Fri, 28 Oct 2011 13:55:34 -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.4) with ESMTP id p9SKtOZI006041; Fri, 28 Oct 2011 23:55:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 23:55:21 +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; Fri, 28 Oct 2011 22:55:02 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.167]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Fri, 28 Oct 2011 22:55:01 +0200 From: To: , , Thread-Topic: IEEE 802.22 Feedback on PAWS Requirements Thread-Index: AcyJLY8Hc7p+3+DsTR20bWVYhgQVbwMd1rLQAAKp4rD//+HTAP//3BGQ Date: Fri, 28 Oct 2011 20:55:01 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4761490E3@008-AM1MPN1-006.mgdnok.nokia.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716403075@dfweml503-mbx.china.huawei.com> <20111028203621.E60DC21F84B3@ietfa.amsl.com> In-Reply-To: <20111028203621.E60DC21F84B3@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.89.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2011 20:55:21.0414 (UTC) FILETIME=[E8316E60:01CC95B3] X-Nokia-AV: Clean Subject: Re: [paws] IEEE 802.22 Feedback on 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, 28 Oct 2011 20:55:35 -0000 Since more people are bringing up this co-existence topic, I'll reserve som= e time in the Taipei session to discuss about its in_scope/out_of_scope iss= ue. -Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Mody, Apurva (US SSA) Sent: Friday, October 28, 2011 1:36 PM To: Peter McCann; paws@ietf.org Subject: Re: [paws] IEEE 802.22 Feedback on PAWS Requirements Hello Peter,=20 In our opinion, the database service can do much more than just providing t= he list of available channels.=20 Especially now that spectrum sensing is no longer a requirement, how are we= going to ensure co-existence between disparate technologies and efficient = usage of spectrum?=20 Why can' t we create a protocol that is flexible enough so that if some dat= abase service provider does want to solve the co-existence problem, they ca= n. In our opinion, eliminating this possibility is too constraining for a t= echnology of the future.=20 Thanks Apurva Apurva N. Mody, Ph. D. Chair, IEEE 802.22 Standard Working Group BAE Systems Technology Solutions 130 Daniel Webster Highway, Mail Stop 2350 Merrimack, NH 03054 Work: (603)885 2621, Mobile: (603)-809-0459 E-mail: apurva.mody@baesystems.com =20 -----Original Message----- From: Peter McCann [mailto:Peter.McCann@huawei.com] Sent: Friday, October 28, 2011 4:29 PM To: Mody, Apurva (US SSA); paws@ietf.org Subject: RE: IEEE 802.22 Feedback on PAWS Requirements Hi, Apurva, Mody, Apurva (US SSA) wrote: > [NEW] O.7: The database must be capable of keeping track of the=20 > channels that are currently being utilized by the master devices and=20 > the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.). I thought the point of whitespace operation was to enable experimental uses= , e.g., completely non-standard air interface technologies. Do you expect = to enumerate the complete set of allowed technologies? I don't think it's = possible and it raises all kinds of political questions. > If a request for the available channel is made by another master WSD=20 > from the same area and it is found that the new requesting master=20 > device technology cannot co-exist, then that channel should be removed=20 > from the available channels list going to this new device. Unless the=20 > given master WSD fails to re-query within the specified contact=20 > period, the database should make that channel available. Accordingly,=20 > the protocol should provide the master WSDs with a means to release=20 > their operating channel when not needed. >=20 > Note that without an active channel management mechanism (e.g., 802.22=20 > spectrum manager), it is unlikely that having the database just=20 > specifying which channels are available to protect incumbent services=20 > on a 24 hours cycle will be sufficient to allow for proper operation=20 > of multiple WSDs in an area without interference being caused among=20 > themselves. Without area specific centralized spectrum management that=20 > directs and juggles master WSD channel assignments virtually=20 > instantaneously, the result will be inefficient use of White Space=20 > spectrum. I think the working group agreed that keeping any state in the database was= out of scope for this iteration of the charter items. -Pete _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Fri Oct 28 17:06: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 E97E211E8087 for ; Fri, 28 Oct 2011 17:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.272, 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 fr3ifJA9oYVa for ; Fri, 28 Oct 2011 17:06:53 -0700 (PDT) Received: from na3sys009aob103.obsmtp.com (na3sys009aob103.obsmtp.com [74.125.149.70]) by ietfa.amsl.com (Postfix) with ESMTP id E372521F85F7 for ; Fri, 28 Oct 2011 17:06:52 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP; Fri, 28 Oct 2011 17:06:47 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 28 Oct 2011 17:06:36 -0700 From: Paul Lambert To: "Mody, Apurva (US SSA)" , Peter McCann , "paws@ietf.org" Date: Fri, 28 Oct 2011 17:06:35 -0700 Thread-Topic: IEEE 802.22 Feedback on PAWS Requirements Thread-Index: AcyJLY8H0bjED5cjTgqFaAdMmKqbFwMd1rLQAAKp4rAAAEJhAAAG//yg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0141EF22B78@SC-VEXCH2.marvell.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716403075@dfweml503-mbx.china.huawei.com> <20111028203621.E60DC21F84B3@ietfa.amsl.com> In-Reply-To: <20111028203621.E60DC21F84B3@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] IEEE 802.22 Feedback on 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: Sat, 29 Oct 2011 00:06:54 -0000 Hi Apurva, > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Mody, Apurva (US SSA) ... > Hello Peter, >=20 > In our opinion, the database service can do much more than just > providing the list of available channels. >=20 > Especially now that spectrum sensing is no longer a requirement, how > are we going to ensure co-existence between disparate technologies and > efficient usage of spectrum? Googling, I can see an example of your notion of a cognitive radio with sen= sing and co-existence: http://tinyurl.com/3r3ouy7 =20 However, I do not see why this should be in scope. This group will be succ= essful if it solves the more narrow problem of just getting the regulatory = allowed channels. While sending channels for coexistence looks like a similar protocol and ma= y use many of the same fields, it has a variety of other complexities that = we should avoid. Specifically: 1) The authentication range of the security is very different for a known r= egulatory authority versus a recommendation for "co-existence" that may com= e from another third party. Coexistence is typically a more local issue an= d really cannot be bundled in the same authenticated spectral entitlements.= Also - our requirement is to support unlicensed radio, which means it's r= ally difficult to securely determine who should pay attention to a specific= coexistence service. 2) It greatly complicates the database. As Peter points out - we do not wa= nt to have to support this type of stateful behavior. 3) Radio link layer protocols already handle many sensing and detection mec= hanisms necessary for this type of functionality (802.11v measurements 802.= 22 coexistance, etc). So - this group should "just say no" to the whole co-existence quagmire. I= t's not necessary for our work and only takes up the bandwidth of this grou= p. Humm - maybe we should consider it a channel of discussion that is not = available :-)=20 Paul >=20 > Why can' t we create a protocol that is flexible enough so that if some > database service provider does want to solve the co-existence problem, > they can. In our opinion, eliminating this possibility is too > constraining for a technology of the future. >=20 > Thanks >=20 > Apurva >=20 >=20 > Apurva N. Mody, Ph. D. >=20 > Chair, IEEE 802.22 Standard Working Group > BAE Systems > Technology Solutions > 130 Daniel Webster Highway, Mail Stop 2350 > Merrimack, NH 03054 > Work: (603)885 2621, Mobile: (603)-809-0459 > E-mail: apurva.mody@baesystems.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Peter McCann [mailto:Peter.McCann@huawei.com] > Sent: Friday, October 28, 2011 4:29 PM > To: Mody, Apurva (US SSA); paws@ietf.org > Subject: RE: IEEE 802.22 Feedback on PAWS Requirements >=20 > Hi, Apurva, >=20 > Mody, Apurva (US SSA) wrote: > > [NEW] O.7: The database must be capable of keeping track of the > > channels that are currently being utilized by the master devices and > > the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, > etc.). >=20 > I thought the point of whitespace operation was to enable experimental > uses, e.g., completely non-standard air interface technologies. Do you > expect to enumerate the complete set of allowed technologies? I don't > think it's possible and it raises all kinds of political questions. >=20 > > If a request for the available channel is made by another master WSD > > from the same area and it is found that the new requesting master > > device technology cannot co-exist, then that channel should be > removed > > from the available channels list going to this new device. Unless > the > > given master WSD fails to re-query within the specified contact > period, > > the database should make that channel available. Accordingly, the > > protocol should provide the master WSDs with a means to release their > > operating channel when not needed. > > > > Note that without an active channel management mechanism (e.g., > 802.22 > > spectrum manager), it is unlikely that having the database just > > specifying which channels are available to protect incumbent services > on > > a 24 hours cycle will be sufficient to allow for proper operation of > > multiple WSDs in an area without interference being caused among > > themselves. Without area specific centralized spectrum management > that > > directs and juggles master WSD channel assignments virtually > > instantaneously, the result will be inefficient use of White Space > > spectrum. >=20 > I think the working group agreed that keeping any state in the database > was out of scope for this iteration of the charter items. >=20 > -Pete > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From jmh@joelhalpern.com Fri Oct 28 22:24:03 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 58C6A21F85F7 for ; Fri, 28 Oct 2011 22:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 5TeojYz8kexQ for ; Fri, 28 Oct 2011 22:24:02 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9240921F8610 for ; Fri, 28 Oct 2011 22:24:02 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) by morbo.tigertech.net (Postfix) with ESMTP id 352D7CD04F for ; Fri, 28 Oct 2011 22:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 70AC8361FB7; Fri, 28 Oct 2011 22:24:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-191.clppva.btas.verizon.net [71.161.50.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 5D316361FB5; Fri, 28 Oct 2011 22:23:59 -0700 (PDT) Message-ID: <4EAB8DE8.5040805@joelhalpern.com> Date: Sat, 29 Oct 2011 01:23:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Mody, Apurva (US SSA)" References: <20111028203621.E60DC21F84B3@ietfa.amsl.com> In-Reply-To: <20111028203621.E60DC21F84B3@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] IEEE 802.22 Feedback on 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: Sat, 29 Oct 2011 05:24:03 -0000 There is no question that a service can provide more than just the regulatory information. The service to provide that may or may not be the same service as the one that provides the regulatory information. And more importantly, as Paul observed, we had agreed to focus on solving the small problem first. For the IETF< this has been found to be a (arguably the) path to success. So we should deliver the query / response protocol for the regulatory information, and after that is done we can entertain other ideas for what can/should/must be done. Yours, Joel On 10/28/2011 4:36 PM, Mody, Apurva (US SSA) wrote: > Hello Peter, > > In our opinion, the database service can do much more than just providing the list of available channels. > > Especially now that spectrum sensing is no longer a requirement, how are we going to ensure co-existence between disparate technologies and efficient usage of spectrum? > > Why can' t we create a protocol that is flexible enough so that if some database service provider does want to solve the co-existence problem, they can. In our opinion, eliminating this possibility is too constraining for a technology of the future. > > Thanks > > Apurva > > > Apurva N. Mody, Ph. D. > > Chair, IEEE 802.22 Standard Working Group > BAE Systems > Technology Solutions > 130 Daniel Webster Highway, Mail Stop 2350 > Merrimack, NH 03054 > Work: (603)885 2621, Mobile: (603)-809-0459 > E-mail: apurva.mody@baesystems.com > > > > > > > > > > > -----Original Message----- > From: Peter McCann [mailto:Peter.McCann@huawei.com] > Sent: Friday, October 28, 2011 4:29 PM > To: Mody, Apurva (US SSA); paws@ietf.org > Subject: RE: IEEE 802.22 Feedback on PAWS Requirements > > Hi, Apurva, > > Mody, Apurva (US SSA) wrote: >> [NEW] O.7: The database must be capable of keeping track of the >> channels that are currently being utilized by the master devices and >> the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.). > > I thought the point of whitespace operation was to enable experimental > uses, e.g., completely non-standard air interface technologies. Do you > expect to enumerate the complete set of allowed technologies? I don't > think it's possible and it raises all kinds of political questions. > >> If a request for the available channel is made by another master WSD >> from the same area and it is found that the new requesting master >> device technology cannot co-exist, then that channel should be removed >> from the available channels list going to this new device. Unless the >> given master WSD fails to re-query within the specified contact period, >> the database should make that channel available. Accordingly, the >> protocol should provide the master WSDs with a means to release their >> operating channel when not needed. >> >> Note that without an active channel management mechanism (e.g., 802.22 >> spectrum manager), it is unlikely that having the database just >> specifying which channels are available to protect incumbent services on >> a 24 hours cycle will be sufficient to allow for proper operation of >> multiple WSDs in an area without interference being caused among >> themselves. Without area specific centralized spectrum management that >> directs and juggles master WSD channel assignments virtually >> instantaneously, the result will be inefficient use of White Space >> spectrum. > > I think the working group agreed that keeping any state in the database > was out of scope for this iteration of the charter items. > > -Pete > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From andy.sago@bt.com Mon Oct 31 07:40: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 3ECC821F8C94 for ; Mon, 31 Oct 2011 07:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 UCMDR16-kJXM for ; Mon, 31 Oct 2011 07:40:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 052FF21F8C66 for ; Mon, 31 Oct 2011 07:40:42 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 14:39:40 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.68]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 31 Oct 2011 14:39:40 +0000 From: To: , Date: Mon, 31 Oct 2011 14:39:37 +0000 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyMqaywLGptZ9r7QaW3AHrkv+e5BAGcbgGAASk1WVA= Message-ID: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F714140491FE3ED@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414049E2619CEMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:40:46 -0000 --_000_619CDADDCCD2B44380834BE8BF6F71414049E2619CEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case.= .." which might mistakenly imply some preference to this solution, and note= this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don't currently anticipate a fixed IP address or url for a database= . Personally I feel a fixed address would have some drawbacks so I didn't i= nclude this method in the submission. As you are stating you require it, I'= m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too - at present we don't yet have their final list of requ= irements. Thirdly, a database operator may require this facility in order t= o offer value added services. The operators in the UK are currently unknown= (no but my company could be a prospective database operator, so I am reque= sting this facility. This is certainly within the scope of PAWS (fulfilling= the requirements of database operators is specifically mentioned in the Ch= arter, viz. "the particular data exchanged between a device and a database = might depend on the ranges of radio spectrum that are to be used, the requi= rements of the database operators and their governing regulations, and othe= r factors"). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2..." [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_619CDADDCCD2B44380834BE8BF6F71414049E2619CEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott

 

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

 

Regards

 

Andy

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>From: scott.probasco@nokia.com [mailto:scott.probasco@n= okia.com]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy= ,COD R; paws@ietf.org
Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zun= iga@InterDigital.com
Subject: Re: [paws] New indoor and M2M use c= ases, revision of DB discovery use case

 

Hi A= ndy, Mike & Juan Carlos,

 

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

 

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

 

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

 

2. In the Indoor Networking use case, I suggest to re= move step 7 which describes updating the database with the selections made = by the master device. I personally see merit in this capability. However, f= ollowing previous discussions on this mail list, and after review of our Ch= arter, I believe this step to update the database with information is not w= ithin our current scope; I am planning to remove similar steps from other u= se cases in the next update. The issue of scope is merely my personal opini= on.

 =

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

 <= /b>

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

 

[First paragraph]

"In this use case, each "machine" include= s a white space slave device and can be located anywhere, fixed or on the m= ove. Each machine needs to have connectivity to the internet and or to othe= r machines in the vicinity. Machine communication over a TVWS channel, whet= her to a master device or to another machine (slave device), is under the c= ontrol of a master device. This deployment scenario is typically characteri= zed by a master device with internet connectivity by some connection that d= oes not utilize TV white space. Figure 2…"

=

 

[Andy Sago] Agreed

 

[St= ep 6]

6. The slav= e devices fitted to the machines scan the TV bands to locate the master tra= nsmissions, and associate with the master device. Further signaling ca= n take place outside  scope of PAWS to establish direct links among th= ose slave devices that have associated with the master device.

 

[Andy Sago] Agreed

 

[Step 7]

Pr= opose to remove this step for same reasons as discussed in Indoor Networkin= g use case.

 

[Andy Sago] Disagree, for same re= asons as for the Indoor Networking use case.

<= p class=3DMsoNormal> 

= Regards,

Scott<= o:p>

 =

From: "ext andy.sago@bt.com" = <andy.sago@bt.com>
Date= : Mon, 17 Oct 2011 09:49:34 +0100
To: "paws@ietf.org" <paws@ietf.org>, Database Device <scott.probasco@nokia.com>
Cc: <michael.fitch@bt.com>, Juan Zuniga <= ;JuanCarlos.Zuniga@In= terDigital.com>
Subject: [paws] New indoor and M2M use cas= es, revision of DB discovery use case

 

Hi Scott, all

 

I-D http://www.i= etf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-00.txt propo= ses revision of the database discovery use case, two new use cases for indo= or networking and machine to machine communications, and a set of requireme= nts that drop out of all the use cases included so far in the working docum= ent. These especially address the UK Ofcom requirements as currently known.= Also, a definition is proposed for the term ‘device ID’ which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as ‘model ID’ and ‘FCC ID= ’. This Internet Draft is a joint submission from Mike Fitch (BT), An= dy Sago (BT) and Juan Carlos Zuniga (Interdigital). We would welcome commen= ts made to the reflector on these proposals. We are willing to present in T= aipei if it would be helpful in providing further explanation to the conten= t in the document.

 

Regards

 

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

<= div>

 

 

=  

 

= --_000_619CDADDCCD2B44380834BE8BF6F71414049E2619CEMV62UKRDdoma_-- From scott.probasco@nokia.com Mon Oct 31 08:38: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 0D0DF21F8DDA for ; Mon, 31 Oct 2011 08:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 6UVa8CIDVwi3 for ; Mon, 31 Oct 2011 08:38:47 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6721F8DD9 for ; Mon, 31 Oct 2011 08:38:47 -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.4) with ESMTP id p9VFc6Om006681; Mon, 31 Oct 2011 17:38:43 +0200 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); Mon, 31 Oct 2011 17:28:21 +0200 Received: from 008-AM1MMR1-008.mgdnok.nokia.com (65.54.30.24) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 16:28:20 +0100 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 16:28:19 +0100 From: To: , Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyMqaywLGptZ9r7QaW3AHrkv+e5BAGcbgGAASk1WVD//95iAA== Date: Mon, 31 Oct 2011 15:28:18 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.60.143] Content-Type: multipart/alternative; boundary="_000_CAD42348BDA1scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 15:28:21.0318 (UTC) FILETIME=[B8F19E60:01CC97E1] X-Nokia-AV: Clean Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:38:49 -0000 --_000_CAD42348BDA1scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, Thank you for your reply. As said, I do favor to keep the possibility for d= evices to update information in the database, my concern is merely to opera= te within our guidelines. You mention below that FCC and Canada require the= database to know the details of some links, are you able to cite a referen= ce? My personal opinion is that PAWS should accommodate all regulatory requ= irements. The updated I-D must be uploaded in a few hours, unfortunately not much tim= e remains to include discussions from the email list in this draft. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:39:37 +0000 To: Database Device >, "paws@ietf.org" > Cc: >, Juan Zuniga > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case= =85" which might mistakenly imply some preference to this solution, and not= e this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don=92t currently anticipate a fixed IP address or url for a databa= se. Personally I feel a fixed address would have some drawbacks so I didn= =92t include this method in the submission. As you are stating you require = it, I=92m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too =96 at present we don=92t yet have their final list of = requirements. Thirdly, a database operator may require this facility in ord= er to offer value added services. The operators in the UK are currently unk= nown (no but my company could be a prospective database operator, so I am r= equesting this facility. This is certainly within the scope of PAWS (fulfil= ling the requirements of database operators is specifically mentioned in th= e Charter, viz. =93the particular data exchanged between a device and a dat= abase might depend on the ranges of radio spectrum that are to be used, the= requirements of the database operators and their governing regulations, an= d other factors=94). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2=85" [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_CAD42348BDA1scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Andy,

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

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

Regards,
Scott


Scott

 

Thanks for your comments on our joint submission. U= nfortunately I am not in full agreement with your position, please see my c= omments in-line.

 

Regards

 

Andy

 

From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.o= rg
Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com
Subject: Re: [paws] New indoor and M2M use cases, revision of DB dis= covery use case

 

Hi Andy, Mike & Juan Carlos,=

 

Thank you for providing the I-D. After revi= ew I have a few comments.

 

1. The proposed revision to the database di= scovery use case does simplify the text and introduces the "listing&qu= ot; method from the UK. These changes make sense to me. The revision also removes the option for a pre-programmed address o= f a trusted database. I believe this is an important option and should rema= in in the I-D. A possible remedy is to remove  "In the simplest c= ase=85" which might mistakenly imply some preference to this solution, and note this to be an option.

 

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

 

2. In the Indoor Networking use case, I sug= gest to remove step 7 which describes updating the database with the select= ions made by the master device. I personally see merit in this capability. However, following previous discussions on t= his mail list, and after review of our Charter, I believe this step to upda= te the database with information is not within our current scope; I am plan= ning to remove similar steps from other use cases in the next update. The issue of scope is merely my person= al opinion.

 

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

 

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

 

[First paragraph]

"In this use case, each "machine&= quot; includes a white space slave device and can be located anywhere, fixe= d or on the move. Each machine needs to have connectivity to the internet and or to other machines in the vicinity. Machine communic= ation over a TVWS channel, whether to a master device or to another machine= (slave device), is under the control of a master device. This deployment s= cenario is typically characterized by a master device with internet connectivity by some connection that does= not utilize TV white space. Figure 2=85"

 

[Andy Sago] Agreed

 

[Step 6]

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

 

[Andy Sago] Agreed

 

[Step 7]

Propose to remove this step for same reason= s as discussed in Indoor Networking use case.

 

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

 

Regards,

Scott

 

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 17 Oct 2011 09:49:34 +0100
To: "paws@ietf.org" &= lt;paws@ietf.org>, Database Device = <scott.probasco@nokia.com>
Cc: <michael.fitch@bt.com= >, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>
Subject: [paws] New indoor and M2M use cases, revision of DB discove= ry use case

 

Hi Scott, all

 

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

 

Regards

 

Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigi= tal)

 

 

 

 

 --_000_CAD42348BDA1scottprobasconokiacom_-- From Andrew.Gowans@ofcom.org.uk Mon Oct 31 09:08: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 0C70E11E80E6 for ; Mon, 31 Oct 2011 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 yhgIsRe87c1N for ; Mon, 31 Oct 2011 09:08:02 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0967E21F8C7A for ; Mon, 31 Oct 2011 09:08:01 -0700 (PDT) X-Env-Sender: Andrew.Gowans@ofcom.org.uk X-Msg-Ref: server-16.tower-216.messagelabs.com!1320077182!1725466!1 X-Originating-IP: [194.33.160.65] X-StarScan-Version: 6.4.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20838 invoked from network); 31 Oct 2011 16:06:22 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 31 Oct 2011 16:06:22 -0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local (10.130.130.68) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 31 Oct 2011 16:06:22 +0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b]) by WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19%15]) with mapi id 14.01.0289.001; Mon, 31 Oct 2011 16:06:22 +0000 From: Andrew Gowans To: "scott.probasco@nokia.com" , "andy.sago@bt.com" , "paws@ietf.org" Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AQHMk1YZ6SKVlRwazEKmVNLf4j08uJWWjyeAgAANmgCAAAYxQA== Date: Mon, 31 Oct 2011 16:06:18 +0000 Message-ID: <9983D74B649EED43B27BF353837B20C559CE45FF@WOK-INTRA-EXC01.intra.ofcom.local> References: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.39.12] Content-Type: multipart/alternative; boundary="_000_9983D74B649EED43B27BF353837B20C559CE45FFWOKINTRAEXC01in_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:08:08 -0000 --_000_9983D74B649EED43B27BF353837B20C559CE45FFWOKINTRAEXC01in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott/All, I can confirm that Andy Sago is correct in that Ofcom have not confirmed wh= at our final requirements may be regarding the need for a return channel as= a regulatory requirement or not. I would say at this stage there is no har= m in keeping it in the document being taken forward as it seems that it wil= l be within your guidelines if any regulator requires it in the future. I t= ake it these elements can be treated like other requirements that may be re= gion or country specific. I say this in the knowledge that the current prop= osals from Ofcom will require different requirements from that of the US pr= oposals hence there will have to a master set of requirements which will mo= re than likely be reduced to a subset of the requirements dependent upon ea= ch regulatory domain. Best regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 31 October 2011 15:28 To: andy.sago@bt.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Thank you for your reply. As said, I do favor to keep the possibility for d= evices to update information in the database, my concern is merely to opera= te within our guidelines. You mention below that FCC and Canada require the= database to know the details of some links, are you able to cite a referen= ce? My personal opinion is that PAWS should accommodate all regulatory requ= irements. The updated I-D must be uploaded in a few hours, unfortunately not much tim= e remains to include discussions from the email list in this draft. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:39:37 +0000 To: Database Device >, "paws@ietf.org" > Cc: >, Juan Zuniga > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case.= .." which might mistakenly imply some preference to this solution, and note= this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don't currently anticipate a fixed IP address or url for a database= . Personally I feel a fixed address would have some drawbacks so I didn't i= nclude this method in the submission. As you are stating you require it, I'= m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too - at present we don't yet have their final list of requ= irements. Thirdly, a database operator may require this facility in order t= o offer value added services. The operators in the UK are currently unknown= (no but my company could be a prospective database operator, so I am reque= sting this facility. This is certainly within the scope of PAWS (fulfilling= the requirements of database operators is specifically mentioned in the Ch= arter, viz. "the particular data exchanged between a device and a database = might depend on the ranges of radio spectrum that are to be used, the requi= rements of the database operators and their governing regulations, and othe= r factors"). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2..." [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_9983D74B649EED43B27BF353837B20C559CE45FFWOKINTRAEXC01in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott/All,

 

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

 

Best regards

 

Andy  Gowans

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of scott.probasco@nokia.com
Sent: 31 October 2011 15:28
To: andy.sago@bt.com; paws@ietf.org
Subject: Re: [paws] New indoor and M2M use cases, revision of DB dis= covery use case

 

Hi Andy,

 

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

 

The updated I-D must be u= ploaded in a few hours, unfortunately not much time remains to include disc= ussions from the email list in this draft.

 

Regards,

Scott

 

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 31 Oct 2011 14:39:37 +0000
To: Database Device <= scott.probasco@nokia.com>, "pa= ws@ietf.org" <paws@ietf.org>
Cc: <michael.fitch@bt.com= >, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>
Subject: RE: [paws] New indoor and M2M use cases, revision of DB dis= covery use case

 

Scott<= /span>

 =

Thanks for your comments on our joint sub= mission. Unfortunately I am not in full agreement with your position, pleas= e see my comments in-line.

 =

Regards

 =

Andy

 =

From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.o= rg
Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com
Subject: Re: [paws] New indoor and M2M use cases, revision of DB dis= covery use case

 

Hi Andy, Mike & Juan = Carlos,

 

Thank you for providing t= he I-D. After review I have a few comments.

 

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

 

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

 =

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

 

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

 

3. In the M2M use case, w= ould you consider the following revisions:

 

[First paragraph]<= span style=3D"color:black">

"In this use case, e= ach "machine" includes a white space slave device and can be loca= ted anywhere, fixed or on the move. Each machine needs to have connectivity to the internet and or to other machines in the vicinity. Machine communic= ation over a TVWS channel, whether to a master device or to another machine= (slave device), is under the control of a master device. This deployment s= cenario is typically characterized by a master device with internet connectivity by some connection that does= not utilize TV white space. Figure 2…"

 

[Andy Sago] Agreed

 =

[Step 6]

6. The slave devices fitt= ed to the machines scan the TV bands to locate the master transmissions, an= d associate with the master device. Further signaling can take place outside  scope of PAWS to establish direct links among tho= se slave devices that have associated with the master device.

 

[Andy Sago] Agreed

 =

[Step 7]

Propose to remove this st= ep for same reasons as discussed in Indoor Networking use case.

 

[Andy Sago] Disagree, for same reas= ons as for the Indoor Networking use case.

 =

Regards,

Scott

 

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 17 Oct 2011 09:49:34 +0100
To: "paws@ietf.org" &= lt;paws@ietf.org>, Database Device = <scott.probasco@nokia.com>
Cc: <michael.fitch@bt.com= >, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>
Subject: [paws] New indoor and M2M use cases, revision of DB discove= ry use case

 

Hi Scott, all

 

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

 

Regards<= /span>

 

Andy Sago (BT), Mike Fitch (BT), Juan Carlo= s Zuniga (Interdigital)

 

 

 

 



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

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

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

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

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_9983D74B649EED43B27BF353837B20C559CE45FFWOKINTRAEXC01in_-- From peter@spectrumbridge.com Mon Oct 31 09:50: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 9745A11E810C for ; Mon, 31 Oct 2011 09:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6] 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 7mtnN2BAqsq7 for ; Mon, 31 Oct 2011 09:50:32 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2971811E810E for ; Mon, 31 Oct 2011 09:50:29 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 31 Oct 2011 12:52:43 -0400 From: Peter Stanforth To: "andy.sago@bt.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Date: Mon, 31 Oct 2011 12:50:34 -0400 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyX7YHZD1vdN5SKQmWCAlDTqVqvzA== Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> 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_CAD4490C15FB4peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:50:33 -0000 --_000_CAD4490C15FB4peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Andy, In reference to 2. below, The FCC does not have any rule that a radio rep= ort it's channel use to a DB. There has been no comment/concern about this = in our TVWS database trial. I agree that it is nice to have and could be th= e basis of value added services, but it is not explicitly required. I could= not find any "requirement" in the Canadian proposal either. Regards, Peter S. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 10:39:37 -0400 To: "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case= =85" which might mistakenly imply some preference to this solution, and not= e this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don=92t currently anticipate a fixed IP address or url for a databa= se. Personally I feel a fixed address would have some drawbacks so I didn= =92t include this method in the submission. As you are stating you require = it, I=92m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too =96 at present we don=92t yet have their final list of = requirements. Thirdly, a database operator may require this facility in ord= er to offer value added services. The operators in the UK are currently unk= nown (no but my company could be a prospective database operator, so I am r= equesting this facility. This is certainly within the scope of PAWS (fulfil= ling the requirements of database operators is specifically mentioned in th= e Charter, viz. =93the particular data exchanged between a device and a dat= abase might depend on the ranges of radio spectrum that are to be used, the= requirements of the database operators and their governing regulations, an= d other factors=94). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2=85" [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_CAD4490C15FB4peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Andy,
In reference to= 2. below,  The FCC does not have any rule  that a radio report i= t's channel use to a DB. There has been no comment/concern about this in ou= r TVWS database trial. I agree that it is nice to have and could be the bas= is of value added services, but it is not explicitly required. I could not = find any "requirement" in the Canadian proposal either.
Regards,
Peter S.

From: "andy.sa= go@bt.com" <andy.sago@bt.co= m>
Date: Mon, 31 Oct 201= 1 10:39:37 -0400
To: "scott.probasco@nokia.com" = <scott.probasco@nokia.com>, "paws@ietf.org" <<= a href=3D"mailto:paws@ietf.org">paws@ietf.org>
Subject: Re: [paws] New indoor and M2M use cases, re= vision of DB discovery use case

Scott=

 

Thanks for your comments on our joint submission. Unfortu= nately I am not in full agreement with your position, please see my comment= s in-line.

 

Regards

 

Andy<= /o:p>

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.org
Cc: Fitch,MR,Michael,= DES8 R; JuanCarlos.Zu= niga@InterDigital.com
Subject: Re: [paws] New indoor and M2M = use cases, revision of DB discovery use case

 

= Hi Andy, Mike & Juan Carlos,

<= p class=3D"MsoNormal"> 

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

 

1. The proposed revision to the database discovery use case does simp= lify the text and introduces the "listing" method from the UK. Th= ese changes make sense to me. The revision also removes the option for a pr= e-programmed address of a trusted database. I believe this is an important = option and should remain in the I-D. A possible remedy is to remove  &= quot;In the simplest case=85" which might mistakenly imply some prefer= ence to this solution, and note this to be an option.

=

 

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

 

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

 

[Andy Sa= go] I have to disagree, both with removi= ng this step here and with removing similar steps in other use cases. First= ly, as I understand it FCC and Canada already require the database to know = the details of some links (e.g. rural broadband) and this requirement could= be fulfilled by having the master device report back directly to the datab= ase. The recent 802.22 requirements posted to the reflector also ask for th= is. Secondly, UK may require this facility too =96 at present we don=92t ye= t have their final list of requirements. Thirdly, a database operator may r= equire this facility in order to offer value added services. The operators = in the UK are currently unknown (no but my company could be a prospective d= atabase operator, so I am requesting this facility. This is certainly withi= n the scope of PAWS (fulfilling the requirements of database operators is s= pecifically mentioned in the Charter, viz. =93the particular data exchanged= between a device and a database might depend on the ranges of radio spectr= um that are to be used, the requirements of the database operators and thei= r governing regulations, and other factors=94).

 

=

3. In the M2M use case, would you cons= ider the following revisions:

 

[First paragraph]

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

 

[Andy Sago] Agreed

 

[Step 6]

6. The slave device= s fitted to the machines scan the TV bands to locate the master transmissio= ns, and associate with the master device. Further signaling can take p= lace outside  scope of PAWS to establish direct links among those slav= e devices that have associated with the master device.

 

[Andy Sago] Agreed

 

[Step 7]

Propose to remove t= his step for same reasons as discussed in Indoor Networking use case.<= /o:p>

=  

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

 

Regards,

Scott

 

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 17 Oct 2011 09:49= :34 +0100
To: "paws@iet= f.org" <paws@ietf.org>,= Database Device <scott.prob= asco@nokia.com>
Cc: <michael.fitch@bt.com>, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>Subject: [paws] New indoor and M2M use cases, revision of DB disco= very use case

= Hi Scott, = all

 <= /o:p>

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

 

=

Regards

 

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

 

 

 

&nbs= p;<= o:p>

--_000_CAD4490C15FB4peterspectrumbridgecom_-- From andy.sago@bt.com Mon Oct 31 09:51: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 6219911E810C for ; Mon, 31 Oct 2011 09:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 slK1oqDrmrf8 for ; Mon, 31 Oct 2011 09:51:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 071FA11E80EA for ; Mon, 31 Oct 2011 09:51:15 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 16:51:12 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.68]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 31 Oct 2011 16:51:13 +0000 From: To: , Date: Mon, 31 Oct 2011 16:51:15 +0000 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AQHMk1YZ6SKVlRwazEKmVNLf4j08uJWWjyeAgAANmgCAAAYxQIAACBaA Message-ID: <619CDADDCCD2B44380834BE8BF6F71414049E2634C@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> <9983D74B649EED43B27BF353837B20C559CE45FF@WOK-INTRA-EXC01.intra.ofcom.local> In-Reply-To: <9983D74B649EED43B27BF353837B20C559CE45FF@WOK-INTRA-EXC01.intra.ofcom.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414049E2634CEMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:51:25 -0000 --_000_619CDADDCCD2B44380834BE8BF6F71414049E2634CEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott So Ofcom has confirmed below that there could be a potential UK requirement= , which shouldn't be shut out at this stage. As for providing a reference f= or the US and Canadian requirements, I am hardly the best placed person on = this reflector to comment, but my understanding is that the FCC document on= the Part 0 and Part 15 rules for "Unlicensed Operation in the TV Broadcast= Bands; Final Rule" http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf s= pecifically expects databases may perform additional functions such as "tra= cking active channel use if reported by the TV bands device", hence the PAW= S protocol should enable this. I reproduce below the relevant paragraph: Additional Service Features 73. Decision. Database administrators may perform additional functions besides those required by the rules, such as tracking active channel use if reported by the TV bands device, or sending additional information to a TV bands device to enable it to determine the ''best'' available channel to use. Such functions are not prohibited by the rules, and the ability to add additional functionality could allow multiple database operators to distinguish their services and could be useful in the development of industry standards to enable more efficient spectrum sharing. I'm even less of an expert on Canada, but their August consultation at http= ://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) "To meet = these requirements, each white space device will need to provide data, incl= uding its location, to a database. This data would be retained for a period= of time in order to provide a capability for after-the fact data audits of= suspected interference cases." I think that, when this requirement is full= y unpacked, the data needing to be retained by the database for audit purpo= ses will include actual channel frequency used. Also, they are consulting o= n whether to move future high power Remote Rural Broadband Systems (RRBS) f= rom the current licensed model to use of TV band devices with the geolocati= on database (p.17, "it is anticipated that white space devices could be rea= dily adapted for operation under the current rules for RRBS"). These would = require protection from other TVWS devices to provide a similar service to = existing RRBS, so in practice the actual channel in use would need to be re= ported back to the database. Regards Andy From: Andrew Gowans [mailto:Andrew.Gowans@ofcom.org.uk] Sent: 31 October 2011 16:06 To: scott.probasco@nokia.com; Sago,AJ,Andy,COD R; paws@ietf.org Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott/All, I can confirm that Andy Sago is correct in that Ofcom have not confirmed wh= at our final requirements may be regarding the need for a return channel as= a regulatory requirement or not. I would say at this stage there is no har= m in keeping it in the document being taken forward as it seems that it wil= l be within your guidelines if any regulator requires it in the future. I t= ake it these elements can be treated like other requirements that may be re= gion or country specific. I say this in the knowledge that the current prop= osals from Ofcom will require different requirements from that of the US pr= oposals hence there will have to a master set of requirements which will mo= re than likely be reduced to a subset of the requirements dependent upon ea= ch regulatory domain. Best regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.pro= basco@nokia.com Sent: 31 October 2011 15:28 To: andy.sago@bt.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Thank you for your reply. As said, I do favor to keep the possibility for d= evices to update information in the database, my concern is merely to opera= te within our guidelines. You mention below that FCC and Canada require the= database to know the details of some links, are you able to cite a referen= ce? My personal opinion is that PAWS should accommodate all regulatory requ= irements. The updated I-D must be uploaded in a few hours, unfortunately not much tim= e remains to include discussions from the email list in this draft. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:39:37 +0000 To: Database Device >, "paws@ietf.org" > Cc: >, Juan Zuniga > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case.= .." which might mistakenly imply some preference to this solution, and note= this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don't currently anticipate a fixed IP address or url for a database= . Personally I feel a fixed address would have some drawbacks so I didn't i= nclude this method in the submission. As you are stating you require it, I'= m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too - at present we don't yet have their final list of requ= irements. Thirdly, a database operator may require this facility in order t= o offer value added services. The operators in the UK are currently unknown= (no but my company could be a prospective database operator, so I am reque= sting this facility. This is certainly within the scope of PAWS (fulfilling= the requirements of database operators is specifically mentioned in the Ch= arter, viz. "the particular data exchanged between a device and a database = might depend on the ranges of radio spectrum that are to be used, the requi= rements of the database operators and their governing regulations, and othe= r factors"). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2..." [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_619CDADDCCD2B44380834BE8BF6F71414049E2634CEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott

 

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

 

Addi= tional Service Features

73. Decision. Datab= ase administrators

may perform additional f= unctions

besides those required by the rule= s, such

as tracking active channel use if

reported by the TV bands device, or

sending additional information to a TV

bands device to enable it to determine

the ‘‘best’’ available channel to u= se. Such

functions are not prohibited by th= e

rules, and the ability to add additional<= o:p>

functionality could allow multiple

database operators to distinguish their<= /span>

services and could be useful in the<= /p>

development of industry standards to

enable more efficient spectrum sharing.

 

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

 

Regards

 <= /o:p>

Andy

<= span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'> =

 

From: Andrew Gowans [mailto:Andrew.= Gowans@ofcom.org.uk]
Sent: 31 October 2011 16:06
To: s= cott.probasco@nokia.com; Sago,AJ,Andy,COD R; paws@ietf.org
Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery use ca= se

 <= /p>

Scott/All,

 

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

&= nbsp;

Best regards<= o:p>

 

Andy  Gowans

 

From: p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 31 Oct= ober 2011 15:28
To: andy.sago= @bt.com; paws@ietf.org
Subje= ct: Re: [paws] New indoor and M2M use cases, revision of DB discovery u= se case

 

Hi Andy,

=

 

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

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>The updated I-D must be uploaded in a few hours, unfortunately not much= time remains to include discussions from the email list in this draft.

 

Regards,

=

Scott

=

 

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 31 Oct 2011 14:39:37 = +0000
To: Database Device <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ie= tf.org>
Cc: <mi= chael.fitch@bt.com>, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>
Sub= ject: RE: [paws] New indoor and M2M use cases, revision of DB discovery= use case

 =

Scott

 

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

 

Regards

 

Andy

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f";color:black'>From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: 25 = October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.org
Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigit= al.com
Subject: Re: [paws] New indoor and M2M use cases, revi= sion of DB discovery use case

 

Hi Andy, Mike & Juan Carlos,

=

 

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

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'> 

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

 

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

 

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

 

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

 

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

 

[First paragraph]

"In this use case, each &qu= ot;machine" includes a white space slave device and can be located any= where, fixed or on the move. Each machine needs to have connectivity to the= internet and or to other machines in the vicinity. Machine communication o= ver a TVWS channel, whether to a master device or to another machine (slave= device), is under the control of a master device. This deployment scenario= is typically characterized by a master device with internet connectivity b= y some connection that does not utilize TV white space. Figure 2…&quo= t;

 

[Andy Sago] Agreed

 

[Step 6]

6. The slave devices fitted to the machines scan the TV bands = to locate the master transmissions, and associate with the master device.&n= bsp;Further signaling can take place outside  scope of PAWS to establi= sh direct links among those slave devices that have associated with the mas= ter device.

&nb= sp;

[Andy Sago] Agreed

 

<= div>

[Step 7]

Propose to remove this step for same reasons as discu= ssed in Indoor Networking use case.

 

[Andy Sag= o] Disagree, for same reasons as for the Indoor Networking use case.=

 

Regards,

Scott

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:bla= ck'>From: "ext and= y.sago@bt.com" <andy.sago@b= t.com>
Date: Mon, 17 Oct 2011 09:49:34 +0100
To: "paws@ietf.org" <paws@ietf.org>, Database Device <scott.probasco@nokia.com>
<= b>Cc: <michael.fitch@bt.com<= /a>>, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>
Subject: [paws] Ne= w indoor and M2M use cases, revision of DB discovery use case

 

Hi Scott, all

<= p class=3DMsoNormal> 

I-= D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-= requirements-00.txt proposes revision of the database discovery use cas= e, two new use cases for indoor networking and machine to machine communica= tions, and a set of requirements that drop out of all the use cases include= d so far in the working document. These especially address the UK Ofcom req= uirements as currently known. Also, a definition is proposed for the term &= #8216;device ID’ which we suggest should be used throughout the use c= ases and requirements for consistency in place of terms such as ‘mode= l ID’ and ‘FCC ID’. This Internet Draft is a joint submis= sion from Mike Fitch (BT), Andy Sago (BT) and Juan Carlos Zuniga (Interdigi= tal). We would welcome comments made to the reflector on these proposals. W= e are willing to present in Taipei if it would be helpful in providing furt= her explanation to the content in the document.

=

 

<= span style=3D'font-family:"Calibri","sans-serif";color:black'>Regards

 

=

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

 

 

 

 

=

 


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

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

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

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

Any views e= xpressed in this message are those of the individual sender and do not repr= esent the views or opinions of Ofcom unless expressly stated otherwise.
= ***************************************************************************= ***************************************

<= /html>= --_000_619CDADDCCD2B44380834BE8BF6F71414049E2634CEMV62UKRDdoma_-- From peter@spectrumbridge.com Mon Oct 31 09:58: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 C0F4511E812B for ; Mon, 31 Oct 2011 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6] 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 8mMCFgYpMQUH for ; Mon, 31 Oct 2011 09:58:08 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6777311E8109 for ; Mon, 31 Oct 2011 09:58:08 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 31 Oct 2011 13:00:24 -0400 From: Peter Stanforth To: "andy.sago@bt.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Date: Mon, 31 Oct 2011 12:58:14 -0400 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyX7pQo+jafGhkIQQixvo52WqnsKA== Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414049E2634C@EMV62-UKRD.domain1.systemhost.net> 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_CAD44B6715FC5peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:58:10 -0000 --_000_CAD44B6715FC5peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Some other thoughts on the use cases discussion that this trail is related = to. (https://datatracker.ietf.org/doc/draft-zuniga-paws-uk-use-cases-and-r= equirements/) Peter S. 3.2: indoor networking Step 3: In the US, and probably Canada, there is no requirement for locati= on uncertainty so this may have to be optional or have a default value. Thi= s impacts 4.1.7 step 7: (radio reporting channel use to the DB) is not specified in any of= the regulations we are aware of so this may have to be optional. 4.1.11 se= ems to contradict this statement. 3.3: I can see a general concern with this Use Case from the Broadcasters.= In the simple Master/Slave Use Cases there is a perceived coverage area of= the master, based on it's power etc, which can be calculated into a buffer= to ensure that neither the master or the slaves will interfere with an inc= umbent. However in the M2M case there is the implication of multi-hopping w= hich could dramatically increase the distance of a slave from a master. Unl= ess hopping is limited and the function of hopping is known there is no way= to accurately compute the likely interference from the multi hopping slave= s. 4.1: Requirements 10: In most cases the slave does not have location capability so how is it = going to know that it has changed location? I don't know how a master can d= etermine it's coverage area in a way that a slave can resolve this. I also= think this is irrelevant in many cases. If you consider a set of Access Po= ints (masters) in a building a slave should be able to roam around and asso= ciate with any, or all of the Masters without having to go through a channe= l discovery process as all the channels it will use are validated by the ma= sters. 4.2: Database Most regulators include some requirement that the DB validate or authentica= te a Device before providing it with a channel list. The FCC also requires = that the DB be able to black list specific devices. This implies that a dev= ice may get a "no channels available" message because it is not permitted t= o use either the DB or TVWS. I know you cover security in 4.2, but the impl= ication of failure is no channel list returned to the device. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 12:51:15 -0400 To: "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott So Ofcom has confirmed below that there could be a potential UK requirement= , which shouldn=92t be shut out at this stage. As for providing a reference= for the US and Canadian requirements, I am hardly the best placed person o= n this reflector to comment, but my understanding is that the FCC document = on the Part 0 and Part 15 rules for =93Unlicensed Operation in the TV Broad= cast Bands; Final Rule=94 http://edocket.access.gpo.gov/2010/pdf/2010-30184= .pdf specifically expects databases may perform additional functions such a= s =93tracking active channel use if reported by the TV bands device=94, hen= ce the PAWS protocol should enable this. I reproduce below the relevant par= agraph: Additional Service Features 73. Decision. Database administrators may perform additional functions besides those required by the rules, such as tracking active channel use if reported by the TV bands device, or sending additional information to a TV bands device to enable it to determine the =91=91best=92=92 available channel to use. Such functions are not prohibited by the rules, and the ability to add additional functionality could allow multiple database operators to distinguish their services and could be useful in the development of industry standards to enable more efficient spectrum sharing. I=92m even less of an expert on Canada, but their August consultation at ht= tp://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) =93To m= eet these requirements, each white space device will need to provide data, = including its location, to a database. This data would be retained for a pe= riod of time in order to provide a capability for after-the fact data audit= s of suspected interference cases.=94 I think that, when this requirement i= s fully unpacked, the data needing to be retained by the database for audit= purposes will include actual channel frequency used. Also, they are consul= ting on whether to move future high power Remote Rural Broadband Systems (R= RBS) from the current licensed model to use of TV band devices with the geo= location database (p.17, =93it is anticipated that white space devices coul= d be readily adapted for operation under the current rules for RRBS=94). Th= ese would require protection from other TVWS devices to provide a similar s= ervice to existing RRBS, so in practice the actual channel in use would nee= d to be reported back to the database. Regards Andy From: Andrew Gowans [mailto:Andrew.Gowans@ofcom.org.uk] Sent: 31 October 2011 16:06 To: scott.probasco@nokia.com; Sago,AJ,Andy= ,COD R; paws@ietf.org Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott/All, I can confirm that Andy Sago is correct in that Ofcom have not confirmed wh= at our final requirements may be regarding the need for a return channel as= a regulatory requirement or not. I would say at this stage there is no har= m in keeping it in the document being taken forward as it seems that it wil= l be within your guidelines if any regulator requires it in the future. I t= ake it these elements can be treated like other requirements that may be re= gion or country specific. I say this in the knowledge that the current prop= osals from Ofcom will require different requirements from that of the US pr= oposals hence there will have to a master set of requirements which will mo= re than likely be reduced to a subset of the requirements dependent upon ea= ch regulatory domain. Best regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.pro= basco@nokia.com Sent: 31 October 2011 15:28 To: andy.sago@bt.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Thank you for your reply. As said, I do favor to keep the possibility for d= evices to update information in the database, my concern is merely to opera= te within our guidelines. You mention below that FCC and Canada require the= database to know the details of some links, are you able to cite a referen= ce? My personal opinion is that PAWS should accommodate all regulatory requ= irements. The updated I-D must be uploaded in a few hours, unfortunately not much tim= e remains to include discussions from the email list in this draft. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:39:37 +0000 To: Database Device >, "paws@ietf.org" > Cc: >, Juan Zuniga > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case= =85" which might mistakenly imply some preference to this solution, and not= e this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don=92t currently anticipate a fixed IP address or url for a databa= se. Personally I feel a fixed address would have some drawbacks so I didn= =92t include this method in the submission. As you are stating you require = it, I=92m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too =96 at present we don=92t yet have their final list of = requirements. Thirdly, a database operator may require this facility in ord= er to offer value added services. The operators in the UK are currently unk= nown (no but my company could be a prospective database operator, so I am r= equesting this facility. This is certainly within the scope of PAWS (fulfil= ling the requirements of database operators is specifically mentioned in th= e Charter, viz. =93the particular data exchanged between a device and a dat= abase might depend on the ranges of radio spectrum that are to be used, the= requirements of the database operators and their governing regulations, an= d other factors=94). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2=85" [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_CAD44B6715FC5peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Some other thoughts = on the use cases discussion that this trail is related to.  (https://datatracker.ietf.org= /doc/draft-zuniga-paws-uk-use-cases-and-requirements/)

= Peter S.

=

 <= /p>

3.2:   indoor networking 

Step 3:  In the US, and probab= ly Canada, there is no requirement for location uncertainty so this may hav= e to be optional or have a default value. This impacts 4.1.7

= step 7:  (rad= io reporting channel use to the DB) is not specified in any of the regulati= ons we are aware of so this may have to be optional. 4.1.11 seems to contra= dict this statement.

 

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

 =

4.1: Requirements

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

 

4.2: Database<= span style=3D"color: rgb(4, 1, 0); ">

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

=  

<= /div>

=
From: "andy.sa= go@bt.com" <andy.sago@bt.co= m>
Date: Mon, 31 Oct 201= 1 12:51:15 -0400
To: "scott.probasco@nokia.com" = <scott.probasco@nokia.com>, "paws@ietf.org" <<= a href=3D"mailto:paws@ietf.org">paws@ietf.org>
Subject: Re: [paws] New indoor and M2M use cases, re= vision of DB discovery use case

Scott=

 

So Ofcom has confirmed below that there could be a potent= ial UK requirement, which shouldn=92t be shut out at this stage. As for pro= viding a reference for the US and Canadian requirements, I am hardly the be= st placed person on this reflector to comment, but my understanding is that= the FCC document on the Part 0 and Part 15 rules for =93Unlicensed Operati= on in the TV Broadcast Bands; Final Rule=94 http://edocket.access.gpo.gov/2010/pdf/2= 010-30184.pdf specifically expects databases may perform additional fun= ctions such as =93tracking active channel use if reported by the TV bands d= evice=94, hence the PAWS protocol should enable this. I reproduce below the= relevant paragraph:

&nb= sp;

Additional Service Features

73. Decision. Database administra= tors

may perform additional fu= nctions

besides those required= by the rules, such

as trackin= g active channel use if

report= ed by the TV bands device, or

<= span style=3D"color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">= sending additional information to a TV

bands device to enable it to determine

the =91=91best=92=92 available channel to use. Such<= /o:p>

functions are not prohibited by the=

rules, and the ability to add= additional

functionality coul= d allow multiple

database oper= ators to distinguish their

ser= vices and could be useful in the

enable more efficient spectrum sharing.

 

I= =92m even less of an expert on Canada, but their August consultation at http://w= ww.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) =93To mee= t these requirements, each white space device will need to provide data, in= cluding its location, to a database. This data would be retained for a peri= od of time in order to provide a capability for after-the fact data audits = of suspected interference cases.=94 I think that, when this requirement is = fully unpacked, the data needing to be retained by the database for audit p= urposes will include actual channel frequency used. Also, they are consulti= ng on whether to move future high power Remote Rural Broadband Systems (RRB= S) from the current licensed model to use of TV band devices with the geolo= cation database (p.17, =93it is anticipated that white space devices could = be readily adapted for operation under the current rules for RRBS=94). Thes= e would require protection from other TVWS devices to provide a similar ser= vice to existing RRBS, so in practice the actual channel in use would need = to be reported back to the database.

 

Regards

 

Andy

&nbs= p;

 

From: Andrew G= owans [mailto:Andrew.Gowans@o= fcom.org.uk]
Sent: 31 October 2011 16:06
To: scott.probasco@nokia.com; Sago,A= J,Andy,COD R; paws@ietf.org
Subj= ect: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case

 = ;

Scott/All,<= o:p>

 

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

 

Best regards

 

Andy  Gowans

 

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.pr= obasco@nokia.com
Sent: 31 October 2011 15:28
To: andy.sago@bt.com; paws@ietf.org
Subject: Re: [paws] New indoor an= d M2M use cases, revision of DB discovery use case

 

Hi Andy,

 

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

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri, sans-s= erif; "> 

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

 <= o:p>

Regards,

Scott

 <= /p>

From: = "ext andy.sago@bt.com" &l= t;andy.sago@bt.com>
Date: = Mon, 31 Oct 2011 14:39:37 +0000
To: Database Device <<= a href=3D"mailto:scott.probasco@nokia.com">scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Cc: <michael.fitch@bt.com>, Juan Zuniga = <JuanCarlos.Zuniga= @InterDigital.com>
Subject: RE: [paws] New indoor and M2M = use cases, revision of DB discovery use case

 

Scott

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

 

Regar= ds

 

Andy

<= span style=3D"color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">=  

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: 2= 5 October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.org
Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDig= ital.com
Subject: Re: [paws] New indoor and M2M use cases, re= vision of DB discovery use case

 

Hi Andy, Mike & Juan Carlos,

 

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

 

1. The proposed revision to the database disc= overy use case does simplify the text and introduces the "listing"= ; method from the UK. These changes make sense to me. The revision also rem= oves the option for a pre-programmed address of a trusted database. I belie= ve this is an important option and should remain in the I-D. A possible rem= edy is to remove  "In the simplest case=85" which might mist= akenly imply some preference to this solution, and note this to be an optio= n.

 

[Andy Sago] The text in our submiss= ion mainly addresses the UK requirements, which don=92t currently anticipat= e a fixed IP address or url for a database. Personally I feel a fixed addre= ss would have some drawbacks so I didn=92t include this method in the submi= ssion. As you are stating you require it, I=92m happy for it to remain as a= n option.

 

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

 

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

 

3. In the M2M use c= ase, would you consider the following revisions:

 

[First paragraph]

"In this use case, each "= ;machine" includes a white space slave device and can be located anywh= ere, fixed or on the move. Each machine needs to have connectivity to the i= nternet and or to other machines in the vicinity. Machine communication ove= r a TVWS channel, whether to a master device or to another machine (slave d= evice), is under the control of a master device. This deployment scenario i= s typically characterized by a master device with internet connectivity by = some connection that does not utilize TV white space. Figure 2=85"

&nb= sp;

[Andy Sago] <= /i>Agreed

 

= [Step 6]

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

&nb= sp;

[Andy Sago] <= /i>Agreed

 

= [Step 7]

Pr= opose to remove this step for same reasons as discussed in Indoor Networkin= g use case.

 

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

 =

Regards,

Scott

 

<= div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm">

From: "ext = andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, = 17 Oct 2011 09:49:34 +0100
To: "paws@ietf.org" <paws@= ietf.org>, Database Device <scott.probasco@nokia.com>
Cc: <michael.fitch@bt.com>, Juan Zuniga <JuanCarlos.Zuniga@InterDigi= tal.com>
Subject: [paws] New indoor and M2M use cases, rev= ision of DB discovery use case

 

Hi Scott, all

 

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

 

Regards

 

Andy Sag= o (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital)

 

<= /div>

 

<= div>

 

 

<= /div>

 


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

This email (and any attach= ments) is confidential and intended for the use of the addressee only.
<= br>If you have received this email in error please notify the originator of= the message and delete it from your system.

This email has been sca= nned for viruses. However, you open any attachments at your own risk.
Any views expressed in this message are those of the individual sender an= d do not represent the views or opinions of Ofcom unless expressly stated o= therwise.
**************************************************************= ****************************************************

<= /div> --_000_CAD44B6715FC5peterspectrumbridgecom_-- From andy.sago@bt.com Mon Oct 31 10:02: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 A3C6011E815D for ; Mon, 31 Oct 2011 10:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 u36F61kD6l47 for ; Mon, 31 Oct 2011 10:02:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 573AC11E816B for ; Mon, 31 Oct 2011 10:02:00 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 17:01:57 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.68]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 31 Oct 2011 17:01:57 +0000 From: To: , , Date: Mon, 31 Oct 2011 17:02:00 +0000 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyX7YHZD1vdN5SKQmWCAlDTqVqvzAAAGVFw Message-ID: <619CDADDCCD2B44380834BE8BF6F71414049E2635E@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414049E2635EEMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:02:08 -0000 --_000_619CDADDCCD2B44380834BE8BF6F71414049E2635EEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter Thanks, our emails crossed and I have suggested some indications from FCC a= nd IC which might lead to this facility being needed. I think the fact that= US has some databases up and running and implementing the minimum FCC rule= s shouldn't restrict the work in PAWS to develop a flexible and innovative = protocol that is capable of addressing current and future requirements worl= dwide. I realise that is an impossible task when regulators are mostly stil= l in consultation mode (or not even at that point yet), but we should read = between the lines as much as possible. Regards Andy From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: 31 October 2011 16:51 To: Sago,AJ,Andy,COD R; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Andy, In reference to 2. below, The FCC does not have any rule that a radio rep= ort it's channel use to a DB. There has been no comment/concern about this = in our TVWS database trial. I agree that it is nice to have and could be th= e basis of value added services, but it is not explicitly required. I could= not find any "requirement" in the Canadian proposal either. Regards, Peter S. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 10:39:37 -0400 To: "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case.= .." which might mistakenly imply some preference to this solution, and note= this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don't currently anticipate a fixed IP address or url for a database= . Personally I feel a fixed address would have some drawbacks so I didn't i= nclude this method in the submission. As you are stating you require it, I'= m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too - at present we don't yet have their final list of requ= irements. Thirdly, a database operator may require this facility in order t= o offer value added services. The operators in the UK are currently unknown= (no but my company could be a prospective database operator, so I am reque= sting this facility. This is certainly within the scope of PAWS (fulfilling= the requirements of database operators is specifically mentioned in the Ch= arter, viz. "the particular data exchanged between a device and a database = might depend on the ranges of radio spectrum that are to be used, the requi= rements of the database operators and their governing regulations, and othe= r factors"). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2..." [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) --_000_619CDADDCCD2B44380834BE8BF6F71414049E2635EEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter

 

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

 

Regards

 =

Andy

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: 31 Oc= tober 2011 16:51
To: Sago,AJ,Andy,COD R; scott.probasco@nokia.com= ; paws@ietf.org
Subject: Re: [paws] New indoor and M2M use cases,= revision of DB discovery use case

 

Andy,

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

Regards,

Peter S.

<= /div>

 

From: "andy.sago@= bt.com" <andy.sago@bt.com>
Date: Mon, 31 Oct 2011 10:39:37 -0400
To: "= scott.probasco@nokia.com&qu= ot; <scott.probasco@nokia.co= m>, "paws@ietf.org" &= lt;paws@ietf.org>
Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use cas= e

 

Scott

 

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

 

Regards=

 

Andy=

 

 

 

&= nbsp;

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

=  

"In this use case, each "machine"= ; includes a white space slave device and can be located anywhere, fixed or= on the move. Each machine needs to have connectivity to the internet and o= r to other machines in the vicinity. Machine communication over a TVWS chan= nel, whether to a master device or to another machine (slave device), is un= der the control of a master device. This deployment scenario is typically c= haracterized by a master device with internet connectivity by some connecti= on that does not utilize TV white space. Figure 2…"

[Step 6]

Regards,

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 17 Oct 2011 09:49:34 +0= 100
To: "paws@ietf.org&= quot; <paws@ietf.org>, Database = Device <scott.probasco@nokia= .com>
Cc: <mich= ael.fitch@bt.com>, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>
Subje= ct: [paws] New indoor and M2M use cases, revision of DB discovery use c= ase

 

Hi Scott, all

 

<= div>

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

 

Regards

 

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

 

 <= span style=3D'color:#040100'>

 <= /p>

 

= --_000_619CDADDCCD2B44380834BE8BF6F71414049E2635EEMV62UKRDdoma_-- From brian.rosen@neustar.biz Mon Oct 31 10:30: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 D781C1F0C67 for ; Mon, 31 Oct 2011 10:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 XDBUMf7ef+4W for ; Mon, 31 Oct 2011 10:30:48 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CA6F21F0C35 for ; Mon, 31 Oct 2011 10:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1320082199; x=1635441440; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=XnoCrLR3CMYx1LGmMrBEaULrqNvdYSLP1FBwYefbIVM=; b=qG0Fme+xZDXPEJxLGl4DY4FaPOi8j18eWBf+D9BPACXantRG4teFbPEH6dyzKR BbdD4sBYkARLLFxS26reoOoQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.1039078; Mon, 31 Oct 2011 13:29:56 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 31 Oct 2011 13:30:41 -0400 From: "Rosen, Brian" To: " " Date: Mon, 31 Oct 2011 13:30:39 -0400 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyX8s8vtZ2o0j0aTGmkZGEsN7/zGg== Message-ID: <3B4900E0-5C01-439B-900A-ED562901211F@neustar.biz> References: <619CDADDCCD2B44380834BE8BF6F71414049E2619C@EMV62-UKRD.domain1.systemhost.net> <619CDADDCCD2B44380834BE8BF6F71414049E2635E@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414049E2635E@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BOIVRHPFTJNuOxsluNgNzg== Content-Type: multipart/alternative; boundary="_000_3B4900E05C01439B900AED562901211Fneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:30:50 -0000 --_000_3B4900E05C01439B900AED562901211Fneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Whenever you start work, in the IETF and most standards groups, you need to= start with a restricted goal, or you don't get anything done when it is ne= eded. Sometimes, you have to deal with the fact that the simple goal isn't= as comprehensive as one would like, but it does get you to something faste= r. Our charter controls what we do, and the notion of sharing the spectrum amo= ng secondary (WS device) users was discussed, and explicitly ruled out of s= cope for our first charter. That limits us. If it limits us too much (like we can't really meet anyone= s needs), then we can go to the IESG and request our charter to be expanded= . I don't believe we are at this stage. So, for now, any mechanisms that attempt to share available spectrum among = secondary users is OUT OF SCOPE. We can anticipate future use and make sur= e our protocols and data structures are extensible to meet that need, but a= s of now, this whole subject is out of scope. The way to get these discussions revved up again is to quickly meet our ini= tial milestones (that is, get a database query protocol and data structures= finalized) and then recharter to include this additional scope. Could we therefore please focus our attention on requirements that don't in= clude this notion. Brian On Oct 31, 2011, at 1:02 PM, > > wrote: Peter Thanks, our emails crossed and I have suggested some indications from FCC a= nd IC which might lead to this facility being needed. I think the fact that= US has some databases up and running and implementing the minimum FCC rule= s shouldn=92t restrict the work in PAWS to develop a flexible and innovativ= e protocol that is capable of addressing current and future requirements wo= rldwide. I realise that is an impossible task when regulators are mostly st= ill in consultation mode (or not even at that point yet), but we should rea= d between the lines as much as possible. Regards Andy From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: 31 October 2011 16:51 To: Sago,AJ,Andy,COD R; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Andy, In reference to 2. below, The FCC does not have any rule that a radio rep= ort it's channel use to a DB. There has been no comment/concern about this = in our TVWS database trial. I agree that it is nice to have and could be th= e basis of value added services, but it is not explicitly required. I could= not find any "requirement" in the Canadian proposal either. Regards, Peter S. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 10:39:37 -0400 To: "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case= =85" which might mistakenly imply some preference to this solution, and not= e this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don=92t currently anticipate a fixed IP address or url for a databa= se. Personally I feel a fixed address would have some drawbacks so I didn= =92t include this method in the submission. As you are stating you require = it, I=92m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too =96 at present we don=92t yet have their final list of = requirements. Thirdly, a database operator may require this facility in ord= er to offer value added services. The operators in the UK are currently unk= nown (no but my company could be a prospective database operator, so I am r= equesting this facility. This is certainly within the scope of PAWS (fulfil= ling the requirements of database operators is specifically mentioned in th= e Charter, viz. =93the particular data exchanged between a device and a dat= abase might depend on the ranges of radio spectrum that are to be used, the= requirements of the database operators and their governing regulations, an= d other factors=94). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2=85" [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_3B4900E05C01439B900AED562901211Fneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable andy.sago@bt.com= > <andy.sago@bt.com> w= rote:
Peter<= /div>
 
Thanks, our emails crossed and I hav= e suggested some indications from FCC and IC which might lead to this facil= ity being needed. I think the fact that US has some databases up and runnin= g and implementing the minimum FCC rules shouldn=92t restrict the work in P= AWS to develop a flexible and innovative protocol that is capable of addres= sing current and future requirements worldwide. I realise that is an imposs= ible task when regulators are mostly still in consultation mode (or not eve= n at that point yet), but we should read between the lines as much as possi= ble.
 
Regards<= /o:p>
 
From: "andy.sago@bt.com" <a= ndy.sago@bt.com>
Date:&n= bsp;Mon, 31 Oct 2011 10:39:37 -0400
To: "scott.probasco@no= kia.com" <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subjec= t: Re: [paws] New ind= oor and M2M use cases, revision of DB discovery use case<= /div>
 
<= div>
Scott<= /div>
 
Thanks for your comments on our joint submission. Unfortunately I = am not in full agreement with your position, please see my comments in-line= .
&nb= sp;
R= egards
=
Andy
 
From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] 
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.org<= br>Cc: Fitch,MR,Mi= chael,DES8 R; JuanCarlos.Zuniga@InterDigital.com
Subject: Re: [paws] New indoor = and M2M use cases, revision of DB discovery use case
 
Hi Andy,= Mike & Juan Carlos,<= /o:p>
 
Thank you for p= roviding the I-D. After review I have a few comments.
 <= /span>
<= div>
1. The proposed revision to the database discovery use case d= oes simplify the text and introduces the "listing" method from the UK. Thes= e changes make sense to me. The revision also removes the option for a pre-= programmed address of a trusted database. I believe this is an important op= tion and should remain in the I-D. A possible remedy is to remove  "In= the simplest case=85" which might mistakenly imply some preference to this= solution, and note this to be an option.
 
<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: r= gb(31, 73, 125); ">[Andy Sago] <= /span>The text in our submission mainly = addresses the UK requirements, which don=92t currently anticipate a fixed I= P address or url for a database. Personally I feel a fixed address would ha= ve some drawbacks so I didn=92t include this method in the submission. As y= ou are stating you require it, I=92m happy for it to remain as an option.
 =
=
2. In the Indoor Networking use case, I suggest to remove st= ep 7 which describes updating the database with the selections made by the = master device. I personally see merit in this capability. However, followin= g previous discussions on this mail list, and after review of our Charter, = I believe this step to update the database with information is not within o= ur current scope; I am planning to remove similar steps from other use case= s in the next update. The issue of scope is merely my personal opinion.
 
[Andy Sago] I have to disagree, bot= h with removing this step here and with removing similar steps in other use= cases. Firstly, as I understand it FCC and Canada already require the data= base to know the details of some links (e.g. rural broadband) and this requ= irement could be fulfilled by having the master device report back directly= to the database. The recent 802.22 requirements posted to the reflector al= so ask for this. Secondly, UK may require this facility too =96 at present = we don=92t yet have their final list of requirements. Thirdly, a database o= perator may require this facility in order to offer value added services. T= he operators in the UK are currently unknown (no but my company could be a = prospective database operator, so I am requesting this facility. This is ce= rtainly within the scope of PAWS (fulfilling the requirements of database o= perators is specifically mentioned in the Charter, viz. =93the particular d= ata exchanged between a device and a database might depend on the ranges of= radio spectrum that are to be used, the requirements of the database opera= tors and their governing regulations, and other factors=94).
 =
3. In the M2M use case, would you consider the following re= visions:
 <= o:p>
[First paragraph]
"In this use case, each "machine" includes a white space slave device and = can be located anywhere, fixed or on the move. Each machine needs to have c= onnectivity to the internet and or to other machines in the vicinity. Machi= ne communication over a TVWS channel, whether to a master device or to anot= her machine (slave device), is under the control of a master device. This d= eployment scenario is typically characterized by a master device with inter= net connectivity by some connection that does not utilize TV white space. F= igure 2=85"<= /div>
 
[Andy Sago] Agreed
 =
=
[Step 6]
6. The slave devices fitted to the ma= chines scan the TV bands to locate the master transmissions, and associate = with the master device. Further signaling can take place outside  = ;scope of PAWS to establish direct links among those slave devices that hav= e associated with the master device.
 =
[Andy= Sago] Agreed
 =
[Step 7]
Propose to r= emove this step for same reasons as discussed in Indoor Networking use case= .
 [Andy Sago] Disagree, for same reasons a= s for the Indoor Networking use case.
 
Regards,
=
Scott
 
From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 17 Oct 2011 09:49:34 +0100
To: "paws@ietf.org" &= lt;paws@ietf.org>, Database Device < <michael.fitch@bt.com>= , Juan Zuniga <JuanCarlos.Zuniga@InterDig= ital.com>
Subject: = [paws] New indoor and M2M use cases, revision of DB discovery us= e case
=
Hi Scott, all
 
I-D http://www.ietf.org/id/draft-zuniga-paws-uk= -use-cases-and-requirements-00.txt proposes revision of the database discovery use case, two new= use cases for indoor networking and machine to machine communications, and= a set of requirements that drop out of all the use cases included so far i= n the working document. These especially address the UK Ofcom requirements = as currently known. Also, a definition is proposed for the term =91device I= D=92 which we suggest should be used throughout the use cases and requireme= nts for consistency in place of terms such as =91model ID=92 and =91FCC ID= =92. This Internet Draft is a joint submission from Mike Fitch (BT), Andy S= ago (BT) and Juan Carlos Zuniga (Interdigital). We would welcome comments m= ade to the reflector on these proposals. We are willing to present in Taipe= i if it would be helpful in providing further explanation to the content in= the document.
 
Regards=
 
Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Inter= digital)
 
 
 
____________________________________= ___________
paws mailing list
paws@i= etf.org
https://www.ietf.org/mailman/listinfo/paws

= --_000_3B4900E05C01439B900AED562901211Fneustarbiz_-- From andy.sago@bt.com Mon Oct 31 11:51: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 629FD1F0C8C for ; Mon, 31 Oct 2011 11:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, 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 7SUTuojGfMw0 for ; Mon, 31 Oct 2011 11:51:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id A5A541F0C7D for ; Mon, 31 Oct 2011 11:51:37 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 18:51:36 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.68]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 31 Oct 2011 18:51:36 +0000 From: To: , , Date: Mon, 31 Oct 2011 18:51:33 +0000 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyX7pQo+jafGhkIQQixvo52WqnsKAADANmg Message-ID: <619CDADDCCD2B44380834BE8BF6F71414049E263E2@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F71414049E2634C@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414049E263E2EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:51:48 -0000 --_000_619CDADDCCD2B44380834BE8BF6F71414049E263E2EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Peter, some comments inline (avoiding topics ruled out of scope by t= he Chair): Regards Andy From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: 31 October 2011 16:58 To: Sago,AJ,Andy,COD R; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Some other thoughts on the use cases discussion that this trail is related = to. (https://datatracker.ietf.org/doc/draft-zuniga-paws-uk-use-cases-and-r= equirements/) Peter S. 3.2: indoor networking Step 3: In the US, and probably Canada, there is no requirement for locati= on uncertainty so this may have to be optional or have a default value. [An= dy Sago] Agreed, optional would be sensible. This impacts 4.1.7 step 7: (radio reporting channel use to the DB) is not specified in any of= the regulations we are aware of so this may have to be optional. 4.1.11 se= ems to contradict this statement. 3.3: I can see a general concern with this Use Case from the Broadcasters.= In the simple Master/Slave Use Cases there is a perceived coverage area of= the master, based on it's power etc, which can be calculated into a buffer= to ensure that neither the master or the slaves will interfere with an inc= umbent. However in the M2M case there is the implication of multi-hopping w= hich could dramatically increase the distance of a slave from a master. Unl= ess hopping is limited and the function of hopping is known there is no way= to accurately compute the likely interference from the multi hopping slave= s. [Andy Sago] The key here is in Step 6. "The devices fitted to the machines = scan the TV bands to locate the master transmissions, and associate with th= e master device. Further signalling can then take place to establish direct= links among those machines that have associated with the master device." S= o all slave devices are within range of a master, and the master can expand= the location uncertainty (a method described by Ofcom for the UK case) to = account for the area of coverage that encompasses all the slaves. Only afte= r that, can the slaves talk slave-to-slave. It is implicit that the machine= s (perhaps utility meters) are not going to move far. Potentially mobile de= vices could be required to always maintain contact (listen only) with a mas= ter device, whilst transferring data slave-to-slave, or there could be othe= r mechanisms to detect motion. These are policy issues for the regulator an= d not the domain of PAWS. 4.1: Requirements 10: In most cases the slave does not have location capability so how is it = going to know that it has changed location? I don't know how a master can d= etermine it's coverage area in a way that a slave can resolve this. I also= think this is irrelevant in many cases. If you consider a set of Access Po= ints (masters) in a building a slave should be able to roam around and asso= ciate with any, or all of the Masters without having to go through a channe= l discovery process as all the channels it will use are validated by the ma= sters.[Andy Sago] See comment to 3.3 above. 4.2: Database Most regulators include some requirement that the DB validate or authentica= te a Device before providing it with a channel list. The FCC also requires = that the DB be able to black list specific devices. This implies that a dev= ice may get a "no channels available" message because it is not permitted t= o use either the DB or TVWS. I know you cover security in 4.2, but the impl= ication of failure is no channel list returned to the device.[Andy Sago] A= greed. There might be an "Access Denied" message. Databases might cover pa= rticular specialisms, e.g. rural broadband, so accessing the 'wrong' databa= se might return "Access Denied" if there is no commercial agreement to use = that database, at which point the master tries another database from the Of= com list. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 12:51:15 -0400 To: "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott So Ofcom has confirmed below that there could be a potential UK requirement= , which shouldn't be shut out at this stage. As for providing a reference f= or the US and Canadian requirements, I am hardly the best placed person on = this reflector to comment, but my understanding is that the FCC document on= the Part 0 and Part 15 rules for "Unlicensed Operation in the TV Broadcast= Bands; Final Rule" http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf s= pecifically expects databases may perform additional functions such as "tra= cking active channel use if reported by the TV bands device", hence the PAW= S protocol should enable this. I reproduce below the relevant paragraph: Additional Service Features 73. Decision. Database administrators may perform additional functions besides those required by the rules, such as tracking active channel use if reported by the TV bands device, or sending additional information to a TV bands device to enable it to determine the ''best'' available channel to use. Such functions are not prohibited by the rules, and the ability to add additional functionality could allow multiple database operators to distinguish their services and could be useful in the development of industry standards to enable more efficient spectrum sharing. I'm even less of an expert on Canada, but their August consultation at http= ://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) "To meet = these requirements, each white space device will need to provide data, incl= uding its location, to a database. This data would be retained for a period= of time in order to provide a capability for after-the fact data audits of= suspected interference cases." I think that, when this requirement is full= y unpacked, the data needing to be retained by the database for audit purpo= ses will include actual channel frequency used. Also, they are consulting o= n whether to move future high power Remote Rural Broadband Systems (RRBS) f= rom the current licensed model to use of TV band devices with the geolocati= on database (p.17, "it is anticipated that white space devices could be rea= dily adapted for operation under the current rules for RRBS"). These would = require protection from other TVWS devices to provide a similar service to = existing RRBS, so in practice the actual channel in use would need to be re= ported back to the database. Regards Andy From: Andrew Gowans [mailto:Andrew.Gowans@ofcom.org.uk] Sent: 31 October 2011 16:06 To: scott.probasco@nokia.com; Sago,AJ,Andy= ,COD R; paws@ietf.org Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott/All, I can confirm that Andy Sago is correct in that Ofcom have not confirmed wh= at our final requirements may be regarding the need for a return channel as= a regulatory requirement or not. I would say at this stage there is no har= m in keeping it in the document being taken forward as it seems that it wil= l be within your guidelines if any regulator requires it in the future. I t= ake it these elements can be treated like other requirements that may be re= gion or country specific. I say this in the knowledge that the current prop= osals from Ofcom will require different requirements from that of the US pr= oposals hence there will have to a master set of requirements which will mo= re than likely be reduced to a subset of the requirements dependent upon ea= ch regulatory domain. Best regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.pro= basco@nokia.com Sent: 31 October 2011 15:28 To: andy.sago@bt.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Thank you for your reply. As said, I do favor to keep the possibility for d= evices to update information in the database, my concern is merely to opera= te within our guidelines. You mention below that FCC and Canada require the= database to know the details of some links, are you able to cite a referen= ce? My personal opinion is that PAWS should accommodate all regulatory requ= irements. The updated I-D must be uploaded in a few hours, unfortunately not much tim= e remains to include discussions from the email list in this draft. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:39:37 +0000 To: Database Device >, "paws@ietf.org" > Cc: >, Juan Zuniga > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case.= .." which might mistakenly imply some preference to this solution, and note= this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don't currently anticipate a fixed IP address or url for a database= . Personally I feel a fixed address would have some drawbacks so I didn't i= nclude this method in the submission. As you are stating you require it, I'= m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too - at present we don't yet have their final list of requ= irements. Thirdly, a database operator may require this facility in order t= o offer value added services. The operators in the UK are currently unknown= (no but my company could be a prospective database operator, so I am reque= sting this facility. This is certainly within the scope of PAWS (fulfilling= the requirements of database operators is specifically mentioned in the Ch= arter, viz. "the particular data exchanged between a device and a database = might depend on the ranges of radio spectrum that are to be used, the requi= rements of the database operators and their governing regulations, and othe= r factors"). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2..." [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term 'device ID' which = we suggest should be used throughout the use cases and requirements for con= sistency in place of terms such as 'model ID' and 'FCC ID'. This Internet D= raft is a joint submission from Mike Fitch (BT), Andy Sago (BT) and Juan Ca= rlos Zuniga (Interdigital). We would welcome comments made to the reflector= on these proposals. We are willing to present in Taipei if it would be hel= pful in providing further explanation to the content in the document. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_619CDADDCCD2B44380834BE8BF6F71414049E263E2EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

Regards<= /span>

 

Andy=

 

From: Peter Stanforth [mailto:peter@spect= rumbridge.com]
Sent: 31 October 2011 16:58
To: Sago,AJ= ,Andy,COD R; scott.probasco@nokia.com; paws@ietf.org
Subject: Re:= [paws] New indoor and M2M use cases, revision of DB discovery use case

 

Some other thoughts on the use cases discussi= on that this trail is related to.  (https://datatracker.ietf.org/doc/draft-z= uniga-paws-uk-use-cases-and-requirements/)

Peter S.

 

3.2: &n= bsp; indoor networking 

Step 3:  In the US, and probably Canada, the= re is no requirement for location uncertainty so this may have to be option= al or have a default value. [Andy Sago] Agreed, optional would be sensib= le. This impacts 4.1.7<= /p>

step 7:  (radio reporting ch= annel use to the DB) is not specified in any of the regulations we are awar= e of so this may have to be optional. 4.1.11 seems to contradict this state= ment.

 

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

= [Andy Sago= ] The key here is in Step 6. “The devices fitted to the machines scan= the TV bands to locate the master transmissions, and associate with the ma= ster device. Further signalling can then take place to establish direct lin= ks among those machines that have associated with the master device.”= So all slave devices are within range of a master, and the master can expa= nd the location uncertainty (a method described by Ofcom for the UK case) t= o account for the area of coverage that encompasses all the slaves. Only af= ter that, can the slaves talk slave-to-slave. It is implicit that the machi= nes (perhaps utility meters) are not going to move far. Potentially mobile = devices could be required to always maintain contact (listen only) with a m= aster device, whilst transferring data slave–to-slave, or there could= be other mechanisms to detect motion. These are policy issues for the regu= lator and not the domain of PAWS.

 

=

4.1: Requirements=

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

 

4.2: Database

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

 

<= div>

 

=

From: "andy.sago@bt.com= " <andy.sago@bt.com>=
Date: Mon, 31 Oct 2011 12:51:15 -0400
To: "scott.probasco@nokia.com" &l= t;scott.probasco@nokia.com&= gt;, "paws@ietf.org" <paws@ietf.org>
Subject: Re: = [paws] New indoor and M2M use cases, revision of DB discovery use case=

 

Scott

 

So Ofcom has confirmed below that ther= e could be a potential UK requirement, which shouldn’t be shut out at= this stage. As for providing a reference for the US and Canadian requireme= nts, I am hardly the best placed person on this reflector to comment, but m= y understanding is that the FCC document on the Part 0 and Part 15 rules fo= r “Unlicensed Operation in the TV Broadcast Bands; Final Rule” = http://ed= ocket.access.gpo.gov/2010/pdf/2010-30184.pdf specifically expects datab= ases may perform additional functions such as “tracking active channe= l use if reported by the TV bands device”, hence the PAWS protocol sh= ould enable this. I reproduce below the relevant paragraph:

 

Additional Service = Features

73. Decision. Database administrators

may perform additional functions<= span style=3D'color:#040100'>

besides those= required by the rules, such

as tracking active channel use if

reported by the TV ba= nds device, or

sending additional information to a TV

bands device to enable it to dete= rmine

= the ‘‘best’’ available channel to use. Such<= span style=3D'color:#040100'>

functions are= not prohibited by the

rules, and the ability to add additional

functionality could a= llow multiple

database operators to distinguish their

services and could be useful in t= he

dev= elopment of industry standards to=

enable more efficient spectrum sharing.<= span style=3D'color:#040100'>

 =

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

 

Regards

 

Andy

 

 

From: Andrew Gowans [mailto:Andrew.Gowans@ofcom.org.uk]
Sent: 31 October 2011 16:06
To: scott.probasco@nokia.com; Sago,AJ,Andy,COD R; = paws@ietf.org
Subject: RE: [= paws] New indoor and M2M use cases, revision of DB discovery use case

 

Scott/All,

 

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

 

Best regards

&nb= sp;

Andy  Gowans<= /o:p>

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of <= a href=3D"mailto:scott.probasco@nokia.com">scott.probasco@nokia.com
= Sent: 31 October 2011 15:28
To: andy.sago@bt.com; paws@ietf.= org
Subject: Re: [paws] New indoor and M2M use cases, revisio= n of DB discovery use case<= /span>

&n= bsp;

Hi Andy,

 

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

 =

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

 

Regards,

Scott=

 

= From: "ext andy.sa= go@bt.com" <andy.sago@bt.co= m>
Date: Mon, 31 Oct 2011 14:39:37 +0000
To: Dat= abase Device <scott.probasco= @nokia.com>, "paws@ietf.org" <paws@ietf.org>
Cc= : <michael.fitch@bt.com&= gt;, Juan Zuniga <= JuanCarlos.Zuniga@InterDigital.com>
Subject: RE: [paws] Ne= w indoor and M2M use cases, revision of DB discovery use case

 

Scott

 

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

 

Regards=

 

Andy=

 

From: scott.probas= co@nokia.com [mailto:scott.= probasco@nokia.com]
Sent: 25 October 2011 21:39
To: Sago,AJ,Andy,COD R; paws@ietf.orgCc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com
Subject: R= e: [paws] New indoor and M2M use cases, revision of DB discovery use case

 

Hi Andy, Mi= ke & Juan Carlos,

 

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

 

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

 

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

 

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

 

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

 

3. In the M2M use case, would you con= sider the following revisions:

 

[First paragraph]=

"In this use case, each "= ;machine" includes a white space slave device and can be located anywh= ere, fixed or on the move. Each machine needs to have connectivity to the i= nternet and or to other machines in the vicinity. Machine communication ove= r a TVWS channel, whether to a master device or to another machine (slave d= evice), is under the control of a master device. This deployment scenario i= s typically characterized by a master device with internet connectivity by = some connection that does not utilize TV white space. Figure 2…"=

 

[Andy Sago] Agreed

=  

[Step 6]<= /span>

6. The slave devices fitted = to the machines scan the TV bands to locate the master transmissions, and a= ssociate with the master device. Further signaling can take place outs= ide  scope of PAWS to establish direct links among those slave devices= that have associated with the master device.

 <= /span>

= [Andy Sago] Agreed

 

[Step 7]

Propose to remove this step for same reasons as discussed= in Indoor Networking use case.

 

[Andy Sago] Di= sagree, for same reasons as for the Indoor Networking use case.<= /b>

 

Regards,<= /span>

Scott

&n= bsp;

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 17 Oct 2011 = 09:49:34 +0100
To: "paws@ie= tf.org" <paws@ietf.org>= , Database Device <scott.pro= basco@nokia.com>
Cc: <michael.fitch@bt.com>, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com><= br>Subject: [paws] New indoor and M2M use cases, revision of DB disc= overy use case

 

Hi Scott, all=

 =

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

 

Regards<= /p>

 

Andy Sago (BT), Mike Fitch (BT), Juan Carl= os Zuniga (Interdigital)

 

&nb= sp;

 

 

 


****************************************= **************************************************************************<= br>For more information visit www.ofcom= .org.uk

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

If you have received this e= mail in error please notify the originator of the message and delete it fro= m your system.

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

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

= --_000_619CDADDCCD2B44380834BE8BF6F71414049E263E2EMV62UKRDdoma_-- From peter@spectrumbridge.com Mon Oct 31 12:57: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 7CB5A11E81D0 for ; Mon, 31 Oct 2011 12:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6] 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 5PS45j-16Uzw for ; Mon, 31 Oct 2011 12:57:08 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id B67A811E81C6 for ; Mon, 31 Oct 2011 12:57:07 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 31 Oct 2011 15:59:23 -0400 From: Peter Stanforth To: "andy.sago@bt.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Date: Mon, 31 Oct 2011 15:57:05 -0400 Thread-Topic: [paws] New indoor and M2M use cases, revision of DB discovery use case Thread-Index: AcyYB5WB7CxzohFtQDq9ZDKSBwqr5A== Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414049E263E2@EMV62-UKRD.domain1.systemhost.net> 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_CAD474E81603Dpeterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:57:10 -0000 --_000_CAD474E81603Dpeterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Andy, I understand your P2P use case (3.3) better now and your explanation deals = with my concern. I have to think a little longer on the slave roaming aroun= d a cluster of masters (4.1) as it relates to slaves knowing, or needing to= know, their location. Peter S. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:51:33 -0400 To: Peter Stanforth >, "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Thanks Peter, some comments inline (avoiding topics ruled out of scope by t= he Chair): Regards Andy From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: 31 October 2011 16:58 To: Sago,AJ,Andy,COD R; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Some other thoughts on the use cases discussion that this trail is related = to. (https://datatracker.ietf.org/doc/draft-zuniga-paws-uk-use-cases-and-r= equirements/) Peter S. 3.2: indoor networking Step 3: In the US, and probably Canada, there is no requirement for locati= on uncertainty so this may have to be optional or have a default value. [An= dy Sago] Agreed, optional would be sensible. This impacts 4.1.7 step 7: (radio reporting channel use to the DB) is not specified in any of= the regulations we are aware of so this may have to be optional. 4.1.11 se= ems to contradict this statement. 3.3: I can see a general concern with this Use Case from the Broadcasters.= In the simple Master/Slave Use Cases there is a perceived coverage area of= the master, based on it's power etc, which can be calculated into a buffer= to ensure that neither the master or the slaves will interfere with an inc= umbent. However in the M2M case there is the implication of multi-hopping w= hich could dramatically increase the distance of a slave from a master. Unl= ess hopping is limited and the function of hopping is known there is no way= to accurately compute the likely interference from the multi hopping slave= s. [Andy Sago] The key here is in Step 6. =93The devices fitted to the machine= s scan the TV bands to locate the master transmissions, and associate with = the master device. Further signalling can then take place to establish dire= ct links among those machines that have associated with the master device.= =94 So all slave devices are within range of a master, and the master can e= xpand the location uncertainty (a method described by Ofcom for the UK case= ) to account for the area of coverage that encompasses all the slaves. Only= after that, can the slaves talk slave-to-slave. It is implicit that the ma= chines (perhaps utility meters) are not going to move far. Potentially mobi= le devices could be required to always maintain contact (listen only) with = a master device, whilst transferring data slave=96to-slave, or there could = be other mechanisms to detect motion. These are policy issues for the regul= ator and not the domain of PAWS. 4.1: Requirements 10: In most cases the slave does not have location capability so how is it = going to know that it has changed location? I don't know how a master can d= etermine it's coverage area in a way that a slave can resolve this. I also= think this is irrelevant in many cases. If you consider a set of Access Po= ints (masters) in a building a slave should be able to roam around and asso= ciate with any, or all of the Masters without having to go through a channe= l discovery process as all the channels it will use are validated by the ma= sters.[Andy Sago] See comment to 3.3 above. 4.2: Database Most regulators include some requirement that the DB validate or authentica= te a Device before providing it with a channel list. The FCC also requires = that the DB be able to black list specific devices. This implies that a dev= ice may get a "no channels available" message because it is not permitted t= o use either the DB or TVWS. I know you cover security in 4.2, but the impl= ication of failure is no channel list returned to the device.[Andy Sago] A= greed. There might be an =93Access Denied=94 message. Databases might cove= r particular specialisms, e.g. rural broadband, so accessing the =91wrong= =92 database might return =93Access Denied=94 if there is no commercial agr= eement to use that database, at which point the master tries another databa= se from the Ofcom list. From: "andy.sago@bt.com" > Date: Mon, 31 Oct 2011 12:51:15 -0400 To: "scott.probasco@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott So Ofcom has confirmed below that there could be a potential UK requirement= , which shouldn=92t be shut out at this stage. As for providing a reference= for the US and Canadian requirements, I am hardly the best placed person o= n this reflector to comment, but my understanding is that the FCC document = on the Part 0 and Part 15 rules for =93Unlicensed Operation in the TV Broad= cast Bands; Final Rule=94 http://edocket.access.gpo.gov/2010/pdf/2010-30184= .pdf specifically expects databases may perform additional functions such a= s =93tracking active channel use if reported by the TV bands device=94, hen= ce the PAWS protocol should enable this. I reproduce below the relevant par= agraph: Additional Service Features 73. Decision. Database administrators may perform additional functions besides those required by the rules, such as tracking active channel use if reported by the TV bands device, or sending additional information to a TV bands device to enable it to determine the =91=91best=92=92 available channel to use. Such functions are not prohibited by the rules, and the ability to add additional functionality could allow multiple database operators to distinguish their services and could be useful in the development of industry standards to enable more efficient spectrum sharing. I=92m even less of an expert on Canada, but their August consultation at ht= tp://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10058.html says (p.12) =93To m= eet these requirements, each white space device will need to provide data, = including its location, to a database. This data would be retained for a pe= riod of time in order to provide a capability for after-the fact data audit= s of suspected interference cases.=94 I think that, when this requirement i= s fully unpacked, the data needing to be retained by the database for audit= purposes will include actual channel frequency used. Also, they are consul= ting on whether to move future high power Remote Rural Broadband Systems (R= RBS) from the current licensed model to use of TV band devices with the geo= location database (p.17, =93it is anticipated that white space devices coul= d be readily adapted for operation under the current rules for RRBS=94). Th= ese would require protection from other TVWS devices to provide a similar s= ervice to existing RRBS, so in practice the actual channel in use would nee= d to be reported back to the database. Regards Andy From: Andrew Gowans [mailto:Andrew.Gowans@ofcom.org.uk] Sent: 31 October 2011 16:06 To: scott.probasco@nokia.com; Sago,AJ,Andy= ,COD R; paws@ietf.org Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott/All, I can confirm that Andy Sago is correct in that Ofcom have not confirmed wh= at our final requirements may be regarding the need for a return channel as= a regulatory requirement or not. I would say at this stage there is no har= m in keeping it in the document being taken forward as it seems that it wil= l be within your guidelines if any regulator requires it in the future. I t= ake it these elements can be treated like other requirements that may be re= gion or country specific. I say this in the knowledge that the current prop= osals from Ofcom will require different requirements from that of the US pr= oposals hence there will have to a master set of requirements which will mo= re than likely be reduced to a subset of the requirements dependent upon ea= ch regulatory domain. Best regards Andy Gowans From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.pro= basco@nokia.com Sent: 31 October 2011 15:28 To: andy.sago@bt.com; paws@ietf.org Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Thank you for your reply. As said, I do favor to keep the possibility for d= evices to update information in the database, my concern is merely to opera= te within our guidelines. You mention below that FCC and Canada require the= database to know the details of some links, are you able to cite a referen= ce? My personal opinion is that PAWS should accommodate all regulatory requ= irements. The updated I-D must be uploaded in a few hours, unfortunately not much tim= e remains to include discussions from the email list in this draft. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 31 Oct 2011 14:39:37 +0000 To: Database Device >, "paws@ietf.org" > Cc: >, Juan Zuniga > Subject: RE: [paws] New indoor and M2M use cases, revision of DB discovery = use case Scott Thanks for your comments on our joint submission. Unfortunately I am not in= full agreement with your position, please see my comments in-line. Regards Andy From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: 25 October 2011 21:39 To: Sago,AJ,Andy,COD R; paws@ietf.org Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com Subject: Re: [paws] New indoor and M2M use cases, revision of DB discovery = use case Hi Andy, Mike & Juan Carlos, Thank you for providing the I-D. After review I have a few comments. 1. The proposed revision to the database discovery use case does simplify t= he text and introduces the "listing" method from the UK. These changes make= sense to me. The revision also removes the option for a pre-programmed add= ress of a trusted database. I believe this is an important option and shoul= d remain in the I-D. A possible remedy is to remove "In the simplest case= =85" which might mistakenly imply some preference to this solution, and not= e this to be an option. [Andy Sago] The text in our submission mainly addresses the UK requirements= , which don=92t currently anticipate a fixed IP address or url for a databa= se. Personally I feel a fixed address would have some drawbacks so I didn= =92t include this method in the submission. As you are stating you require = it, I=92m happy for it to remain as an option. 2. In the Indoor Networking use case, I suggest to remove step 7 which desc= ribes updating the database with the selections made by the master device. = I personally see merit in this capability. However, following previous disc= ussions on this mail list, and after review of our Charter, I believe this = step to update the database with information is not within our current scop= e; I am planning to remove similar steps from other use cases in the next u= pdate. The issue of scope is merely my personal opinion. [Andy Sago] I have to disagree, both with removing this step here and with = removing similar steps in other use cases. Firstly, as I understand it FCC = and Canada already require the database to know the details of some links (= e.g. rural broadband) and this requirement could be fulfilled by having the= master device report back directly to the database. The recent 802.22 requ= irements posted to the reflector also ask for this. Secondly, UK may requir= e this facility too =96 at present we don=92t yet have their final list of = requirements. Thirdly, a database operator may require this facility in ord= er to offer value added services. The operators in the UK are currently unk= nown (no but my company could be a prospective database operator, so I am r= equesting this facility. This is certainly within the scope of PAWS (fulfil= ling the requirements of database operators is specifically mentioned in th= e Charter, viz. =93the particular data exchanged between a device and a dat= abase might depend on the ranges of radio spectrum that are to be used, the= requirements of the database operators and their governing regulations, an= d other factors=94). 3. In the M2M use case, would you consider the following revisions: [First paragraph] "In this use case, each "machine" includes a white space slave device and c= an be located anywhere, fixed or on the move. Each machine needs to have co= nnectivity to the internet and or to other machines in the vicinity. Machin= e communication over a TVWS channel, whether to a master device or to anoth= er machine (slave device), is under the control of a master device. This de= ployment scenario is typically characterized by a master device with intern= et connectivity by some connection that does not utilize TV white space. Fi= gure 2=85" [Andy Sago] Agreed [Step 6] 6. The slave devices fitted to the machines scan the TV bands to locate the= master transmissions, and associate with the master device. Further signal= ing can take place outside scope of PAWS to establish direct links among t= hose slave devices that have associated with the master device. [Andy Sago] Agreed [Step 7] Propose to remove this step for same reasons as discussed in Indoor Network= ing use case. [Andy Sago] Disagree, for same reasons as for the Indoor Networking use cas= e. Regards, Scott From: "ext andy.sago@bt.com" > Date: Mon, 17 Oct 2011 09:49:34 +0100 To: "paws@ietf.org" >, Database Device > Cc: >, Juan Zuniga > Subject: [paws] New indoor and M2M use cases, revision of DB discovery use = case Hi Scott, all I-D http://www.ietf.org/id/draft-zuniga-paws-uk-use-cases-and-requirements-= 00.txt proposes revision of the database discovery use case, two new use ca= ses for indoor networking and machine to machine communications, and a set = of requirements that drop out of all the use cases included so far in the w= orking document. These especially address the UK Ofcom requirements as curr= ently known. Also, a definition is proposed for the term =91device ID=92 wh= ich we suggest should be used throughout the use cases and requirements for= consistency in place of terms such as =91model ID=92 and =91FCC ID=92. Thi= s Internet Draft is a joint submission from Mike Fitch (BT), Andy Sago (BT)= and Juan Carlos Zuniga (Interdigital). We would welcome comments made to t= he reflector on these proposals. We are willing to present in Taipei if it = would be helpful in providing further explanation to the content in the doc= ument. Regards Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigital) ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_CAD474E81603Dpeterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Andy,
I understand yo= ur P2P use case (3.3) better now and your explanation deals with my concern= . I have to think a little longer on the slave roaming around a cluster of = masters (4.1) as it relates to slaves knowing, or needing to know, their lo= cation.
Peter S.


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

 

<= p class=3D"MsoNormal">Regards

=  

Andy=

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com] =
Sent: 31 October 2011 16:58
To: Sago,AJ,Andy,COD R; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paw= s] New indoor and M2M use cases, revision of DB discovery use case

 

<= p class=3D"MsoNormal">Some other thoughts on the use cases = discussion that this trail is related to.  (https://datatracker.i= etf.org/doc/draft-zuniga-paws-uk-use-cases-and-requirements/)

Peter S.

 

3.2:   indoo= r networking 

Step 3:  In the US, and probably Canada= , there is no requirement for location uncertainty so this may have to be o= ptional or have a default value. [Andy Sago] Agreed, optional= would be sensible. This impacts 4.1.7

step 7:  (radio reporting channel use to the DB) is not specified= in any of the regulations we are aware of so this may have to be optional.= 4.1.11 seems to contradict this statement.=

 <= o:p>

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

[And= y Sago] The key here is in Step 6. =93The devices fitted to the machines sc= an the TV bands to locate the master transmissions, and associate with the = master device. Further signalling can then take place to establish direct l= inks among those machines that have associated with the master device.=94 S= o all slave devices are within range of a master, and the master can expand= the location uncertainty (a method described by Ofcom for the UK case) to = account for the area of coverage that encompasses all the slaves. Only afte= r that, can the slaves talk slave-to-slave. It is implicit that the machine= s (perhaps utility meters) are not going to move far. Potentially mobile de= vices could be required to always maintain contact (listen only) with a mas= ter device, whilst transferring data slave=96to-slave, or there could be ot= her mechanisms to detect motion. These are policy issues for the regulator = and not the domain of PAWS.

 

4.1: Requirements<= /span>

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

 

4.2: Database

<= /div>

Most regulators include so= me requirement that the DB validate or authenticate a Device before providi= ng it with a channel list. The FCC also requires that the DB be able to bla= ck list specific devices. This implies that a device may get a "no cha= nnels available" message because it is not permitted to use either the= DB or TVWS. I know you cover security in 4.2, but the implication of failu= re is no channel list returned to the device.[Andy Sago] &nbs= p;Agreed. There might be an =93Access Denied=94  message. Databases mi= ght cover particular specialisms, e.g. rural broadband, so accessing the = =91wrong=92 database might return =93Access Denied=94 if there is no commer= cial agreement to use that database, at which point the master tries anothe= r database from the Ofcom list.

 <= /p>

 

From: "andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 31 Oct 2011 12:51:15= -0400
To: "scot= t.probasco@nokia.com" <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.or= g>
Subject: Re: [paws] New indoor and M2M use cases, revis= ion of DB discovery use case

 

Scott

 <= o:p>

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

 

Addit= ional Service Features

73. Decision. Database administrators<= span style=3D"color:#040100">

<= span style=3D"color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">= may perform additional functions<= /o:p>

besides those required by the rules= , such

as tracking active channel use if

reported by the TV= bands device, or

sending additional information to a TV

band= s device to enable it to determine

the =91=91best=92=92 available ch= annel to use. Such

functions are not prohibited by the

rules,= and the ability to add additional

functionality could allow multipl= e

database operators to distinguish their

services and could = be useful in the

=

development of industry standards to

enable = more efficient spectrum sharing.<= /o:p>

 

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

=

 

Regards

 

Andy

 

 

Andrew Gowans [mailto:Andrew.Gowans@ofcom.org.uk] Sent: 31 October 2011 16:06
To: scott.probasco@nokia.com; Sago,AJ,Andy,COD R; paws@ietf.org
Subject: RE: [paws] = New indoor and M2M use cases, revision of DB discovery use case

 

Scott/All,

&nbs= p;

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

&= nbsp;

Best regards

 

Andy  Gowans

 

From: paws-bounces@ie= tf.org [mailto:paws-b= ounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 31 October 2011 15:2= 8
To: andy.sago@bt.com; <= a href=3D"mailto:paws@ietf.org">paws@ietf.org
Subject: Re: [p= aws] New indoor and M2M use cases, revision of DB discovery use case=

 

=

Hi Andy,

 

Thank you for your reply. As said, I do favor to k= eep the possibility for devices to update information in the database, my c= oncern is merely to operate within our guidelines. You mention below that F= CC and Canada require the database to know the details of some links, are y= ou able to cite a reference? My personal opinion is that PAWS should accomm= odate all regulatory requirements.

 <= span style=3D"color:#040100">

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

 

Re= gards,

Scott=

 

From: "ext andy.sago@bt.com" <andy.sago@bt.com>
Date: Mon, 31 Oct 2011 14= :39:37 +0000
To: Database Device <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Cc: <michael.fitch@bt.com>, Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com>= ;
Subject: RE: [paws] New indoor and M2M use cases, revision of D= B discovery use case=

 

 

Thanks for your comments on our joint submiss= ion. Unfortunately I am not in full agreement with your position, please se= e my comments in-line.

 

Regards

 

An= dy

 

=

From: scott.p= robasco@nokia.com [mailto:s= cott.probasco@nokia.com]
Sent: 25 October 2011 21:39
T= o: Sago,AJ,Andy,COD R; paws@ietf.org
Cc: Fitch,MR,Michael,DES8 R; JuanCarlos.Zuniga@InterDigital.com
Subject:<= /b> Re: [paws] New indoor and M2M use cases, revision of DB discovery use c= ase

<= p class=3D"MsoNormal"> 

 =

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

 

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

&nb= sp;

[Andy Sago] <= span style=3D"font-size: 10.5pt; color: rgb(31, 73, 125); font-family: Cali= bri, sans-serif; ">The text in our submission mainly addresses the UK requi= rements, which don=92t currently anticipate a fixed IP address or url for a= database. Personally I feel a fixed address would have some drawbacks so I= didn=92t include this method in the submission. As you are stating you req= uire it, I=92m happy for it to remain as an option.

 

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

 

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

 

3. In the M2M use case, would you consider the following re= visions:

 

[First = paragraph]

=

"In this use case, each "mac= hine" includes a white space slave device and can be located anywhere,= fixed or on the move. Each machine needs to have connectivity to the inter= net and or to other machines in the vicinity. Machine communication over a = TVWS channel, whether to a master device or to another machine (slave devic= e), is under the control of a master device. This deployment scenario is ty= pically characterized by a master device with internet connectivity by some= connection that does not utilize TV white space. Figure 2=85"<= span style=3D"color:#040100">

 

[Andy Sago] Agreed

 

[Step = 6]

6. The slave devices fitted to the machines sc= an the TV bands to locate the master transmissions, and associate with the = master device. Further signaling can take place outside  scope of= PAWS to establish direct links among those slave devices that have associa= ted with the master device.=

 

[Andy Sago] Agreed

&nbs= p;

[Step 7]<= o:p>

Propose to = remove this step for same reasons as discussed in Indoor Networking use cas= e.

 

[Andy Sago] Dis= agree, for same reasons as for the Indoor Networking use case.

<= div>

Regards,

Sc= ott

 

From: <= /span>"ext andy.sago@bt= .com" <andy.sago@bt.com= >
Date: Mon, 17 Oct 2011 09:49:34 +0100
To: &quo= t;paws@ietf.org" <paws@ietf.org>, Database Device <scott.probasco@nokia.com>
Cc:= <michael.fitch@bt.com&g= t;, Juan Zuniga <J= uanCarlos.Zuniga@InterDigital.com>
Subject: [paws] New ind= oor and M2M use cases, revision of DB discovery use case

=  

<= /div>

Hi Scott, all

&nbs= p;

I-D http://www.ietf.org/id/draft-zuniga-paws-uk-us= e-cases-and-requirements-00.txt proposes revision of the database disco= very use case, two new use cases for indoor networking and machine to machi= ne communications, and a set of requirements that drop out of all the use c= ases included so far in the working document. These especially address the = UK Ofcom requirements as currently known. Also, a definition is proposed fo= r the term =91device ID=92 which we suggest should be used throughout the u= se cases and requirements for consistency in place of terms such as =91mode= l ID=92 and =91FCC ID=92. This Internet Draft is a joint submission from Mi= ke Fitch (BT), Andy Sago (BT) and Juan Carlos Zuniga (Interdigital). We wou= ld welcome comments made to the reflector on these proposals. We are willin= g to present in Taipei if it would be helpful in providing further explanat= ion to the content in the document.

 

Regards

&nb= sp;

Andy Sago (BT), Mike Fitch (BT), Juan Carlos Zuniga (Interdigita= l)

 =

 

 =

 

 

<= /span>


********************************= ***************************************************************************= *******
For more information visit w= ww.ofcom.org.uk

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

If you have receive= d this email in error please notify the originator of the message and delet= e it from your system.

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

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

 --_000_CAD474E81603Dpeterspectrumbridgecom_-- From internet-drafts@ietf.org Mon Oct 31 14: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 8B91921F8E40; Mon, 31 Oct 2011 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 qWWaWfHdML09; Mon, 31 Oct 2011 14:03:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2759C21F8E36; Mon, 31 Oct 2011 14:03:42 -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.62 Message-ID: <20111031210342.30470.85068.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 14:03:42 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:03:42 -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 Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt Pages : 33 Date : 2011-10-31 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-01.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-01.txt From scott.probasco@nokia.com Mon Oct 31 14:23: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 F1CF711E8195 for ; Mon, 31 Oct 2011 14:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.307, 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 WgmZIVs1WR31 for ; Mon, 31 Oct 2011 14:23:10 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2626011E81E7 for ; Mon, 31 Oct 2011 14:23:10 -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.4) with ESMTP id p9VLN7bT013689 for ; Mon, 31 Oct 2011 23:23:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 23:23:07 +0200 Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 22:23:06 +0100 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 22:23:05 +0100 From: To: Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt Thread-Index: AQHMmBNGIWSL3+ZyV0m0lP/6i/e03w== Date: Mon, 31 Oct 2011 21:23:04 +0000 Message-ID: In-Reply-To: <20111031210342.30470.85068.idtracker@ietfa.amsl.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 x-originating-ip: [172.19.60.143] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 21:23:07.0349 (UTC) FILETIME=[48683050:01CC9813] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:23:11 -0000 Hi, As shown below the update of the use case & requirements document has been posted. For your convenience, here is a link to the difference between the updated 01 and older 00 version. Regards, Scott & Raj On 10/31/11 4:03 PM, "ext internet-drafts@ietf.org" wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Protocol to Access WS >database Working Group of the IETF. > > Title : Protocol to Access White Space database: PS, use cases >and rqmts > Author(s) : Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt > Pages : 33 > Date : 2011-10-31 > > 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. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases- >rqmts-01.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-r >qmts-01.txt >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Oct 31 14:26: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 3EC0F1F0C3E for ; Mon, 31 Oct 2011 14:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, 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 3q6ytnXJ+LR6 for ; Mon, 31 Oct 2011 14:26:56 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 751291F0C56 for ; Mon, 31 Oct 2011 14:26:56 -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.4) with ESMTP id p9VLQs3r030814 for ; Mon, 31 Oct 2011 23:26:55 +0200 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); Mon, 31 Oct 2011 23:26:54 +0200 Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 22:26:53 +0100 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 22:26:53 +0100 From: To: Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt Thread-Index: AQHMmBNGIWSL3+ZyV0m0lP/6i/e035WWkt4A Date: Mon, 31 Oct 2011 21:26:52 +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.13.0.110805 x-originating-ip: [172.19.60.143] Content-Type: text/plain; charset="us-ascii" Content-ID: <8EBA79AFD185EE4C95B760ADBF3F1B31@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 21:26:54.0119 (UTC) FILETIME=[CF928B70:01CC9813] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:26:57 -0000 http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-= rq mts-01 On 10/31/11 4:23 PM, "ext scott.probasco@nokia.com" wrote: >Hi, > >As shown below the update of the use case & requirements document has been >posted. For your convenience, here is a link to the difference between the >updated 01 and older 00 version. > >Regards, >Scott & Raj > > > >On 10/31/11 4:03 PM, "ext internet-drafts@ietf.org" > wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. This draft is a work item of the Protocol to Access WS >>database Working Group of the IETF. >> >> Title : Protocol to Access White Space database: PS, use cases >>and rqmts >> Author(s) : Scott Probasco >> Basavaraj Patil >> Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt >> Pages : 33 >> Date : 2011-10-31 >> >> 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. >> >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases >>- >>rqmts-01.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- >>r >>qmts-01.txt >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From subir@research.telcordia.com Mon Oct 31 18:11: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 63CED1F0C42 for ; Mon, 31 Oct 2011 18:11: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=[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 8WbzUDkOYCZF for ; Mon, 31 Oct 2011 18:11:39 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9723A1F0C3B for ; Mon, 31 Oct 2011 18:11:39 -0700 (PDT) Received: from [128.96.58.39] (vpntnlA39.research.telcordia.com [128.96.58.39]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id pA11BcP8011486; Mon, 31 Oct 2011 21:11:38 -0400 (EDT) Message-ID: <4EAF474F.2000009@research.telcordia.com> Date: Mon, 31 Oct 2011 21:11:43 -0400 From: Subir Das User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [paws] draft-das-paws-protocol-00.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 01:11:40 -0000 Hello, We have published a protocol framework document. It is currently available at the following ftp site since we missed the -00 draft submission deadline: ftp://ftp.research.telcordia.com/pub/world/Das/ If your browser setting requires a 'login' and 'passwd', please login as 'Anonymous' user and provide your email address as passwd. regards, _Subir